Re: Great SWT Program

On Nov 30, 6:19 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
All I need to do is show that having more input options isn't
/necessarily/ better in all possible cases, which I have done and you
concede so yourself above.

But it is necessarily no worse, which is all I need to show.

You seem to assume that "not necessarily better" means "why bother?"
-- a typical Luddite attitude, unsurprising in someone who prefers to
use tools he dug up while playing amateur archaeologist to anything
modern. :P

Yes, it is a contrived example, but that is perfectly good enough for
what I'm trying to do.

Which is to erect and then torch a straw man, from the look of it.

Since the software wouldn't be available to you, this would all just
be pleasent dreams, of course.

What are you babbling incoherently about now? Of COURSE the software
would be available to you, because you WROTE it.

Have you lost complete track of the context here?

First we have new hardware capabilities (e.g. graphics or the mouse,
or your ridiculous huge keyboard).

Then we have programmers writing software that may or may not use
those capabilities.

Then we have users eventually use the software.

The added hardware capabilities, all other things being equal, do not
constrain the programmers to write software that uses all of them and
in the most awkward manner possible, the way you seem to be implying
in your straw man argument.

The users can of course pick whatever software they choose for their
computer, as well.

All it requires is for them to be incompetent: They couldn't make a
decent GUI design if their lives depended upon it.

My hypothesis was that they made the best design possible given the
constraints, numbnutz.

Your caps lock is stuck.

No, it isn't. I did that deliberately. I was shouting in your face,
because there seems to be a massive buildup of wax in both your ears.
Or between them.

Anyway, a programmer can easily be an expert in keyboard input design
but completely out of it when it comes to incorporating the mouse.

Irrelevant. Programmers bad at such a thing should program something
else, like the backend engine or something. Or let a widget library
like Swing take care of the detailed handling of the input mechanics,
if possible.

(e.g. hold down right button, move the mouse in a circle, hold down the
left button, move the mouse side to side, release both buttons)

Straw man alert! No GUI app I've used wants mouse inputs this specific
and clunky. There are left and right clicks, double-clicks, and drags,
and that's about it. Hovering can produce extra information but is not
needed to do anything really important as a rule.

[remainder of straw man deleted]

[irrelevancies snipped]

Irrelevant, and false. It may be more efficient than some specific
other typing style (such as the one that you seem to *think* I use
that involves constantly looking at the keyboard),

I never said that you were constantly looking at the keyboard.

You implied that you suspected that I did, a while back.

I have only said that your typing style is atrocious and inefficient.

Without, mind you, any evidence whatsoever to support such a claim
other than that my typing style differs from yours. Arrogant so-and-
so.

In what manner it is so, I have not bothered to speculate.

That you would even need to speculate is itself a good indication that
you have insufficient evidence to conclude THAT it's inefficient.

If there is a more efficient one, it probably involves a different
input device altogether.

You have not shown any evidence that yours is the most efficient
possible any more than you've shown that mine is either a)
particularly inefficient or b) less efficient than yours. All you have
is blanket assertions, which so far as I can tell indicate that you
believe that:
a) your method is perfect -- it is not possible to make it more
efficient without redesigning the keyboard, supplementing it (but not,
apparently, with a pointing device), or doing away with it entirely,
and
b) all other methods are enormously less efficient than your method.

This may be because a) it's true or b) you're an arrogant so-and-so,
but b) seems to be a far more likely explanation.

And all of this is irrelevant to whether emacs' interface sucks,
anyway.

Since most people have no trouble googling to see what the huge typing
pools of the first half or so of the 20th century were using, there is
no need to go around proving to them that touch typing is the most
efficient text input method when using modern keyboards.

I can tell you one thing that the huge typing pools of the first half
or so of the 20th century *weren't* using -- modern keyboards. They
used mechanical QWERTY keyboards with less than half the keys of a
modern one and somewhat different exact size and positioning of the
keys, ones whose keys took more time and pressure to depress and whose
mechanisms could jam from too-fast typing!

[implied insults deleted]

None of the nasty things that you have said or implied about me are at
all true.

I suggest to everyone that they look up posts from Twisted wherein he
writes "... everyone else ...", ponder a bit over whether or not he
actually /does/ refer to the entire human race in his statement, and
finally reflect over whether or not this means that he is calling
himself an "arrogant sumbitch" in the above paragraph.

No, I am calling myself "average", and simply relaying observations,
about how other people type and use computers.

(I looked up "sumbitch" in an /actual/ dictionary, by the way. It's
not there. Your vocabulary betraying you again?)

