The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Web design / usability question

I am developing a web application where the user can manage a various concepts (entities in the database). By manage I mean list, insert, update, delete and search. I am trying to get to a common format/design to the maintanance pages.

So far I have these two pages:

1) List page
2) New and Edit page

In the list page:

I have a grid that lists all the records and a pagination control. I also have an "ADD NEW" button. In the grid I have buttons "EDIT" and "DELETE" for each row.

When the user clicks on "ADD NEW" or "EDIT" he is taken to the second page (New and Edit). It's a single page for both adding and editing records. I pass to this page the mode that it will be opened ("insert mode" or "edit mode"). Based on this mode it ajusts some labels and controls.

My question is: on the "New and Edit page", after the user types all the information and click "ADD" (insert mode) or "SAVE" (edit mode), what would be the best to happen?

Some possibilities:

1) it adds or saves the record and returns immediatly to the list page. In the list page I may or may not show a message "record successfully added or saved".. I also have two possibilities:
  1-a) the list page will have the same state (list filter, page number...) that it had before the user left it;
  1-b) the list page will have a reseted state;

2) it adds or saves the record, displays a success message and stay on the same page (in case the user wants to add another record or edit again the same record)

I am walking in circles, can't decide what to do. What do you suggest?

Thanks.
Confused
Thursday, November 10, 2005
 
 
Do your users regularly add more than one record at a time? This is the question you need to ask. If yes, it's more efficient to return them to the add new page with a confirmation of success. If no, then back to the main listing.

It should be surmisable from the type of task and monitoring usage which of these is correct.
Andrew Cherry Send private email
Thursday, November 10, 2005
 
 
There's another possibility.

Since you have an edit button for each row, you may want to consider having an "update" button on each row instead.

What I've found is that my users tend to treat the grid as a spreadsheet; they'll scan the entire page, and try to make corrections to the page as they go along.  I did try a separate edit page, but consider the following situation...

I have a grid that prints the name and mailing address of my customers (one per row).  I have several customers that hail from Albuquerque, New Mexico.  In this format, it's easy to see that one of my customers mispelled Albuquerque.

In your scenario, I have to click the edit button, go to a new page, and remember how to correctly spell the city.

In my scenario, the correct spelling is right in front of me - better yet, I can just cut and paste the city name from one row to another.

I'm not saying this is the right thing to do - it really depends on the data itself (or the context of your application).  But if you're struggling with trying to find an intuitive way of updating the records, it helps to think of why you might want to update the records, and if you're really going to focus on one and only one record at a time.

There are cases when I would want to use a separate edit page.  For example, if I had a receipe database and I wanted to adjust the portions and play around with the possibilities before I saved it.
Anonymous Coward
Thursday, November 10, 2005
 
 
Put a checkbox at the bottom - "Would you like to add another record?"

Put the user in charge of everything.
user
Thursday, November 10, 2005
 
 
They say you can't give users many choices. They don't like to think much.

Thursday, November 10, 2005
 
 
You know, I've always had trouble with that confirmation checkbox at the bottom (or in this case, the more records checkbox).

Philosophically, the checkbox is just another choice the user has to make.  In this case, the user has to choose "yes/no additional changes" and then choose "submit".  I find having three buttons representing "submit and do a new one", "submit and go back" and "cancel and go back" tends to be more intuitive.

But there are practical reasons why you'd want to use a checkbox - to confirm that you've read all the legalese before you purchase a plane ticket, for example.
Anonymous Coward
Thursday, November 10, 2005
 
 
When the data presented in a grid is a subset of a record, a place to view and edit the entire record is needed. Rather than taking the user to a different place, consider using an area in the same screen for edits and updates. When the entire record can be viewed in the grid, it is benificial to edit and update in place, assuming technical issues can be overcome. Changes should be reflected in the grid after save/update. An additional non-intrusive status indicator is helpful. Errors should be handled and/or reported in a user-friendly way. Great tips from others on editing next record or returning to the grid.
Nonymous
Thursday, November 10, 2005
 
 
If the user will frequently (over 1/3 of the time) be adding multiple records, I advocate having separate 'Insert and Add Again', 'Insert and Return', and 'Cancel and Return' buttons. If they rarely add multiple records in a row, it is probably better to only have 'Insert' and 'Cancel' buttons. A small usability test would help you choose which is more appropriate for your users.

I am not a fan of inline editing normally, due primarily because of the problems assicated with informing the user about invalid input.

When you have a full page edit/input, you can put informational error messages right next to the control that has invalid input. You can also check multiple fields, and put multiple errors, one next to each invalid input. But when you try to edit things on a grid, you have no room to put errors right next to the appropriate field. You have to resort to errors placed at the top of the page, or inserted clumsily and cramped into the grid... bad handling of wrong user input is a prime problem with most data entry applications, and trying to use a grid exacerbates the issue.

I also strongly believe that if the user can customize how the list is displayed, that customization should not be clobbered after every edit/insert... that would likely cause user frustration. If possible, the list should scroll (with an #anchor) back to the record that was just modified or inserted when they return to that page, and the new record(s) should be highlighted.
Myrddin Emrys Send private email
Thursday, November 10, 2005
 
 
Anonymous and Nonymous are right. If you can keep it on one page, keep it on one page, and that’ll solved your problem and make for a simpler and less awkward UI that in my opinion outweigh concerns about error messages. If you can’t do that, let your task frequencies dictate the solution. For example, let’s suppose users usually do a quick edit and return to the list --the fields are relatively few, and there’s little point in the users hanging out on edit page if they’re not actively editing (e.g., users aren’t going to edit a little, wait for some event, then re-edit the same entity). If that describes your situation, it’s pretty clear that Save should bring the user back to the list because usually saving is only needed when editing it done and users will be ready to go back. On average you save more clicks, and reduce the frequency users have to deal with “Discard Edits?” message boxes.
Michael Zuschlag Send private email
Friday, November 11, 2005
 
 
I suggest going with option 2 where it saves, shows that it saved and stays on the same page for more editing.

I do this a lot with wordpress where I am making changes save them, view the changes in a different tab or window and continue editing.

It would be kind of a pain to keep going back and waiting for the page to load.

I think having a check box at the bottom would annoy me in a situation where I had to check it every time. It would just get in the way.

Your goal for the UI should be to let the user get their work done and stay out of the way as much as possible. It's the little things such as check boxes, msgboxes and page reloads that make the difference.
Noam Send private email
Monday, November 14, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz