User Initiated Save vs. Implicit Save

16 Oct 2008 - 10:17pm
6 years ago
13 replies
1851 reads
Adam Connor
2007

I'm currently working on a project that consists of a fairly lengthy
data entry activity.

Today, this process is done through filling out a series of paper forms,
which themselves are fairly. There is an initial set of forms, and then
depending on how those are filled out, other forms may be required. The
smallest possible set of forms consists of 12 full pages of data.

We are now working to put this process online. The original thinking was
to utilize a stepped process for moving the user through the forms
progressively. However, due to the type of information gathered, it
became clear that the user may not have all the information at once, so
he/she will need to skip past sections and be able to return to them later.
Due to the sheer size and length of this process, forcing a user to step
forward or backward through the forms to find the one he/she has data
for seems to intensive, so we plan to provide a navigation utility to
move to any particular section.

This also necessitates that a user be able to "save" their semi-complete
forms to return to later.

All of this has brought up the question of implicit saving of data vs.
user initiated save.

For example if I'm on one form, complete it and click a "next" button to
move to the next form, should the data I entered be automatically saved.
Most seem to expect it to be? What about the situation where I complete
one form and then jump to another in the process, not the previous or
next one, but say 5 steps away? Should my data be automatically saved?

And how about if I want to stop filing in the forms now, because I don't
have any more data to provide right now and need to go gather it so I
can fill it in later. Should there be an explicit "save" button for that
situation? And if so, doesn't having a save button for that situation
raise some consistency issues with the fact that the other two
situations don't require the user to manually initiate a save?

We are doing some user studies on paper prototypes to get a glimpse of
what the user would expect, but the results to this point have not
exposed a clear answer. I'd love to get some of your opinions.

Thanks ahead of time.

--
adam connor
little green toaster
www.littlegreentoaster.com
413.244.4457
adam at littlegreentoaster.com
twitter.com/adamconnor

Comments

17 Oct 2008 - 12:17am
Andreas Ringdal
2008

I think Confluence from Atlassian has solved quite nicely.
When I edit or create a new page in the wiki, the content is saved in
the background. If I navigate away from the form, and return at a
later stage to either the page I was editing or the new page for, the
present a notice above the form with the following text: "A new page
you were adding on 2008-10-17 07:10 called %u201Ctestpage %u201D was
not saved. Do you want to resume editing or discard it? " (Resume
edit and discard is behaving as link buttons). Unless I explisitly
clicks the save button, it is not committed to the live content of
the wiki.

The question here shold not be if you should save the data, but
rather how should you handle the process. With the stability of
browser and the possibilities of accidental navigating away from the
form, you should save all data to a temporary storage.

The challenge is how to present the user with automatically saved
data.
Should the entered data be available to other users, or just the user
who has started to enter it into the form?

Andreas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

17 Oct 2008 - 8:23am
Jack L. Moffett
2005

Adam,

I do a lot of work with forms in industry—data logging, reporting,
etc. I tend to have software save values as they are entered, rather
than saving by page or document. This insures that data isn't lost due
to dropped connectivity, hardware/software failure, or any kind of
browser redirect. Data in a field is saved on loss of focus.
Checkboxes, radio buttons, and menus save selections on change.

In this type of work, there is very rarely, if ever, a case in which
the user wants to do the equivalent of "closing without saving". These
applications typically have "undo" features, which cover the case of
accidentally changing a value. During field trials of one such
application, I believe one or two users specifically asked when or how
the data was being saved. There has been no confusion about the lack
of a Save button and no requests for the application to work
differently.

On the other side, I work on document-centric software. In these
cases, I follow the explicit save model, as the user is opening a
document, making changes, and closing it. There is more likely to be a
case that they would want to discard changes made. A document contains
multiple pages (typically navigated by tabs), and the Save buttons
saves the entire document. Values are stored temporarily to allow
navigation between the pages, of course, but not committed until the
explicit save. An alert will remind the user to save if s/he tries to
close or navigate away from the document.

Best,
Jack

On Oct 16, 2008, at 11:17 PM, Adam Connor wrote:

> For example if I'm on one form, complete it and click a "next"
> button to move to the next form, should the data I entered be
> automatically saved. Most seem to expect it to be? What about the
> situation where I complete one form and then jump to another in the
> process, not the previous or next one, but say 5 steps away? Should
> my data be automatically saved?
>
> And how about if I want to stop filing in the forms now, because I
> don't have any more data to provide right now and need to go gather
> it so I can fill it in later. Should there be an explicit "save"
> button for that situation? And if so, doesn't having a save button
> for that situation raise some consistency issues with the fact that
> the other two situations don't require the user to manually initiate
> a save?

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

