[olpc-software] AbiWord, HIG

[Robert Staudinger]

On 3/15/06, Alan Kay <alan.kay at squeakland.org> wrote:
> 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.

Are any further details on that available? URL?

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

Oh, i was only referring to the visual appearance ("theme").

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

Where can I learn more about the requirements?

Best,
Rob