So, I'm working on this little project that has a task flow that includes a Summary page.

Here's the scenario:

User searches for something. Application displays results. User clicks on result. Application displays summary of result.

Option A User clicks field to edit. Application enables editable field. User clicks saves. Application saves. User clicks "back to results" Application displays results.


Option B User clicks field to edit. Application displays editable page of result. User clicks saves. Application saves. Application displays results.

So, I'm wondering what everyone's thoughts are on having the summary page multi-task as a summary page AND a place to edit data VS taking the user to an editable page?

My gut says it's easier for the user to do it all on summary page but it seems to break the mental model.

Any thoughts?

  • Thanks. And yes, I guess it's a detail page. I spoke with the team and we agreed to make the detail editable.
    – Shane Fontane
    Commented May 17, 2010 at 20:56

5 Answers 5


How many fields are involved? Will your users want to edit more than field at a time? How many edits are they likely to want to do? Will they be editing something that's not shown in the results page? All these sorts of questions should guide you to an approach --- which you then should test with some actual users if possible.

It doesn't actually sound like a 'summary' page, the pattern sounds more like 'detail on demand'. The search result is your summary, the user then asks for more detail when they click the result.

The detail page could be completely editable by default? Removes one step from the entire process.


Option B seems the most intuitive BUT if the fields are editable you need to make sure that the action to make the field editable is blindingly obvious.



If you are trying to give people a simple way to edit a subset of the details, I would give people a choice from the search results rather than just give them only the smaller set and then make them click to edit the full record.

For example, Wordpress has the idea of "Quick Edit" which is an inline editing of certain details about a post (like title, enable contents), vs clicking on the post to edit the actual content.


If your summary page is able to provide the supporting information (to make an appropriate informed decision for change) and facilities to make a change why introduce an additional step between the user and the action they wish to carry out?

Option A (with appropriate caveats).


On a larger enterprise system (i.e. something that spans a large number of pages) I would opt for an edit popup view (as opposed to an edit screen). I am presuming this is form data you are dealing with and those forms can have data that can be modified by other people which would result in optimistic locking conflicts.

By having a popup view you can check if there is a conflict on save or for more complicated ones you can have a message that appears saying that the record you are trying to modify has been changed by [xxx] and if you want to load the new changes (at the expense of losing your changes). Even better would be to have a diff view, but that's going to be way too complex for operations people to deal with easier to just click on the person's name have it pop up with their contact info and call them up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.