"William Sommerwerck" writes:

snips

Not sure what you were seeing. The UI was fairly consistent among the
various platforms, though because of the underlying dictates of the
Windows UI resources sometimes things were a bit squirrely.

They were simply lousy -- poor layout, poor of choice what a particular dialog
box contained, etc. Whoever designed them apparently had no experience with or
understanding of DTP.

I'm curious; do you remember a specific example?

Generally, things are related in an FM dialog; depends on how far down you want to
drill. For example, most everyone knows what a "paragraph" is, but related to DTP a
paragraph takes on many layers. Within the FM "paragraph designer" dialog, for
example, live 6 tabs with some 50-60 parameters in total. At first glance, this
might seem overwhelming. But start using it, and you appreciate the logical
divisions and clarity, given the information density.

But you also have to know enough about the product to see how this parameter set
relates to other things you might be doing.

Any complex app is like this; perhaps a real test is how well you can predict
how something works you don't know based on other things that you already know.

Protools looked really odd to me at first, but as I got to work through it, most of
it seemed fairly well thought out and I've learned to appreciate how PT deals with
high information density. But my initial impression was, "who designed this piece of
excrement?"

In general FM dialogs could get confusing because they are very dense --
lots of stuff you can do. While a little off-putting at first, once you got
used to this you appreciate having so much power close at hand.

I didn't. A dialog box should contain a closely related set of functions.

See above.


Contrast to Interleaf (competitor of the day) when most things were 3-4 menu
pulls down with few or no keyboard shortcuts, and lots of clicking through
"single
purpose" dialogs -- THAT was crazy-making if you wanted any speed with the
UI.

Neither Ventura nor PageMaker were like that. Word isn't like that.

And these three products are for different groups of users. The one that's closest
to FM is probably VP. PageMaker (distant weak cousin of In Design) is more for
display and design work, not so much for long documents.

Each is great for what they do. For example, I would never suggest that someone
writing a 2-4 page business letter fire up FM unless they really know it well. By
all means, use Word. Use PM for newsletters. But for that kind of work, Word will
likely break; FM will do it but you're using a complicated, big machine to swat a
fly.

At the same time, I would never suggest that the doc set for a Boeing 747 be put
together with Word, PM, or even Ventura. Those 80,000 (or so) pages are best handled
by FM or something like it. (My personal record with FM was a 9,000 page doc set, hw
and sw, in some 21 volumes, for an high-speed I/O computer. FM easily handled
this. As an aside, it was simple to create a master TOC and master index.)


I hope it's gotten better.

Yes and no; YMMV. While the new UIs since FM9 are more "contemporary,"
many of us who have used FM for 20+ years don't like the new UI dictates
(I still use 10 year old FM7 for most of my daily doc needs, as do many
folks).
As with many applications these days, some UI designers think they know
best and force you into something that's far less efficient.

I'll take clarity over efficiency any day.

Again, depends on your goals and needs. And are we talking surface clarity or deep
clarity? Sometimes the two are in conflict.

If a superficial level of "clarity" reduces an expert user's speed by even 10%, I'd
probably not want to change the UI. At 50% or more, leave the UI alone, period. Find
another product for the user who wants a "simpler" UI.

A better solution might be a configurable UI, with higher-level UI "personality"
settings for expert or novice. (There is a subset of that in FM now and has been for
a while, but it's not called that directly and it really only scratches the
surface of the concept.)


It's unsettling how often UI folks don't actually use the product they're
working
on -- they just do what seems pretty with little understanding of the work
flows.

This is critical. No one should be allowed to design a product who does not
use it.

Yup. Absolutely. But that's not the way applications development works in too many
cases, unfortunately.

Last fall, at Adobe's invitation, I spent 90 minutes on the phone with the
new UI
guy for FM pleading with him to keep certain UI needs and standards in mind.
Mostly, doc professionals were sick of "cute" and just wanted the damn UI to
not
get in their way. I think he got the message, and I was not the only one
making
the same complaints. We shall see what comes along...

What is "cute"?

As one example, how about a small, drop shadowed, serifed font for dialog title
bars, stippled gray on a dark gray title bar background? I know that many of the
graphics folks get a tingle of excitement when they see such a thing, but for the
rest of us, it's an eye-aching outrage. Worse, because it's an app-specific
windowing system, you can't get to it to change it to something rational. At least
within Windows there are adjustments for such things.

Or, how about "pods" and "docks" that *might* lend clarity at first, but then
severely bog down the experienced user. (Fortunately, the more recent versions of
FM allow you to disable such "cute clutter" and get directly to where you want to
go, without "hand-holding" that becomes "hand-cuffed holding".

I'm not necessarily disagreeing with you; my main abstract point is not to force one
UI design on all different levels of users doing different kinds of work.

And I'm in complete agreement when the UI of a complex app is seemingly a random
mess. Ugh. For the most part, though, FM is not in that camp.

Frank
Mobile Audio
--