unsaved input

30 Aug 2004 - 12:05pm
10 years ago
18 replies
576 reads
Florian Weber
2004

hi!

i'm having a application where a user can fill out a list. for example:
each list item is a text input field and a file upload field for a
photo.
the user can add new list items by clicking on a button.

now wondering how to deal with situations where the user
wrote text, selected a file for an existing item and then presses
the 'add new item' button, before actually saving the item she/he
just filled out.

adding a new item requires some server action to executed. so
i'm forced to store the values the user entered, but didnt save
yet, temporary and use them again (instead of the real values)
when the edit pages comes up again.

now my problem:

i cant force the file input element to pick up the files the user
selected before the 'add new item' request.

basically there are only three ways:

* ignore it completely and let the user pick the files again
* find some way to display the current saved photo, the
temporary unsaved photo and the file input dialog
* display the temporary unsaved photo like a 'current saved photo'

all three ways unfortunately sound kinda bad to me.

what you would you recommend?

thanks for any tipp!

ciao!
florian

Comments

30 Aug 2004 - 1:10pm
Dave Collins
2004

>now wondering how to deal with situations where the user
wrote text, selected a file for an existing item and then presses
the 'add new item' button, before actually saving the item she/he
just filled out.

I may not be seeing this clearly enough. Why is there an active 'Add
New' button when that is not the next step for the user? The next step
is 'Save'. So don't give them a button they shouldn't be using.

Alternately, if you want to save a bit of time, you could have the 'Add
New' button on-screen, but disabled. Enable it once the user Saves
(though I assume that'd require a page refresh anyway, so we're back to
option 1).

30 Aug 2004 - 1:32pm
Florian Weber
2004

>> now wondering how to deal with situations where the user
> wrote text, selected a file for an existing item and then presses
> the 'add new item' button, before actually saving the item she/he
> just filled out.
>
> I may not be seeing this clearly enough. Why is there an active 'Add
> New' button when that is not the next step for the user? The next step
> is 'Save'. So don't give them a button they shouldn't be using.

okay. i didnt describe it clear enough. the save button will save
the whole list (with all of its items).

basically if there are three list items the screen will look like

- add new list button

1st item
- text input
- file input

2nd item
- text input
- file input

3rd item
- text input
- file input

save button

so at any time the next step for the user could be save the list
(without adding another list item) or adding another list item

31 Aug 2004 - 1:20am
Florian Weber
2004

On Aug 31, 2004, at 3:58 Uhr, Jef Raskin wrote:

