11

Currently we have several screens in an enterprise application that allow the user to view information but also, should they choose, to change the information in that screen. For the most part, they would be going there to view but there are times where the user needs to associate a state or company to something, or wants to change dates of those associations etc.

Right now, they can "View" this screen and if the user wants to modify it, we have a button in the upper right that says "Modify" that then switches the mode of the screen from a read-only to editable. A couple of questions came up and I was looking for anyone that may have run into something like this:

  1. The "modify" button could change to "view" when editable and would allow the user to switch back to "locking it down" as view only. This "mode" idea just feels clunky though.

  2. Also, people have suggested that the "Save" button at the bottom of the screen, when pressed, would automatically switch the mode back to "view" but that also feels very strange and I want to steer clear of this.

I would love to see if anyone has dealt with any scenarios that are similar, how they dealt with it, etc. I'm not big on the mode idea but in order to switch right now, especially if there was some sort of Basecamp like "hover and edit" links showing up, they'd have to make tremendous changes across the application to get everything consistent.

  • (a) if you were to guess, what's the percentage of times a user will need to edit vs just view the page? (b) What is the cost of an erroneous edit, where 1=harmless and 10=nuclear meltdown – tohster Mar 10 '15 at 20:41
  • They were saying that probably around 3/4th of the time the user would be coming in to view and might want to make a change here and there. (adding a company or state association, changing a date, etc) That's why I initially liked the idea of a "view" or "locked" mode that would protect them from accidents and make changes very deliberate. Most of the real work is done at creation. – Charles Mar 10 '15 at 20:44
  • Oh and as far as severity of errors, a wrong date "could" cause issues with policies and muck some things up. It could be easily changed though but I would say damage wise probably a 6-7. – Charles Mar 10 '15 at 20:46
  • 1
    "modify" and "view" are engineering terms; better might be "editing" and "read only". To this day I find toggles confusing. That is, if I'm editing, the toggle will show "read-only" to show what mode that click will change my mode to and effectively hides what mode I'm in. – msw Mar 11 '15 at 5:41
  • 2
    Have a look at your profile page on LinkedIn. They treat 'view' and 'edit' as the same thing. – JonW Mar 11 '15 at 11:02
8

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.

  • 2
    This is a nice framework, and I like the methodology. However I think CM is not 5 seconds, because it's 1 click to enter, and 1 click to save/exit. In an always-modify view, the user should still need to save the form, so the incremental workload for click-to-edit is 1 click. Under KLM-GOMS for a familiar user that should be about 1.5 seconds if I recall, since it's a GUI and the user's hand will already be on the mouse. This should not diminish the high quality of your answer. – tohster Mar 11 '15 at 18:00
  • 1
    Holy ship! Who was the product manager that you needed to convince that his/her idea it not a good idea?! – digsrafik Mar 11 '15 at 19:25
  • 1
    @Tohster. Check if you included mentally preparing –time for the user to think, “I need to change this, which I do by first going into Modify mode with that button.” Using Kiera’s times (given in Wikipedia), activating a button = 1.2 sec to mentally prepare + 1.1 sec to point the mouse + 0.10 sec click the mouse = 2.4 seconds. I kicked it up to 2.5 guessing that about 25% of the time the user also has to move from keyboard to mouse (0.4 sec). Using Card, Moran, and Newell’s values yields 2.75 sec per click (YMMV). – Michael Zuschlag Mar 11 '15 at 21:10
  • 1
    If it's a Web app the user will already be on the mouse, but frankly the difference is close enough that contextual factors will dominate the theoretical estimation. On the broader point I agree with your analysis around cost-benefit. In some forms (eg contact information) the cost of errors is small. In others (eg manufacturing automation, air traffic control) the cost is very high. In either case the cost benefit framework you outlined is quite helpful for aiding a decision. – tohster Mar 11 '15 at 21:16
  • 1
    @Tohster: Good point on the mouse. Even if the user were using the keyboard for data modification (e.g., a text box), s/he probably needs to switch to the mouse anyway to carry out the viewing task even if there weren't a mode (e.g., to use scroll bar). And, yes, all these numbers are pretty rough approximations, so the framework only helps if the costs grossly outweigh the benefits, or vice versa. – Michael Zuschlag Mar 12 '15 at 13:24
3

The click-to-edit pattern you describe is very common for enterprise applications.

Given (a) the 75% view / 25% edit ratio you describe and (b) the moderate to high cost of accidental edits, I would definitely recommend this pattern for you.

Benefits:

  • Click to edit provides a positive affirmation of intent...given the cost of errors it helps to erect a confirmation interaction before users edit.

  • Helps prevent unintentional edits with "single tap" controls like radio buttons, selects and checkboxes where a single errant key can change the value unintentionally.

I've seen this approach in a lot of enterprise apps ranging from CRM and collaboration to industrial control systems, manufacturing scheduling, air traffic control, and defense.

  • Yeah, it's starting to look like I'm probably trying to force it into more of a lighterweight web app but this may not be possible. One of the other ideas played with was to show it all listed out and then bring up a dialog on "modify" that would handle that and clearly look like a different mode but I don't want dialogs popping up all over the place. Your point about preventing the unintentional edits is why I went in that direction before too. Stopping someone from nuking information. – Charles Mar 10 '15 at 21:06
  • 1
    Yup. Enterprise apps often have an asymmetry where information gets built up over time but it takes just 1 errant user to destroy its integrity. Btw it may be a bit more effort to lay out click-to-edit, but on the back end it's easier to implement because submitting a form as a whole gives you better ability to ensure transactional integrity, implement undo/rollbacks, etc. – tohster Mar 10 '15 at 21:09
  • Exactly. I think why I initially was drifting away from this was because before I had come onboard, they had screen after screen that was styled as if it was disabled instead of a nice way to read information. Taking this mode idea further would really allow me to create one really clean, well-designed view and then enable an edit mode with all of the form fields, etc. Plus inline styling would be a pain if I had several changes and was hovering and clicking over several fields. I guess not every thing can be forced to look like Basecamp. :) – Charles Mar 10 '15 at 21:20
  • 1
    Totally agree. Since view mode is the >75% use case, eliminating the form fields actually allows you to create some really beautiful views. Good luck! – tohster Mar 10 '15 at 21:22
2

For bimodal I like a simple checkbox

Edit check box

With a toggle button is it not clear if the toggle represents the current mode or the mode you would toggle to

In the app this is used in even in view mode (not edit) the users still want to be able to select text for copy and they like an explicit view (read only) mode so they know they can't accidentally change data. They don't want a separate Save button in Edit mode. In view mode the fields have a slightly different look (and the data is read only). On this app in edit mode they want changes to be immediate - fields are independent.

Users preferred Edit over Modify. Edit unchecked is clearly view - the data is displayed.

  • Blam, we have that too where the users wanted to highlight and copy things and so before I came onboard, they made everything just look like disabled fields. I would rather a cleaner, nicer design that can still just be highlighted and selected. – Charles Mar 14 '15 at 1:27
  • @Charles Slightly different look does not mean disabled look. – paparazzo Mar 14 '15 at 10:12
  • Oh I know. I was saying they used to convert all of their read-only to a "disabled" style which looked odd. I wanted it looking like a true read only without the form fields, etc. – Charles Mar 16 '15 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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