Re: Great SWT Program

On Dec 11, 5:43 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
I've not seen any evidence to support a claim that archaic tools are
"more efficient once you're proficient with them" as Bent, especially,
has claimed.

For a fair comparison, we need someone who's proficient with both sets
of tools, or a neutral observer to watch people on both sides of the
debate.

We seem to have neither, although arguments from first principles
strongly suggest that more modern tools are superior.

Yes. Recently. I'd really categorize it more as "perhaps these
things aren't as awful and limiting as I'd thought", plus a slightly
heightened awareness of how some of the ways I currently do things
could stand improvement.

Modern tools are a giant leap forward in terms of making it easier for
users to know what to do or what they can do and how to do it. But I
have little doubt that there is still room for improvement, perhaps
even for as much additional improvement as the amount that has
occurred already.

One issue seems to be that in a certain sense the SAME OLD PROBLEM
persists: keyboard shortcuts aren't always obvious. Menu items that
indicate a corresponding keyboard shortcut help, but right-click-menu
functions and other functions absent from the main menus or accessible
only via a dialog box function that way tend to have no visible
shortcut key information. The major difference is that you can still
get things done without the keyboard shortcuts. It may seem clunky and
awkward though. It may be red-light syndrome. Ever notice that you
notice all the red lights on a car trip but none of the greens? Only
the red ones stopped you. A user using a GUI app may notice something
being tedious when repeating the use of a menu command or similarly. A
user using a text-mode app won't notice anything in the corresponding
circumstance -- they'll have completely failed to do whatever it was
because they don't know of ANY way to do so. So they find some other
app to use, and notice tedium using a GUI app to do it. Or they summon
an expert to tell them how to make the text app do it. Or they just
decide the text app is so primitive it's entirely missing the feature
and find a workaround, some alternate way to achieve their larger
goal. Or even give up on that. They only notice mouse-associated
awkwardness with the GUI app however. The text app was worse, but its
deficits may not have been as *noticeable* if the user didn't
specifically think of the feature they wanted and couldn't find in it.
Red lights noticed; apparent absence of a more direct road between A
and B not noticed. Bushes and terrain conspiring to hide the turnoff
onto that road also not noticed.

But here we really have the crux of the debate, don't we? On one
side we have tools designed for a small market consisting of people
who are willing to invest some time up-front in learning a tool
if it pays off in ease of use later.

I don't imagine "ease of use" and "emacs" ever belonging together in
one sentence, except for this one. :P Expertise may get you past its
quirks and lack of a self-documenting UI, but it won't get you past
the various tunnel-vision issues endemic to text mode, nor the lack of
true rapid transit capability as afforded by scrollbars in GUI
applications. The foregoing also applies to vi, of course.

It's certainly
not impossible for the latter to also be expert-friendly, but
it's not at all obvious to me that that's usually a design goal,
or that it's met if it is.

Define "expert-friendly". The things characterized sometimes as such
each tend to have some mix of the following traits:
* More able to be puppeted by other processes.
* Novice-hostile.
* Mouseless.
* Feature-rich.
* With internal automation tools.
* Extensible.
* Text-mode.
* Eschew use of the right half of the keyboard AND use of the mouse.
* Remotely usable from primitive hardware terminals.

Which of these can we cross off? Let's see:
* Feature-rich. Various fancy text editors for Windows exist. Eclipse
exists. Word has a ton of complex features. Photoshop. Yet somehow I
have the feeling that you and Bent will consider these not to be
expert-friendly.
* With internal automation tools. Word has such too. And Photoshop.
And some Windows text editors.
* Extensible. Eclipse certainly is.
* Support for external automation. AFAICT, both vi and emacs lack
this; scripting text manipulation tends to be done with sed instead.
But you seem to consider vi and emacs expert-friendly.
* No mouse; no GUI. Bent seems to like GUI variants of emacs, even if
he hates everything else with mouse support ever coded by man.
* Right half of the keyboard eschewed. Neither of you seems to mind
some apps that have working arrow keys, though you don't seem to care
for actually using them, inexplicably.

The key characteristics that make something "expert-friendly"
therefore appear to be some subset of:
* Support for remote use from ancient hardware no-one uses anymore
* Novice-hostile.

The first one doesn't seem important, which leaves the second.

And speaks volumes about the motives of nearly everyone participating
in this thread that isn't named bbound, nebulous, or twerpinator.

Well, it *might* just be that "expert-friendly" means "gives a
challenge to people who love a challenge", but then wouldn't you move
on after mastering each one? Those that stick with one seem likely to
have the other plausible motive here: some sort of credential that, at
least in their own minds, gives them some justification to look down
their noses at the masses. :P

Of all the above things, only ONE is not (in theory) GUI-specific: a
system-wide clipboard. (In practise, it does seem to only be found in
GUI environments, for whatever reason.)

I guess it depends on your definition of "system-wide" -- it
seems to me that "screen" provides something that functions as
a clipboard

Oh. That awful thing again? Screen's "clipboard" is to a proper,
Windows-style clipboard as Homo habilis is to H. sapiens. :P
.

Relevant Pages

  • Re: MacUpdatePromo
    ... easy way to know which app will work which way. ... so users are supposed to know all GUI guidelines and understand the ... when they close a window. ... them to quit. ...
    (comp.sys.mac.advocacy)
  • Re: 1stPMTry.EXE
    ... Adding a GUI itself isn't important, ... method instead of a table with a few records and a scrollbar? ... Text entry field for the next, followed by a checkbox and whatever you ... The way the underlying "remarable" app works may be interesting, ...
    (comp.os.os2.programmer.misc)
  • Re: Can ooRexx, Regina and Reginald coexist?
    ... I pretty much agree with your point of view, but only as a programmer. ... Faced with an app with one GUI which I understood I'd hope I could set it up ... However I wouldn't expect a non-programmer to be able to take a reginald ...
    (comp.lang.rexx)
  • Re: Getting stuck
    ... OpenVMS 7.3-1 + Oracle 8.1.7.4 ... > The app was developed here at Mitre, so we are the software provider. ... > uses an X-windows feature which I believe is called "overlay bit-planes". ... > breaks on DECW 1.2-6 and 1.3-X because I tried it. ...
    (comp.os.vms)
  • Re: app with standalone gui and web interface
    ... > and separately creating a gui for the ... (for the wxPython version). ... installed could access the application as if it was a desktop app. ... fetch the same wxwml source, convert it into html/xml and send that to ...
    (comp.lang.python)