> I don't really want to get into another long discussion, but we should
> never need a Save button or command. A system should preserve a users'
> work as its default behavior. Whenever I've built such systems, users
> have been delighted (also, they don't lose work).

while it works perfect in most situations, imho, there are two
situations
where it simple doesn't:

* technical restrictions. for web applications it would be very hard to
implement
such an auto-save functionality. most of the time it wouldn't really
work very
well.

* what if the data entered is quite complex and long. for example if a
user
changes the text of a existing item, but then in the middle figures
that he/she
just wants to keep the old text?

31 Aug 2004 - 3:28am
Donna Maurer
2003

I did this once, on a browser-based app (it was an internal app, so the
response time was fast) and still think that it was the right decision,
despite lots of feedback on my blog that I should have included a save
button for 'consistency' (with other apps):
http://www.maadmob.net/donna/blog/archives/000083.html

In this case, the users were delighted, though they didn't know it. Saving
would have taken a *lot* more user effort and would have resulted in a
*lot* more error. The only negative comment was that people got to the end
of the entire process easily then said 'what do I do now'.

Donna

At 05:20 PM 8/31/2004, you wrote:

>while it works perfect in most situations, imho, there are two situations
>where it simple doesn't:
>
>* technical restrictions. for web applications it would be very hard to
>implement
>such an auto-save functionality. most of the time it wouldn't really work very
>well.
>
>* what if the data entered is quite complex and long. for example if a user
>changes the text of a existing item, but then in the middle figures that
>he/she
>just wants to keep the old text?

-------------------------------------------------
Donna Maurer
Usability Specialist
Step Two Designs Pty Ltd
Knowledge Management / Content Management / Intranets

http://www.steptwo.com.au/
donna at steptwo.com.au
(02) 6162 6307

-------------------------------------------------
New Workshop: Introductory Information Architecture
http://www.steptwo.com.au/seminars/041013/index.html

31 Aug 2004 - 3:47am
Mark Canlas
2003

1. Can you duplicate the saving function when the user clicks add? That is,
the state will be saved, no matter what state the user enters, either an
explicit save or an implicit save on add.

2. Disable the add new button until the user clicks save. Kind of annoying,
but something to consider.

Mark Canlas
http://www.htmlism.com/mark/

> adding a new item requires some server action to executed. so
> i'm forced to store the values the user entered, but didnt save
> yet, temporary and use them again (instead of the real values)
> when the edit pages comes up again.

31 Aug 2004 - 10:22am
jstanford
2003

In regards to the person who suggested that there is no reason why a Save
button is needed and the app should always Save, I have an interesting
finding from a user study that I conducted a few years ago for a financial
application.

We were also very interested in automaticallly saving the user's input so we
did not have any sort of Save button in the original design. Users could
click to different areas of the application that held their data, make
changes, go to other areas, and (voila!) everything would always be
automatically saved. However, in user testing, this severely backfired. Not
because users did not want their data saved, but because all other
applications provided them with a Save button and they were concerned that
if they did not hit Save, their data would be lost. So, we observed an
interesting phenomenon where users would enter informaton on a screen and
then would sit and stare uncomfortably for a while, looking confused. We
would ask them what they were looking for and they would explain that they
were looking for a "done" or "save" button to tell the computer that they
were done with this screen so that it could be saved and they could move on
to the next step in their task. Even telling users that the application
saved their data, did not help the situation. When we tested a revised
design that had a save button, everything worked great.

So, my point is that although it is technically feasible to automatically
Save information and less steps for the users, in some cases the user may
have been "trained" that they need to save their data so removing that
option from them leaves them feeling like they have not completed a task and
cannot move on.

In another application I created that involved organizing photos, I was able
to create an interaction that did not demand a save button. The target
audience was professional film photographers who were moving into the
digital word. In this case, users expected that if they moved photos around
on a screen or made some touchups that the information would automatically
be saved (because that is how it works in the real world if you are dealing
with physical photos) so the lack of Save button was wonderful.
_____________________________________
Julie Stanford
Principal, Sliced Bread Design | www.slicedbreaddesign.com
650-799-7225

30 Aug 2004 - 12:17pm
Listera
2004

Florian Weber:

> i cant force the file input element to pick up the files the user
> selected before the 'add new item' request.

Don't you always have to assume that filepaths are temporary and, thus, any
saved location info may be out of date at any given moment?

Ziya
Nullius in Verba

30 Aug 2004 - 7:58pm
Jef Raskin
2004

I don't really want to get into another long discussion, but we should
never need a Save button or command. A system should preserve a users'
work as its default behavior. Whenever I've built such systems, users
have been delighted (also, they don't lose work).

On Aug 30, 2004, at 12:32 PM, Florian Weber wrote:

>>> now wondering how to deal with situations where the user
>> wrote text, selected a file for an existing item and then presses
>> the 'add new item' button, before actually saving the item she/he
>> just filled out.
>>
>> I may not be seeing this clearly enough. Why is there an active 'Add
>> New' button when that is not the next step for the user? The next step
>> is 'Save'. So don't give them a button they shouldn't be using.
>
> okay. i didnt describe it clear enough. the save button will save
> the whole list (with all of its items).
>
> basically if there are three list items the screen will look like
>
> - add new list button
>
> 1st item
> - text input
> - file input
>
> 2nd item
> - text input
> - file input
>
> 3rd item
> - text input
> - file input
>
> save button
>
> so at any time the next step for the user could be save the list
> (without adding another list item) or adding another list item
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

30 Aug 2004 - 9:24pm
Dan Cooney
2004

Florian,

My suggestion: when the user presses the 'add new item' button, have
the system save any changes. Make this explicit by changing the name
of the button to something like "save changes and add new item".

I say this 1) because we've run into a similar problem/behavior on a
system I work on - and the behavior/interface seems to work for the
users, and 2) because if the user is moving on to adding new things,
there is a very good chance they are finished with the previously
entered material, and are being forced to choose between saving what
they've done and moving to the next thing. Giving this natural 2-in-1
button saves them time and might match their mental model better.

If you can shrink the button label from it's grotesquely long "save
changes and add new item", to something like "save and add new", and
not loose comprehension along the way, that would be a nice bonus.

all the best,
Dan Cooney

(my first post here!)

On Mon, 30 Aug 2004 21:32:17 +0200, Florian Weber
<csshsh at structbench.com> wrote:
> >> now wondering how to deal with situations where the user
> > wrote text, selected a file for an existing item and then presses
> > the 'add new item' button, before actually saving the item she/he
> > just filled out.
> >
> > I may not be seeing this clearly enough. Why is there an active 'Add
> > New' button when that is not the next step for the user? The next step
> > is 'Save'. So don't give them a button they shouldn't be using.
>
> okay. i didnt describe it clear enough. the save button will save
> the whole list (with all of its items).
>
> basically if there are three list items the screen will look like
>
> - add new list button
>
> 1st item
> - text input
> - file input
>
> 2nd item
> - text input
> - file input
>
> 3rd item
> - text input
> - file input
>
> save button
>
> so at any time the next step for the user could be save the list
> (without adding another list item) or adding another list item
>
>
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

