6

Background:

We have a large fullscreen inline editable data table. The user can click to enter an individual cell and click outside to save their changes. Now we're looking to add an on/off setting to either show or not show the item to clients. Horizontal space is a concern, we wish to keep this column narrow. We're also attempting to optimize on the speed of edits. Our users spend 15+ minutes a day manipulating this data.

Question:

On this table, what would be the best way of showing the user what the current value is (whether it's on or off) and allow users to toggle between the two states?

Thoughts:

  • Under most circumstances, you would use a checkbox or a toggle switch to present this. We've ruled out checkboxes because we already have a set of these to the left to allow user to select row items. Putting in additional checkboxes may potentially confuse users.
  • We had some users report the inline edit capabilities of the table was not immediately apparent. You need to mouse over to see the edit outline. For now, we're avoiding putting in persistent edit icons to keep the data compact and easier to scan since this is a utility tool for repeat use. Putting in a toggle switch may make inline editing of the other fields less discoverable.
  • Another option would be to only show the current state. This isn't necessarily easily discoverable, however it isn't a stretch when the user knows everything on the table is editable.

Options considered so far:

Toggle control enter image description here

label only enter image description here

  • Any thoughts around simply styling an icon button with a plain clickable behaviour? Seems like it would be the best combination of your toggle control and label only options. – Michael Lai May 19 '16 at 1:16
  • @MichaelLai Hmmm somehow I think the button may not work well. A toggle makes it easy to see there are two states. We don't get the same with a button. We would have also altered styling of the row, making it harder to recognize the other cells are editable. – nightning May 19 '16 at 16:18
5

Personally, an option like dennislees' makes the most sense; text is much clearer than an icon. The visibility icon is instantly recognisable, but I found it unclear before reading the explanation how to apply the recognized meaning to the table.

However, you're right about a dropdown being less pleasant to use. One option is to simply keep dennislees' display method, but instead of showing a dropdown when clicked you cycle through the options. Alternatively you could use some kind of toggle state, like below.

Toggle indicator

In the above, I used "Public"/"Private" instead of "Visible"/"Not Visible", as I find those terms a lot more clear about who this setting applies to. However, I'm still not 100% on these terms.

  • We have a special case in which the portal access is restricted to specific clients, so the term "public"/"private" doesn't quite work for us. However, putting in a very short text label is helpful. Thanks! – nightning May 19 '16 at 23:53
  • Its not obvious how to toggle the state as it doesn't look like a button or even clickable at all. It could be made clearer by adding some form of visual cue that a toggle state is possible. – Adnan Khan May 20 '16 at 9:16
  • @AdnanKhan The same is true for the other cells, though; IMO one doesn't need to privilege this one in particular. They'll realize it's a toggle rather than editable text as soon as they try to interact with it. – Veedrac May 20 '16 at 12:05
  • @Veedrac editable and toggle-able are two different things. – Adnan Khan May 20 '16 at 13:12
2

What about an affordance that says "You can click here to reveal more options'. Clicking reveals both options. Like a stylized dropdown selector.

You still have the same, slight, problem as with the toggle i.e. the prominence of that type of editable element makes other less obvious elements seem less editable.

But I think you could mitigate that by being understated with the design.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  • I think this solution will work well under normal circumstance. Converting it to a dropdown selector will put it on par with the other fields. For this case, we're attempting to optimize for editing speed, extra clicking involved in a dropdown menu will frustrate a user who's trying to quickly mark off items. – nightning May 19 '16 at 16:24
1

For me the eye toggle makes sense, as an Adobe user I know immediately what it means. Your users may not use those products, and there may be copy write with Adobe to consider there. The toggle switch is functionally the same, as would be a square check box. So for me the toggle switch with a labelled column fits and would seem constant to the design.In respect of the question, you may have answered it yourself, and validation should be with the actual users.

An alternative approach (which is probably inferior) is to use the existing check box as a selection of the elements to want to hide. The context menu (or such like) has a hide command. How do you unhide ? Same process; as I understand it is only hidden to the presented portal users and only requires to be indicated as hidden in this interface. You could indicate visibility by "dimming" each hidden row, or using a small icon (like the eye I suppose)

On the 2nd bullet point, this is not related to the focus of row visibility to the portal users, but whether the user perceives the table as editable. This is an interesting question.

So the obvious answer is to let the users know that the data is editable. How ? Just tell them that. You can tell them in a few ways:

  1. New users have an introduction tutorial when they first use the software, perhaps just as a popover. The tutorial can be called back whenever, by selecting from help menu (or such like)
  2. Like (1) you have a popover which is dismissed easily with "tip of the day" and the tip about this being inline editable will have a high priority in early use
  3. Additionally your product is sold with training provision. Trained users will know that this is how it works
  4. Indicate visually that this is all editable. OK, so it is a difficult thing to be sure about in an interactive system.

Expanding on (4) consider that your App is like a spreadsheet, just more specialized to a specific purpose. I am no fan of spreadsheets, and only use it when I have to. However, there are two contexts about spreadsheets. If you fired up a spreadsheet app for the first time in your life, you would likely be presented with a blank grid of empty boxes. How would you know that these are editable? What happens is you have a blank "canvas" in front of you, a keyboard and a mouse. Inevitably you click screen and see what happens. The empty box is highlighted. Still puzzled you tap the keyboard, the letters or number appear on the screen. After a few minutes of playing, you get the basic function of the App. Although, to use it properly, you feel there must be more to it. You are going to go get the training, or read the manual if you are interested. However, you actually learned more by playing in 5 minutes. The manual is tedious, and methodical, but you do not have time to wade through the slow, and supposedly idiot proof tutorials. Instead, you really get proficient by having tasks and challenges in the software. Especially you learn when you see others using the program, and start to teach others likewise.

From a static image of the spreadsheet you would have no clue. you have to interact to see it working.

The other context is this. You start a new job and never used a computer before. You are shown the Apple Mac, and assured it is as easy as pie. Your boss wants you to make some edits to a company report in a Numbers spreadsheet. This report has formatted texts, graphics, and tables of calculations, also presented as bar and pie charts. Theres only one thing to do, you are going to have to find a friendly co-worker to help you get started, and hold your nerve! If you lied about having Apple Mac experience in the interview, you are sweating now

But these days, most people are not so phased by the sight of a computer or even a spreadsheet. What may be on the line may be their reputation as a good employee; they definitely don't want to screw up. There is an easy deflection: the UI is hopeless ! Quite often this is the case... it depends. If the company have invested in the solution they will want to make it work. However, a bad UX will eventually be a downfall, as frustrated users complain. So really the issue is one of quality. These two contexts of a spreadsheet apply here as well. First test is the experience when the database is empty, and the (naive) user is left with the software, and left to their own device to play and explore the interface. Do they discover that it is editable just as the spreadsheet user did? If not, what is the spreadsheet doing that your UI is not? Second test is the (savvy) user who has not used the system presented with a populated data scenario. Will they be able to get going with edits, or will they need help?

In the second scenario, it is no embarrassment if they need help. The spreadsheet user needed help in that context, if only to understand the domain of the data, and to be brought onboard.

  • Welcome to UX.SE Nao and thank you for your thoughts. Yes, I think this is one where context matters a lot and I should be testing with the actual users. – nightning May 19 '16 at 16:26

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.