Re: [Usability] Filechooser and filename suffixes
- From: Kirk Bridger <kbridger shaw ca>
- To: Robert Staudinger <robert staudinger gmail com>
- Cc: usability gnome org
- Subject: Re: [Usability] Filechooser and filename suffixes
- Date: Sat, 30 Sep 2006 09:54:32 -0700
Here are my thoughts.
Abiword should be somewhat "intelligent" here but allow the user to
override that intelligence if they choose to. By intelligent I mean it
should append the correct suffix as specified in the combobox box
whenever appropriate. It is not appropriate, for example, when the user
has chosen their own suffix. In this case Abiword should update the GUI
(combobox) to reflect their choice and obey their request. So looking
at your examples (embedded):
Robert Staudinger wrote:
> since I couldn't find any discussion on that in the HIG I'm directing
> my request to this mailing list.
> As you know AbiWord supports a handful of document formats (depending
> on the number of installed plugins) which are commonly distinguished
> primarily by filename suffix. Discussions have been emerging from time
> to time how to best present that different formats in the "Save"
> Most apps (including abiword) present a combo-box for selecting the
> desired format, what's less consistent is the interaction between the
> manually typed filename and the format combo.
> + Assuming the combo shows "use default" or something like that should
> the combo automatically switch to ".doc" when e.g. "foo.doc" is typed
> in the filename entry?
Yes, that's a good idea.
> + Assuming the combo switched to ".doc" as described above, should the
> combo revert to "use default" or whatever previous selection if the
> user continues typing "foo.document"?
Also a very nice touch, and it sounds good.
> + Or should maybe the selected suffix be appended to the typed
> filename regardless of whether it matches a known suffix?
This is overriding what the user is trying to do and I'd recommend
against doing that. If the user types a known suffix the file should be
saved in that format.
> + Let's again assume the user typed "foo.doc" and then changes the
> combo to ".odt" (1) should the ".odt" suffix be appended in the
> filename entry (2) should the application try to find out whether the
> filename entry contains a known suffix and eventually replace it or
> (3) should the filename entry not be modified at all?
This is an interesting one. I think we should try to focus on what the
user is trying to do here and support that. Why would the user type a
filename with a known suffix?
a - they don't know it is a known suffix
b - they want to have a filename with the suffix in it (file.doc.odt is
valid, for example)
c - they want to save in that suffix
In both a and b the obvious choice is to save in the combo box's
format. So for your number 1 I would say the suffix should be
appended. That sounds messy though doesn't it. Note that this
overriding only happens when it is the last thing the user indicates.
In the first example in this message the user just typed the suffix and
that was the last thing they did so we follow the behaviour described
above. In this case here though the user last chose something from the
combobox, so it trumps their typing. Does choosing something from the
combo box update the filename entry widget immediately, so the user can
see the results of their choice?
Your number 2 I would recommend against, as we're assuming we know
better than the user and that leads to problems.
So we look at scenario c and see that the last thing the user did to
indicate their choice was to choose something from the dropdown - and
this should trump whatever previous choices they made. So for c we see
again that the suffix should be appended.
The only ugly thing here is that the typed suffix is not being replaced
by the combobox, so the user could end up with multiple suffixes if they
type, choose, type, choose. I don't know if this is ideal or simply a
corner case that will exist simply because of the decisions made by
> There might of course be more examples I'm just listing the most
> obvious ones that came up in previous discussions.
> Ultimately it might of course be favourable to have the behaviour
> implemented in the filechooser itself, but that would as well require
> to figure out the preferred way of solving that issue.
I'm not sure what you mean by the filechooser here - do you mean the GTK
dialogue invoked in some way via Abiword? I just tried using my version
of Abiword and it looks like it calls the standard GTK dialogue already
for saving .. is there an Abiword-specific dialogue I'm missing here?
> Thanks for any advice,
> AbiWord developer
> Usability mailing list
> Usability gnome org
] [Thread Prev