31 Aug 2004 - 11:02am
Dave Malouf
2005

I think that Julie's challenge to the save onChange concept is a clear
example of how context of use is really important.

I love save onChange for my palmBased devices. It just works really well, so
this way "modality" is just never an issue. This works b/c the types of
changes I make are done in a very short interval and there is no network
involved, so the concept of "committing changes" is not a requirement.

But in two cases such as a network-based application or where the tasks
being done iterate often between "mental" saves; it is very necessary to
have a state called "saved" vs. "in progress".

This brings up other reasons to have "save" as a tangible trigger. Save
might not be your only option. "Save as draft"; "Save as", etc might be
required. AND lastly you might have to commit to a lifecyle change at some
point as well and you only want to do that at a defined tangible point. Last
thing is security or perception of security.

-- dave

5 Sep 2004 - 2:21pm
Andrei Herasimchuk
2004

On Aug 30, 2004, at 6:58 PM, Jef Raskin wrote:

> I don't really want to get into another long discussion, but we should
> never need a Save button or command. A system should preserve a users'
> work as its default behavior. Whenever I've built such systems, users
> have been delighted (also, they don't lose work).

Except of course when I'm just doodling and don't want the system to
save over something at the point I forced a save by using the Save
command. Otherwise, I might have to multiple undo to back out of the
changes, and who knows, maybe I screwed up the undo tree in that
process?

Another nice idea that has a wealth of problems in real world execution.

Andrei

5 Sep 2004 - 7:18pm
Jef Raskin
2004

Dave's suggestions require the user to remember to be clever as to
where they might want to go back to. Sometimes we remember to save an
intermediate state, sometimes we don't. Sometimes we only realize later
that an intermediate state is the one we wanted.

Putting the burden on the user, when it can be done better by computer,
is, I think, not as good interface design as possible. I do not
understand why "save as draft" is ever necessary. The "Save As"
function is simply making a copy and giving it a new name. If you have
a mechanism for making a copy and a mechanism for naming something,
then "Save As" is redundant. I think that the principle of "monotony"
suggests that we not make our users learn a different command.

When I've built systems with no Save command, they have been received
(by users) very favorably. Palm's automatic saving is, as you mention,
a good example.

As usual, whether you can get away without Save depends on the other
facilities available in the system.

On Aug 31, 2004, at 10:02 AM, David Heller wrote:

> [For those using lower bandwidth, or the DIGEST version of this list;
> the administrators ask people to voluntarily trim their postings to
> only include relevant quoted material.]
>
> I think that Julie's challenge to the save onChange concept is a clear
> example of how context of use is really important.
>
> I love save onChange for my palmBased devices. It just works really
> well, so
> this way "modality" is just never an issue. This works b/c the types of
> changes I make are done in a very short interval and there is no
> network
> involved, so the concept of "committing changes" is not a requirement.
>
> But in two cases such as a network-based application or where the tasks
> being done iterate often between "mental" saves; it is very necessary
> to
> have a state called "saved" vs. "in progress".
>
> This brings up other reasons to have "save" as a tangible trigger. Save
> might not be your only option. "Save as draft"; "Save as", etc might be
> required. AND lastly you might have to commit to a lifecyle change at
> some
> point as well and you only want to do that at a defined tangible
> point. Last
> thing is security or perception of security.
>
> -- dave
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

5 Sep 2004 - 8:04pm
Listera
2004

Jef Raskin:

> I do not understand why "save as draft" is ever necessary.

You're in an app and working on a doc called "Foo." You want a duplicate of
it in its current state, you do a "Save As" and call it "Bar." Now the doc
you're working on is called "Bar."

> If you have a mechanism for making a copy and a mechanism for naming
> something, then "Save As" is redundant.

In OS X, you'd need to first save "Foo," close the doc, switch to another
app called "Finder," locate "Foo," duplicate it, rename it "Bar" and open
it.

"Save As" allows you to do all that in one step from within the app you're
already using.

Ziya
Nullius in Verba

6 Sep 2004 - 1:52am
Jef Raskin
2004

On Sep 5, 2004, at 7:04 PM, Listera wrote:

> Jef Raskin:
>
>> I do not understand why "save as draft" is ever necessary.
>
> You're in an app and working on a doc called "Foo." You want a
> duplicate of
> it in its current state, you do a "Save As" and call it "Bar." Now the
> doc
> you're working on is called "Bar."
>
>> If you have a mechanism for making a copy and a mechanism for naming
>> something, then "Save As" is redundant.
>
> In OS X, you'd need to first save "Foo," close the doc, switch to
> another
> app called "Finder," locate "Foo," duplicate it, rename it "Bar" and
> open
> it.

What does the dreadful OSX have to do with this discussion?

>
> "Save As" allows you to do all that in one step from within the app
> you're
> already using.

In THE, you never have to name files, so it is one step in that system.
Also you defended "save as" but not "save as draft" which is what I was
discussing.

>
> Ziya
> Nullius in Verba
>
>
>
>

6 Sep 2004 - 2:06am
Listera
2004

Jef Raskin:

> What does the dreadful OSX have to do with this discussion?

It's an actually-shipping OS, the one I and, I suspect, many others on this
list happen to be using. I wasn't aware that the discussion was about
imaginary OSes.

> Also you defended "save as" but not "save as draft" which is what I was
> discussing.

I wasn't "defending" anything. You said,

>> If you have a mechanism for making a copy and a mechanism for naming
>> something, then "Save As" is redundant.

So I explained why "Save As" was more efficient if you had to (separately)
copy, name and save.

Ziya
Nullius in Verba

6 Sep 2004 - 8:43am
Elizabeth Buie
2004

Jef Raskin writes:

>I don't really want to get into another long discussion, but
>we should never need a Save button or command. A system should
>preserve a users' work as its default behavior.

As long as it lets me return to an earlier state, OK. Otherwise, *I* want
to be in control of when it saves.

One thing I like about Photoshop (and use a lot) is the capability to save
a file and still go backwards in the history to an earlier state.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

6 Sep 2004 - 1:05pm
Florian Weber
2004

>> i cant force the file input element to pick up the files the user
>> selected before the 'add new item' request.
>
> Don't you always have to assume that filepaths are temporary and,
> thus, any
> saved location info may be out of date at any given moment?

well, i would assume that the filepath is still correct 0.2 seconds
later,
after the new item was added =)

