On 25 Aug 2008 at 15:38, Allen Fisher wrote:
> What about the help button that's right in dialogs?
It should be mapped to the F1 key on Windows, and the appropriate key
on a Mac.
And *everything* in the window has to be covered if it's a single
help document for an entire dialog box. And the help screens for
everything reachable from the dialog need to be cross-referenced (as
well as related topics).
I had an epiphany about the way in which UI design is determined by
how the designers define the purpose of the application. This came
about when thinking about my TiVo (which is an old Series 1 from
2001, and definitely well behind the curve in terms of up-to-date
TiVo technology) and my roommate's cable company-provided DVR. It's
not just a matter of TiVo fanaticism to say that the TiVo is vastly
superior *for the user who wants to find programs to record*.
This was brought home to me last night. I was going through the list
of movies playing over the next 10 days to pick things to record.
While doing so, I encountered two films I've already seen and really
love ("Touch of Evil" and "Sweet Smell of Success") and wanted to
suggest to my roommate that he set his DVR to record them. I assumed
he could easily find them by Title (on TiVo, you go to the main menu,
choose "Pick Programs to Record", then "Search by Title" then select
to search only "Movies" (that step is optional -- you can search
everything if you like), and then you use the onscreen alphabet to
put in the letters of the titles. I can find both of these movie
titles by putting in only TWO letters.
On the Cablevision-provided DVR (your typical Scientific Atlanta
model), you can *browse* by title, but only in broadcast time order
(not in alphabetical order). I ended up going back to the TiVo and
finding the channels and times and then my roommate could easily find
them.
The epiphany:
TiVo is not a DVR, it's a really find database searching application
that drives a DVR. The TiVo was designed from the ground up to make
it really easy for a user to find any program that is in the program
schedule for the next 10 days. The Cablevision DVR was *not* designed
with this in mind -- it was designed as a DVR with some minimal tools
to find programs, added in seemingly as an afterhought.
The difference in philosophy of what the device is *for* is reflected
in how the UI for them is designed. When the Scientific Atlanta box
has the program guide up onscreen, one quarter of the screen to show
what's the channel that the box is currently tuned to. This is, of
course, completely useless -- if you don't want to miss the program,
you pause it! The TiVo screen, on the other hand, takes up the whole
screen for the search UI. This means it's clean, easy to see, and
much easier to understand. The quarter size picture-in-a-picture
display on the Scientific Atlanta box is clearly there to serve the
interests of the advertisers on broadcast TV (though due to a
complete misunderstanding of how people could use their DVRs) -- and
it does *not* serve the interest of the user.
In short, TiVo was designed entirely around what the USER wants,
while the cable company DVRs have competing constituencies that
determined the design, and the user is only one of those
constituencies (and, apparently, in last place in a lot of cases).
Back to Finale:
The IE-only "feature" of the Finale HTML documentation on Windows is
a case just like that, where some other constituencies needs trumped
those of Finale users (likely it's a result of a limitation of the
tools used to produce the HTML documentation).
For help files to be useful, they *must* be designed from the USER's
point of view, and *entirely* from the user's point of view.
And that's an incredibly difficult task, especially for the people
who have been intimately involved in the design of the program. I
know -- I *hate* producing help files for the database applications I
create, and charge an arm and a leg for them (my design philosophy
for the UI of my apps is that you need 20 minutes of help to get up
and running, but once you've used the app for a couple of days,
everything makes sense and you don't *need* a help file to figure out
how to do things). I produce custom-designed software so I can get by
with that.
But Finale is a shrink-wrapped product and needs the help files, and
they require a huge investment in thought and organization to be
successful. To me, the most important thing is GOOD CROSS REFERENCING
and GOOD INDEXING. If you have the former, it's easy to get where you
need to be if you've accidentally ended up in the wrong place. And
the latter makes it possible to have a single destination page
accessible from many entry points, since different users will have
different conceptual models of the program and different terminology
in mind.
There is no shortcut for these. Just as creating indexes for
published books is an art that can't be done with a computer (a
computer can help automate it, but the best index will have entries
that a computer could never figure out), creating a help file is one
of those arts that is much harder than it seems.
It's good that MM is making it a priority.
--
David W. Fenton http://dfenton.com
David Fenton Associates http://dfenton.com/DFA/
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
