Subject: Re: AbiWord Interface Review
From: Jared Davis (firstname.lastname@example.org)
Date: Thu Aug 09 2001 - 17:37:54 CDT
It's been a long day, but I'd like to respond to a few of the replies. I'll
apologize ahead of time if this gets long.
Several people have pointed out that the Gnome version is further ahead than
the Windows version. I only chose to use the Windows version because this
way themes and styles of widgets would not interfere with a simple
comparison between Word's and AbiWord's interface. Anywhere in the user
interface review that the words "this isn't implemented yet, so it shouldn't
be presented as an option to the user" were to appear, then I was strictly
speaking about the Windows version. To put it more directly, I do not
support the idea of crippling any version of AbiWord because another version
has not caught up yet. I'm sorry I didn't make that more clear to begin
Response to David Chart's comments:
> Also, if we make significant changes to the interface now, 1.0 will be
> undocumented. Us docs people don't have time to rewrite everything in the
> apparent 1.0 timeframe. As it stands, we should have the interface
> documented, in XHTML, in time. Minor changes might be doable, though.
Understood. Perhaps we should hold off on implementing some of these, or at
least be conscious of the documentation behind them before we change them,
so that we can change the documentation at the same time. I hadn't really
considered this when writing the review, and I apologize for any headaches
that may get sent your way. =)
Response to Nils Barth's Comments:
I tend to agree with most of what you've pointed out. I'm glad you liked
the review. =)
> Currently AbiWord's icons are GNOME-ish; since we're making everything
> else platform-based (widgets, etc.), we should probably use
> Windows-standard icons on Windows. However, this makes it a little
> less cross-platform/makes appearance platform dependent, so this is
I agree that there is a conflict of interest here, with strong cases on both
The two sides seem to be roughly as follows:
1. Use the Windows icons for consistency with other applications on the
smae platform, or
2. Use the Gnome icons so that AbiWord looks consistent on all platforms it
I don't have a particularly strong argument for #1, but I would say that
since users of Windows are more likely to already be familiar with the
Windows icons, we should use the Windows icons on the windows platform. If
this is not a popular idea, which it doesn't seem to be, then we can
continue using the gnome icons and tout #2 as our rationale.
I apparently suffered from the same mistake that Johnson mentioned in his
book, and assumed that the export/save as did the same thing since the
dialog was different.
Upon realizing that they actually perform different functions, I would have
to agree with Barth's assessment of renaming the options for clarity and
changing the dialog window's name.
>.2: Date and time... This is hard, and bears more discussion.
> I'd like to be able to specify arbitrary formatting, as in the
> GNU/Unix `date' command. Also, turn off leading zeros. Also, I'd
> like to be able to write `August 9th' or whatever. But we don't
> want to be overwhelming -- this is tough.
Perhaps having a few common options in the submenu, (possibly generated for
the user's Language choice), we could also provide an option that would be
"Custom format", which
would allow this sort of customization for more advanced users. The user
could also pick and choose which formats they wanted in the menu.
>.10/.13: Having font options directly in the menu made sense on early
> Macs, when you had few options; now they should be relegated to a
> submenu, and people should use keyboard shortcuts/toolbars.
Agreed. An "effects" or "formatting" submenu could do the trick nicely.
Response to Alan:
> Im really nit picking here but the graphics included in your document
> dont look good.
The graphics were created primarily with Microsoft Image Composer 1.5. They
are available in their original .png form from
http://aiken.clan11.com/abiword/ui/. If this is a problem with AbiWord's
displaying, a bug report should be filed. To me they look pretty nice,
maybe it's just my computer.
> I dont like having icons in menus and it might be good idea but i would
> definately want to be able to turn them off.
I'm not sure I understand the motivation for wanting to turn icons in menus
off. The space for the icon is there, just being used by gray... and icons
shouldn't be bothersome or distracting (if anything they should assist in
being able to quickly scan the menu). I don't think I've ever even seen a
program that let me turn off icons in the menus... so I'm curious as to why
the option should be available? I agree that turning text labels on in the
tool bar should be an option.
> incredibly long filepath in an attemp to crash abiword. But what happens
> if the file path in the tooltip is wider than the screen? (or status bar
> if we choose to show it there as well/instead)
In an ideal world, the tooltip splits onto two (or three, or n) lines to
accomodate the Very Long Path. In an easy-to-implement world, the tooltip
probably just spills over the edge of the screen and is truncated. The user
still gets more information than MS Word provides.
> 2. Close and Exit Options
> each window is not a seperate instance of the program and it would be
> grossly inefficient to do so (but you can cause two copies of abiword to
> be running at the same time by starting from the shortcut, but not when
> you create a new document).
I never asserted that two copies of the programs were running. What I did
say was: "Each document that is open *seems* to be running in its own copy
Since in SDI each window has its own title bar, menu bar, tool bar, and
status bar, this means that each window looks like it is a different copy of
the program. Even though this is not what's actually happening, that's the
perception. Since perceptually they are different copies of the program,
exiting from one should not exit from both.
The motivation for my suggestion mainly came from using Mozilla for awhile,
and finding much to my surprise that executing File Exit from the IRC client
closed not only the IRC client, but also my mail and web browser. This did
no make me a happy person at the time.
But, I can see that 86ing the exit option is not a popular idea, so it can
go into the rejects pile. =)
> if clear does not merit being on the context/popup menu why have it on
> the edit menu? It should be called Delete to be totally obvious and uh
> umm clear....
I like this suggestion as a compromise in case anyone objects to removing
the 'clear' option altogether. At least it becomes a little more obvious
what it does.
> I dont think changing the Status Bar label is a good idea. To follow you
> train of logic it really should be Show/Hide Status Bar or it should
> change from "Show Status Bar" to "Hide Status Bar" depending on its
> current state, the tool. This is totally obivious once you try it, and
> you when you hover over the item it says in the Status Bar Show or Hide
> Status bar.
Having the option change between Show Status Bar and Hide Status Bar is also
plausible. I had suggested the checkmark next to "Show Status Bar" since
then the menu option names do not change, and you still are made to
understand that it's a boolean sort of deal. I would be happy with either.
> Id leave the Date and Time option alone. In this case i think the
> specifics are necessary.
I disagree. Any time you have a dialog box where a user must choose only
one item, and then hit ok/cancel, you have a function that is better as a
sub menu. A sub menu doesn't interrupt the chain of thought like a dialog,
and provides all the same functionality. Even if we don't get rid of any
options, I think a sub menu is better.
> Stuff from your Appendix i strongly disagree with and think are terrible
> 8 Add description of action in undo option in edit menu, i.e. 'undo
> bold' (1.1.3)
I'd like to know why you think this is a terrible idea. It seems to me that
knowing what the program is going to undo is valuable.
> It will take you hours to submit all these RFE's, i dont envy you, have
> fun :P
=) I have no intention of doing *that*.
I'll try to go about integrating the replies into the document itself
eventually. This way we'll be able to see which suggestions are popular and
which are not.
This archive was generated by hypermail 2b25 : Thu Aug 09 2001 - 17:40:20 CDT