Subject: Re: Interested in overall plan + unified editor/browser model
From: Aaron Leventhal (aaronl@chorus.net)
Date: Wed Dec 01 1999 - 16:23:05 CST
Paul,
>Cool. We could always use more help.
Thanks. And I appreciate the in depth explanation. I'm not very familiar
with what it takes to write a browser, though I do understand the problems
with poorly formed code. Also, the progressive rendering difference was
something I hadn't thought of. I've worked on my own word processor, which
probably has a very nonstandard internal structure (a double-linked list of
objects) than a modern piece of software.
As far as StarOffice goes, I definitely agree it suffers from GUI clutter.
However, I don't think the clutter is necessarily because of the
unification of the browser and word processor. I think it's because they
wanted to have everything available immediately as a button on the screen,
even when it's a rarely used feature. Perhaps the browser isn't the browser
either, but it works.
I agree there are many differences between HTML/web page markup and the
markup one might use for publishing. I'm thinking that both could be
represented internally as a meta-XML that covers all the bases. The
internal structure would have to be able to handle both paper-publishing
and electronic publishing.
Possibly this is just something for the computer world to chew on for a
while. I think it makes sense that eventually it will be done well. The
difference between a personal computer's files and files that on the
internet will eventually become transparent. The only difference between
the 2 will be the location of the file, and whether you have write access
privledge. People will want one simple tool that they can do it all with:
feed various types of data into, view or manipulate in a familiar way, and
publish either electronically or on paper. It should work on a desktop or a
palmtop. A app that does this will differentiate it from old word
processors based on proprietary pre-web markup models.
I really think XML is key, and I understand Abiword bases everything on
XML. I find it interesting that many XML formats start off from a base of
HTML. For example, the open eBook XML standard, which will be used in
electronic books, started from a base of HTML.
Perhaps a major thing that makes bad HTML is the lack of end tags, which is
required in XML. Am I correct that if a piece of HTML had enough end tags,
it would be a small step from XML. Perhaps when the HTML is imported it can
be turned into XML internally? I don't know - I believe you when you say
writing a good browser is incredibly difficult. I don't personally know how
to build such a unified architecture.
But the main reason I bring this up is simplicity for the user. Designing a
software architecture for a unified text program may create extra
headaches, but I think the outward interface design could be very elegant.
I think it could turn heads.
Do you think eventually future software might sucessfully do this? Is it
intuitive? Or do you think the traditional separation between
browser/mailer/word processor/HTML exists because it makes sense and
should/will stay that way?
Looking forward to hearing your thoughts,
Aaron
At 12:19 PM 12/1/99 -0800, Paul Rohr wrote:
>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 - 16:35:54 CST