2

I'm designing an admin panel for a database-backed web application. I've noticed that in most interfaces like this, each record has both a "show" page, which displays the record's information, and an "edit" page, which displays the same information but in editable input fields with an Update button.

If the user has edit permissions, why bother with the show page? It's more work for me, and it requires an extra click for the user who wants to edit. Clicking on a record can just bring them to the edit page. If they don't want to edit, they don't click Update. If they don't have edit permission, the input fields or the Save button can be disabled. Is there something I'm missing?

Improve this question

4 Answers 4

Reset to default
1

Usually the show page displays information in a more compact way. Sometimes it may even show related objects: For example the show page of a CRM might list notes associated with the contact, whereas the edit page will let the user edit the contact details.

I think the best option is to have a mix of the two: Have a single page, perhaps divided into multiple "box", where the user clicks on a field or "box" title and that field or group of fields become editable.

On the web, it's not always simple to implement since edit fields tend take a lot more space than plain data.

Improve this answer
3

It is a data integrity thing. I may have edit permission and I may be selecting field values for copy paste. But I don't want to inadvertently change a value.

Also a view only mode typically will have less clutter. Like a date - you just show the date and not a date control. An enumeration you just show the current value and no pull down to select other valid values.

And it is a speed thing. Edit controls are a lot heavier. A date control takes 20X the resources (and time) as a textblock to display a read only date. Page to the next record in 0.1 second or 1.0 seconds makes a difference to users.

And don't make them go into one mode and then click to the other. Give them a checkbox on the single record page to toggle between show and edit modes, and use that for every record (until they change it). If they change the toggle then immediately change the mode for the current record.

A user will tend to be in one mode or the other for a period of time. Doing research they will be in view mode and stay there for a while. If they are coding they will tend to be in edit mode for a period of time.

Improve this answer
9
  • Can you clarify this please? "Give them a single Edit checkbox and that is is used for every record (until they change it). If they change it then change it for the current record." Thanks!
    – linesarefuzzy
    Jan 23, 2015 at 20:28
  • I don't know how to be more clear. You state input fields as in plural. Have a single setting that is applied to all fields.
    – paparazzo
    Jan 23, 2015 at 20:32
  • When I said "input fields" I was referring to the various different fields on one record's edit page. Are you referring to a batch edit function on the index page, where you can check several records and edit them all at once? What is the "single setting" you're referring to?
    – linesarefuzzy
    Jan 24, 2015 at 19:10
  • I don't know how to be more clear. I have a single check box that is edit on (or off). When they open / display any field (or row of fields) it honors that setting (edit mode or read only mode). A person is typically in an edit mode or read only mode and they stay in the mode for a while. At any time they they can change that single check box (and the change is immediately honored).
    – paparazzo
    Jan 24, 2015 at 20:16
  • @Blam: Good points! I personally don’t think that this type of “admin” panel got that much attention and that the speed and data integrity points are the result of following system standards, not use cases.
    – jazZRo
    Jan 26, 2015 at 9:33
1

It sounds to me like your assessment (in the second paragraph) makes complete sense. There could be legacy reasons why it is built the way it is now.

Improve this answer
0

This looks like a typical CRUD application. CRUD stands for create, read, update and delete which are standard database actions with each it's own query. It might just have been easier to create a GUI on top of that than rethinking a whole new concept. Your conclusion is probably right that it doesn't make much sense to the user, it was designed to meet a system and not the user in the first place.

With so less information it is only possible to guess what the reason is behind choices made. But to make the above a bit more substantial... I’ve seen this type of application a lot and most were on a low budget, designed to meet a fast development process to reduce costs. To reduce development time the focus was on following programming and system standards and not elaborate use cases.

Improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.