I am developing an application that allows for a user to manage some individual data points. One of the things that my users will want to do is "delete" but what should that mean?
For a web application is it better to present a user with the option to have serious delete or to use a "trash" system?
Under "serious delete" (would love to know if there is a better name for this...) you click "delete" and then the user is warned "this is final and tragic action. Once you do this you will not be able to get -insert data point name here- back, even if you are crying..."
Then if they click delete... well it truly is gone forever.
Under the "trash" model, you never trust that the user really wants to delete... instead you remove the data point from the "main display" and put into a bucket called "the trash". This gets it out of the users way, which is what they usually want, but they can get it back if they make a mistake. Obviously this is the way most operating systems have gone.
The advantages of "serious delete" are:
Easy to implement
Easy to explain to users
The disadvantages of "serious delete" are:
it can be tragically final
sometimes, cats walk on keyboards
The advantages of the "trash" system are:
user is safe from themselves
bulk methods like "delete a bunch at once" make more sense
saves support headaches
The disadvantages of the "trash" system are":
For sensitive data, you create an illusion of destruction users think something is gone, but it is not.
Lots of subtle distinctions make implementation more difficult
Do you "eventually" delete the contents of the trash?
My question is which one is the right design pattern for modern web applications? How does an "archive" function work into this? That is how gmail works. Give enough discussion to justify your answer... Would love to be pointed towards some relevant research.
-FT
Here is a relevant article you might like. It's more focused on business scenarios, but it can apply anywhere.
Don't Delete, Just Don't.
In my personal idiosyncratic view, every irreversible action is a serious design error. These “Are you REALLY, ABSOLUTELY, POSITIVELY sure?” message boxes are pure crap because the user is very quickly conditioned to just click “OK” and be done with it. In fact, I have lost important data despite such dialogs on several occasions.
In other words: these dialog boxes do not add a working fail-safe barrier, just a usability barrier.
Even trash systems have this problem (they just postpone the moment); the best solution from a usability point of view is an infinite history. Of course, implementing this may carry forbidding costs (e.g. in terms of memory usage).
Permanently deleting sensitive data can (and should!) by all means be implemented as a much more complicated action: it is rarely needed. The only issue is to make it clear to the user that data is normally not lost. Using a history instead of the trash can may help here: the trash can could be misunderstood as being a permanent delete while a (visible) history of actions doesn’t give this illusion of safety.
I think you pretty well summarized the pros and cons for the trash model:
Pro: Overall, better for the user.
Con: Overall, easier for the developer.
For a usability specialist like myself, it’s a no brainer. As far as I’m concerned developers are supposed to work hard to make life easier for users. Frankly, until web apps have Undo capabilities like trash, I don’t think we can consider them usable. Time that web apps catch up to 1984.
A few other details:
Another advantage of the trash model is the capacity to eliminate the need for confirmation message in most cases. The vast majority of the time, the user is deleting something intentionally, so putting an extra step in with a confirmation message is usually adding work for them. Worse, they get in the habit of smacking OK quickly, which generalizes to other confirmations they really better read. See http://alistapart.com/articles/neveruseawarning.
Part of the beauty of the trash metaphor is that it suggests to user that deleting is not permanent. Like a physical trash can, objects can be retrieved. If you feature the trash can obviously enough on your page (so users realize they can open it), and include an image of the trash can as an icon next to the Delete menu item, that should be enough to indicate that deleting doesn’t destroy, but rather moves things to the trash.
It’s probably acceptable to destroy the oldest deletions in the trash if there are performance considerations. That is once again consistent with the trash can metaphor: users can anticipate that sooner or later “someone” is going to empty the trash. I don’t think users will care if the trash never empties. If they need to truly destroy something sensitive, you can provide an explicit procedure for it (e.g., deleting something that’s already in the trash).
My opinion is that there really is no reason to hard-delete anything that could be of importance to someone. In my experience, the pain of having to do a tape backup because a user realized they deleted something last week that they needed is easily resolved by using an 'IsActive' or 'IsDeleted' flag on records that a user could soft-delete.
Totally context-dependent.
If it's an easily reversible action, just delete it, you might not even need a confirmation
If you might be losing lots of data, a "temporary deleted items storage" might well be in place
I don't see that the presentation of the application (Web App or not) is a major driver for this decision. I would be more concerned with the value of the data, its ease of recreation and the costs of keeping and housekeeping it.
My feeling is that when your app is acting as a respository of valuable data then delete-via-trash is preferable.
Related
This is an interesting interview question that I found somewhere. To elaborate more:
You are expected to design classes and data structures for some website such as facebook or linkedin where your activity can be shared and re-shared. Design should be such that it avoids redundancy and duplication.
While thinking of this problem I was stuck on "link vs copy" problem as discussed here
But since the problem states that duplication should be avoided I decided to go "link" way. This makes sharing/re-sharing easier but deleting very difficult. i.e. if the original user deletes their post all the shares should be deleted. (programmatically speaking all the objects on the pointing to the particular activity should be made null. And this is the difficult part here, i.e. to find all the pointing objects)
Wouldn't it be better to keep the shares? The original user deletes
their post, fine, it's gone. But everyone who has linked to it should
not suddenly have it disappear on them.
This could be done the way Unix handles hard links. "Deleting" just
means removing one link to an object -- an inode, in Unix terms. You
don't remove the object itself until the link count is zero.
It's not obvious from the original specification that deletion should work as you describe. It might be desired that when the original user deletes the item, it is not deleted elsewhere; in that case you don't necessarily need to track all references, just keep a reference count on each post, and remove it from the database only when the count hits zero.
If you do want the behavior you describe, it may be achievable by simply removing broken links as and when you encounter them, again relieving you of the need to track each reference. The cost of tracking and updating every reference to every post is replaced with the comparable cost of one failed lookup for each referring page. The latter case is simpler to implement, though, and the cost doesn't hit your server all at once.
In real life, I would implement all references as bidirectional anyway, because it's likely to be needed sooner or later as you add features. For example, a "like" counter seems pretty simple, but to prevent duplicate votes you need to keep track of who has liked each item, and then if you want to remove their "like" when they delete their profile, you need to keep a list of each user's outbound "likes" too.
It takes a lot of database activity to implement something like Facebook...
I have an application that might receive a net request for data from another computer. The data can be grouped into several categories so that filtering can be made upon it.
In this situation two things can happen:
I give the user the ability to filter the information he wants to send (thus reducing bandwidth and providing the user with a powerful feature)
Try not to bother the user with this so that the use of the application remains as simple as possible and decide beforehand what information will be send.
Basically is the old debate between Google UI and "your app UI". The second option is too simple but it limits the user ability to decide exactly the data he wants to send, the second introduce a complexity to the user that might be unneeded.
What alternative do you thing is better?
I think the best is if you can to do the default thing without asking the user, but provide an options menu or similar somewhere so that an interested user can go in and optimize if she wishes. If it makes sense in your situation, it might be an idea to notify the user in a subtle way that there are options that can be configured when they start the operation, without requiring them to take any action.
Without a lot more detail it is hard to say. It depends on the sort of users you will be getting and how skillful they are.
You might be able to do some sort of compromise, where it is simple by default, but has an advanced button for advanced users.
It always depends on the situations. You can assume the default inputs wherever possible and ask the user for more. But in my opinion simplicity is the best. If you need lot on user interventions, you can try wizard kind-of-interfaces.
It depends on how much time you want to put into polishing.
I would say if its a feature you are thinking of adding, its probably a good feature. However, if you have concerns of overwhelming the novice user, have a basic feature and simply add a link like "advanced" next to it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What UI/GUI guidelines should be followed that subtly (or not so subtly) direct users so they don't shoot themselves in the foot.
For instance, you might want to give power users the ability to "clean" a database of infrequently used records, but you don't want a new user to try out that option if they've just spent hours entering new records - they may lose them all because they're 'infrequently used'. Please don't address this specific issue - it's just here to clarify the question.
While one could code a bunch of business logic in place to prevent some issues, you can't account for everything a user might do.
What are some common techniques, tips, and tricks that prevent improper usage?
ie, How should I design the interface to alert users that a function or action is to be taken with care
What should I design in that limits risk and exposure if a poor action is taken?
-Adam
Everything can be undone. Don't erase - deactivate. Back up before every destructive operation, and give the user a way to restore.
That's the path. It's hard to follow it all the way, but it's what you're aiming for.
Make it possible to undo dangerous actions.
If it's a reasonably big application or system, require separate admin access for dangerous operations as well.
Don't Make Me Think
And you can, in fact you HAVE to account for everything they might do. Because you (as the designer) as the one who gives them the ability to do all those things.
Before putting ANY item on a gui as yourself "Can this be misused?" and if it can, you might want to go with a lower level of customizability.
Example hierarchy
Button - Can be clicked.
T/F Radio Button (mandatory) - Only two options.
Combo Box - Many options, possibly "no option". more confusing.
Text field - Myriad of wildly inconsistent options. More confusing for user, more dangerous for coder.
Basically, if the user doesn't need extra options, then don't give them extra options. You'll only confuse them.
This is an old article, but it's still a great one:
Microsoft Inductive User Interface Guidelines
Never rely on anything that says "Are you sure?" The user is ALWAYS sure and that's if they even bothered to read it before dismissing.
Partition your users and have fine-grained permissions.
Define some power-user permissions that enable the "more dangerous" operations.
Power user permission is not given out lightly -- only to actual power users -- and revoked readily.
I'm of the school of thought that, in case of inclarities or ambiguousity, the user is rarely wrong, and the UI is always to blame. So, when you say "punch the user in the face", tagged with "pebkac", I'm thinking that you would do good with a slap in the face.
Unfortunately, I'm unable to give any good UX-advice, since I'm a mere programmer, and therefore more or less by definition disqualify as a good UI-designer. I'd like just to point out the possibility, that you actually could be the one who needs to get a clue, and try to be more humble towards the users.
Edit for Adam:
The little I know about UX is how little I know about it. It's an entire career path. I know for a fact that there's very little anyone can learn by asking a single make-me-good-at-this question at Stack Overflow. It's like me asking "help me write better code", with the body text formulated as a story of how my colleagues ridicule me of my code.
We, programmers, are engineers. We like order and reason and logical decisions. But the average user is not a programmer, not an engineer and, in many cases, not interested in computers themselves the very least bit.
I'm glad that people are giving you nuggets of good advice, and I'm glad that you, contrary to my first impression (I'm sorry about that), are eager to take those bits and understand the needs of the user.
But the point remains: You need to buy books (Don't Make Me Think is a great place to start, as already recommended). You need to watch how people use your software. You need to observe where they stumble, and jig things around until your UIs seem natural.
I'm sorry I still can't give you an answer. Because I don't have it. And even if I would have it, I would probably have to charge you 50EUR an hour, for years into the future.
Make the results of the user's action visible and offer a way to undo those changes.
When the changes are visible, then the user gets feedback of whether the results were what he intended to do, and if they are not, then the possibility to undo will let the user to try again to reach his goal. If possible, make the results of the action visible before the user invokes the action (for example, when dragging some element, show what would happen if the user would release the mouse button, for example visualize addition of the element where it will be moved to and visualize the removal of the element from where it was moved from).
There are a couple of types of undo. The most simple is a single-step undo (as in Notepad), but it is often not enough. Better is a multi-step undo (as in Word), which covers most of the cases, but does not allow undoing a specific action without undoing all the actions that have been done after it. That can be solved by object-specific undo, for example in a form with many fields (or cells in a grid like in Excel), right-clicking the field would show a list of previous values in that field. For deleted data you could have a store of deleted data, from where the user can restore things after deleting them (for example if the user deletes a slide in Powerpoint). And finally you could have a full version history of every change, for example as Local History works in IntelliJ IDEA - make a history entry every time the file is saved (and save everything automatically after a couple seconds of inactivity).
Confirmation dialogs don't help. The user might read it the first time, but soon after that clicking "OK" in the dialog becomes an automated process, and the user will press Enter before the dialog even shows up. Then the confirmation dialog has become just a source of unnecessary mechanical work. The user is always sure about doing some action, even when he is wrong - otherwise he would not have done that action.
Well there are a few different ways that I can/do go about these types of things.
User documentation - first and foremost give them some documentation to work with, and make the systems easy for them to use. Just general usability and descriptive names/actions for everything.
Provide confirmation screens with warnings. Full disclosure of what the action is going to do, with the warnings inside of a yellow box. It draws attention to it and helps prevent the need for the other items.
Have a roll-back plan. For large risky operations you can either simply set "deleted" flags, or offload the data to a temporary "recycle bin" of sorts should they accidentally remove/modify data that was unintended.
Require multiple approvals, for data purge operations especially go to a two-tiered approach, requiring approval from separate users.
These are just a few of the ideas that I have.
Two things immediately come to mind.
The first is the notion of progressive disclosure, i.e., only show users what they need in order to accomplish the task at hand. How many UIs have we seen that have hundreds of controls on a single dialog? Divide the controls into their respective tasks and only allow the user to do a single task at a time. An Advanced button on a dialog is one way to implement this, and this concept has the added benefit of separating the power users from the run-of-the-mill users. Run-of-the-mill users are less likely to attempt a task that is likely to be beyond their skill level.
The second is to leverage the wizard concept for complicated tasks. I know wizards have fallen out of style, but if a task is truly complicated, users usually appreciate having their hands held the first few times. A good example of this is the WinZip wizard interface. If you've never zipped a file before, this wizard uses a logical progression to walk you through the process. And then, once you've grown comfortable with it, you can switch to the classic interface to zip files more quickly.
Of course to do all of this requires a committment not only by the developers, but by management. And that, sadly, is where many of these usability battles are lost.
I'm a software developer who has a background in usability engineering. When I studied usability engineering in grad school, one of the professors had a mantra: "You are not the user". The idea was that we need to base UI design on actual user research rather than our own ideas as to how the UI should work.
Since then I've seen some good examples that seem to prove that I'm not the user.
User trying to use an e-mail template authoring tool, and gets stuck trying to enter the pipe (|) character. Problem turns out to be that the pipe on the keyboard has a space in the middle.
In a web app, user doesn't see content below the fold. Not unusual. We tell her to scroll down. She has no idea what we're talking about and is not familiar with the scroll thumb.
I'm listening in on a tech support call. Rep tells the user to close the browser. In the background I hear the Windows shutdown jingle.
What are some other good examples of this?
EDIT: To clarify, I'm looking for examples where developers make assumptions that turn out to be horribly false about what users will know, understand, etc.
I think one of the biggest examples is that expert users tend to play with an application.
They say, "Okay, I have this tool, what can I do with it?"
Your average user sees the ecosystem of an operating system, filesystem, or application as a big scary place where they are likely to get lost and never return.
For them, everything they want to do on a computer is task-based.
"How do I burn a DVD?"
"How do I upload a photo from my camera to this website."
"How do I send my mom a song?"
They want a starting point, a reproducible work flow, and they want to do that every time they have to perform the task. They don't care about streamlining the process or finding the best way to do it, they just want one reproducible way to do it.
In building web applications, I long since learned to make the start page of my application something separate from the menus with task-based links to the main things the application did in a really big font. For the average user, this increased usability hugely.
So remember this: users don't want to "use your application", they want to get something specific done.
In my mind, the most visible example of "developers are not the user" is the common Confirmation Dialog.
In most any document based application, from the most complex (MS Word, Excel, Visual Studio) through the simplest (Notepad, Crimson Editor, UltraEdit), when you close the appliction with unsaved changes you get a dialog like this:
The text in the Untitled file has changed.
Do you want to save the changes?
[Yes] [No] [Cancel]
Assumption: Users will read the dialog
Reality: With an average reading speed of 2 words per second, this would take 9 seconds. Many users won't read the dialog at all.
Observation: Many developers read much much faster than typical users
Assumption: The available options are all equally likely.
Reality: Most (>99%) of the time users will want their changes saved.
Assumption: Users will consider the consequences before clicking a choice
Reality: The true impact of the choice will occur to users a split second after pressing the button.
Assumption: Users will care about the message being displayed.
Reality: Users are focussed on the next task they need to complete, not on the "care and feeding" of their computer.
Assumption: Users will understand that the dialog contains critical information they need to know.
Reality: Users see the dialog as a speedbump in their way and just want to get rid of it in the fastest way possible.
I definitely agree with the bolded comments in Daniel's response--most real users frequently have a goal they want to get to, and just want to reach that goal as easily and quickly as possible. Speaking from experience, this goes not only for computer novices or non-techie people but also for fairly tech-savvy users who just might not be well-versed in your particular domain or technology stack.
Too frequently I've seen customers faced with a rich set of technologies, tools, utilities, APIs, etc. but no obvious way to accomplish their high-level tasks. Sometimes this could be addressed simply with better documentation (think comprehensive walk-throughs), sometimes with some high-level wizards built on top of command-line scripts/tools, and sometimes only with a fundamental re-prioritization of the software project.
With that said... to throw another concrete example on the pile, there's the Windows start menu (excerpt from an article on The Old New Thing blog):
Back in the early days, the taskbar
didn't have a Start button.
...
But one thing kept getting kicked up
by usability tests: People booted up
the computer and just sat there,
unsure what to do next.
That's when we decided to label the
System button "Start".
It says, "You dummy. Click here." And
it sent our usability numbers through
the roof, because all of a sudden,
people knew what to click when they
wanted to do something.
As mentioned by others here, we techie folks are used to playing around with an environment, clicking on everything that can be clicked on, poking around in all available menus, etc. Family members of mine who are afraid of their computers, however, are even more afraid that they'll click on something that will "erase" their data, so they'd prefer to be given clear directions on where to click.
Many years ago, in a CMS, I stupidly assumed that no one would ever try to create a directory with a leading space in the name .... someone did, and made many other parts of the system very very sad.
On another note, trying to explain to my mother to click the Start button to turn the computer off is just a world of pain.
How about the apocryphal tech support call about the user with the broken "cup holder" (CD/ROM)?
Actually, one that bit me was cut/paste -- I always trim my text inputs now since some of my users cut/paste text from emails, etc. and end up selecting extra whitespace. My tests never considered that people would "type" in extra characters.
Today's GUIs do a pretty good job of hiding the underlying OS. But the idosyncracies still show through.
Why won't the Mac let me create a folder called "Photos: Christmas 08"?
Why do I have to "eject" a mounted disk image?
Can't I convert a JPEG to TIFF just by changing the file extension?
(The last one actually happened to me some years ago. It took forever to figure out why the TIFF wasn't loading correctly! It was at that moment that I understood why Apple used to use embedded file types (as metadata) and to this day I do not understand why they foolishly went back to file extensions. Oh, right; it's because Unix is a superior OS.)
I've seen this plenty of times, it seems to be something that always comes up. I seem to be the kind of person who can pick up on these kind of assumptions (in some circumstances), but I've been blown away by what the user was doing other many times.
As I said, it's something I'm quite familiar with. Some of the software I've worked on is used by the general public (as opposed to specially trained people) so we had to be ready for this kind of thing. Yet I've seen it not be taken into account.
A good example is a web form that needs to be completed. We need this form completed, it's important to the process. The user is no good to us if they don't complete the form, but the more information we get out of them the better. Obviously these are two conflicting demands. If just present the user a screen of 150 fields (random large number) they'll run away scared.
These forms had been revised many times in order to improve things, but users weren't asked what they wanted. Decisions were made based on the assumptions or feelings of various people, but how close those feelings were to actual customers wasn't taken into account.
I'm also going to mention the corollary to Bevan's "The users will read the dialog" assumption. Operating off the "the users don't read anything" assumption makes much more sense. Yet people who argue that the user's don't read anything will often suggest putting bits of long dry explanatory text to help users who are confused by some random poor design decision (like using checkboxes for something that should be radio buttons because you can only select one).
Working any kind of tech support can be very informative on how users do (or do not) think.
pretty much anything at the O/S level in Linux is a good example, from the choice of names ("grep" obviously means "search" to the user!) to the choice of syntax ("rm *" is good for you!)
[i'm not hatin' on linux, it's just chock full of unix-legacy un-usability examples]
How about the desktop and wallpaper metaphors? It's getting better, but 5-10 years ago was the bane of a lot of remote tech support calls.
There's also the backslash vs. slash issue, the myriad names for the various keyboard symbols, and the antiquated print screen button.
Modern operating systems are great because they all support multiple user profiles, so everyone that uses my application on the same workstation can have their own settings and user data. Only, a good portion of the support requests I get are asking how to have multiple data files under the same user account.
Back in my college days, I used to train people on how to use a computer and the internet. I'd go to their house, setup their internet service show them email and everything. Well there was this old couple (late 60's). I spent about three hours showing them how to use their computer, made sure they could connect to the internet and everything. I leave feeling very happy.
That weekend I get a frantic call, about them not being able to check their email. Now I'm in the middle of enjoying my weekend but decide to help them out, and walk through all the things, 30 minutes latter, I ask them if they have two phone lines..."of course we only have one" Needless to say they forgot that they need to connect to the internet first (Yes this was back in the day of modems).
I supposed I should have setup shortcuts like DUN - > Check Email Step 1, Eduora - Check Email Step 2....
What users don't know, they will make up. They often work with an incorrect theory of how an application works.
Especially for data entry, users tend to type much faster than developers which can cause a problem if the program is slow to react.
Story: Once upon a time, before the personal computer, there was timesharing. A timesharing company's customer rep told me that once when he was giving a "how to" class to two or three nice older women, he told them how to stop a program that was running (in case it was started in error or taking to long.) He had one of the students type ^K, and the timesharing terminal responded "Killed!". The lady nearly had a heart attack.
One problem that we have at our company is employees who don't trust the computer. If you computerize a function that they do on paper, they will continue to do it on paper, while entering the results in the computer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
This is a perennial question for me that I've never really resolved so I'd like your input. If I have actions that I know a user will not be able to perform due to insufficient privileges or object state, should the UI elements for those actions be hidden from the user, visible but disabled, or visible and result in an error if attempted? What would be the rationale for your answer? If disabled, would you communicate the reason why and, if so, how?
This is a web interface so I already know that I need to check the incoming post/get for permissions and handle errors there anyway. I'm primarily talking about how to handle the UI.
This is similar to Rules about disabling or hiding menu items, though I am interested in all types of UI elements not just menus.
Examples:
I have a New page that allows a user to create a new Event. Events can be master events or subevents. Creating a master event requires "EditMasterEvent" privilege, while creating a subevent requires only "EditEvent" privilege. I have a drop down that allows one to choose an existing event as the parent (master event) or no parent (this is a master event). Should the "Create Master Event" choice be shown on the dropdown or omitted if the user only has "EditEvent" privileges.
Deleting events requires that you be an application administrator or have the appropriate edit permission for the event type. In the latter case, the event must also be more than 5 years old. Deleting an event causes major cascading deletes of related data in the system and for legal reasons this data must be kept for at least 5 years after the event. Since this operation is rare for the normal user, the typical case is that the action is not available. Should it be shown always or only when actually possible?
Hidden - This is the best approach for actions that are never available to the current user. There is no point in having the user waste mental effort figuring out why something is disabled if there is no action they can take to change this.
Disabled - This is the best approach for actions that are sometimes available, but not at the moment or in the current context. A disabled option should convey two things: first, the action is not available right now, and second, there is something the user could do to make the action available (change some setting or permission, select an item, enter prerequisite data, etc.). If you can indicate what needs to be done to enable the action in a tooltip - all the better. Enabling/disabling actions as the user enters data or changes context provides excellent feedback about what the program requires.
Fail with an Error - This is the worst choice. You should only resort to an error report for operations that might work: you can't tell that it will fail except by trying.
As with nearly all UI questions, the answer is "it depends".
You need to weigh discoverability with user satisfaction, among other things. For example, allowing an invalid action gives you an opportunity to explain why something is invalid. This is particularly useful if the answer to "why is this disabled" isn't obvious. For an application where most users are beginners, that's important.
On the other hand, it can be mightily frustrating to see a control, click on it, only to be rewarded with a "sorry, you can't do that now" message. An app I inherited a couple years back was rife with that sort of stuff and it made using the UI an exercise in frustration.
Completely hiding functionality is probably rarely a good idea. Imagine knowing some feature "was there a minute ago" but now it's gone. Whether it's a menu item or a toolbar button or something else entirely, making it hidden can be an exercise in frustration for the end user.
Try doing a little usability testing, if only by asking the next person you see "hey, does it make sense to disable this or show you an informative dialog". Just one other opinion is often enough to get you to look at the problem from another direction.
Bottom line: do what best serves the user. All the scenarios you mention are valid under certain circumstances. As with all UI questions, ask yourself (or better, your users) what best serves their needs.
I disable the elements instead of hiding them. That way the user knows the option would normally be available, and I provide a tooltip to explain why the element isn't currently available.
It depends. Do you want the user to be aware that the action is possible, just not for them? In that case, show them the button, but disable it. An example might be if a user doesn't have delete authority, but other users do, they should know that entries CAN be deleted, so they can ask someone to do it for them if they need the action.
On the other hand, if the user is not supposed to even know about the action (for example, a user who does not have read access to audit logs probably shouldn't know that these logs exist) should not be able to see the button, so hide it completely.
Great question!
A couple of considerations:
If you place the elements on the page but disable them, there's still a remote chance that the user could doctor the system and enable them using a javascriptlet.
If you do not show them at all, the overall functionality may be a bit confusing to the general user. "Shouldn't there be an edit button here?"
If you're going to either display and disable or display and verify the elements, I would definitely do server-side validation. Don't leave the validation in the hands of JavaScript; I think the reasons for this are obvious.
I tend to handle the two different types of situations differently. Is this an action that is governed by privilege and by state of the object.
If the person does not have enough privileges to do an action, I hide the option, they do not know they can perform the action.
If the option is not available because the object is not in a state that can use that option, I disable it, allowing the option to be visible to the user, but no action can be done.
From your examples:
I would not have "Create Master Event" as an option. The user has insufficient privileges to view it.
I would have the Delete button visible to the administrators. Then depending on how you do the rest of the site (a lot of visible text, tooltips, help icon, etc) I would follow that convention about informing the user why the button is not usable at this time. And possibly putting a timer on, above, near the button with either how old the post is or how long until it can be deleted.
Depending on the item, we will either hide them or disable them. If the user has access to a large feature, but not to a smaller piece inside it, then we will hide the smaller piece. However, if the user has access to several large features, but not to others, we'll leave them visible but disabled as a marketing ploy to remind them that the features are available for purchase if they should decide they want them.
I've also seen some programs that disable the menu item and change the text of it to "Log in to do blah..."
I like this because it doesn't leave me with the "why isn't this working?" feeling and tells me immediately what to do to get it working. Not applicable in every case, but this is a nice approach if you can implement it.
The general rule is use disabling if the user can do something in the UI to get the privilege. Disabled means “you can do this command, but just not right now the way things are.” The “way things are” includes the current selection, so use enabling/disabling if the user has the EditEvent privilege for old objects but not for new objects. There should be a clear indication which objects are delete-able so users understand why the associated commands are disabled for some objects (e.g., if users generally know that records must be kept for 5 years, a simple Age field maybe be sufficient, perhaps reinforced with a graphic difference for records over 5 years old).
Use message boxes instead of disabling if there is no way to make the reason for the disabling clear to the user assuming they have average knowledge of the domain. Tooltips for disabled controls, BTW, are a great idea, but may not be sufficient by themselves.
Use hiding if the user never has the privilege no matter what they do in the UI given their current position in the organization (e.g., they are not an Application Administrator). It is cluttering and frustrating to use disabling or message boxes for this case. As far as the users are concerned, actions they don’t have the privilege for are not their job (otherwise they’d have the privilege), and so the associated controls should simply not exist in their UI. Documentation or organization procedure manuals may tell users how such actions are accomplished (e.g., “Your supervisor creates new events for you.”).
I’ve more details at http://www.zuschlogin.com/?p=40.
I would say disable with a hover containing the reason.
It prevents the user from wondering what the hell is going on while at the same time letting them know certain actions are possible under the right conditions.
I have a particular hatred of applications that disable buttons. If you're an end user - you want to know why you can't use that button. Having it greyed out doesn't tell you anything. How do you get to the state to enable it? Tooltips are one solution, but they aren't the best, a lot of users will struggle with tooltips (unless you're working with experienced users).
My personal feeling is that the elements should always be present. If the user doesn't have enough permissions to do them, they should generate an error when clicked upon.
I know that translators don't really enjoy creating a zillion different "permission denied" error messages, so this is often not done in localised applications, which tend to hide the elements instead.
In practice a lot of people tend to hide the options instead even in non-localised apps.
Other people have provided good answers with valid suggestion to avoid hiding elements and instead disable them and provide some hints for the reasons.
So, I would like to look at it from different perspective - but how to hide some UI elements in cases when user does not need to see them, no matter if he has or has no permissions for particular actions related to the elements?
For example, let's say, users of some role are given access to sellers records in the system.
But then business analyst says: "Look, there is a dropdown with sellers list in this form and we should not allow some specific roles to see it".
Developer asks: "So, we just remove the "Read sellers" permission from this role, right?" But the analyst replies: "No! This role should still be able to view the sellers on the Sellers page. It's just this single form where we should hide the list for some roles and show it to some other roles."
So, the developer adds permission called "Show sellers dropdown on the form X".
Ooops, now we have a problem. Access to the same data is being controlled by two separate permissions. Now we have to figure out how to combine both of them. And what if there are more than one form where seller's list should be hidden for some roles? How do we combine it with "Read seller's list"? For us, developers, it is somewhat clear that "Read" permission should have higher priority above "View", so even if a user can "View" a list, he still should not see it (or see empty or disabled with a helpful hint) if he does not have "Read" permission. We, developers and analysts of the system know it. But how should the system administrator know it? Should we teach him this? How can we guarantee that the admin won't confuse all those "View" and "Read" for the single data list?
As you see, it all gets messy for one reason - we are mixing data processing permissions with UI conveniences in the list of role permissions.
I have seen many projects where it gets messy because permissions on the server side get coupled too much to UI, which asks for troubles and possible security holes (because you have multiple items in your role permission editor for the same actions on the same data).
Permissions are about access and operations on some specific data. UI can only react to permissions in consistent way throughout entire system (disabling with hints, hiding etc.). We should never invent new permission entries just for UI purposes.
Now the question remains - but how do we actually hide UI elements for some system users to avoid overwhelming them with huge amount of always disabled items? One solution might be role workspaces. If we clearly know that users of some role will never ever need access to some specific data, we create a set of UI control entries, similar to permissions, but this time we don't call them permissions. And we can get really fancy here, even allowing users themselves to freely customize their workspace and choose what they can or cannot see. Of course, permissions will always take the highest priority, but it will only affect the data and state of UI elements and not visibility.
That's my two cents. Unfortunately, I myself haven't worked on such a system where permissions and UI workspace options are neatly separated because I always somehow come too late to a project, when the "damage has been done". But I hope some day I'll have a chance. I just hope to find a good example how to do this right, but somehow internet searches do not give me anything useful. Does it really mean that nobody else has came to the same conclusions as me? I don't believe it, somebody in the enterprise design pattern world should have noticed this UI<->permission impedance mismatch long ago.