18

We're working on a new management console for an online service. The management console consists of about 30 forms as well as lots of reporting and various other goings-on.

My developers have moved away from my original vision for the forms, and I'm looking for the community's thoughts on their current direction. Do I need to reign them in quickly?

In my original design, everything was in "edit" mode. If you went to a page, you could read the data out of normal form widgets. If you wanted to edit anything, you just edited it and clicked save.

But the developers have now created "view" mode and made it the default on any page.

This means that when you get to a page everything is static text without the ability to edit. It's great if you're just looking for information, but if you have to edit something then it's an extra click on the "edit" button.

Are they on the right track? Should I move them back to the original vision?

If we're going with the switchable mode, where should that switch be positioned, and should it be a button, a radio group, a checkbox or an iPhone type slider?

Improve this question

3 Answers 3

Reset to default
7

Is the expectation that the primary use of the form is to edit the data? If it is, then the entire form should be editable by default.

If editing data is only an occasional then why not use an edit in place pattern? You just click what needs to be edited, then click save when finished. This of course assumes that your users have javascript available.

You probably need to include an Edit button, for users without javascript, or if a significant amount of editing could ever be required. Without seeing the form, I'd suggest you look at putting the "Edit" button beside the "Save" button — but ideally this is something you should test with actual users.

As for the type of control, radio controls and checkboxes are form fields not command buttons. An iPhone "switch" slider might be OK, but depending on what the rest of your app uses. Consistency is going to be important.

I'm going to assume if your developers are making stuff up as they go along you're either using an agile approach or your design specs aren't up to scratch. Fluid design methodologies are great if they are design lead, not development lead, and iterative testing is needed.

Improve this answer
3
  • 1
    Yes, we're agile -- and I don't want to stifle creativity unless it's going to hurt the users. Your answer is effectively mine: What's the primary use of the site? And the answer is that you go there to change the information, not to read it.
    – Sam McDonald
    Jun 6, 2010 at 13:02
  • Then I think you have your answer - screens should be editable by default.
    – Nathan-W
    Jun 6, 2010 at 22:17
  • 1
    Hmm... "making stuff up as they go" is not something that matches any agile process I've been involved with...
    – adrianh
    Jun 7, 2010 at 12:10
1

I'll say something obvious: use the same form, in different states if need be. There's no point in making the users learn two different user layouts, one for viewing and one for editing.

How often will a user open the form? All day? Once a month?

If the form is always editable by default, is there a confirmation of the edit that is clear yet not annoying? How will you prevent unintended edits?

Improve this answer
0

I would suggest you to make it something like... Everything is read only but there's one button on the Top which says "Edit this record/entry", when a user clicks on it, that button becomes "Done Editing" and all the editable info becomes textboxes filled with the current value.

This way user dont have to guess that the clicking on the field will make it editable and you wont have to handle multiple saving (everytime textbox looses focus).

I hope I'm making sense.

Good luck :)

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.