I'm building a web application where one of the features causes users to be notified in real-time when an alert pertaining to them occurs, similar to the big orange bar in Stack Overflow.
I have a few options, and I was wondering if there was a usability guideline on the best way to go about this. One option is to have a small notifications box on the screen that flashes colors when an alert appears, but I'm worried that a simple, repeated change in color won't be sufficient to attract the user's attention.
Another option is to have a window come floating across the screen, demanding the user's attention, but I've always found those to be obtrusive. Maybe another form of animation could be less annoying yet equally likely to attract the user's attention?
I'm not really looking for an opinion as much as I'm looking for a usability discussion/resource that might cover this kind of decision.
The answer somewhat depends on how important it is that the user pay attention and how important it is that they take some action? E.g. is the alert of the "your server just crashed" kind or "you have new e-mail from aunt Zelda" kind?
For the first kind, something obtrusive is the best - either your option of floating a window, or may be change the page background to flashy color (and blink??? Don't hit me please!). One other nice way of grabbing attention I saw was to change the page (and thus a browser window) title to a flashing set of "* * * * * *" - that is un-usual enough to attract attention sometimes.
For something less obtrusive for less critical-too-notice-quickly, SO's top notification bar is one of the very best solutions from usability standpoint (if not the best), going by the main metrics (how much work does the user need to do to deal with this and to look at it, and how intuitive its behavior is):
The user's eyes travel to top of the screen more often and more likely than elsewhere
It is very easy to get rid of once you notice it - the bar is wide (easy to hit with mouse, no horisontal adjustments needed) and at the very top (not too much fine mouse work to get the pointer there).
IMHO, the annoyance level should reflect the error level...
For an error, a layer with the error message, preventing the user to do anything else should be better.
For a notification, a box that appears on the top of the page (like a browser asking you to save a password) is nice.
So I don't think there is a better solution... It just depends on the type of the alert... : )
Check out JGrowl, it's a nice framework for unobtrusive notifications, you can find some sample screenshots here.
If you are looking for resources, I suggest Don't Make Me Think by Steve Krug. His site, Advanced Common Sense, is also a great source.
Another great site for Usability tips and guidelines is Jakob Nielsen's useit.com
I was at a site the other day that had a product download button. I clicked on it, it seemed nothing had happened. I clicked it again, and the download link that the first button created did a little shake at me. Very effective and it got a laugh:
http://haanstra.eu/putty/
My system has three types of notifications. Each type of notification is styled with a border and background color:
Success: Green
Warning: Yellow
Error: Red
Alerts, like "You didn't fill that field in properly!" are handled inline, so no popups to irritate the user.
I've designed my system to fade out notifications a few seconds - this means that users are accustomed to seeing the green box that fades away after a few seconds. However, when an error or warning occurs the box stays on the screen right in front of the user, demanding attention.
I believe warnings and errors should be used only when absolutely necessary - that way when they are used, they maintain a significant level of impact. In my system, warnings and errors don't fade out - they stay there to remind you SOMETHING IS NOT QUITE RIGHT.
In my experience, if you're going to interact with a user, make it large and in their face, but don't make it so much so that it obstructs the rest of the page. So no prompts, or lightbox style overlays (in my opinion).
I find the jQuery UI highlight() effect function is good for unobtrusively alerting users that something has changed; however as others have said, it depends on the importance of the message - sometimes you just need to be obtrusive!
Related
I'd like to have the users desktop or whatever windows they have open show through the background with a slight bit of opacity. I did a quick mockup in photoshop to try and illustrate what I'm aiming for
I'm fine with using a bit of jQuery if need be, but would prefer to keep the foot print light. I don't really want to add a ton of overhead just for a fancy effect.
No. You cannot make the browser window translucent.
This is completely impossible... using current APIs. It's theoretically possible that one might be implemented in the future, but for now, the best you can do is transparency to the user desired color.
I doubt this is possible since it requires the actual browser window to be transparent, which is almost surely not the case.
Maybe with some plugin for the browser, but not by code in your website.
No, this is impossible.
99.99% of the time, if you've never seen it before, there's a good reason*.
*EDIT: These comments are specific to web programming... not meant to apply to the sum total of human innovation.
The term is Form Opacity, and you have to have access to the applications source code, in most cases to manipulate it. Several programs already have this as a standard or hidden feature, i.e. Trillian, and iCalenderLite, to name a couple.... Windows 7 allows you to do it to any open window.
form.opacity
EDIT: Answer has been getting downvoted without comment, so I added the OP's and my additional remarks here.
Would this still be out of bounds for a website to change though? FREX I couldn't have my website turn form opacity on (just for site X) if it wasn't already? – aslum Jun 7 '11 at 23:33
For that, I would have to say "not possible", unless it was a "live" control, loaded by the browser to begin with. You most likely would not be able to do it on a "by site" basis only. And even though most user initiated events are "technically" replicable via script or code, proper security levels, would render such an event, inaccessible to outside manipulation. – tahwos Jun 8 '11 at 22:04
I am seeing a lot of this is impossible. The correct answer is currently mostly impossible ;) Using programming, you can create a window or application that is transparent. I have never done anything of the sort, but I have used several programs that allow you to control transparency.
My best bet for controlling opacity of a window is DirectX. So If you were to make a browser with DirectX, you could control the opacity of the window by reading the CSS.
So basicly, you could do it your self, much like mozilla firefox reads their own css (-moz-radius) just make your own DirectX based Web browser. I could see someone getting a lot of support on a project like that.
Is it possible to add animation to Microsoft Access? What I am envisioning is that someone clicks a button on a form and an animation appears and then goes away. Kind of like how when Mario jumps and hits a block, a coin appears and disappears. I know its a very general question, but I couldn't find much online regarding this.
You can move a timer event or similar to adjust the top/left position of a control/picture.
But you wouldn't, as Access (VBA) is single-threaded meaning that while such animation goes on, nothing else will happen, effectively freezing your application. That is really annoying for the user, and that is one of the reasons you meet very little code in this area.
Yes, this is possible. You would basically be drawing and redrawing sprites at specific screen coordinates. It's horrendous in Access, it looks clunky and will kill your app. The reason you can't find much about it online is because it's a very bad idea to try to incorporate it into a database.
Even if you took a shortcut and had multiple GIFs made up (think of an old-school flip book animation), you still have to draw and redraw a bunch of controls. I suppose if you really wanted it you could add it, but I still think it'll drag and look clunky.
Sometimes when I Inspect Element in Google Chrome I find that I have some large frames, but they are filled with white space. Anyone know what often causes such large amounts of empty space? I have seen timers cause issues with extending the frames length but in the example below I am unsure why a frame would be so large.
Would love some help minimizing these
This is documented here, see the 'About clear or light-gray frames' section. 'Clear frames' in question are described there as
Idle time between display refresh cycles.
According to this video, clear bar indicates browser waiting for a CPU or a GPU. There is nothing that developers can do to fix this when working on a 'standard' website.
I found some interesting relations and i hope it will save time for someone (I spent lot of time before figure out all of this)
Most important - chrome devtools cost a lot. A mean A LOT, even if it says nothing about it. For example:
"Screenshots" in performance monitor increases frametime from 16ms to 66ms in my case and just fills it with empty space in timeline - without screenshots and with screenshots. (Now i see long operations on GPU with screenshots, but there's no any info about what exactly particular operation did)
Things in "rendering" tools like "paint flashing" or "fps meter" greatly increase painting operations time. Just be sure that you disabled all of this before analyze performance!
Very strange things happens with "other" segment(Grey color on timeline). It suppose to be devtools cost itself, but sometimes it can randomly be around zero with lot of calculations or be on 100% wile idle. My advice - there's new "performance monitor" tool in new chrome versions (Not simple "performance"). It is better to toggle it on and keep an eye on "CPU usage" timeline. If you see unexpected behavior of gray curve just reload page or whole chrome - it may save lot of time for you.
Some extensions may cause random effects on timeline. It better to disable it too.
Actually any thing in tools or extensions may ruin your measuring. Toggle all of it off before start search out issues in you code, dom, or styles
I'm working on a web application where we have a modal panel/dialog popup to collect user data. The form within the panel has grown large and we've suggested splitting the form across multiple tabs, but our client has suggested adding scrollbars within the modal panel.
Are there usability issues with scrollbars within a modal panel? I believe it's a bad practice but I'd like other opinions.
Thanks,
Glen
Update:
I'll explain the scenario in more detail. We have a search page where search result items can be saved (copied into a another area of the system). Additional information can be saved with this items (e.g. additional comments, assignment to other buckets - I can't get into any more detail than that). When a user wants to save a search result item, they can check one or more items and click a save button - that's when our modal panel popups.
Originally, the users were taken to a separate page and they followed a series of pages. Our clients felt this was time consuming, so we changed the page to use a modal panel.
I'm not 100% sure using a modal panel is the best design, but that's what we have now. I welcome any other ideas.
Well, I gotta ask, if you have a modal form that's so long, shouldn't it be made into its own page?
I mean, the whole point of modal dialogues is to tell the user something he needs to know (which are usually disregarded and are annoying) or to get some information from the user that is necessary before proceeding.
You say your form is for gathering user input. If it's something the user must enter before proceeding (as in a part of a checkout flow or something like that), then I would say it's probably best to dedicate an entire page to the flow.
If it's something that's more of a "log in here before proceeding with what you're doing" kind of thing, again, I think it would make more sense for it to be its own page that brings you back to the page you were on before you entered it once you're done filling out the form. That's how the Stack Overflow human-verification page works.
If it's something annoying like "give us your feedback about the site", then it shouldn't be modal at all but rather an easily-dismissed (dare I say it?) pop-up window.
Modal dialogues really should be kept as brief as possible. If brevity is impossible, and the dialogue really must be modal, then I think it would make more sense to create a flow of pages that must be filled in before the next one can be accessed. Like a checkout: you need to add products to a cart before adding shipping information, and you need shipping information before you can determine the cost of the shipment. That kind of thing.
But without knowing the exact nature of your modal dialogue I can't tell you exactly which way would be best.
EDIT: Aha! Your clients felt this was time consuming, eh? This is the type of situation where you should do a very quick and dirty live usability test to see which way is actually better. Grab some people from down the hall, show some of them the modal way (with scrolling) of doing it and show others the old (non-modal) way of doing it and see what they have to say.
(Ideally you are recording the session and the screen, and you make sure to not let your own personal preferences show through. Just ask them to use the system while you watch to see how well they perform the task. Use the recording to time both methods to see if one way really is faster than the other.)
You shouldn't ever make a usability decision that goes against the norm (the norm in this case being "large forms merit their own pages") without making sure that it actually is more usable the abnormal way. When it comes to usability, the norm is usually the norm because it's usable (but not always, which is why you must test). If the client fights back, you'll at least have evidence that they're going against hard empirical evidence that what they want is silly.
Ultimately, though, the clients are the ones paying the bills. If you can't get them to see reason then you'll have to make the most of what they tell you. If the form must be in a modal dialogue, then you can at least try to hide non-essential fields under the fold (if there are non-essential fields) so that the majority of users will never have to scroll.
Make sure the buttons to submit the form (or whatever it is that you need to do with the form) are visible no matter where the user has scrolled. A really bad idea would be to put all the required fields at the top and then force the user to scroll down anyway to hit the submit button. That's just rude.
It seems to make sense to put a modal window here--I assume you're doing it as a layer on the page. But what it sounds like is that it's getting crowded, and you're looking at ways to manage the ever-increasing array of UI elements.
To answer your initial question about scrollbars, no, they are not verboten. However, as another responded asserted, you should never design action UI elements within the scrolling area.
It sounds as if some good user research could be useful here. What items are important to users. Which items are required and which are optional? Can they be categorized?
Some people suggest that tabs are useful for categorization when the number of UI items overflows a dialog box. In this case, though, I think this would be a bad idea. This isn't a setting category of dialog box, but more of a confirmation/selection/entry dialog where users will save whatever is entered and chosen. There's a good chance with tabs that users would miss the tabs and miss entering information. And if something on a "back" tab is required and a user doesn't go there, then you have a really poor error experience.
One of the things about scrolling is that it is easy for users with mice. they have the option of either clicking on the scrollbar or (for many) rolling a scroll wheel.
One thing you may not have considered, especially if some things that users can enter or choose are optional, is to create sections within the dialog box that can be collapsed and expanded. Sections with required elements would be expanded by default and sections with optional elements would be collapsed by default. If expansion of a section adds a scrollbar, that addition to the UI is obvious to users.
Of course, you may have to figure out how all this would work for people who have only keyboards, who have disabilities, and who might be accessing this on a mobile device.
I don’t think a tabbed panel is fundamentally better or worse than a scrolling panel. Each has advantages in different situations. However more important in your case is this: If you need tabs or scrolling then your panel is probably too complex to be modal. The more information input in a modal panel, the more likely a user will need to go somewhere else to get an answer, and the more work you throw away if the user decides they must go somewhere else for any reason.
The solution is to move as much information as you can out of the panel and onto the parent page/window. Let users enter the “additional information” right onto the search results page, allowing them to explore the results to help them decide on the information. Since the additional information apparently consumes a lot of space, make its controls show-able and hide-able, but always preserve user inputs between hides and shows. I think it’s okay to either tabs or scrolling to keep the footprint small. Additional information about a single search result should go in controls next to that search result, rather than in a separate panel.
The modal Save panel should only include a few controls that are instrumental to saving, such as the filename and location, and maybe the file type. If all the information is instrumental to saving, then make the save panel modeless. Who says you can’t?
Putting all the save information on another page is not much better than a modal panel, since that is also effectively modal, in the sense that the users can’t go somewhere else without losing their input. Even if you take steps to preserve users’ inputs to the page if they go to another page, most web-abused users will think they might lose their input, so they won’t try.
I like to display more info on certain keywords in a web page. I don't want to send the visitor to another page and I prefer to show the extra info on top of the current page.
The keywords are in an html list. It's basically a list of features and I want to offer more info about the features. So I have two ideas based on having 'More Info' or '?' hyperlinks.
The user hovers on the link and a popup window shows up with the info and goes away when they hover away.
They click on the link, a popup window with an 'X' shows up and they click on the X to close.
Which one offers a better friendlier user experience?
I like #1 because they don't have to click to open and click to close but the disadvantage is that windows might open inadvertently while they are mousing over the page.
Both are pretty annoying, but if I had to pick the lesser of two evils, I'd go with properly done mouseovers.
You can setup Javascript on the page to handle the accidental mouse over, and instead wait for a few seconds before displaying the popup window.
What would your users expect? Try not to break those expectations.
Maybe try a hallway usability study, grabbing a handful of users as they walk past the office, and just ask them to tell you what they would expect. :)
Asking Stack Overflow is a good idea too, but you won't get the advantage of context, which is very important with usability testing.
As a user myself, I find it annoying when I move a mouse and something pops up unexpectedly. Even with a javascript delay (which is better), I still think it's unexpected that something would pop up when I didn't explicitly click on it.
But, that might vary depending on the context of your application.
Personally, I'd go with the click option. There's a standard Way Things Work on the web which says that hovers are for information about the link itself and what action clicking on it will do ("See more comments", "Click for help", etc.), whereas clicking is what actually performs the action.
If you do decide to go with the hover option, make sure that you code it such that users can select the text in the popup. It's really annoying when you just want to copy some useful information somewhere and the GUI hides it before you can reach it.
Adding to what the others have said, I would also prefer the click option.
The problem I have with the hover option is that, and maybe this is just me, if the hoverable area is on the small side, I have a hard time keeping my mouse still enough to keep hovering. The cursor tends to move off the link in the middle of reading and my nice help text disappears.
People don't expect a pop-up on hover - I'd definitely go with the click.
Edit / addition: think about the website you visit every day - text and pictures are (generally) static, and hovering, at most, changes the colour or add underline to a link, or displays a small menu of clickable links.
When clicking on a link, you expect something to happen - a redirect to another page, a pop-up box with information, a form being submitted, etc.
I'm not saying this is the best way to do things, but it is the way 99% of the web works, and asking users to deal with pop-up boxes on hovers or the like is a good way to turn them away. I know I personally don't read any pages with double-underlined links; it's a good indication that an accidental break in scrolling to read the content might end up with my mouse over a link with an advertisement tied to it.
Having a little graphic beside clickable text, or otherwise denoting that clicking will lead to more information is a great way of providing contextual information without frustrating people. For most of the world, pop-ups without clicking still == advertisements or spyware.
Edit / clarification: I don't mean a pop-up in the new window sense, just a lightbox-style javascript pop-up. Don't take the user away from the page, and give them a very visible button to click to close the pop-up. I guess what I'm saying is that people don't expect something to happen without clicking, especially not if it's going to take up more space on the screen.
As a couple of additional precedents to consider, you might want to consider the functionality of the acronym and abbr HTML tags. Both allow you to provide extra information on a particular piece of text in the page, and both work on the "hover" principle.
Points to ponder:
If items are so dense that everywhere you move the mouse something pops up on hover then do NOT do hover!
Can you make hover show very brief info, and have click show more detail? This may be the best of both worlds if it works for you.
Can you have a dedicated box that displays info when you hover? This may be better than any pop-up. Opinions vary...
In the end it's what works for your app, from your users' point of view.