SEUL: Thoughts on UIs and LP's requirements

[John Munoz <jmunoz@nospam.mho.net>]

Jay Bloodworth wrote:
snip....
> One thing we also need to consider is desktop/network integration.
> Netscape and Microsoft are both making big promises in this department.  I
> know that some GUI file managers already offer transparent access to
> remote files via http or ftp.  We could probably come up with lots of
> other interesting ways to integrate the internet into the desktop.  This
> may seem a little frivolous, but I think it's going to be the next big
> thing and I think we should encourage it wherever we can.

Very important if the interface is to be intuitive.  Reuse metaphors as
long as they make sense.  I can think of no major reason to
differentiate a local file and a file on a ftp server.  Why does one
have to access one through file manager and the other through telnet or
a browser?  This is one good area to simplify.  At work, we use an
automount daemon for on-the-fly access to the shared filesystems.  This
is nice and slick, but not seul worthy.  You need to know the name of
the directory before you can switch to it, and it does not show under
the mount point with the usual ls.  There must be a better way to
implement this.

> 
> These are just some random thoughts to kick off the discussion.  I think
> we need to hear from everyone who has an opinion, especially people who
> have training and experience in HCI.  I suggest we stay away from thinking
> too hard about what apps might solve some or all of these problems right
> now.  Lets just figure out what we need.  Then we can figure out how to
> get it.
> 

This is an excellent suggestion, both for this particular topic, and for
the project in general.  Requirements (wish-list) first, implementation
later.  Don't do now what you can safely postpone till later is another
way of saying this.  We need to gather all requirements, and pick a
small, manageable set to implement for ver 1.  Put the rest on the back
burner, but make sure we think about what we need to do now to support
them with ver 2 so that we can get to ver 2 from ver 1.

Unfortunately, I think UI (of SEUL design)should be version 2.  Making
some scripts and config for an existing UI would be manageable, but not
a ground-up redesign.  I think loopback filesystem will be harder than
some think, and if so, should be ver 2 also.  I think  version one
should focus on the first large problem, ease of install.  I know fdisk
can be intimidating, but with a little guidance, most will be able to do
it. 

New Mail .....

Luka (Peter) Wrote ..
>> Also important to usefulness is a GOOD online help system.  ...snip

Yes.  This is the main problem I have with most curses installs:  If a
help window were available during fdisk to make suggestions, give
advice, etc, a child could do it safely.  This is hard (Not impossible
though) to do with curses.  A windowing system makes this incredibly
easy to implement...
  There should be some kind of graphical interface (with help) to
syslogd,  If only an icon to start a window displaying them in some
config folder or menu.

>> get harder.  However, stability in the final release is still just
>> as important as the addition of the features for which SEUL was created.

>Erik Walthinsen <omega@aracnet.com> Wrote:
>This is why testing (pre-alpha, alpha, beta, pre-release) is *extremely* 
>important.  At the very least we need to have a complete regression suite 
>(which is where tags/hooks might come in again, allowing the regression suite 
>to have UI-level control over the application).  As it happens, I work in QA, 
>so I have an idea how these things work... ;-)

Ditto.  Compiled in hooks (removable after test?) will greatly enhance
ability to bulk automated testing.  A test tool may not be deliverable,
but should be very high on the list of priorities.  The key to good
testing is good specification so that the tester can tell the difference
between a "feature" and a defect.  Linux has many features, and many
annoying features.  We must carefully define the features that will make
it to a SEUL users desktop, and exclude the rest.  The more packages and
the more features, the harder to document, the harder to configure,
understand, and the harder to test thoroughly.

WE MUST LIMIT SCOPE.  We should also try to pick one or two mainstream
packages for each category to limit the complexity of the distribution. 
Less is better when you are overwhelmed, as I often am when trying to
decide what to install. 

PS Hope someone posts a mini-howto or pointers to TFM (the fine manuals)
for the irc channel- never used one.  

-- 
John Munoz:  jmunoz at mho.net. Remove nospam from Reply address, or
change at to @  No unsolicited ads please send spam, get added here:
alfoster@llv.com glen.quantc.com completefree@hotmail.com Support the
Anti-Spam bill.  Join at http:/www/cauce.org/
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------