Social Business User Experience blog
Amy Travis 1100006T7G firstname.lastname@example.org Tags:  smartcloud design ux socialbiz ibmconnect 3,518 Visits
I can't wait to talk to folks at IBM Connect about SmartCloud for Social Business. I'd love to hear from people who are using it, people who are thinking about it, and even those who aren't!
My colleague Ethan and I have got some great activities planned in the User Experience lab -- help us understand what's most important for you in the cloud, take a quick usability test, and give your feedback on some potential future design directions.
See you next week!
Amy Travis 1100006T7G email@example.com Tags:  communities ux engage features feedback 1,601 Visits
In the latest SmartCloud Engage release, you can now create three types of communities:
Currently, if you want someone from outside of your organization to join your community, it must be a restricted community. In other words, if your organization is "Company A", and you want to have a community that also includes people from "Company B", you can only do this if your community is Restricted.
I'd love to get some feedback on this from our SmartCloud Engage users! What types of communities do you create most often, and why? And would you want to invite people from other organizations into Moderated or Open communities?
Looking forward to hearing from you.
- Amy Travis (SmartCloud Design Lead)
Two weeks ago, I described hows inserting a fraction-of-a-second delay before display can go a long way toward alleviating one of the major criticisms of hover-invoked pop up displays like pop-up cards, hover help, and banner menus. This week, I’ll blabber about dismissing hover-invoked pop ups via methods that avoid the “squirrely-ness” that users hate…
Say “no way” to auto decay
Don’t design and implement an automatic decay (i.e., timeout) behavior. The pop-up should display until the user initiates dismissal by moving the cursor. The automatic decay behavior is often problematic as the system is guessing when the user is done viewing the contents of the pop-up, rather than allowing the user to indicate this through action.
Define the right cursor boundaries
The pop-up will generally display on mouse-over of a relatively small underlying UI element such as a hover help icon or a text link. The pop-up itself will extend from that underlying element and consume much more space. To prevent accidental dismissal, it is important to treat the underlying element, the pop-up itself, a small area of padding around each, and all the space in between the two as active areas. As long as the cursor remains within these active areas, the display should persist.
Implement a delay before dismissal on mouse-out
Another good practice for preventing accidental dismissal is to implement a delay of 800 ms or so after mouse out before dismissing the pop up. This allows users to persist the display when the cursor momentarily traverses outside of the boundaries of the active area described above.
When to make your hover-invoked pop-up sticky
If the user indicates a desire to interact with the pop-up beyond simply displaying and viewing, it should become a more stable, and less transient, part of the UI.
Once the user interacts with the pop up by setting focus to a field or other control within the pop up, moving it (possible with certain pop-ups), etc, it should become sticky – i.e., the pop up should no longer close on mouse out, requiring a more explicit means of closing (e.g., click-off, selecting the close button, or selecting ESC). As a side note – pop-ups that are displayed on click should almost always require this level of explicit action to close.
Summary: 4 keys to avoiding “squirrely” pop ups on hover
The behaviors described here are important for all users and many of them are especially important to ensure a usable design for users with a range of physical and cognitive disabilities.
So, don’t be lazy. Laziness leads to squirrelly-ness…and squirrely-ness leads to unhappy users. We like our users to be happy
Patrick Commarford 06000165T3 firstname.lastname@example.org Tags:  hover sustained_hover ux popups 3,175 Visits
Need a better view of Uncle Harry’s hairy nose? Just hover over his thumbnail and you’re all set! Want more info about that remote-controlled beer pager without leaving your current page? Hover, friend. Hover.
It has become common practice for many sites and web apps to display certain types of “pop-up” UI elements on hover (mouse-over). For example, banner menus, contextual help, and preview cards (e.g., person cards, movie cards, etc.) all commonly display when users hover over a link, icon, thumbnail image or other UI element.
The good and the bad…
When using a mouse (or other device that controls cursor movement & interaction), this behavior can be really useful – allowing a single UI element (e.g., a link) to provide two different capabilities for hover and click. For example, it’s common that hovering over a person’s name link will display a person card; whereas clicking the name navigates to the person’s profile.
The biggest criticism to allowing hover to invoke pop-up UIs has been the complaint that these pop-ups can appear without user intent – for example, when the user drags their mouse across a screen and inadvertently passes a hover help icon, a link, or a banner menu. This complaint is especially strong (and valid) when the pop-up interferes with a user task or displays something that the user considers of no value (e.g., an advertisement).
Enter the sustained hover!
Sustained hover is just what it sounds like...we don’t display the pop-up on simple pass-by, but require that the pointer rest over the underlying UI element for a sustained period. This allows users to request the pop-up and usually prevents inadvertent display.
So, what’s the right delay?
We believe that delay times should range from 300-700 ms, depending on a number of factors including the likelihood that the user’s cursor will inadvertently come to rest on a particular UI element (largely determined by placement and density of pop-up UI hover targets) and user expectations driven from common industry practice.
For example, 300 ms appears to be the appropriate delay for invoking a banner menu. We have user data indicating that immediate display annoys users who intend to simply drag the cursor past the menu. However we’ve also found that if we set the delay to more than 300 ms users report that the menus feel “sluggish” (this is likely largely in comparison to the common industry practice of implementing zero delay or a very small delay).
On the other hand, object preview cards and the like are often invoked from lists or grids of data and are invoked on hover over thumbnails and/or displayed names of items. These types of elements often populate a fairly substantial portion of the UI; therefore it’s generally more appropriate to allow for a little longer hover. In this case, we believe it to be a best practice to also provide a subtle, but immediate visual change to the underlying element. This is a good way to tell the user that a pop-up is coming if he just holds his little horsies for a half second or so
Does sustained hovering solve everything?
Nope. Unfortunately, this technique does not prevent inadvertent display in the less-common scenario in which users rest their cursor on an active UI element. It also doesn’t tackle other concerns of hover-invoked UIs like how best practices for dismissal and how to handle touch screen interaction. I’ll look to blabber about those in a future blog post.
Patrick Commarford 06000165T3 email@example.com Tags:  ux mega nav menu design navigation 3,133 Visits
Some IBM products have begun providing mega menus for global navigation, quick access to secondary views, and even direct access to individual artifacts. Feedback has been positive and we have recently drafted design guidance, as part of our IBM One UI initiative, for standardizing mega menu interactions.
The IBM One UI mega menu guidance is based on a combination of our experiences from multiple IBM products, UX-articles outlining best practices, our internal UXR data, and a review of industry practices.
The following is a sample mega menu design. There are no current plans for this design to appear in any IBM product.
Industry practices and user research data
During the course of defining the IBM One UI guidance for mega menus, we reviewed a number of UX articles documenting proposed best design practices for mega menus (along with the rationale behind those practices). As an example, see that Jakob Nielsen gave mega menus a big thumbs up after observing them to be a very usable & useful form of navigation.
Within IBM, we have also tested our own mega menu prototypes, with our UXR Team reporting that usability test participants like mega menus and make solid use of the shortcuts that the menus provide.
Our mega menu practices are also partially guided by an industry review of 35 web apps and sites that provide mega menu navigation. This review has helped us understand the dominant behaviors in the industry as we recognize that user expectations are shaped largely by their everyday software experiences.
A sample of a product experience
IBM Lotus Connections 3.0 began implementing mega menus in part to fix a design problem such that the top-level navigation, when exposed as a series of individual navigation links, didn't fit properly at 1024 px. The mega menus allowed us to provide navigation to all the primary views by collapsing some of them into an Apps menu. This also allowed us to save users clicks (and page refreshes) by providing direct access to secondary views, and in some cases direct access to specific artifacts (e.g., recent communities). By all accounts, this has been a very positive change.
Ethan Perry, our Connections Design Lead reports that he has received positive feedback from several customers, during design discussions, on both the mega menus implemented in v3.0 and on prototypes of more advanced mega menus (which include additional controls such as search mechanisms with autocomplete as well as primary actions that would otherwise only be available by first navigating to another view).
We like mega menus. We especially like our mega menus. We hope you do, too.
In visual perception a color is almost never seen as it really is—as it physically is.
This fact makes color the most relative medium in art.
–Josef Albers, Interaction of Color
Our perception of color is constantly influenced by the relationship between a given color and it's surrounding color (or colors) and is an important principle to be mindful of when working with color. Below is a simple example of this principle similar to the studies found in the above quoted book (Interaction of Color - Albers, Josef). The two small squares in the illustration below are the same color but have been purposefully made to appear different by placing them on particular background colors.
This principle can also be seen within our products as well. As an example, the 'IBM blue' of our application icons can appear to be different in varying contexts i.e. the dark backgrounds of our mobile applications and the lighter backgrounds we use in our web UIs. The following two Connections icons are identical but have been placed on a light and dark background. It's not as stark as the above example, but you can see how the left icon appears to be more vibrant than the icon on the right, even though they are both identical.
Brian Utesch 0600022PW3 firstname.lastname@example.org Tags:  userresearch userexperience ux research 1,153 Visits
IBM is looking to get design feedback and to understand how you create and edit content online. No experience with IBM products is required and it should only take a few minutes to complete. This information will be used to influence product design and direction. Thank you!
Take the survey (https://www.ibm.com/survey/oid/wsb.dll/s/ag457)