How to Switch between View and Modify Modes
To answer your explicit questions, it’s acceptable to have a single command button toggle between View and Modify. This can be effected by changing the caption of the button between “View” and “Modify”, or you can have a toggling “Modify” command button. When pressed “in,” the page is in Modify mode. Click again to “raise” it, and the page is in View mode.
Toggling the command button back to View should save all input. However, you should also consider having a separate Save button that saves but does not toggle the Modify mode. This allows the users to save work as they go in order to reduce the chance of lost work (e.g., due to losing connection or power, or the user screwing something up so much they have to exit). As a rule of thumb, Save should be included if users frequently work for 30 seconds or more on a screen before they’re done modifying. At the very least, this will save some user anxiety.
Or you can automatically save every time the user changes a field, and not make the user worry about it.
Save and Modify buttons should be in a non-scrolling division of your screen so they are always accessible.
Your screen probably will need some clear indication of the mode other than the Modify button so users always know immediately what they can and shouldn’t do. At the same time, the layout and labeling shouldn’t change –fields and captions should be the same in order to minimize learning and re-orientation time. Furthermore, you should optimize the screen for viewing since that’s what most users will be doing. So, yes, don’t use disabling to make fields read-only (in addition to interfering with legibility, some users interpret a disabled field to mean “not applicable” data).
I recommend View mode have no or very faint borders around the field values, or maybe just an underline under field values. Borders suggest editability, and can also add clutter that interferes with readability. In View mode, there should be no radio, dropdown, or spinner buttons –not even disabled ones. Show only the selected radio button value. Substitute text for checkboxes (e.g., “Yes” and “No,” or “Do” and “Don’t). In Modify mode, the fields appear in the proper editing controls (text boxes, drop downs, radio buttons, checkboxes) with prominent borders.
That’s just about the simplest and easiest way to handle a mode.
Should there be a Modify Mode?
Modes are still clunky, add workload, and contribute to user error and confusion, so you are right to consider no separate Modify mode. To decide on whether to have an edit mode or not, estimate the cost-benefit. The cost of entering and leaving edit mode (CM), in user time alone (for a skilled user), is about 5 seconds, using GOMS-KLM constants for clicking a button twice. You estimate the probability of the user needing to edit (PM) as 0.25. So the average cost of edit mode is PM*CM = 0.25 * 5 = 1.25 seconds of work per session.
To calculate the benefit, estimate:
PE: The probability of a given user making an error while merely viewing content. This is a very low probability. The mouse isn’t even being clicked near any content –it’ll be over the scroll bar or back button mostly. How often have you ever accidentally clicked on the content of a web page when browsing? What are the odds that would change a field value if there happened to be one where you clicked? I’d say PE is something like one in 1000.
CU: The time for the user to correct an error after making it. In a properly designed app, this should no more than the time to make the error in the first place. So let’s say 2.5 seconds for a one-click error. You do have an Undo feature, don’t you?
PI: The probability of the user being unaware of the error or otherwise unable to correct the error. In a properly designed app, any user change should be immediately apparent to the user and the means to revert it should also be immediately apparent –that’s just good feedback. A properly designed app should also provide alternative means for users to check if anything is changed (e.g., by a Save button becoming enabled, or an action appearing on the Undo list). I expect PI to be about 0.10 or less.
CE: The time (or time equivalent) lost due to an average uncaught error. If you can put a dollar value on an error, translate it into time using the user’s hourly rate. Be realistic: most errors will have negligible cost –if you delete one letter from a customer’s name, the package will still be delivered, and you’ll only lose the tiniest bit of customer good will.
Now calculate:
(1 - PM) * PE * [(1 – PI) * CU + PI * CE]
If this value is more than PM*CM, then it’s worth having a Modify mode.
Using the ballpark numbers above, and solving for CE, we see that the cost of a uncaught error must be at least 16,667 seconds to justify Modify mode. If your users are relatively low in the corporate hierarchy, being paid $25 per hour, that’s $115.74 dollars.
Try you own numbers, but I’d say very very rarely is a Modify mode justified. It’ll only be if there’s either very high cost of an uncaught error (CE) or very low probability of a need to modify (PM) (which means the average cost of the mode (PM*CM) is very low). The latter can happen. Consider Wikipedia, where PM is miniscule for the average visitor.
What if there is a High Cost of Uncaught Error (CE)?
Frankly, if every uncaught slip of a mouse cost on average $115.74, then, with PI = 0.10, you should rethink the application, because the same errors are going to happen in Modify mode. In fact, even though users edit the content in only 25% of the sessions, I’d wager that erroneous modifications will be far more likely in Modify mode than View Mode. The user is trying to change something –at least they got their respective mice over the editing controls and clicking. Probably the most common error isn’t the slip of the mouse, but the mis-modifying a field due to a misunderstanding.
When the cost of uncaught errors are high, your UI design needs to specifically attend to making them very unlikely (i.e., reducing PI). This includes such UI features as:
Clear Data Representation. The value and changes to critical data should be very apparent to the user. For extreme cases, consider highlighting changes made in a session, so the users can check back anytime to be sure they’re doing it right.
Undo. Undo should be mandatory for any web app that users frequently complete more than 30 seconds of modifications. If you don’t have Undo, you must support a Cancel function.
Sanity Checks. Supply verification messages for users inputting unusual (i.e., crazy) values that would have a high cost.
Progressive Disclosure. Data that rarely needs to be seen and is dangerous to change should be in a separate division or even a separate screen/page/window.
Safety covers. Single controls that have dangerous ramifications can include a “cover” –something that requires two clicks to change. For example, rather than radio buttons or a checkbox for a binary field, use a dropdown list (defaulting to the safe value) to effect this.
Explicit Commitment. Save-as-you-go and automatic save features are fine, but in some cases, you also want the user to explicitly click something to say, “Yes, I’ve finalized the data, go do something with it.” This is necessary when data modification can trigger a process, but multiple fields will need modification first.
Checks and Double Entry. Include in the business process an individual that checks the user’s work before it’s put into action. Consider two users independently making entry/modification of critical data. If both don’t agree, flag it so they can resolve their differences (possibly with help of a supervisor).
User groups. Divide users into groups that do and do not need to modify critical data. Those that don’t get view-only representations.
In minimizing PI, you reduce uncaught errors made whether or not the user is intending to modify something. Thus, by addressing the potential for costly uncaught errors in Modify mode, you will likely end up not needing Modify mode.
