[olpc-software] AbiWord, HIG

[Alan Kay]

Hi Kim --

At 09:56 AM 3/15/2006, Jim Gettys wrote:
>Firefox and Opera (and probably Safari, but I have no first hand data),
>are much more capable of dynamic behavior than you probably realize.
>                                 - Jim

Makes sense. However, too bad the minimal needed things (e.g symmetric 
authoring as in all other personal computer software) were not done in the 
early browsers. That was a complete lapse.

So perhaps the question is how to get around IE?

Cheers,

Alan



> >
> > I said a little more about what I think the larger problem is in a recent
> > email to Rob.
> >
> > Cheers,
> >
> > Alan.
> >
> > At 08:25 AM 3/15/2006, Jim Gettys wrote:
> > >Ah, Alan, sounds like you can join the long line of X Window manager
> > >writers.  All the titlebars and decorations for manipulating windows are
> > >generated by the WM, and not the application.  Anything you can imagine
> > >should be possible with some work; it isn't buried in the base system
> > >where it is difficult to change.  Fundamentally, this is one of the real
> > >innovations that we did with X, very different than other window systems
> > >of the '80s (including yours ;-)); window management is left to external
> > >applications and not hard-wired.
> > >
> > >While window manager wars have been unproductive, the ability to swap
> > >out window management policy also enabled X to survive and for desktops
> > >such as Gnome and KDE to be built many years after X11 was released.
> > >
> > >In fact, the early X Window managers had no stink'n title bars at
> > >all ;-), and were mostly driven by "control-shift-meta-cokebottle"
> > >keybindings; until X11, we couldn't even do titlebars and controls in
> > >the window managers.
> > >                                 - Jim
> > >
> > >P.S. for those young turks here, it turns out that some keyboards at MIT
> > >really did have cokebottle keys in that era, though we never actually
> > >used them in window management. :-).
> > >
> > >
> > >On Wed, 2006-03-15 at 07:09 -0800, Alan Kay 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.
> > > >
> > > > 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
> > > >
> > > >
> > > > --
> > > > olpc-software mailing list
> > > > olpc-software at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/olpc-software
> > >--
> > >Jim Gettys
> > >One Laptop Per Child
> >
> >
>--
>Jim Gettys
>One Laptop Per Child