If there's anything more annoying
than a machine that won't do what you want,
it's a machine that won't do what you want
and has been programmed to behave
as though it likes you.

- Don Norman

17 Oct 2008 - 10:18am
jrrogan
2005

In the application I'm presently working on, we take a similar approach to
Andres "Atlassian", but present this message at the point of navigation away
from form, without saving, (this is a fairly standard point to present the
message). The message has typical actions "Return", "Discard/Cancel" "Save".

As Jack pointed out, saving data as the user enters it, is always a valuable
feature. I differ with Jack in that a "Save" button can be a benefit in this
case as well, as it reinforces to users that their data has been saved,
(note this reinforcement is more important with non-repetitive, non-trivial
data entry), (I'll caveat for experienced user's forcing a "Save" for no
purpose does suck).

Also given users may want to discard any entries, it would be kind of odd to
have just "Undo" options. Thus a "Cancel" button - negative action becomes
valuable, and should also have a corresponding positive action, such as
"Save".

We also have the case of different execution options of initial "Save" VS
"Discard" and interim "Save" VS "Undo" VS "Discard".

And lastly there's the interim "Save" VS "Submit", with "Submit" being an
actual and necessary Finalization step, (leads to workflow, etc).

--
Joseph Rich Rogan
President UX/UI Inc.
http://www.jrrogan.com

17 Oct 2008 - 10:29am
DampeS8N
2008

Users shouldn't have to understand SAVE. However, they already
understand and you should make use of SUBMIT.

In other words. Store the heck out of the thing at any point, and
then require the user to Submit the form at the end and flip in.

Store every time the user changes a page, store internally whenever
the user switches form fields when there has been a change, and show
the user how much they have completed and where they need to go to
finish.

It is also helpful to allow the user to navigate away and come right
back to where they left off without having to skip pages by hand.

This works even for repeat forms, since the Submit process logically
clears the form.

This only doesn't work completely if the user needs to edit multiple
forms all at once, or will need to swap between more than one form at
a time of the same format.

However, it can be made to do that easily with some thought.

Also, don't forget to have defaults for everything that makes sense
to have a default. If you aren't sure what would make a good
default. Have the system generate one automatically by keeping track
of fields that need a default... For example... you may not know what
a good default might be for something like an internal ORG code, but
you can keep track of which code is used the most and make that the
default. Or better, keep track for everyone, and also for each
individual, and after they have submitted a form use their own
default.

The end result should be something really fast to fill out
repeatedly, and even if it is something people fill out once only, it
will be faster because the defaults are truly logical.

Remember, a wrong default is better than no default.

Will

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

17 Oct 2008 - 10:33am
Jens Meiert
2004

> All of this has brought up the question of implicit saving of data vs. user
> initiated save.

Oh I may feel lazy:
<http://meiert.com/en/blog/20070625/a-plea-for-better-software-provide-auto-save/>.
Meaning that user input should always get saved thus protected
(ideally followed by undo functionality).

--
Jens Meiert
http://meiert.com/en/

17 Oct 2008 - 10:39am
Jack L. Moffett
2005

I should probably also mention that the data logging / reporting
software I was referring to is collaborative, such that the data is
immediately shared with other users logged into the system working on
the same task. Because of this, a save button is superfluous—probably
even detrimental to the understanding of the way in which the software
works. I recognize, of course, that this is an edge case, but a common
one in the industries I work in.

Jack

On Oct 17, 2008, at 11:18 AM, Rich Rogan wrote:

> As Jack pointed out, saving data as the user enters it, is always a
> valuable
> feature. I differ with Jack in that a "Save" button can be a benefit
> in this
> case as well, as it reinforces to users that their data has been
> saved,

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

To design is much more than simply
to assemble, to order, or even to edit;
it is to add value and meaning,
to illuminate, to simplify, to clarify,
to modify, to dignify, to dramatize,
to persuade, and perhaps even to amuse.

- Paul Rand

17 Oct 2008 - 4:55pm
Susan Fowler
2008

Just a tiny note: When you're doing user studies, ask about closure.
People tend to save when they've come to the end of
something--reached closure.

The closure points in data entry tend to be "I finished this page
finally" or "I've put in all 12 pages." In interactive systems
like word processors or spreadsheets, the closure points are "I've
finally got that idea down on paper" or "I've finally figured out
that formula."

While you're watching your users, listen for a satisfied sigh or
watch for the person putting down the pencil. Ask why they sighed or
put down the pencil. If they say, "I finished that part," then
that's probably a good "Save" point.

