a new day… some new “excise”athena.ecs.csus.edu/~buckley/csc238/cooper_ch14_s2016.pdf ·...

32
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

Upload: letuyen

Post on 18-Aug-2018

217 views

Category:

Documents


0 download

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

16

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

e-Mail

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

Rethinking Data Retrieval

Constrained natural-language output

Not yet!

Still not possible for use in “run of the mill

computers”… it’s Watson, yes

Constrained natural-language

A set of bounded controls for users to choose

32