Re: [Usability] FOSA ideas

["Eli M. Dow" <dowem clarkson edu>]

snip
> it would be great if
> somebody could take a step back and just list the user tasks we think
> we're trying to support here, before we comment too deeply on any
> mockups and get taken in by how good/bad/indifferent they look.  If we
> could agree on those and some rough task categorisation (e.g.
> frequently-done by many users, frequently by few, occasionally by many,
> and occasionally by few), we'd be in great shape for assessing which
> designs best met the user requirements :)
> 
> Cheeri,
> Calum.
/snip



Here are my thoughts on frequency of user tasks.

Keep in mind this is a File Dialog and there are limited options known
to exist in relation to them. The problem space seems rather limited
(Advanced operations on files have no real need to be in a FOSA window):

1) navigating

2) selecting (aspects of search refinement and preview probably fall
under this category)

3) deleting (to avoid conflicts)

4) renaming (to avoid conflicts)

5) selecting encoding

Frequent by many:

Navigating to the folder they want

Recognizing and selecting the file within the folder that pertains to
them

Occasionally by many:

Renaming a file (prevents conflictive naming at save)

Selecting the encoding of a file 

Frequent by few:

 ??? // I don't see many FOSA operations done frequently by a small
segment of people... I would love to get some other peoples opinions on
it. 

Occasionally by few:

 Deleting a file 





Given those items above and some generally applicable research and books
on the subject, I have written up some design goals and rationale behind
them. 

1) 

Quick, efficient, and comfortable navigation to correct destinations for
saving and retrieving the desired files. 

The interface needs to be user centered. The user wants to accomplish
these tasks quickly and with minimal effort/intervention. No one takes
joy in selecting files to open, or selecting a destination and filename
for something they want to save. Thus any interfaces must be quick to
use, so the user may go on about what it is they are really trying to
do. We need to remove barriers that stand in the way of achieving these
goals (a good example is providing multiple routes to the same
destination that users may not even realize exist). 

2)

Provision of mechanisms to hide file system specifics where applicable.
Alan cooper said it best "Disks and files don't help users achieve their
goals." Shortcuts to avoid traversing directory hierarchy seems like a
good solution to this problem.  By removing the knowledge required to
locate relevant files we have provided the user more effective means of
reaching common destinations quickly. 

3)

Minimalistic design, we need to avoid cluttering the UI where possible
to prevent higher levels of cognition from occurring. The less
reflective cognition (conscious choice and seeking) we impose the
better.  

4)

We need to emphasize recognition rather than recall where we can.
Thumbnailing, providing proper icons to initiate recall, consistent
location and item placement with the rest of the desktop, etc... 

5)

Familiarity with existing tools to maximize knowledge transfer. We need
users coming from other environments to be able to make connections to
what they know and have seen. This does not mean we should copy bad
design, but rather stick to some conventions about location naming and
provide parallel destinations to existing environments (Documents,
Network come to mind as good examples, although I do not know if OS X
has comparable locations that map well)

6)

Design for the intermediate user - most users are perpetual
intermediates. Almost everyone at one point or another was a  beginner.
But likewise almost no one wants to stay that way. Since learning and
improving provides obvious rewards, many users learn just enough to be
comfortably quick at the tasks they need to perform. Almost no one
masters every aspect of a program or software components, so we
shouldn't intentionally design for the expert user. 

This fits with the gnome projects overall goals. We need to make new
users be able to recognize familiar things, we need them to be able to
easily adapt existing knowledge to this new environment, we need to
provide minimal opportunity for error.

7)

We need to make sure and make advanced options less prominent in the UI
for the majority of cases, while providing sane defaults in the case
where we feel the need to provide this extra information. The persons
likely to want to master the tool will find them. This implies we should
wherever possible hide details about encoding and such (GTK is doing a
good job of providing us ways to selectively include that information).