I would like to design a GUI dashboard for a document management application. The dashboard contains only documents thumbnails. Each document may belong to a few hierarchies (e.g. "topic" hierarchy, "language" hierarchy, "genre" hierarchy, etc.) A user may want to select math texts in English, or lyrics in all Roman languages, etc.
How would you design a GUI for this ? What if the dashboard runs in a multi-touch tablet device ? What are examples of such GUI ?
I sketched these examples that would work with mouse or touch:
1) Dropdown Tags: You can use a approach similar to what Delicious do with tags, but put tags under hierarchies which you can chose on dropdown menus right on the top. The documents are filtered on real time while you choose the filters. It would be interesting to save an old filters for quickly navigation.
2) CheckBox: If you have few filter and options you can keep a bunch of checkbox on the side and filter the documents on real time:
However, it is hard to come with a UI like that, I think you should prototype and ask for the user to test what is better.
When you design a UI interface, remember that the user has to know where they are in a system. They need to know what they can do next; and what will happen when they do it and get there.
The most intuitive GUI for any user will be one whose interface they're already familiar with.
This way, they won't have to spend time thinking about what would happen when they perform a certain action.
Browser UI's and File explorer UI's are some such examples.
Hovering on a file to see a semi-transparent pop-up which lists options of what to do with the file is another way to enhance usability without cluttering the screen with navigation aids. (this works even for multitouch screens)
Related
I want to create a form with iOS like transitions (in a Cocoa desktop application) between the form input. For instance, the user would input information to the form and click next to continue to input the remainder of the information. On the last form, the user would click submit. Upon clicking next, the form would have an animated transition, like on the iPhone before displaying the next set of forms. Sort of like how Turbo Tax ask a ton of questions before allowing you to submit that grouped information.
What would be the best approach to achieve this goal?
This is commonly referred to as a wizard.
You basically have two options:
Use a tabless tab view, following Apple's sample code in AnimatingTabView from http://developer.apple.com/library/mac/#samplecode/Reducer/Introduction/Intro.html
Manually swap the views in and out yourself.
There are pros and cons to both approaches. Which you choose will probably depend on your requirements. One issue with Core Animation on the desktop is lack of subpixel rendering for layer-backed views. This is mostly an issue with text display but some people find it not to be an issue.
I've needed this functionality a few times. I used this tutorial to get started.
I'm trying to modify overflow7 so that its even quicker to navigate - trying to make it more quickly browsable.
To do this, I want to add the notion of navigating "up" as well as the "back" direction that's so natural in WP7. So, if a user is browsing a StackOverflow question then I want them to be able to:
quickly navigate "up" to the StackOverflow page (this could be ten steps "back" otherwise)
quickly navigate "up" again to the list of all StackExchange sites.
Currently, I've experimented with using a "Home" icon on the application bar (but this goes too far currently - all Home requests go to the top level), and I've experimented with putting a hyperlink top-left on the page. I've also tried putting a series of them as a breadcrumb.
These experiments have so far had several problems:
they've required too much thumb dexterity - links at the top of the page are a bit of a stretch
they've looked a bit ugly
they've taken up too much screen real-estate (especially the breadcrumb)
I think I'm currently heading towards trying to use some sort of Up icon on the Application Bar - although the designs I've looked at so far don't really look like they fit with Metro...
So... I'm asking the Metro design gurus among us: what's a nice Metro-friendly way to achieve the effect I'm looking for? Is there a Metro-friendly concept I could link to in terms of verb and icon? I am trying to work with Metro, rather than against it.
This is one of those situations where there just isn't a good "metro" way to do this - the guidance really is, back key presses, until "home". In fact, some of the marketplace ingestion requirements enforce this in some situations.
I'm rebuilding a language selection interface for a multi-national website, and I'm beginning to think it might be better for usability to use a simple form drop down rather than the custom JavaScript drop down menu that they're currently using. Am I way off base here, or should I go with my instinct? What do you think?
Simple drop down has its advantages. When you let the browser decide what to do, instead of forcing it to do what you want via JS, then browsers for unique circumstances (such as mobile devices) will format the drop down as its native selector.
If the custom js menu provides no additional functionality then definitely go with the basic select menu. However, if there's a good reason to use the custom menu, consider implementing it in a way that uses progressive enhancement so you can be sure it provides the basic functionality for everyone and adds features for browsers that can support it.
Any user who reaches the page for setting languages, comes with a specific aim in mind. He already knows what language he wants to set here (just as in most forms people know what they want to fill in for their birth date).
For this reason, I would recommend a text box with autocomplete functionality. Here are the advantages:
a text-box with a type-ahead works much better than a dropdown in most cases when the user knows what his options are
a dropdown with searching for "R" functionality doesn't always work the same way for all browsers, and not all browsers implement searching for "RUS...." and beyond.
from a purely is-this-usable standpoint, the type-ahead will prove to be far more useful over time.
I wouldn't use a drop down for countries - they are cumbersome to use when the number of items are large (https://ux.stackexchange.com/questions/31738/what-is-the-maximum-recommended-number-of-item-to-put-in-a-drop-down-list).
The "start typing a letter" to jump directly to say Russia when pressing R is a great feature in drop down lists - although I suspect that this is a power user feature - one that a lot of users will be unaware of (basically because it's a hidden feature).
Check out this solution instead -
http://uxdesign.smashingmagazine.com/2011/11/10/redesigning-the-country-selector/
Cheers
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I'm writing an internal-tools webapp; one of the central pages in this tool has a whole bunch of related commands the user can execute by clicking one of a number of buttons on the page, like this:
toolbar http://img709.imageshack.us/img709/1928/commands.png
Ideally, all of the buttons would fit on one line. Ordinarily I'd do this by changing each widget from a button with a (sometimes long) text label to a simple, compact icon - e.g.
button labelled "Save" http://img337.imageshack.us/img337/773/saver.png
could be replaced by a familiar disk icon:
Unfortunately, I don't think I can do this for every button on this particular page. Some of the command buttons just don't have good visual analogs - "VDS List". Or, if I needed to add another button in the future for some other kind of list, I'd need two icons that both communicate "list-ness" and which list. So, I'm still considering this option, but I don't love it.
So it's come time for me to add yet another button to this section (don't you love internal tools?). There's not enough room on that single line to fit the new button. Aside from the icon solution I already mentioned, what would be a good* way to simplify/declutter/reduce or otherwise improve this UI?
*As per Jakob Nielsen's article, I'd like to think that a dropdown menu is not the solution.
Edit: I'm not looking for input about the icon idea. I'm looking for other solutions. Sorry my example disk icon was a small one; it was just an example. I'm showing a bigger one now to hopefully be more clear.
I would add a More Link Like Google does.
See the Top Bar of Google with WeB Images Map More >>
To this more >> drop down you can add logic to add button less frequently used by user or something like that.
If you read Jef (and Aza) Raskin, you'll probably realize that icons are also not a good solution – both were pretty vocal in their dislike for them (with very few notable exceptions). For a start they're even harder to hit than tiny buttons, then their symbols can be confusing, culture-dependent and misleading. We're already good at reading text, parsing and interpreting icons is often slower.
In any case, that button bar looks like it accommodates pretty much anyone and their dog who might be using that product. You might have had some specific scenarios in mind when creating it that should be easy to do and are important. Most likely not all buttons are needed at once for such a task to complete.
Another thing is that maybe not all buttons are even useful at any single state of the application. Can you maybe branch into different sets of buttons, depending on the state. That's only possible however, if each state has clearly defined what actions can be taken. If all buttons are equally pressable regardless of state this won't do anything.
Grouping commands according to related functionality might also be an option. This doesn't have to be done with menu-like idioms, you can also put them into containers with different background color or even color the buttons themselves (just keep in mind color blindness, though). Depending on how related those individual functions are this can be a good way of speeding up interaction. It might requier some training for users to know what the colors refer to but for an in-house tool that's only used by people you know (instead of by arbitrary random ones [which is a problem Microsoft faces quite prominently]) this should pose not much of a problem.
What if you use icons and text?
For the commonly understood commands - use just an icon (like the save)
For the uncommon commands use an Icon + the text.
If you put a border around the button as a whole it should tie the icons / text together nicely and show it's still a button. You could also do some hover effects.
Since you can't do a dropdown menu (or similar techniques like clicking a button to generate a secondary menu). The best I can think of is what Prescott did or showing an area of buttons that are grouped in such a way to make it easy for the user to know which section their button should be in.
I would start by changing some of the longer labels. At a minimum, "Application Loading" could be abbreviated "App Loading." What's another (shorter) way to say "Quick File Transfer"?
You could also group the buttons into tabs (i.e. make it a ribbon). That might work particularly well if different classes of users tend to use different, non-overlapping sets of buttons.
Numerous options:
Group and labeling. Any time you have more than eight commands, you should divide the menu items into semantic groups of about four to help the user scan for the command they want. Labeling the groups also helps the scan and can make the menu more compact. For example, Instead of VDS Ping and VDS List, Have a group labeled “VDS” with “Ping” and “List” menu items. You’ve one less word to fit in (two if you put the label above it’s associated menu items when using a horizontal orientation).
Pulldown menus. Nielsen is correct about avoiding the use of a dropdown menu for making commands. However, he’s clearly in favor of pulldown menus which look and behave like a menubar in a thick client app (Nielsen calls them “command” and “navigation” menus). I think you’ll find that there are several Javascript pulldown menus out there now, unlike back in 2000 when Nielsen wrote his post. You can fit 100s of commands in a menubar.
Sidebar menu. Arraying the menu items vertically and you should be able to fit 20 or more commands and you won’t have to shorten any command names to something user might not understand. If that’s not enough, consider a “menu bank” than combines the benefits of sidebar menu with the capacity of a pulldown menu.
Ribbon. If your commands fit into discrete tasks, where the user tends to stick to one task for a while, you can arrange the buttons on a tab control, with one sheet per task.
Command Overloading. Represent your data objects as selectable entities in your window and change your commands into more general operations, like Drill-down, Create, Copy, Move, Delete, and Link, that can be applied to various different classes of objects, thereby reducing your total number of commands. The user can select one or more data objects then select the desired command to act on them.
Work Area Attributes. Some of your commands may not be commands by settings or attributes. Remove them from the menu and represent them as data objects in the work area of the page (or another page, if they are rarely used) using controls like radio buttons, dropdown lists, and check boxes. This has the added benefit clearly showing the user the current setting as well as providing a means to change it.
Variants. For an internal app, you probably have formal roles and responsibilities that vary by work position. Include the user’s position in your model, and dynamically hide commands (and other controls and pages) that aren't relevant to that position.
What about a combobox and a Confirm button?
Or a simple dropdown menu?
Add a "Tools" or "Actions" menu bar, and stick rightmost 4 commands (or more) into the menu.
Would it be possible to implement a "most used" or "preferred" set of buttons (preferably for the user, but globally if necessary) and button to take you to the rest of the items if you need one of those?
You could group them (like the two 'vds' buttons) behind a single button that, when clicked pops a context menu with the individual icons.
It truly seems like what you're developing is a administration console which happens to present its UI through a web page, rather than something which I'd quantify as a web app. As such, especially given your statement that this is an internal use application, Jakob Nielson's advice regarding <select> tags being poor design need not apply.
For this particular set of assumptions, I think the better option is to imitate a system menu setup using one of the many CSS-based menuing designs possible.
Icons are terrible from a user experience stand point. A picture of a Floppy Disk doesn't un-equivocally mean SAVE. It means something to do with a Floppy Disk. A Floppy really, its 2010, SAVE on a web app means save to the server, how does a Floppy Disk even compute?
Here is an application that has had the same extremely usable interface for 10 years! And hardly any images for buttons, and it is one of the most productive applications in its category.
You know what ICONS stand for I ncomprehesible C ryptic O bfucsated N onsense S ymbol!
Also how do you internationalize an icon?
Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action