David,
It's great to hear that you're looking for a coding project. I've already
had my say on the MDI vs. browser-like UI battle the last time that
particular flamewar erupted last fall, so I'll concentrate my feedback on
the dialogs.
You've zeroed in on one of the places where we could use a lot of design and
coding help right now -- fleshing out all those unimplemented dialogs -- so
pardon me for the long response.
In short, no, we don't have mockups all worked out for those dialogs.
Getting the design right is the creative part of the process, and we didn't
want to take that fun away from whoever got to do the implementation. To
date, our approach to dialog design has been pretty simple:
1. Don't surprise the user -- it should Just Work
==================================================
Essentially, whoever's ready to implement a particular dialog first goes off
and looks at other existing word processors to see how they handle that
functionality. Our general design approach is to try to *not* surprise
people with innovations, but instead to take advantage of the ideas
encapsulated in almost 20 years worth of GUI design for word processors.
Since Word has such dominant market share, that's an obvious source of
ideas, but if you want to code up something better, that's cool too. Just
remember that the problem with GUI innovations is that almost *all* of them
suck.
If you feel like innovating, remember that your design needs to be "obvious"
to folks who don't write code for a living. As a quick test, pick someone
like your Mom, give them a paper sketch of your dialog design, and ask
*them* to tell you what it does, when to use it, and how it works. If you
find yourself tempted to "correct" them, then your design is wrong, because
it's not obvious enough to *them*.
2. In any debate, working code is worth 100 email messages
===========================================================
One of the nice things about running code is that everyone can tell how it
feels to use it. Also, it's fairly easy to add patches to make it work
better.
(For example, MDI proponents are encouraged to code up their ideas on how an
MDI interface should work. Note that it'll take a *lot* of work to get all
the "little" details right, so don't be discouraged if your first patch
doesn't set the world on fire.)
3. Do the shared code right, so ports to other platforms are trivial
=====================================================================
This is probably the most important point. We've tried fairly hard to set
up the dialog framework so that most of the behaviors for a dialog can be
expressed in XP code. (This takes some work, but it's worth it.)
That way, once a dialog has been completely debugged for the first platform,
we can port that dialog to the other platforms within hours.
bottom line
===========
If this sounds like too much work to tackle all at once, send mail to the
list and sign up for a smaller, more specific piece of the puzzle.
I'm sure any AbiWord developer who's already given any thought to a specific
design problem would be happy to share their insights. All you have to do
is keep asking good questions. :-)
Paul