Re: SEUL: White paper (part I)

[Erik Walthinsen <omega@aracnet.com>]

Oh boy, this is going to take some time...  ;-)

> PROJECT GOAL
> (a.k.a "Who is the end user and what does he have to do with us?")
> 
>  <begin mission statement-type thing>
> The Simple End User Linux (SEUL) project, plans to create a distribution
> of linux which is simple enough in its interface to allow an "end-user",
> a person with no major expertise in programming or system hacking, to
> install it, and get it to do useful things, while running in a stable and
> reliable manner.
>  <end mission statement-type thing>
Good, though I wouldn't use "no major expertise", since that sounds like they 
should have *some*.  Maybe "little or no expertise".

> The exact target user has not yet been fully nailed down.  (See mail
> archives for attempts at it.)  Not much is assumed for the purposes
> of this document, beyond the above statement however.  It is assumed
> that the end-user is not completely clueless, but the exact skill
> threshhold is under debate.
Exactly.  I'll try to find them and post them on the web somewhere.

> Here, I will consider anyone who can install and operate a non-linux OS
> to be targetable.
Probably the best classification I've seen so far.

> Someone who is _absolutely_ only interested in buying
> a system preinstalled (or otherwise having someone else do all system
> administration), regardless of which OS is in use, is not in the target group.
> This person's dealer or other system installer, however, _is_ a target.
As Juhaha mentioned, there's already some commercial interest from this front, 
and I think we should try to get them involved ASAP for design help.

> diversity in thought (though within the above bounds), will keep the project
> on a course tending toward widespread usefulness.
Yup.

> So... this categorization includes a lot of people!  Thus having a large
> enough market to care about will not be considered here.  What will
> be focused on instead is just how far we can go to meet the needs of that
> group before our goals become technically unfeasible.  Given the design
> plan which follows, it seems that we should be able to go quite far,
> actually.  If it turns out that a lot of things have to be changed,
> and it seems that we may be losing much of the above target user group,
> then the project should be re-evaluated in this same form, to make sure
> there is still enough of an audience left to justify the project, and
> to restate the definition of our "end-user" and continue development
> based on the new project goal statement.
Yup.  Gotta stay dynamic.  Static goals are what kill large corporations, 
imagine what they'll do to a group of 100+ volunteers worldwide...

> TOP-LEVEL PROJECT OVERVIEW

> The runtime system may be as little as a friendly hello on first startup, or a
> full-blown off-the-wall distribution unlike anything ever seen before.  (Most
> likely something in between, of course.)
We'll be starting out at the very simple end and working our way up.  We'll 
have the killer front-end to abliterate all other UIs soon enough, but not for 
1.0.

