[olpc-software] AbiWord, HIG

[Alan Kay]

At 06:32 AM 3/15/2006, Robert Staudinger wrote:
>On 3/15/06, Alan Kay <alan.kay at squeakland.org> wrote:
> > Just curious ...  why is a lot of real estate still being taken for
> > non-content items?
>
>Please explain, what do you mean by "non-content items"? That the
>toolbar is too big?

I like to give the end-users the largest possible space for their own 
content. So the UI question is how can we then make it easy to understand 
and use the controls and tools without killing off the content space? E.g. 
is there a more compact way to show the title of the doc without 
permanently taking away vertical real estate (we don't need to know very 
often, but would like to know without having to invoke a command)? Perhaps 
alpha blending would work for this part of the UI?

There are many other ways to provide access to controls -- e.g. William 
Newman at PARC used a kind of overlay scheme that worked quite well.

I'm mainly suggesting that more ideas be tried here.

> > There are very likely more compact solutions that start out with everything
> > being visible, but as the user learns can move to more subtle and smaller
> > cues and access. Also, the chip set can do alpha blending, and we've
> > experimented with using that to overlay some of the UI, etc.
>
>Sure, this stuff is just quickly thrown together. Of course a balance
>has to be found between optimal utilisation of available space and
>"usability".

And this could be (should be) different as the end-user learns. It's always 
pained me that so little learning curve is built into most of today's UI 
designs.

>  Also I've been told in #olpc that colour and b/w screen
>resolutions are different, prolly that should be taken into account as
>well (maybe also a fullscreen/viewer mode for reading). All these
>factors multiply to a considerable number of "modes" which i'm not
>very happy about (in terms of development effort and UI complexity).

I certainly don't like modes ...It's possible to avoid modes *and* still 
have full screen viewing. This should be a goal in general, and especially 
on a small screen

>I'd be very interested learning more about the graphics capabilities
>of the machine.

Right now it has a HW bitbltter with alpha, so quite a bit can be done.

>Maybe some UI parts could be implemented in a scalable
>way using librsvg (if that will be available, it drags in cairo which
>was avoided for the n770).

I haven't heard the recent thoughts about Cairo, but it certainly was (and 
probably is) part of the proposed system.


>I've also written the first few lines of a gtk engine with the goal of
>implementing something like
>http://ramnet.se/~nisse/diverse/temp/kidsthememock2.png - might be
>appealing for kids too. Unfortunately cairo based engines are quite
>slow ATM.

I don't want to foment strife here, but I've always thought that 
applications are bad ideas -- they tend to stovepipe useful objects instead 
of providing a playground to mix, match and make them. This is especially 
true for a children's environment.

 > Good start ... I encourage you to continue with more and different
> > experiments ...
> >
> > P.S. Can AbiWord take plugins (like a LOGO) that could manipulate its 
> media?
>
>AbiWord's plugin system exports pretty much the whole internal API.
>Missing stuff can be hooked up without much effort.

This could be one route for the integration of media and scripting that 
children need.

Cheers,

Alan


>Best,
>Rob