Wednesday, August 22, 2007

UI Best Practice: If They Can't Do It, Don't Show It

Following up on my post regarding UI best practices, here's one of my favorites:

If you have a certain action, section, field, etc., that should only be accessible to a certain user/role, then please, please, please do not show that construct to someone that doesn't have the rights to do something with it.

I cringe every time I encounter a database with an "Edit" action button always visible when I know full well that there is security enabled and most users will click this button only to get an error message. It's really very simple...Spend the extra few seconds/minutes it takes you as a developer to write a hide-when formula to make sure that only people that can really edit the document see the button.

Remember: If they can't do it, don't show it!


Charles Robinson said...

I understand where you're coming from, but sometimes deriving who can edit a document is a tricky prospect.

For example, assume you have an ACL only group called HR that has been granted Author access to a database. This group contains the groups Corporate HR and Branch HR. On a document you have an Author field that uses the HR group. Someone in the group Corporate HR opens the database. They can edit the document, but how can you determine this from a hide/when formula?

The only solution I have found is to duplicate the groups as roles, put the roles into the Author field, then use @IsMember and @UserRoles together. I still need the group to give ACL access, but I have to have the role to easily determine document level access. It's a mildly ugly workaround, and it's a pain to maintain.

Having said all that, I do go to these lengths so my apps only expose the functionality that a particular user has access to. :-) The only downside is it sometimes confuses them that the Edit button appears and disappears as they scroll through a document list.

Nathan T. Freeman said...

!(@UserAccess(@DbName) > 3 | (@UserAccess(@DbName)=3 & @Author=@UserNamesList) | $PublicWriter="1")

That's the formula you need. @UserNamesList is the key.

However, you MUST have only a single Author field on the document. If you have more than one, the comparison to the @userNamesList doesn't work.

sean said...

There is a school of thought that says show the button but generate a prompt saying who can use the button.

e.g. in an expenses approval application "Sorry but you cannot approve this spend but the following people can"

This avoids calls along the lines of "the application is broken because the button has disappeared"

A variation is to have some computed text saying a similar thing

tlbriley said...

The "Edit Document" icon is on the "Universal" toolbar. But if the focus isn't on a document, the icon isn't enabled. It simply doesn't belong here. Like most icons, it belongs on the context sensitive toolbars, not the universal one.

A similar screwup is always displaying a button to the user that he/she will almost never use. An example of that comes from Notes itself. The default "Universal" toolbar contains the icon, "Debug LotusScript". Why oh why, did Lotus make that icon a default on the "Universal" toolbar? If I need to enable this at a user's desktop, I'll just dig in the menu.

On the other hand, something that I do often is merge/split table cells. Not only is that not part of the Edit Table or Design Table toolbars, it's not even available to add to either one. To do either, you have to use the menus.

Nathan T. Freeman said...

Sean, in that case, I'd personally elect to replace the button with a different one that says "who can edit this?"

Actually, the truth is that part of the problem is the paradigm of the "action bar." It's a supposedly constant reference that demands inconsistent behavior based on the user's context. If I'm looking at a list of 10 items in a list, and I can only edit item 3, 6, 7 and 9, then the gesture should be ON items 3, 6, 7 and 9 -- not in some other space.

In other words, there should be something to click on directly at the line, instead of selecting, then moving all the way back up to select the action. I should get 1) a visual cue that THIS ONE is editable; and 2) a method with which to edit. Preferably those should be the same thing.

Note that internet boards work this way. If I look down a list of phpBB posts, I only see "Edit" actions on those that I originally wrote.

Nathan T. Freeman said...

@Mr. Briley - The Toolbars are an abomination. That's one of the reasons I TURN THEM OFF in desktop policies controls every chance I get.

C'mon... CUT is right next to EDIT. CUT!!???!?!?!

Charles Robinson said...

Thanks for the tip Nathan.

"I should get 1) a visual cue that THIS ONE is editable; and 2) a method with which to edit. Preferably those should be the same thing."

Couldn't you combine your tip here to determine document-level access with Chris' "use editable columns to trigger actions" and provide a per-record clickable visual cue for editing documents? :-)

tlbriley said...

@ Nathan - "@Mr. Briley - The Toolbars are an abomination."

I would call the choices Lotus has made for the default icons for each toolbar annoying, but not quite an abomination ;-)

I have the luxury of only needing to roll out a new user about once a month. Each time I do this, I take an extra 5 - 10 minutes, turn off most of the "always on" toolbars and modify the heck out of the context sensitive toolbars. When I'm done, they can save the user quite a few clicks in the course of a day.

Anonymous said...

How about don't show something that is irrelevant when the document is printed. Take Notes 8 mail for example. Print an email and what do we see on the top right? a "show details" link. How bad is that???

Great post BTW!

Charles Robinson said...

I answered my own question... @UserAccess and @UserNamesList don't work in column formulas, unfortunately. :-(

Chris Blatnick said...

@Charles...Yep, it's unfortunate that we can't use that technique because it would be a perfect case for it. But then you'd have to make the view private, otherwise you'd be contending with the index being rebuilt all the time, etc. etc. Why can't this stuff just be easy!!! :-)

Stephan H. Wissel said...

Actually it would be better to disable the button instead of hiding them. If you hide them the spacial layout becomes distorted and users click in wrong places. Also call to the help desk "The button is not there" will be avoided.
Unfortunately there is no "deactivate" state for notes buttons

Rob Novak said...

Funny story on this topic. In the QuickPlace / Quickr world we have always take this for granted. Whether you agree with the general design or not, QP has always been very good about hiding things you can't, wouldn't want to or shouldn't do in every context - security, reading, editing. With Domino applications, we as developers have to make those decisions every time we build an application.

Now a couple years ago I sat in on a Sharepoint session at one of the Advisor multi-vendor events. At the time, the current version of Sharepoint Portal had a significant defect in this area - you could always see things you couldn't do. In fact, you could get all the way through creating a new document until hitting submit, only to have your work lost when you hit it.

The brow-wrinkling part is that the "exciting new feature" coming in what is now Sharepoint was that users wouldn't see what they couldn't do. A fundamental UI and security construct to say the least.

The funny part of this story is what they called it, "Security Clipping". The name itself simply gives away the fact that the people building Sharepoint do not consider security as a core, fundamental service that should be embedded, but something to "add on" -or in this case "clip out"