> The Installation System:
>  + should be as non-destructive as possible
>    current installs tend to be a bit dangerous, and thus scare off
>    a lot of potential users.  this is the number one gripe i hear
>    from people who haven't installed linux, and i also hear complaints
>    about it from people who do use linux (fips'ing win95 tends to suck).
This will easily become a project in itself.  Creating a system that will do 
whatever UMSDOS/VFAT/loopback and partitioning stuff intelligently while 
making it safe for the average user (as defined above) is no simple task.

>  + should provide different levels of help depending on the exact user.
>    the min/typical/custom install options fit in as an aid to solve this.
>    also, providing extra help, or at least pointers to help anywhere that
>    it could be required is essential.  do not leave the user stranded.
>  + good UI.
>    face it -- the UI is what makes or breaks a product in today's
>    world.  (ask me for references if you must.)
>    This does not mean we need a full-blown X install.  It just means the
>    install must look and FEEL (mouse-lovers can mouse, typists can type)
>    good and solid.  The stability thing may also be considered a reason
>    to discourage running X at this stage.  At any rate, this stuff has to
>    all be balanced in the end with the goal of a "good UI" in mind.
These two are closely related, of course.  Avoiding making the user feel too 
stupid or too smart for the installer will take some work.  A help system 
should be implemented, which eventually could be set up to almost walk the 
user through the install process.  More later on that one.

As far as a (G)UI for the install, we could use what RedHat does (if anyone 
noticed...)  When you tell it you're doing a CD, hard-disk, or NFS install, it 
doesn't need the second disk.  Know why?  It uses the install medium to get 
the files that are normally on the supp.img disk.

How about we do a X install if installing from a medium with enough space to 
store it, and do a custom graphical install otherwise.  Or maybe not.  Such an 
undertaking would hinge on the availability of a library that allows us to 
write cross-environment (SVGAlib/X) programs.  At least we don't have too many 
demands on the windowing part of it.

>  + consideration: space
>    on thing to consider as a restriction on us in this system is
>    that of space on the installation medium.  the actual medium has not
>    been etched in stone yet, but this will remain an issue.  floppies
>    are self-explanatory.  cd's help solve the space problem, but at
>    the cost of some compatibility and $$.  in the case of net-install,
>    the space issue equates with bandwidth, and transfer costs.
CD's are available in large quantities for a little over a dollar apiece.  A 
bunch of duplicated floppies would easily cost more than that.  As far as 
compatibility, as I mentioned before, the number of drives that are still in 
use that aren't supported by Linux can be counted on one hand.  In my opinion, 
CD should be the primary distrib medium, with floppies second.  Most network 
installs can be done as easily as a CD install once you have the thing 
mounted.  In the case of a slow net install, we should give them a choice 
between X and the graphical version.

> The Runtime System:
> Specific usefulness features are dependent on the user.  Common things
> are games (yes - many people value games a lot), probably a word
> processor ( wordprocessor != emacs ), and many other apps... all of these
> are dependent on the user for exactly what is desired, but a certain base
> set of these end-user-targeted apps should be offered for excessively
> quick, easy installation, early on, and thus their proper integration
> should be supported (to some extent) directly by the SEUL project.
> I've done a bit of casual surveying of our potential users myself, and games
> and wp's are high on the lists of home users.  Business users care a lot
> about networking and client-server services.  Also people in general are
> more commonly net-connected and need it supported through simple
> net configuration applications (for modem and ether, for both static and
> dynamic configurations).
> 
> Also important to usefulness is a GOOD online help system.  Supporting
> online help for every app out there would be simply ludicrous for us to
> take on.  However, providing some form of a well-designed help system for
> the core system and the base set of SEUL-supported apps is probably a good
> way to go.  If the help system standard is made simple and useful enough, then
> app developers could eventually start to write SEUL-compatible help packages
> for their programs as well.  Thus the exact nature of the help system needs
> careful consideration.  Html and other formats have been mentioned, but much
> more thorough discussion (not pertinent at this level), must still be done.
> (Note: what does LDP use?)
LDP uses Linuxdoc-SGML, a simpler(?) version of the more arcane SGML spec.  
How about this for a help system: SEUL-compatible programs would have tags for 
everything in them, including menus, buttons, keys, etc.  The user can then 
get help on anything (s)he's doing, because it's all there in SGML or HTML.  
If the documentation team can make sure everything's written well and helpful, 
as well as properly xref'd, we can obliterate any competing help system.

A couple of side-benefits of having tags everywhere: 1) cooperating 
applications would be able to cross-reference their help files.  Some kind of 
global database (mentioned further down in quoted msg) could maintain the 
appropriate dependencies and links could form/break based on the installed 
applications.  2) With hooks installed everywhere, not just tags, an 
intelligent tutor could be written that watches what the user's doing, even to 
the point of playing the "hotter, colder" game with the user and his mouse 
while searching for the right menu or whatever.  As the user completes certain 
tasks, they get feedback from either video clips or some kind of "Bob"-like 
character (don't shoot!).  Something to think about for the far future, when 
SEUL is running everyone's set-top boxes.

> Of course, UI has to be considered carefully.  X has been somewhat conceded
> as an absolute on the seul-project list, but it should not be considered
> so at this level.  As a note, shell happens; thus it also needs to be
> _reasonably_ friendly, but this can all be discussed later.
An alternative would be Berlin (pointer-chase: find GGI's home page, then look 
for Berlin there).  It's based on GGI, which when done will provide the kind 
of video performance we're after.  It's designed to be better than X (bad 
ICCCM, bad!!), as well as leaner and faster.  Of course, it's only in the 
running if they can provide libX emulation so we can run X apps without 
re-coding for Berlin right away.

> As apps are added and removed and updated, things that are dependent on
> them do (or should do) things.... to say the least.  Sometimes things break,
> or even crash in really bad ways.  Thus something else that must be considered
> in the runtime system we support is a method (nice generic term again),
> for keeping things in sync.  This will be influenced by the packaging
> system in use.  It may also involve use of some sort of database or
> registry that stores information like this, and perhaps the addition
> of completely new features by SEUL if necessary to fully support
> this sort of complete synchronization.  The impact of this system on the
> UI (which should probably provide many services that are dependent on
> what's actually on the user's machine), should be considered carefully.
Can you say "registry"?  I can't.  I hate the registry.  That's why we need 
something better.  IMO, some kind of registry of installed applications is an 
absolute necessity.  Ideally each application that is managed (in a package 
sense) by the SEUL group would be intentionally interoperable with all the 
other packages we have.  In particular each user app would have an entry that 
defines things like it's "name", it's icon, short description etc, which would 
then be read by a configuration generator for the WM in use at the time, 
generating the appropriate menu or button config.

> And that sort of got into the realm of Stability toward the end there
> as well.  Linux is free, and free stuff has a bad name for one thing
> because of a tendency to be unstable and unsupported.  On the contrary,
> the linux kernel beats many other commercial OS's in stability.
> However, adding all the features we want for SEUL may begin to hurt
> things.  Also, some (linux or non) apps just suck, to put it bluntly.
> The user could be protected from bad apps a bit by putting SEUL-approval
> on products.  Cool stickers, when carefully placed, can make things
> seem much more comfy and reliable, and with appropriate testing measures
> will really ensure greater stability for people who stick only need
> approved apps (which should cover those major-use areas still to be
> discussed further).  Also, tightening up the install/uninstall/upgrade
> system beyond that offered by current pkging systems will help with this
> stability goal.
Bingo.  SEUL-approved is a good idea.  For distrib we'd have the official tree 
with everything SEUL-approved up to that point, an 'approved' directory that 
contains everything else that's approved, and a 'contrib' directory holding 
everything else.  And for commercial apps, we can provide a SEUL-approved logo 
they can put on the box so users know that the app will fit cleanly right into 
their nice, new, SEUL computer.

> Still, thing to keep in mind in design is that as we add greater
> functionality and diversity to SEUL, maintaining stability will
> get harder.  However, stability in the final release is still just
> as important as the addition of the features for which SEUL was created.
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... ;-)


So, when's the revised version of this one coming?  <eg> ;-)

TTYAL,
     Omega

        Erik Walthinsen - Programmer, webmaster, 3D artist, etc.   __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/                /________\ \ \
     Info on Linux, Graphics, Descent, Laptops, etc.         \___________\/


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