Not that you have to put an actual Save button there. If your input
pages are on tabs, for example, switching to the next tab would be an
implicit save (with a message in the status bar saying "Saving page
2" or whatever). Or it you use Next and Previous, each movement
after data input would be an implicit save.

This may bring up data-integrity issues. In the database systems I'm
familiar with, the implicit Saves save the information locally and the
"Submit" on the last page sends it to the database. At that point,
Undo is not possible; you have to explicitly open the record and
change the data.

--Susan

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

17 Oct 2008 - 9:16pm
DampeS8N
2008

I still say interaction designers doing user study is kind of like an
architect asking what parts of the house they should knock down so
they can make what the people really wanted to live in.

If you are doing your job right, you should have gotten it right the
first time. Rather than wasting countless dollars developing
something that doesn't work, in the hopes that you can fix it by
seeing how users deal with it.

I'd like to see study for the sake of study only, much like we have
science for the sake of science. Then take what we learn through
study, create rules based on long chains of study, and then never
have to do those same studies again.

You know, apply the scientific method to informing us, and then use
our expertise to make better products cheaper and faster.

We know a lot about how to build systems that make sense and have
intelligent saving. I don't think we need to do any study to solve
the saving problem we were presented with here.

Will

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

17 Oct 2008 - 9:20pm
Adam Connor
2007

Thanks everyone. What it seems we're running into is a conflict
between two mental models.

The first appears in the younger, more internet savvy users. They
seem to understand/expect the progressive save of there data and
don't expect to have to explicitly save their changes when they want
to leave the set of forms they are working on so that they can return
to it later.

The other group is slightly older and less used to current RIA
paradigms. Their mental model seems to be inline with the document
style model of applications like Microsoft Word, where each new set
of forms they create, is the equivalent of a document. They go in,
make their changes, and expect to explicitly tell the system to save
what they've done.

It strikes me now that I may have left out a distinguishing attribute
of this process from my original description:

The audience for this tool is finite, and a user creates many
different sets of forms. Essential, as it's no secret I work in the
insurance industry. This system is an online tool for Agents to
compile applications for their clients. In other words the users are
our agents, and they compile and fill out a new set of forms for each
sale they make.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

17 Oct 2008 - 10:37pm
DampeS8N
2008

Take a tip from the Game Industry. Turn the next button into a store
and proceed, or save and continue, button.

No one has to know that it was saved before they hit it and it is now
only moving them to the next step.

Allow the auto save to be discoverable, even mention that it will
auto-save so those savvy will pick up on it.

This will let those who don't know/trust auto-save to be happy, and
provides it for those who need it.

Will.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

18 Oct 2008 - 7:04am
Susan Fowler
2008

Adam: A long time ago, I worked in the insurance industry, too,
defining online forms.

Will: Sounds right to me. In fact, it sounds the same as what I was
suggesting.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

18 Oct 2008 - 7:12am
Susan Fowler
2008

Speaking of forms, a call for papers:

User Experience (UX) is the the print magazine of the Usability
Professionals' Association (UPA).

Issue 8.2 is themed "Usable Forms".

Guest editors Caroline Jarrett and Gerry Gaffney are seeking
submissions on the theme.

For more about the magazine, and for submission guidelines, see:

http://www.upassoc.org/upa_publications/user_experience/index.html

The audience is usability practitioners; the magazine has a
global distribution.

Although the official submission date is listed as January 2, we
suggest aiming for early November, as we expect to receive a large
number of high-quality submissions.

You can submit an outline proposal - or queries - by email to
Caroline or Gerry:

caroline.jarrett (at) effortmark.co.uk
gerry (at) infodesign.com.au

We would particularly value articles that are practitioner-focused,
include case studies, and are well-illustrated. Articles are
typically 1500 or 2250 words in length.

- Gerry & Caroline

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=34463

17 Oct 2008 - 12:34pm
Guillermo Ermel
2008

"If it's worth the user entering, it's worth the program remembering"

(chapter 15 of About Face 2.0: The Essentials of Interaction Design, By
Alan Cooper and Robert Reimann)

> All of this has brought up the question of implicit saving of data vs.
> user initiated save.
>
> For example if I'm on one form, complete it and click a "next" button to
> move to the next form, should the data I entered be automatically saved.
> Most seem to expect it to be? What about the situation where I complete
> one form and then jump to another in the process, not the previous or
> next one, but say 5 steps away? Should my data be automatically saved?
>
> And how about if I want to stop filing in the forms now, because I don't
> have any more data to provide right now and need to go gather it so I
> can fill it in later. Should there be an explicit "save" button for that
> situation? And if so, doesn't having a save button for that situation
> raise some consistency issues with the fact that the other two
> situations don't require the user to manually initiate a save?
>

--
Guillermo Ermel
Responsable de usabilidad
MercadoLibre.com

Syndicate content Get the feed