Jules Richardson wrote:
William Donzelli wrote:
How much
has the sales side changed? I mean, I suspect for a typical
user just
doing some word processing etc., a simple bitmapped display is fine -
they
don't *need* the high speed of a card that has a lot more features.
People, including me, want some sort of polish and shine to
applications.
OK, I'm sitting here staring at a GUI that has faded menu bars. Now I
don't *need* those - I'm not going to suddenly find it hard to use an
application if that effect were to disappear. Yet someone's decided to
code them in anyway, increasing disk footprint, memory footprint, and
display redraw time unnecessarily.
Exactly. But, moreso, it also decreases reliability. How often
do we see the same "buffer overrun" bugs creeping into code?
Wasn't OO design, C++, "design by contract" supposed to BURY
all of those little problem issues in a way that would make
them go away FOREVER?? I.e. shouldn't classes take care of
the details of pushing/appending bytes to a buffer so the
developer doesn't have to *count* them??
Also, I think people fail to realize how much faster their machines
*are* because they keep piling on fatter and fatter bloatware.
Does KDE *really* need to be that big??
My favorite text editor (including emacs) is Brief (for DOS).
I take out version 1.1 and run it on a 400MHz machine and it
*flies*. I can't even imagine what it would do on a 2GHz box!
Yet, it does everything I want, runs as a text console (though
uses "line graphics" for the frames of it's "windows"), etc.
Shame Borland never rereleased it after they bought it
(or, better yet, open sourced it!)
That's the sort of stuff I'm talking about -
there's an awful lot of
extras thrown into modern software that just isn't required, and even
more that isn't required *all the time*.
I don't have anything against a well thought out UI - but so often
modern software seems to be about adding frills, or rolling several
applications into one and increasing bloat that way when not all users
want everything that's in the bundle.
Yup. Like constantly telling me I misspelled something instead
of letting me ASK you if I've misspelled anything (or, compromise,
*remind* me to ask you...)
This is
something that most hardcore computer people do
not understand. The polish and shine are the things that take up the
computing resources, and generally make using the machines a bit more
pleasant.
See, it doesn't matter if my menus are a single colour or 523 shades of
grey. It's a tool, not a work of art. Providing it's easy to use with a
little learning, I'm happy.
Exactly. The "polish and shine" *quickly* fade.
In the 80's, a friend was doing video [arcade] game design. I
recall reviewing a pre-alpha copy of his game and being wow'ed
by one of the effects. A few minutes later, when the effect should
next have appeared, I was disappointed that this second instance
wasn't anywhere near as spectacular as the first.
I pointed that out to him.
He replied that it was deliberate. The effect had random elements
in it to ensure that it didn't appear the same each time. This
was puzzling: "Why not put out your best effect EACH time?"
He commented that folks get used to it and then it loses any
impact. OTOH, if really great effects appear only occasionally,
then, when they DO appear, they get noticed.
Sort of like wondering why the fireworks show doesn't have
the same intensity as the finale ALL THE TIME! :>
How many people TODAY look at images of crumpled paper flying
into a wastebasket and go "Ooooo.... Ahhhhh...."?
Printers are a case in point too - a parallel port
does that job just
fine,
yet it's hard to find a machine that doesn't have more complicated USB
interfaces on it, and a printer's now expected to use that.
I suspect one reason for this (and a big one as well) is that a USB
printer is probably cheaper to make. Most of the cost is in the cable
and sockets, and clearly the USB stuff wins there.
It's perhaps cheaper now that so many printer manufacturers have gone
down that route. But the level of complexity of a point-to-point
parallel system must be a lot simpler than a serial bus, surely?
USB will see more attention in the future (than the parallel port)
-- so, "hitch your horse to USB" seems to make sense to manufacturers.
I started designing a product and "settled" on USB simply because it
would let me get by with a *single* connector -- and, I could use
that same connector to charge the batteries in my product! A *big*
advantage when you are designing something that must be small,
portable, lightweight *and* still have some flexibility with
the I/O's.
I've since decided that even USB is too limiting and am moving the
implementation to a BT stack. The cost of the radio offsets the
costs of the connectors, cables, etc. and is slickernsnot.