7 Sep 2004 - 6:14am
hans samuelson
2003

>> [JR] I don't really want to get into another long discussion, but
>> we should never need a Save button or command. A system should
>> preserve a users' work as its default behavior.
>
> [EB] As long as it lets me return to an earlier state, OK. Otherwise,
> *I* want
> to be in control of when it saves.
>
> One thing I like about Photoshop (and use a lot) is the capability to
> save
> a file and still go backwards in the history to an earlier state.

I also appreciate this Photoshop feature (and use it frequently), but
there's an even better model, IMHO, which is Discreet's high-end video
compositing software—expensive and unix—called flint, flame, or
inferno, depending on how much you pay for the hardware underneath.
Their interface, which wisely and accurately makes no claims to be
intuitive, has one pane that shows a process tree: a nodal,
hierarchical, graphic representation of each process that has been
applied to the video (scaling, color correction, FX, etc.). Using
this, it's possible to go in and tweak or delete individual parameters
and processes without losing the overall shape of the processing tree.
Stepping back through the Photoshop history has an annoying tendency to
do away with many useful intermediate steps, and it's often necessary
to do a delicate dance to work around the potential loss of time and
effort. But it's appreciated all the same.

The abstraction of process from result is very powerful, and somewhat
underutilized in graphic editors, for whatever reason; often we get to
see and play with processes in preview mode, but they are then
immediately committed once the effect or parameter is accepted (though
some of the newer Photoshop concepts, like adjustment layers, do give
the possibility of dynamically changing parameters later in the game,
just as vector shapes and text layers are now treated dynamically, to
our sometime delight). I often used After Effects in the past for
still picture manipulation, simply because it provided a more complete
abstraction of the process, and it was easier to play with combinations
of effects without having to repeatedly undo. Pain in the --- to get
an image out at the end of the process, though.

Process abstraction is also a model used in audio editors like ProTools
(and the remarkable Spark from TC Electronics), where it has become
possible to apply effects either as a dedicated one-time application
that overwrites or creates a copy of the underlying source data, or as
a run-time effect that treats the output signal while leaving the raw
source data untouched. Advances in hardware have made this far more
powerful than in the past, and such systems are much more satisfying to
use.

I am trying to think of an equivalent in text editing, but as far as I
know, no one has yet invented the Hemingway (Hurston, Morrison, Twain,
Orwell) filter that I could apply to my own leaden prose as a
convenient Textoshop plug-in. Some things do not translate easily
across all media forms. Perhaps a time-based abstraction would be
possible — nick out all the changes which were made between 7:45 and
11:00 last night, but keep the changes from 11 to 2, when the muse
finally settled in. But the metadata cost could get pretty high,
depending on the granularity of control.

Just to finish the thought, process abstractions also help with
autosaving, since changes to audio files (often large and therefore
more prone to errors of all kinds, including the statistically
improbable) that are being committed to disk at the time of a crash
have an unfortunate tendency towards entropy. Basically, the only
thing worse than a system that doesn't automatically save your changes
is one that crashes while saving them, without even asking your
permission first...

Syndicate content Get the feed