RE: FrameMaker UI

["Szczesniak, Barbara" <bszczesniak@xxxxxxxxxxxxx>]

Thomas,

I also wholly agree with all of your comments on the annoying aspects of
the Frame UI. If I spend time thinking about it, there are probably at
least a dozen others I could add to the list myself. 

No need to apologize, there is something wrong with me (as my family has
known for years ;-). As I said in the quote that you used, I have lost
my perspective on Frame's UI. I have learned to ignore and work around
all of the things about it that bug the **** out of me because I don't
really see any alternative. When writing the 1000+-page developer's
guide I just finished, I wouldn't use anything else.

I did not mean to imply that I thought there was nothing wrong with the
UI in Frame or that I wouldn't be ecstatic if they managed to improve
even one of the items you mention. When reading a message such as this
one, though, the Adobe people would probably pick out the words
"wouldn't use anything else," ignore the rest, and think to themselves
"our product is great." So I should probably instead use the phrase
"there's nothing else to use."

I keep my eye out for those messages where everyone discusses
alternatives to Frame because I'm waiting for that product to come
along. At that point, I will have no problems telling Frame not to let
the door hit it in the ### on the way out.

Barbara Szczesniak
Documentation Specialist
ClearNova, Inc.
770.442.8324 x6520 voice
770.442.5975 fax
bszczesniak@xxxxxxxxxxxxx
-----Original Message-----
From: Thomas Michanek [mailto:framers@xxxxxxxxx] 
Sent: Saturday, June 11, 2005 4:39 PM
To: framers@xxxxxxxxx
Subject: Re: FrameMaker UI

Dear colleagues,
I'd like to give my views on the issue of FM's UI. For me, the User
Interface
is more than how the GUI looks (menus, buttons, dialogs), it's how you
interact with the software to use its functionality.

Whether the UI is to be labelled "odd" or "outdated" or something else
is
a matter of personal preference, but the fact of the matter is that the
UI
hasn't changed for many years, and it needs a lot of improvements.
If you don't agree, I think Barbara Szczesniak summed it up pretty well:

> I think that I am so used to the UI that it is
> second-nature to me now. When newer users talk about how difficult it
is
> to learn, I tend to think that there is something wrong with them,
> rather than with Frame. I guess I've lost perspective on that front.

Anything is OK once you've learned it and got used to it; that doesn't
mean
it has a good design to begin with. If we ever want the popularity of FM
to
grow and see it expand into new markets (including to be used for
documents
where people use Word today), the UI must address not only the needs for
us,
the every-day professional users, but also for new users that may be
used
to "simpler" and more modern software that are more intuitive to run.

I'd like to point out that I agree there are more important features or
shortcomings in FM to address than the UI. I don't want a complete
rework
of the UI to make it like MS Word or Adobe's world of palettes.

So here are a number of my examples:
====================================
(some of these are of course a matter of personal preference!)

1) The default toolbar with character formatting buttons (B, I, U, etc).
Maybe this was added to make it "easier" for new users? But, in fact,
the
buttons contradict and oppose the intended way to apply character
formatting
in FM. Either delete these buttons, or tie them to a character tag in a
way
that can be defined by the user, e.g. "I" applies the "Emphasis" tag.
This
can be expanded to buttons for paragraph formatting, a la Word, that
apply
a specific tag instead of an override.
Experienced users may not like this idea, but it becomes easier for a
casual user to make a simple document and still use tags properly. The
standard templates could have tags tied to suitable toolbar buttons.

2) Customizing the UI (menus, toolbars, shortcut keys, etc). Does
*anyone*
find the current solution of editing ancient text files in a subfolder
somewhere easy, modern or intuitive? Do we really think that a static UI
is the best for all users, workgroups and purposes?

3) Dialog access to all important settings in the maker.ini file.
Why is the Preferences dialog so restricted? How are new users supposed
to
know about and edit the INI settings, like
"DisplayUsingPrinterMetrics=On"?

4) Handling of font substitutions. We all enjoy the informative Missing
Fonts message and the intuitive editing of the maker.ini file, don't we?
Make a dialog for selecting substitution fonts and other font mappings.
It may not be possible to cover all cases, but most of them anyway.

5) A Find/Change dialog that remembers previous searches and allows you
to select them from a drop-down list, one for each object type.
When I'm switching from searching for a tag to searching for Text, it's
not very likely I want to search for the same text string now, is it?
And how about a search function that tells you when you've searched the
entire document and you're back where you started? Rocket science?

6) Dialogs and text fields that can be resized, come on!!! Have you
tried
resizing the Edit Variable or Marker dialog? What bafoon designed this?

7) Why not "catalog" windows for inserting and applying Table tags,
variables, etc. That would seem quite natural to me, at least.

8) Show the Default Properties in the Table Designer! Or do you enjoy
having table properties being changed without you knowing?

9) The Marker dialog... Don't get me started. How about allowing the
user
to select building blocks from a list, depending on the Marker Type?
How about a syntax check for each entry? (very simple to add!)
Perhaps even a normal dialog box for designing index entries?
How about a warning if you've entered marker text and then accidently
put the cursor in the document without adding the marker???
Experienced users may find the current solution "efficient", but it's
surely not easy or helpful.

10) Formatting of generated list through a dialog with building blocks,
together with the Setup of which tags to include. Have you become so
used
to Reference pages that you actually think this is natural and easy to
understand for newcomers? Have you ever misspelled a building block?
How about offering the possibility to add a TOC at the cursors position,
as a non-editable block of text without creating an external file first?
(this can be implemented without changing the document model)

11) How about a button for changing a table body row into a heading row?
Or do you enjoy cutting the row, adding the type of row you want through
a nearly hidden option, and then pasting back the row? 

12) In the book window, the default action of *editing* an entry instead
of opening the file if the entry is selected before you double-click...
This drives me crazy. How often do you want or need to edit an entry,
as compared to opening it? Isn't the Rename menu option enough?

13) How about a menu option "Close All Files Without Saving"? Maybe I'm
using FM in strange ways, but I need to do this quite often...

14) You want to change the zoom setting or the line width to a value
not in the current list. So you click Set, enter the value, and then
the value you entered isn't applied? This is backwards logic, folks.

15) The Graphic tools not showing the setting of the currently selected
object by default. Aahhh, the hidden "Pick up Object Properties"
command,
how stupid of the users not finding this on their own...

16) An easy way to move between table cells with the keyboard. I'm
forced
to use a four-letter word: Word.


I'll stop here. I could easily add twice as many annoyances and
suggestions
for better design (I'm a usability guy). What surprises me is that it
seems
like the FM programmer's don't use the software much themselves. If they
did, they would have fixed the obvious and easiest things at once...

I'm sorry, Barbara S, there is something wrong with FM (and you ;-)

___________________________________________
Thomas Michanek, FrameMaker/UNIX/MIF expert
Technical Communicator, Linkoping, Sweden
mailto:Thomas.Michanek@xxxxxxxxx
___________________________________________


** To unsubscribe, send a message to majordomo@xxxxxxxxx **
** with "unsubscribe framers" (no quotes) in the body.   **



** To unsubscribe, send a message to majordomo@xxxxxxxxx **
** with "unsubscribe framers" (no quotes) in the body.   **