From: Peter Flynn <peter.nosp@m.silmaril.ie>
To: help-gnu-emacs@gnu.org
Subject: WYSIWYG and usability (was: Re: Rapidly navigating buffers using search
Date: Thu, 08 Jul 2010 23:11:56 +0100 [thread overview]
Message-ID: <89n0pcFte4U1@mid.individual.net> (raw)
In-Reply-To: <189683ce-87e4-40ba-ab73-03a223a98f64@y4g2000yqy.googlegroups.com>
bolega wrote:
> On Jul 8, 3:36�am, David Kastrup <d...@gnu.org> wrote:
>
>> In a way, it is a losing battle. �People expect software to just work
>> without reading manuals. �95% of all Word users, for example, create
>> their documents by mostly visual manipulation of their text without
>> having a clue about underlying structures like references, style sheets
>> and so on. �The result is unmaintainable crap, but they would not know
>> better. �Word tries keeping up in this battle of computer illiteracy by
>> doing things like enumerations, styles and so on "automagically",
>> second-guessing the user, and the user tries second-guessing Word in
>> order to get around that.
>>
>> It is an escalation of mutual cluelessness. �The more userfriendly a
>> piece of software becomes, the more this becomes a problem for
>> _competent_ people willing to learn about their tool. �At least Emacs is
>> at its heart and in most of its modes a WYSIWYG system with regard to
>> the actual file contents: regardless of the crap people do, what ends up
>> on disk is that what they see on their screen.
>>
>
> Rare pearls of wisdom ... from DK.
Actually, DK posts a lot of wisdom, but not all is as quotable as the
above :-)
> The new interface of office 2007 with tabs instead of pull-down menu
> is a lot better in terms of visual throughput.
I'm not familiar with that term. The ribbon is an experiment in
interface usability (for doing which, Microsoft is to be congratulated,
regardless of the outcome, and regardless of whether you think the
ribbon better or worse than the old-style menus). Unfortunately it is
based on the tyranny of the majority: it's fine for the unthinking user
that David describes above; it is almost certainly suboptimal for his
"competent user".
> A wysiwig editor with a good markup or definition language can go a
> long way to educate the user about the underlying features while at
> the same time providing user-friendly convenience.
The majority of users don't want to be educated about underlying
features, or indeed about anything outside their field. They just want
the system to produce what *they* *believe* to be right, whether it
actually is right or not. As far as they are concerned, if it looks
pretty, it's right. The fact that it may be unusable, obsolete within
days, unreadable, or whatever, remains forever beyond them (oddly, even
when they have to pay to have it put right afterwards). Fortunately,
most of the material concerned is transient, ephemeral, or simply
unimportant.
However, in the middle (between those users and the "competent user")
there will be users willing to learn how to do it right and avoid
mistakes and unnecessary expense. But my own research is showing that
these users do still insist on a synchronous typographical interface
(what they call WYSIWYG, even when it's not, quite). What I am
attempting to measure is how far you can go towards retaining the visual
manipulation of the text before the interaction descends below the bar
of mutual second-guessing that David describes.
> Things are certainly progressing in this direction.
Yes, slowly.
> I have not used LyX but I have heard that it is wysiwig with the
> option of viewing code in various representations.
It's near-WYSIWYG. They describe it as WYSIWYM (Mean; implying conscious
intent). For users in my middle group above, who require Instant Textual
Gratification [tm :-], it's a valuable tool in that it has made it
clearer where some of the boundaries lie.
///Peter
--
(Followups set to c.t.t)
next prev parent reply other threads:[~2010-07-08 22:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 6:43 Rapidly navigating buffers using search Jonathan Groll
2010-07-07 6:52 ` Aidan Gauland
2010-07-07 6:54 ` Thierry Volpiatto
2010-07-07 7:40 ` Qiang Guo
2010-07-07 8:01 ` Jonathan Groll
2010-07-07 8:45 ` Andrea Crotti
2010-07-07 9:33 ` Deniz Dogan
2010-07-07 10:25 ` Jonathan Groll
[not found] ` <mailman.11.1278498387.2272.help-gnu-emacs@gnu.org>
[not found] ` <9dc07ed9-f6f1-4ac5-949a-5b97368cc32a@n19g2000prf.googlegroups.com>
2010-07-08 2:28 ` despen
[not found] ` <87mxu22rbc.fsf@lola.goethe.zz>
2010-07-08 17:59 ` bolega
2010-07-08 22:11 ` Peter Flynn [this message]
2010-07-08 20:42 ` despen
2010-07-09 21:18 ` Fixing antediluvianisms in Emacs' UI Ilya Zakharevich
2010-07-10 14:22 ` Pascal J. Bourguignon
2010-07-09 21:39 ` Rapidly navigating buffers using search Ilya Zakharevich
2010-07-10 18:13 ` Xah Lee
2010-07-10 23:25 ` B. T. Raven
2010-07-11 4:47 ` Xah Lee
2010-07-11 13:31 ` B. T. Raven
2010-07-11 16:13 ` David Kastrup
2010-07-11 21:58 ` B. T. Raven
[not found] ` <873cd6b9-8a85-478f-9943-c3ce09eb62c6@n8g2000prh.googlegroups.com>
2010-07-11 21:50 ` B. T. Raven
2010-07-10 21:01 ` Uday S Reddy
2010-07-07 10:54 ` Aidan Gauland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89n0pcFte4U1@mid.individual.net \
--to=peter.nosp@m.silmaril.ie \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.