It's idiomatic; plus it requires an IQ of over 70 or so to actually
grasp the meaning. This naturally means that it will confuse you.
Sorry. :P

Unless, of course, the contained window is maximized within the
application.

There's a double row of maximize, minimize, close buttons. The state
is still visible.

That type of MDI is rarer now anyway; tabs seem to be preferred these
days.

It's so revolutionary, you simply cannot comprehend it,
having clearly not tried it much on the basis of the nonsense you've
been spewing copiously onto usenet lately.

You must have forgotten that I use both Opera and Firefox on a regular
basis.

You claim to do so, but your lack of experience with tabs suggests
that either you are lying or you do not use either browser to its full
potential.

This seems something of an odd way of getting back to a relevant topic.

By ignoring irrelevant fluff? It seems to be a quite natural way. But
then you have a very wacky idea of what's natural, so I guess I
shouldn't be surprised that you don't agree with the rest of the
Western world on what's natural here, either.

Having the option of not being able to use a non-existing shortcut?
What sort of option is that?

No, having the option of being able to use the mouse OR the keyboard,
numbskull.

Except you can't use the keyboard to get to a shortcut that doesn't
actually exist.

The shortcut not existing is your straw man. Nothing about the mere
existence of the mouse compels a programmer not to include a keyboard
shortcut for anything in particular, after all.

I can assure you that if I ever developed an event horizon, the world
(and, indeed, the solar system) would be in a lot of trouble.

Bull. First of all, the planet Earth would be peachy-keen, aside from
a few disappointed SETI types. Secondly, the solar system you live in
would be OK. Your home planet would, perhaps, have been replaced with
a pea-sized black hole, but everything else would continue merrily in
its orbit, unaffected. Mind you, there'd now be the odd gamma ray
flare when an asteroid that would have wiped out your world's alien
civilization anyway hits the hole and gets eaten ... although most
such asteroids now will merely miss, whipping around in a hairpin turn
and flying back out into deep space. (Those things' orbits won't be
the same afterward, but they would have collided with your home planet
anyway.)

OK. I claim victory. End of thread.

Claiming victory over your own imagined straw men again?

No, over your argument that adding mouse support and graphics to a
user interface automatically dooms it to awkwardness.

An application-specific problem and not a valid indictment of the
general concept of the GUI.

I never criticised the general concept of the GUI anyway

Poppy***!

I'm not. I'm only repeating your own earlier claims back to you. If
you now disavow them, I claim victory. End of thread.

What you are doing is [bull*** deleted]

So you *are* repudiating your earlier claims that adding a mouse and
GUI always makes things worse, and now claiming merely that they *can*
make things worse *if* someone botches the job. I've never disputed
that, though I note that it's just as possible to botch a text-mode
interface. Actually, it's easier -- a proper GUI toolkit/API makes you
have to jump through hoops to gum many things up or make them behave
in a nonstandard way, by making them work properly by default; text
mode interfaces basically all seem to be of the roll-your-own variety,
which results in the previously noted massive inconsistencies,
idiosyncratic behaviors, and wonkiness that makes them harder to learn
and (if you multitask much, at least) harder to use. That's ignoring
the limitations of the medium, which make doing a good job of keeping
the user apprised of all relevant state much harder to do, compounding
the above and leading an awful lot of programmers to say "*** it" and
leave the user fumbling around in the dark and resorting to crutches
like tab-completion to save typing instead of being able to use an
item-selection mechanic that obviates the need. (Possible, mind you,
in a curses-type interface; a list of selectable items that do
something when hotkeys are pressed. Possible but woefully
underutilized in favor of having users type the name of the item they
want, e.g. a file, at a prompt whose editing capabilities are wildly
variable from one such app to the next, and sometimes even from prompt
to prompt inside a single app.)

Let's see, then. GUI software suffers by default from:
* Lack of some shortcut keys, because most GUI APIs don't provide any
by default or force the programmer to at least think about associating
one with each command.
While text-mode software suffers by default from:
* Primitive item-selection mechanisms
* Uncommunicative information
* Invisible, salient state the user has to track mentally, duplicating
some of the computer's job
* Unobvious navigation of the UI, typically forcing the user to use
the help, which suffers from the same problem itself, compounding the
user's difficulties, at least for novice users
* A kitchen-sink UI, which doesn't have separate places for separate
user tasks but instead jumbles everything together in one place and
has a single global set of key bindings with every possible user
action, forcing many of them to be long multi-key chords or actual
typed command lines
* The default alternative to a kitchen-sink UI being invisible global
modes to be used to switch among several sets of bindings and their
associated commands. The latter more resembles a GUI app's behavior,
but in much the way that a shrub resembles a mature oak tree more than
a blade of grass does. Having actually different screens corresponding
to different modes, and different PLACES inside the UI, is much more
difficult and very non-default.

