sxemacs-devel
[Top] [All Lists]

On usability (draft) [was: Our first bug report...]

From: "Johann 'Myrkraverk' Oskarsson" <johann@xxxxxxxxxxxxxx>
Subject: On usability (draft) [was: Our first bug report...]
Date: Mon, 27 Dec 2004 10:30:38 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)
Hi,

I think I'll take the time to write a bit on usability, becouse the
term "user friendly" is highly misunderstood.  I think we can safely
blame Microsoft for that.

The term "user friendly" is supposed to mean "an interface on a
device, for use by humans, that makes it's usage easy" and that's the
definition I use.  Most people mistake it to mean "newbie or idiot
friendly" but that's not the meaning I use.  For emacs, it means "text
editing expert friendly".

Yes, the learnign curve for emacs is steep, but once there, it's quite
intuitive.  I've been able to guess behaviour many people on #emacs
are (or were) quite unaware of.  (I'm talking about C-u M-x
unload-feature vs. M-x unload-feature -- yes, I correctly *guessed*
the meaning of C-u before I even read the docs)

But there are still many "usability issues" to fix.  And I think most
of them fall under "can (sx)emacs do X without writing lisp?"  Finding
out whether and how should not be a herculean task, which in my
experience is quite often the case.  Not all users know or care to
learn lisp -- I didn't until I needed my window number mode.  Until I
made it, more experienced lispers didn't think it could be done.  M-x
customize helps, but it goes only so far.

Another issue on usability, which we are determined to fix, is the
lack of multithreading.  That makes emacs quite slow on occasions, and
hinders work.  That is a "usability defect".  There are lots of issues
that makes emacs slow and sometimes bloaty, we need to find these
defects, order them (imo) according to "usability severity" and fix
them in that order.  Note: something we should plan on doing
throughout next year or so, this is not something that should be done
last century.

One such issue is the lack of features to enable gnus (or any other
mail reader) to create efficient mbox handler.  There is no need to
keep the entire mbox in memory, it should be sufficient to read in one
message at a time from an index file, and append newer messages
without reading in the entire mbox.  AFAICT, this cannot presently be
done in lisp.  In this case, the usability defect is the lack of
low-level file handling in elisp.

                                 ***

There's more I wanted to say, but I'll leave it to later.  I mean this
as a draft for an article to appear on the website soon next year.

There was some stuff I want to respond to Steve's comments but I'll
leave that to later too.  So *snip* ;)


Johann

-- 
This line is left blank intentionally


<Prev in Thread] Current Thread [Next in Thread>