[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [olpc-software] AbiWord, HIG

At 06:32 AM 3/15/2006, Robert Staudinger wrote:
On 3/15/06, Alan Kay <alan kay 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

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.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]