Sounds like "undo", to me...
> * 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?
> Sounds like "undo", to me...
i agree. thats what i would do in a non-web environment. but things
like that are very hard/not well implementable for web applications..
a undo functionality, which works, but not really well because of
restrictions, doesn't really help in the end
what do you think about following:
the user entered some text in a existing item, presses 'add new item'.
he/she is asked if all old existing (and changed) items should be saved
if the user saved everything before adding a new item, the question
doesnt get asked..
On Sep 1, 2004, at 11:27 AM, Florian Weber wrote:
>> Sounds like "undo", to me...
> i agree. thats what i would do in a non-web environment. but things
> like that are very hard/not well implementable for web applications..
Aha. You listed your exceptios as (to paraphrase) (1) hard to implement
in web-based apps and (2) what if users decide they don't want the
changes they've made? -- I didn't realize that the second issue was
meant to be tied to the first.
> a undo functionality, which works, but not really well because of
> restrictions, doesn't really help in the end
Agreed: "sort of" working is generally worse than not working. I can't
comment on what might or might not be technically feasible. Didn't
someone say she'd worked with an effective undo for web-based apps? Or
maybe that was only auto-save for web.
> what do you think about following:
> the user entered some text in a existing item, presses 'add new item'.
> he/she is asked if all old existing (and changed) items should be saved
> as well.
> if the user saved everything before adding a new item, the question
> doesnt get asked..
Personally, I think this sounds reasonable, given your technical
restrictions; t's the solution that I would have suggested.
> 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.
i've done a few things like this. in my case, when the user clicked the Add
New Item button, they are redirected to a page where a single item is added
to their list. that item can consist of many things, in your case they would
select their photo for upload, and enter their 'caption' text. once they
submit that page, the photo is uploaded, the caption is written to the
database, and they're redirected back to the original page, which now shows
their added item (with an Edit and Delete button for each item in the list).
at this point, they can edit or delete each item in the list (Edit and
Delete buttons for each), or add another item to the list (Add New Item).
alternatively, you can simply combine both pages, and put the two fields
(photo upload, caption text) at the bottom or top of your display page.
every time they fill out the fields and submit, they add a single item.
they'll still only ever have the ability to add one item at a time, thus
your submit action only needs to deal with one set of records and one upload
at a time.
the UI advantage of this system is that the user has little or no confusion
about what's going to happen with each submit.