Subject: Re: Interested in overall plan
From: Paul Rohr (paul@abisource.com)
Date: Wed Dec 01 1999 - 14:19:03 CST
At 10:26 AM 12/1/99 -0600, Aaron Leventhal wrote:
>Just downloaded the Windows version of Abiword and am playing with it.
>Extremely responsive.
Thanks.
>As someone who is looking around for the right office suite to program for,
>I'd like to ask some questions about future development philosophy.
Cool. We could always use more help.
>* My area of specialty has been developing software for disabled people.
>Has thought yet been put into this area?
Probably not enough. We have tried to do the obvious simple things by
following GUI guidelines -- like zoom and honoring system color preferences
-- but I'm sure there are other areas we could be doing even better.
Your expertise and coding help here would be very welcome.
>* I believe in the future that the word processor, web browser, web page
>editor and e-mail client will merge into one application. What is
>Abisource's position on this idea.
I suppose it's possible, but it sure sounds like a lot of work. Each of
those applications has evolved a fairly complex UI which has been adapted to
the specific needs of that product. For example,
- Web browsers optimize for fast network access, progressive rendering of
content, and flexible single-flow layouts. Having served my time in
browser hell, I can also attest to the volumes of code needed to handle
all the sloppy HTML as rendered by previous browsers.
- Web editors optimize for many of the same HTML problems -- in fact,
those UIs need to know a lot more about the specific quirks of various
browsers so authors can consciously choose to restrict the features they
use. More to the point, you use *very* different data structures for
editing than for browsing.
- Word processors optimize for page-oriented layout of complex printed
documents, and have a different blend of desktop-focused compatibility
requirements.
- Mail clients have a different mix entirely, being a lot more like a file
system with lots of filters and sorting.
I suspect that if you really study the codebase for best-of-breed products
in each of these categories, you'll find that the intersection of common
features is smaller than you might think.
More to the point, designing an easy-to-use UI to simultaneously handle all
those functions is very, very hard. Every attempt I've seen to create a
single unified UI to handle all those features falls into one of three
categories:
- a highly-restricted subset of common features (think Works)
- all kinds of confusing GUI clutter (think Star Office)
- ugly warts bolted on after the fact (writing HTML in Word)
I'm not saying it couldn't be done. But if the problem's not totally
intractable, it'll certainly take more effort than I personally am willing
to commit to over the short or medium term.
For now, our goal is to do the coding and design work needed to produce a
cool Open Source office suite using a set of traditional best-of-breed
standalone applications which all share:
- a common look and feel,
- the same underlying scripting engine, and
- a lot of code.
For this reason, we've invested a lot of effort in a lightweight
cross-platform (XP) and cross-application (XAP) application framework (AF)
so that that same logic can be shared across all apps in the suite.
In fact, this approach has forced us to be pretty disciplined about
modularity in structuring our code. By totally separating basic UI
mechanics from app-specific UI logic from the app-specific view logic, we've
done a lot to make it possible to reassemble those building blocks into
different UIs later on. Even so, it'd still be a ton of work.
Does that answer your question?
Paul
This archive was generated by hypermail 2b25 : Wed Dec 01 1999 - 14:14:00 CST