[sugar] Squeak / Etoys RPMs

[Dan Williams]

On Wed, 2006-10-11 at 06:33 -0400, Ivan Krsti? wrote:
> Marco Pesenti Gritti wrote:
> > You know what's my real worry? I'm worried that when the storage system
> > will be spec'd out (or even worst implemented) we will find out it's not
> > what we need to implement the user experience design. And the reason I'm
> > really worried is that I *care* about it because I'm sure you guys are
> > building a great piece of software.
> 
> I wanted to release specs for the storage system a few weeks ago, but
> this got sidetracked because of work on security, the docformat, and
> infrastructure.
> 
> I'm going to try very hard to release the spec before next week. That
> said, I want to caution against the seemingly growing trend to consider
> *everything* a part of the user experience design. I can see the appeal
> in it, but it's simply misguided and incorrect. We're building a
> software stack. As with any other stack, it has a top and a bottom.
> Sugar is the top, and while many of the underlying levels must thus be
> designed with user experience as the primary concern, the fact is that
> many of the bottom layers simply don't.
> 
> The kernel is not designed with regard to user experience. Neither is
> TCP/IP. The document store is a general, relatively low-level interface
> whose actual operation is largely defined by how it's used; just as you
> don't think to go and implement a new NAND flash filesystem with user
> experience in mind (what does that even mean?), so it's the case with
> the docstore.

There are a couple issues here:

1) TCP/IP and the Kernel were written and "designed" long before
computers were ubiquitous and long before people cared about the user
experience for those who were non-hackers.  But that only invalidates
_these_ examples, not your main point.

2) Why should they _not_ be designed with regard to user experience,
where the user has to interact with them directly?  There's a tradeoff
in the lowest levels, of course, between crappy hardware, speed,
security, etc.  But that doesn't mean you don't design the behavior for
the user.

3) The lower layers are obviously implementation, and as such must deal
with implementation difficulties and realities of the world.

4) The linux kernel is a horrible example here, because of the political
pressures to be as generic as possible and work every under the sun.
You simply cannot care about the user much at all in that environment,
and it surely shows.

5) For any project, the user design should drive the implementation if
users are the main "client" of the product.  In an embeded system that
has no UI, of course you don't care about the user that much!  But for a
system that is supposed to be used by an actual human being for the
majority of the time, the human being should be the utmost concern.

Why did X just recently (like, months) get autoconfiguration?  Nobody
should _ever_ have to pick their monitor size and refresh rate,
especially on our platform.  Why should I have to explicitly mount a USB
drive I plug in?  I plugged it in, something should happen dammit.  Why
does my sound not come from my USB speakers when I plug them in?  I
plugged them in, something should happen dammit.  For most of this, it's
because the people who wrote the software were writing it mostly for
themselves and they knew what they were doing.  These are all reasonable
requests, but nobody designed the software _from_the_start_ to even
think of the average user, because "average" users at the time were all
technical and not many people had computers anyway.

The point is that since our laptop is meant to be used by real people,
we should be driving the requirements, architecture, and experience with
that taking precedence over almost everything else (except possibly
security, and then not in all instances).  And that should filter down
through the software stack.  Some things you grow upward, because the
technical requirements and/or limitations are such that you simply
cannot do it any other way.  But in this system, the lower stuff should
_always_ be subservient to the users needs.

If a 10 year old kid can't sit down and figure some basic thing out in
30 seconds, we've lost, and we need to change the software.  Things like
"how do I find my friend" or "how do I chat with my friend" or "how do I
share a picture I just took with my friend" or "how do I browse the
web".  Not "how do I map between file type and default launch activity
to open this thing" or "how do I connect to a wireless network and
browse the web".

Dan


> In terms of my expectations, I don't think we'll have anything more than
> the wiki/eBook reader using the store for B-test. This is fine: we can
> move things over as necessary afterwards, and I'm happy to revisit the
> docstore design decisions if -- by some series of revelations that I
> can't quite fathom -- it turns out that its design is incompatible with
> the 'user experience' considerations.
> 
> Let's not make user experience into another kind of Kool-Aid.
>