So if you're going to criticize a UI style over the default results
you get with a mediocre programming and interface-design job, it makes
more sense to criticize the text-mode style. That it's the older style
that GUI interfaces have, by and large, replaced in the past 12 or
more years is another strong indication of which is generally better.

[calls me a liar]

None of the nasty things that you have said or implied about me are at
all true.

[snip some bull***]

Bull***. I said that having more input options does not automatically
mean lower productivity, and you disputed me.

No, what you said was that having more input options must at least be
as good as having fewer ones

THAT'S THE SAME THING, IDIOT!

Assuming that productivity is the only thing of importance here (so
for example elitist exclusive-club-ness is unimportant), and observing
that more input options does not automatically mean lower
productivity, it follows that more input options does no harm, and
therefore is at least as good. The two are in fact logically
equivalent -- more input options being at least as good likewise
requires that more input options not automatically degrade
productivity.

Of course, what this dispute of yours really indicates, when you don't
dispute "having more input options does not automatically mean lower
productivity" but do dispute "having more input options is at least as
good as having fewer ones", is that you consider something else to be
important besides productivity. That something else can't be
aesthetics, since a text-mode interface is uglier than all but the
most garish GUIs (such as Windows XP with its default theme,
unfortunately). My guess is that it is precisely the elitism factor --
you consider a UI superior the fewer people can use it, as long as
*you* can use it.

I don't consider that to be legitimate. Productivity is the only truly
important consideration, far outshadowing aesthetics (to the extent
that aesthetics doesn't actually damage productivity with, say,
nuisance animation), while elitism-friendliness is an outright
negative.

And now you're relapsing again. You should stay off the drugs.

You lie! I don't use drugs. I don't even use alcohol or tobacco,
nevermind the stronger, illegal ***.

Actually, everyone reading this did, except you;

Speaking for everyone now?

No, merely assuming that yours is the only IQ under 70 hereabouts.

[implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

When someone writes
"The disease being that it was difficult to train people to use the
CLI."
What they inevitably means is that
"The disease being ... the CLI."

This follows rather straightforwardly from the premise and one
additional premise: that the computer exists to serve the human user,
and not the other way around. It then follows that if it's difficult
to train people to use a certain interaction style and other
interaction styles are viable alternatives and easier for people to
use and to learn to use, then the latter interaction style is
superior. Any other conclusion is tantamount to saying that the humans
should kneel before the machine and bend to fit its "needs" instead of
vice versa.

If you are now claiming that humans should bend to accomodate clunky
computer interfaces we know can be improved upon, instead of the
computer being programmed to minimize the degree to which the human
users must adapt to it, then we're done here; we differ on a very
fundamental principle of interaction design and you hold a very
minority position on that principle indeed. You're as much a dinosaur
as the software you prefer to use. Go away. :P

[implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

Again, you really do need to look up "auto completion" some day.

I'm quite familiar with auto-completion, thank you very much; enough
to know that it's a crutch for lack of a proper item-selection UI in
most circumstances where it's used (IDEs and command prompts, where an
open-ended and very large set of valid commands may be typed, excepted
in particular). Most places you want either a menu or list/combobox
type input or you want both (e.g. a combo box with autocompletion, or
a file chooser with a directory listing pane and an autocompletion-
equipped filename input box). (These days you tend to have both
automatically -- typing blind into a file list or listbox tends to
navigate to the first item matching the prefix you've typed. Downside:
it's blind and you can't backspace etc. -- in other words, it's a lot
like emacs' i-search. ;))

[implied insult deleted]

None of the nasty things that you have said or implied about me are at
all true.

One of them was even:
"If so, please name the journal name and number."
which is "arguing" only in the world of Twisted.

The implication being that you think I lied. Of course, I actually did
nothing of the kind.

One more time for the dim-witted: a lack of meaningful argumentation
from you means that you've conceded a point

If only the world played by your rules, eh?

Those aren't *my* rules, they're general rules of debating. Responding
to cogent arguments with things that amount to "Is not" or "I think
you're lying" with no real reasoning and zero evidence is a sign that
you've lost the argument. Guess what, Bent: you've lost the
argument. :P
.

Quantcast