a new day… some new “excise”athena.ecs.csus.edu/~buckley/csc238/cooper_ch14_s2016.pdf ·...
TRANSCRIPT
A new day… some new “excise”
Show details… there were none
Choices: 3 choices or 3 ways to decide on 2 choices
“How do I decide…?” I didn’t
1
My favorite
BBuckley - 2
CSc 238 Human Computer Interface Design
Part II Making Well-behaved Products
Chapter 14
Rethinking Data Entry, Storage, and Retrieval
ABOUT FACE
The Essentials of Interaction Design
Cooper, Reimann, Cronin, and Noessel
Tackling the problems…
Software that forces people to think like computers…
by unnecessarily confronting them with the internal
mechanisms of data entry, storage, and retrieval
“Do you really want to save this document? Well, I’ve been
working on it all afternoon, so yes, oddly enough, I do…”
Solve the data entry, files and saving and retrieval
problems – to be in harmony with the mental models of
the people who use your products!!
Rethinking Data Entry
Data integrity versus data immunity
Handling missing data
Data Entry and fudgeability
Auditing versus editing
3
Rethinking Data Entry
Data integrity versus data immunity
Barriers in user interfaces … are intended to never let bad data
“enter” the system
All data is validated at point of entry
The needs of the database “trump” the needs of the user
“... makes a clear statement that the user in insignificant and the
application is omnipotent – the user works for the good of the
application, not vice versa”
we need “… much smarter, more sophisticated applications that
can handle all permutations o data, giving the application a kind
of data immunity”
“When users enter incorrect data, it is often close to being correct
… assistance in correcting this should be provided”
4
Rethinking Data Entry
Handling missing data
Users may not have access to all the data needed… the software
should accommodate the users’ work flow
“Talk” with the user… with rich modeless feedback
Help with data entry errors…
Data items that should NOT be entered in free text fields
SSN: xxx – xx – xxxx
Credit card: xxxx – xxx – xxxx – xxxx
Information processing systems do tolerate missing information
… the software should as well
“Users won’t tolerate stupid software that insults them, not when
they can push a button and surf for another few seconds until they
find another vendor that presents an interface that treats them
with respect.”
5
Rethinking Data Entry
Data Entry and fudgeability
… requiring a capable interface!
Fudgeability requires facilities to hold records in
suspense.. like the undo function
… recording the user’s actions for later examination
“Let users do what they want, but keep detailed records
of those actions so that full accountability and recovery
is possible”
The technical goal of data integrity should no be our
users’ problem to solve
6
Rethinking Data Entry
Auditing versus editing
… the application should accept what the user “tells”
it… whatever the user enters should be acceptable
Provide warnings … modelessly informing the user was
done, but not stopping the work
… instead, “remembering” the user’s action and
ensuring that the action can be cleanly reversed
The application can provide the user with enough
information to figure our where the problem might be
7
An error may not be your application's
fault, but it is its responsibility
DESIGN
PRINCIPLE
Audit, don't editDESIGN
PRINCIPLE
Rethinking Data Entry
“In our experience, people find computer systems –
facilities that store application and data files – difficult
to use and understand”
Opening a application provides access to the set of
documents created using it… in chronological order
Word, Excel, PowerPoint … do this
The Problems with data Storage
Users’ mental model is of a single document they are
currently working with … not the techie storage model
Saving changes
Closing documents without saving
Save As
Archiving
8
The Problems with data Storage
Saving changes dialog
appears when user requests
Close or Quit … assuming that “yes”
and “no” are equally likely choices
The “yes” should be assumed… the modal interrupt is unnecessary
Closing documents without saving
… is not the way to abandon unwanted changes
Reject the changes when the changes are made
That’s the job of the UNDO function
Hypothetical: You make changes to the wrong file and then use
the above “no” choice … a classic developer “hack” solution
9
The Problems with data Storage
Save As dialog
Name a file
Choose directory location
10
User needs to understand the file
system & how the file can be retrieved
… or where the default directory can
be found
“After … the first time he cannot change
its name or directory cannot be changed
without creating a new document …”
The Problems with data Storage
Save As dialog
Name a file
Choose directory location
11
Changing a name while the “doc” is
still open…
Stored on desktop… double click on
file name and make the change
The “File In Use” dialog appears
The authors’ lament is that “the one
entity that has both the authority and
the responsibility to change the
document’s name while it is still open
… refuses to do so.”
WORD
The Problems with data Storage
Archiving
“… no explicit function for making a copy of, or archiving, a
document.”
Allow for a differing set of changes… to the same document and
save the changes but not “erase” the original
If the file has been saved as “Alpha”, changes are made
Save alone overwrites the original
Save As can do this, but…not exactly the logical tool to be used
to do this
The user must be “savvy” enough to know how and where the
edited versions are to be saved
Why not provide an editing function that allows for saving
changes (e.g. Alpha, Alpha2, Alpha3, … etc.)
12
Rethinking Data Entry
Fixing data storage: a unified file model
A different approach to document management that supports
users’ mental models of the process… allowing users to perform
several specific goal-directed tasks:
• Automatic save
• Creating a copy
• Naming and renaming
• Placing and repositioning in the file system
• Specifying the file type
• Reversing changes
• Discarding all changes
• Creating a version
• Communicating status
13
Rethinking Data Entry
Fixing data storage: a unified file model
Automatic Save
No longer two copies
When user is done, the CLOSE function writes changes to disk
without the “Save Changes” dialog
Changes are saved as they are made… automatic changes at
intervals… no more manual saves
“Naming” must be a separate process?
Creating a Copy
A separate explicit function… identical to the original but not
“tied” to it … and no dialog required for this to happen
A naming convention would identify the copies to the original
nameCopy1, nameCopy2, etc.
14
Save documents and settings
autmaticallyDESIGN
PRINCIPLE
Rethinking Data Entry
Fixing data storage: a unified file model
Naming & renamingOmnigraffle on OS X
Placing and positioning in the file system
The specific location should depend on your users and the
posture of the product you are designing
Specifying the file type (e.g. saving .docx and a .pdf)
Screen shot on next slide
“…characteristic of the doc not the disk file… specifying belongs
in the Properties dialog
15
Put files where users can find themDESIGN
PRINCIPLE
Rethinking Data Entry
Fixing data storage: a unified file model
Reversing Changes
Inadvertent (mistaken) changes requires an UNDO function not a
file system process
Discard all changes
Support for discarding all the changes made (function)… again
not a separate file system process
Creating a version
… with the function to return to the original at each point where
the version was created
A list of versions should exist, allowing the user to select any one
of the versions
The original document is the “first” version
17
Rethinking Data Entry
Fixing data storage: a unified file model
A new File menu (Figure 14-6)
• New and Open work as before
• Close closes the doc without a dialog or any other fuss after automatically
saving changes
• Rename/Move bring up a dialog that lets the user rename the current file or
move it to another directory
• Create a copy creates a new file that is a copy of the current doc
• Print collects all printer-related controls in a single dialog
• Create version is similar to copy, except that the application manages these
copies by way of a dialog summoned by the Revert to Version menu item
• Abandon Changes discards all changes made to the doc since it was opened
or created
• Properties opens a dialog that lets the user change the document’s type
• Exit behaves as it does now, closing the doc and the application
18
Rethinking Data Entry
Fixing data storage: a unified file model
A new name for the File menu
Label the menu according to the type of documents the application
processes (“Sheet” for a spreadsheet, “Invoice” for an invoicing app
Applications that actually represent the contents of disks or files…
should have a file menu
Communicating status
Indicate to the user that a file cannot be changed due to its use by
another application… the point here is that “the software should help
users understand the unintuitive actions.
19
Time for a change
The advantages of remaking the file system’s
represented mode according to users’ mental model
Effort is reduced if users don’t need to manage the their
computer’s file system
Users can store a document on disk as though it were a
journal on a shelf
Interaction designers need not incorporate puzzling file
system awareness into their products
New idioms… new learning curve, but not as steep
20
Rethinking Data Retrieval
How can we make it easy for people to find what
they’re looking for and find what they need?
… crafting an appropriate solution must start with a
good understanding of users’ mental models and usage
contexts
Storage versus retrieval
The use of folders and directories as a retrieval mechanism
requires users to know where an item has been stored in order to
locate it
Retrieval in the physical world
21
Rethinking Data Retrieval
Retrieval in the physical world
Retrieval by location
The storage system is the same as the retrieval system… both
require remembering locations
Indexed retrieval
The world of books and paper on library shelves
Every book has a unique “call number” based on its subject
Books are “arranged” numerically and by author’s last name
The user “participates” in this system of storage… using the
storage system
22
Rethinking Data Retrieval
Retrieval in the digital world
To find a file, you need to know its name and place
The user’s memory assumes 100% of the burden of file retrieval
The limitation “… is one of the most destructive, backward steps
in modern software design.”
The “disk file storage system” works but the “retrieval system”
not as well!
Digital retrieval methods
Positional retrieval – remember where “you” put it
Identity retrieval – remember the name
Associative / Attribute-based retrieval
Although this method is not provided
23
Rethinking Data Retrieval
Retrieval in the digital world
Attribute-based retrieval systems
The ease of finding files should match the ease of keeping files
A file system based on its single storage location must store each
document by a single attribute (client or document type) rather
than multiple characteristics
As storage and retrieval system does have access to information
at the time of creation and subsequent use of what is stored
24
25
Rethinking Data RetrievalAttribute retrieval systems
A retrieval system that learns & remembers
• The user that created or the users that contributed to the document
• The device that created the document
• The app that created the document
• The document’s contents & format
• Which app last opened the document
• The document’s size and whether it is exceptionally large or small
• Whether the document has been untouched for a long time
• The length of time the document was last open
• The amount of information added or deleted in the last edit
• If the document was created from scratch or cloned from another
26Rethinking Data RetrievalAttribute retrieval systems
A retrieval system that learns & remembers
• If the document is frequently edited
• If the document is frequently viewed but rarely edited
• If the document is frequently viewed but rarely edited
• Whether the document has been printed and where
• How often the document has been printed, and whether changes were made to it each time immediately before printing
• Whether document has been faxed, and if so to whom
• Whether the document has been e-mailed, and to whom
Apple’s OS X: Spotlight (Figure 14-7)
“folksonomy”
Retrieval mechanism achieved by “tagging” (manually specifying
attributes about documents)
Good examples noted… Flickr.del.icio.us, Twitter
27
Rethinking Data Retrieval
Relational databases versus digital soup
Users of database technology must
Define the form of the data in advance
Conform to that definition
Facts about users
They rarely can express in advance what they want
Even if they could, more often than not they change their
minds
Organizing the unorganizable
Failing the relational database litmus test
Divided into in, out and deleted
But no way to relate emails with associated (related) content
28
Rethinking Data Retrieval
Relational databases versus digital soup
Organizing the unorganizable
Failing the relational database litmus test
the Web
Equivalent to an infinite, chaotic, redundant, unsupervised hard drive
… the quantity of information and heterogeneity of its content defy
organization
Problems with databasesDo provide retrieval tools to find and fetch a record by examining its
content and matching against search criteria (again, not email!)
To allow for key words… fields for each must be defined in advance
Defining in advance doesn’t guarantee success users will follow the
required definition
Adding a set of keyword fields may not be enough
29
Rethinking Data Retrieval
Relational databases versus digital soup
The attribute-based alternative
The storage system
Accept any record regardless of size, length, type, or contents
Each record is assigned a “token” which could be used to retrieve
the record
Attribute-based retrieval
Create an index that stores a key value along with a copy of the
“token”
The number of indices in unlimited
Example: our email messages
Define an index for each worker/friend/company/meeting
Use the index to retrieve the associated email
30
Rethinking Data Retrieval
Relational databases versus digital soup
The attribute-based alternative
Attribute-based retrieval
Create an index that stores a key value along with a copy of the
“token”
The number of indices in unlimited
Example: our email messages
Define an index for each worker/friend/company/meeting
Use the index to retrieve the associated email
Requirements
The system must be able to read e-mail messages
Extract & index information such as names, Internet addresses, street
addresses, phone numbers, etc.
Make it easy to add ad hoc pointer to messages (a certain email pertains
to a certain value, whether or not the value is included in the message
31