Re: Great SWT Program

In article <c1629f5d-7e3a-4167-8bc3-6952dd1f4e1d@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
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.

I have also shown this to be false, since it is easy to create a
many-input interface that truly sucks.

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.

I didn't, and you didn't. What we did was receive an interface to use
to do a job - we would have no access to its programming.

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.

Since one of the constraints is the skill of the designer, the design
could still be atrocious.

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.

You seem to have misunderstood the concept of computer screens and the
sensory apparatus used to read 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.

Perhaps they should, but that has nothing to do with your claim.

(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.

What we are discussing is what is /possible/, not what has already
been done. Surely, you are capable of debating hypothetical
situations?

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.

What I /have/ said is that you actually /admitted/ to looking at your
keyboard while typing, although not constantly. The impression you
gave was that you do so occassionally, but this remains unclear.

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.

My evidence is your own whining about how inefficient the keyboard is
at routine text editing tasks. In a great many of the cases that have
come up, such whining can only be factual if you are, indeed,
incredibly inefficient at using the keyboard.

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.

Chances are that if a considerably more efficient one exists, it would
have been invented during the typing pool era. Since it wasn't, touch
is most likely as good as it gets or at least close enough.

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!

If all the new keys are essential to using the computer, perhaps this
matters. As it is, I don't need them much and so I don't see them
impacting the equation. This still doesn't mean that having a full
101-key touch equivalent might not be useful, of course.

A system that incorporates them all is, however, going to run into the
tricky problem that not all keyboards have the same layout for all of
these extra keys. The alphanumerics are entirely standardized (making
QWERTY style touch work), and the shift keys are reasonably close to
standard. As for the rest, however, you'd basically have to specialize
on one keyboard type. The computing world just isn't quite ready for
such a system yet.

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.

That paragraph was to everyone else, not to you.

(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

Can I take this to mean that you have now gotten over your dictionary
mania and have begun to accept more creative uses of various words and
concepts?

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.

Only indirectly, and only to trained users.

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

Yes, Microsoft discontinued it (I still get something similar in
Visual Studio .NET 2003 - but it's more like tabbed edit panels than
it is like MDI). This is why you never really know what you'll get
when you're using Word, because older versions will have MDI and newer
will not.

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.

Spoken by the person who cannot even open a new tab to browse
newsgroups in while writing a news posting in the original one . . .

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.

Probably not, but that is neither here nor there. The fact of the
matter is that this has become the norm with modern GUI software and
so it is a significant problem.

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.

I never claimed this - it is a claim of your own invention.

Indeed, emacs has both mouse and graphics support and has survived
this quite well.

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,

I never claimed this. You imagined that I did.

and now claiming merely that they *can*
make things worse *if* someone botches the job. I've never disputed
that,

Excellent.

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.

Of course, the problem you are facing is that we are in actual fact
comparing an exceedingly good text-based interface (emacs in my case)
with mediocre GUI-based ones (notepad, word, etc.). In this case, the
text-based ones win pretty much on walkover for professional use. For
casual use, I would tend to recommend the GUI ones.

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!

Of course it isn't.

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.

Having fewer input options can be a better thing if their design is
better suited for the task than the many input options were. On the
other hand, having fewer input options can be a worse thing if their
design is worse suited for the task than the many input options were.

Of course, what this dispute of yours really indicates, when you don't
dispute "having more input options does not automatically mean lower
productivity"

I do not dispute this.

but do dispute "having more input options is at least as
good as having fewer ones",

Yes.

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.

Or, perhaps it is based on the realisation that it is possible to
completely bollocks up a many-input-option UI design so that it
becomes worse than even a really poor few-input-options design might
be.

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 ***.

You seem to know awful lot about them, and they do seem to be on your
mind all the time . . .

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.

The problem is that modern GUI software isn't actually easier to use
once learned than what e.g. emacs is - it's just easier to learn in
the first place.

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

I shall have to remember this the next time you suggest that it is the
user rather than the software that needs adjustment when the two do
not agree.

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).

And the Windows Explorer, of course. Oh, and Microsoft Word, Excel,
etc.

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.

The implication being that I wanted to read that specification to see
for myself what impact it might have upon the discussion at hand.

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.

Straight out of Twisted's imagined dictionary of Usenet debate
perhaps?

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.

If we were to measure who has written "Liar!" and "Is not" the more of
us two, it is not I who would come out with the highest count.

Guess what, Bent: you've lost the
argument. :P

Sooner or later it is going to sink in that victory by assertion just
isn't going to work out for you.

Cheers,
Bent D
--
Bent Dalager - bcd@xxxxxxx - http://www.pvv.org/~bcd
powered by emacs
.

Quantcast