Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I really want to know if I'm missing anything obvious in the software I'm developing.
What User Interface features that you consider important are often missing in most software?
Undo is bitchy to code, but very useful to the end users.
Save the location and size of all/any windows, so they are restored whenever the program is restarted.
Read this article on Undo from a usability expert (Aza Raskin): Never Use a Warning When you Mean Undo. Coding undo is not all that hard: examples [1], [1.5], [2].
These are some of the UI features that I often find are done badly, or are even missing:
Restoring window state properly.
Conforming to the average (non-beginner, non-expert) user's mental model.
Restricting the number of choices that the user has to make.
Restricting the amount that users have to read while using the app.
Strong consistency with other apps of the same genre running on the same platform.
A well-done Undo / Restore facility.
As somebody else remarked, context-sensitive help.
Allowing an app to be navigated without the aid of a mouse.
Good multi-monitor support.
keyboard Shortcuts
What's usually left out in UI's? Nothing! (literally. empty space). The question is better asked "What can be taken out?". When you have to think of what else your UI needs, you have already gone too far. Leaving out empty space is something UI programmers need to work on. Nobody likes feature creeping.
Remember the KISS rule.
A help menu with more than About...
Context sensitive help
Tool tips
An API and a scripting language so I can bypass the UI.
Seriously. Nothing is more tedious (and error-prone) than having to point-and-click through some repetitive process.
Right click context menu on things like tree views and grids.
We have an record management application here at work that I have to use now and then and they don't have right click on any of the documents in the treeview so you have to keep going to the bottom of the screen to mark a task as completed grrr, and no keyboard shortcuts too grrr
Consistency in your design... There are too many apps that "look" like a programmer wrote them. I can't stress enough!
Automation... Office has it, I wish more apps did.
CLI... As mentioned above, especially if it's a repetitive-wizard-type process
Templates/Presets... like Handbrake... make life easier, not to mention handy in the training process
Error/Confirm messages which don't get in the way... Unless the user needs to take immediate action, don't display a dialog. If the error is obvious, fix it for me and then tell me why
Scalable UI. With WPF this is getting easier, but it is annoying if I'm on a large monitor and I have to squint to see anything. Not to mention my click accuracy isn't that great.
UI Consistency.
I know I've been guilty of leaving out printing support in the past. I would never use it, but some of my users do.
drag and drop
clipboard
Good design.
Leave room in your dialogs so if you internationalize it, you have room for longer words (think Italian) and bigger fonts (think Chinese).
I'll add a few myself that have't been mentioned yet:
Non-modal forms that can remain open while other work is done.
Ability to view multi-windows at once (instead of tabs which show only one at a time)
Ability to have multiple views of a single window at once, i.e. split mode, or panes, or actual multiple windows into the same object.
Clean and intuitive.
Clean icons. Good icons. Meaningful icons.
I am very disappointed with a lot of icons inside applications — especially on Windows ;-)
actual consideration for the user seems to be left out quite frequently:
using terminology that makes sense to the programmer, but not the user
organizing the application's workflow for the convenience of the programmer, but not the user
not considering the user's work processes in the first place, and finding ways to help him/her eliminate steps and simplify things
Being able to use drag and drop to customise the toolbar and to be able to remove/hide unwanted toolbars without leaving an unused button whose only purpose is restore/unhide them.
Freezing the application when it's doing something that takes more than a second.
Not showing users what's happening, and not indicating how long it's going to take.
IMO, user name and password login options need work. I understand there are security concerns with each of these options. The risk-trade off is different for each application and needs to be assessed on an app by app basis.
Often forgotten or poorly implemented features include:
Remember Me
Forgot password
If you have a restrictive password policy, give me a hint as to what it is!
Range for # of characters, no special characters, required numbers or capitol letters, etc
Forgot username
If my username is not my email address, give me a hint to your username policy
Kind of too general a question. It would depend on what does the application do. One thing I see often missing from gui applications is an easy way undo mistakes and not only in the object you're manipulating but also on program UI elements. Closing some floating options panel or toolbar by mistake and then having no idea where is the thing enabled frustrates me to no end. Is it under Windows? Or under View? Was it this one? no that one is for something else entirely. Gah! what's it called?
Cycling through links and fields using the tab button.
Left click drag to highlight, right click for context menu with option to copy highlighted text. Found missing from some applications coded in Java.
Windows that snap to other windows and screenboarders. KDE and Winamp do this, and are the ones most famous for it. Why don't a whole host of other applications and DEs do this?
Related
I currently have 3 very similar, but slightly different mfc applications, which would normally be opened at the same time as part of their workflow and usage in a Windows environment. I would like to keep them as 3 separate applications, but somehow group them together, under a single UI container to provide more clarity to the user.
I've so far considered using named pipes to send data from two of the applications to the third, the latter one being solely responsible for drawing the GUI (possibly having 3 different tabs at the highest GUI level, one for each application). I got this idea from SergeWautier's answer from this post. After looking into the possibility of doing this, there seems to be a lot of work involved in achieving this.
Is there any other (possibly simpler) way of achieving something similar?
Old answer
I have in the mean time come across the TaskSpace tool, which is the closest thing to what I'm looking for. It's liteware and getting the full functionality (e.g. saving a particular tabbing configuration, which I am most interested in) requires purchasing a licence. What would be really cool would be to restrict the user from adding any other windows apart from the 3 applications and have better control over the titles of the tabs & top-level window. At this point, writing a similar tool to TaskSpace would be the ideal solution.
I've also been playing around with tidytabs. It's not exactly what I want, because it doesn't provide a 'wrapper GUI', but I thought it's worth mentioning here in case it helps someone else.
Update
I've found exactly what I was looking for in Window Tabifier, which is open source and I can modify to fit my needs in accordance with the CPOL Licence provided. Very nicely written code too.
I recently had a discussion about the use of contextual help in applications with my colleagues and the argument was if there is a need for it these days or if it's something that many companies do but does not actually have any significant benefit to the end user. Would we be better off having just pdf files or chm files without any context sensitive help in our applications? I was just curious as to what other developers think about it, primarily because context sensitive help is a bit of pain to set up and especially if you depend on a small number of developers.
As I see it, most applications seem to provide one topic per screen.
If you see a phrase that is not clear in a dialog, you want to be simply able to press F1, and be in the topic.
But of course, the commenters are also right. If it considered a chore, and that topic consists out of a screenshot of the form and the exact same texts mechanically repeated, it won't be any help.
But then of course, the manual won't be any more help when created with such attitude either.
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 8 years ago.
Improve this question
I think it would be interesting to get a programmers viewpoint on UI design.
What is your favorite User Interface that you have come across in a web application?
If possible, say a little bit about why you like it.
http://www.google.com is my favorite. Can be considered a "lack of UI" ;)
At the risk of sounding too much of a fan ... I think StackOverflow has a great UI. It is clean, without clutter (except the creeping ads!), the navigation is straight forward and yet manages to compress a fair amount of functionality.
Fairly simple features, like the coloured vote buttons to show what you have voted for, and the live preview really add to the interactive feel.
(And I don't mind the ads as long as they stay away from the flashing punch-the-monkey kind!)
Web application: Wordpress. It's so powerful, yet clean and easy to use.
Desktop application: Excel (or equivelent). Seriously, a spreadsheet is the most innovative and clever user interface ever devised. It's used for everything. I don't know what the question is, but the answer is Excel.
GMail interface is so smooth and fast that I question me why nobody had done that before.
I think Remember The Milk has a brilliantly clean and intuitive interface
Mint.com, if you trust someone else with your bank account information. It keeps track of all your transactions, lets you fill out a budget, notifies you of unusual spending trends or transactions, and lets you drill down through your spending trends to see exactly where all of your hard earned cash is going. Best of all, it's free.
(source: mint.com)
http://bbc.co.uk homepage
http://mail.google.com/
http://stackoverlow.com (that is I liked it before the introduction of ads :)
FreshBooks accounting has a very nice interface.
(Although I upvoted the answer in favor of StackOverflow)
I think stackoverflow has done a great job in many areas in terms of usability, including colour pallete, use of whitespace, anticipating user's need for information and providing or hiding appropriately, non-intrusive JS/AJAX.
Minus points for these increasingly obtrusive ads, though. :P
Gmail is also good. Honourable mention to github.com.
Update: I recently got introduced to FriendFeed. I think they have also done a fabulous job with their web UI, in terms of clean yet attractive design, plus appropriate and helpful use of Javascript and AJAX to provide for a smooth, positive user experience. Check it out.
The new Yahoo Mail UI blew me away when I first saw it. The keyboard shortcuts, drag 'n' drop, tabs, etc. really make it look and feel like a desktop app. Admittedly this quality of UI has become a lot more common on the web in the last few years, but for me at least, Yahoo Mail was the first web app in my experience to bring this kind of usability to the web.
http://fastladder.com has great UI for feedholic. I can't live without fldr's keyboard shortcuts (and some greasemonkey to change them to fit for me.)
http://www.instapaper.com is also simple and great. This is temporary storage for web resource marked as read later, and don't need password for make account because of that purpose.
For the CLI lovers out there...
http://cb.vu/
cat about.txt
Not really useful but it's quite interesting.
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 5 years ago.
Improve this question
Back in the days of Unix, you couldn't even close a software without reading the man page first. Then came Mac and Windows with consistent menu layout and keyboard shortcuts, but you still saw paper user manuals shipped in the shrinkwrap box, which described each and every single operation possible in the app. After the Internet, help files became html documents.
Nowadays with Web 2.0 applications, you hardly see the Help. Even if it's there, they simply describe some specific tasks. In other words, the apps are relying more on the common sense or don't-make-me-think factor of the user base.
Years ago Microsoft came up with a concept called Inductive User Interface, which basically tells programmers to put in instructions on the apps itself, but I am not sure how popular that idea is.
Are help files, user manuals, and context sensitive online help with F1 key dead? Have I failed if user could not find out what to do from the UI? If not, what degree of help should I provide? (both for desktop and web app)
EDIT: How does documentation/help file mesh with agile development methods? For example, should the developers think twice before UI changes that may obsolete a bunch of screenshots?
Three notes on help:
F1 / stand-alone context-sensitive help was always doomed. It was hidden by default, and so the people who most needed it were least likely to read it. There was hope at one time that we would be able to train users to always hit F1 when they ran into trouble, but too many applications without useful context-sensitive help... combined with too many bizarre help interfaces... pretty much killed this.
Manuals are as important now as they ever were. Not so many printed manuals anymore, but online manuals are better than ever. The proliferation of wiki-as-a-manual systems has helped here, reducing the up-front cost of creating good online documentation. Of course, plenty of people just don't read...
The beauty of using web pages as an application interface is that you can combine useful context-sensitive help with the UI, removing the barrier for novices and others who otherwise couldn't be bothered to look for relevant information when they get stuck.
Of course, there are still plenty of apps, even online apps, designed with obtuse interfaces and a tiny little help icon in a corner somewhere, presumably hoping that the latter mitigates the former. Pity them.
No way. You look at the amount of documentation and training and marketing expenditure even MS puts up.. you'll get your answer.
Try using someone else's product, and you will learn the true value of documentation - I'm learning Godiagrams right now.. :)
So I can say without a doubt.. NO and it never will.. no matter how intuitive user interfaces get.. beyond a certain size, you will need help and training. But by understanding the user and what he needs to get done, you could design it such that the time he/she needs to learn the system to do his/her routine tasks is minimal.
Have I failed if user could not find out what to do from the UI?
If not, what degree of help should I provide? (both for desktop and web app)
They should be able to use your your app to do basic things from the UI. eg say for an image editor, they should be able to create a new image, and draw some lines then save it just by looking at the UI.
This is best done by following common layouts (like having new, open and save under file in the menubar, and using the standard open and save dialogs).
The same goes for webapps, people exspect to be able to do the basic stuff without having to read the docs, but for more advanced features people will still read the docs. (eg most pople will read the docs for say BB code, or markdown at least sometimes, but they expect to be able to post without having to know them)
Are help files, user manuals, and context sensitive online help with F1 key dead?
They still have their place. People will use them to learn about how to best use various features, for example markdown or bbcode, or how to use filters to get certain effects in an image editor.
I've been incorporating context-sensitive screencasts into my applications. I've found this helps non-technical users grasp the application quickly, without asking for live help.
The Idiot/Dummy books must be doing quite well. Imagine if the standard application help was as good as those books. The standard F1 help for a lot of apps is just awful.
Is help dead? No, but some of it should be taken out and shot.
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
We are currently working on a new version of our main application. one thing that I really wish to work on is providing support for multiple monitors. Increasingly, our target users are adding second screens to their desktops and I think our product could leverage this extra space to improve user performance.
Our application is a financial package that supports leasing and fleet companies - a very specialised market. That being said, I am sure that many people with multiple monitors have a favourite bit of software that they think would be improved if it supported those extra screens better.
I'm looking for some opinions on those niggles that you have with current software, and how you think they could be improved to support multi-monitor setups. My aim is to then review these and decide how I can implement them and, hopefully, provide an even better environment for my users.
Your help is appreciated.
Thankyou.
Few random tips:
If multiple windows can be open at one time, allow users to have them on separate screens. Seems obvious, but some very popular apps (e.g. Visual Studio) fail miserably at this.
Remember the position of the last opened window, and open new windows on the same screen as before. However, sometimes users switch between multiple and single-display (e.g. docking a laptop with an external CRT), so watch cover this case as well.
Consider how your particular users work, and how having two maximized windows simultaneously might help. Often, there is a (fairly passive) window for reference (e.g. a web browser/help) and an active window for data entry (e.g. editor/database) that users switch between.
Do not put toolboxes/toolbars on a different window than objects they operate on (it's inconvenient to move the mouse so far).
Apple's Human Interface Guidelines for the Mac have covered window management on multiple displays since 1987, when the Mac II was introduced with six slots that could all contain a graphics card. The guidelines offer a few good guidelines that you might not think of at first when implementing multiple window support. For example, if a window spans multiple displays, which display should new windows be opened on? There's an answer around Figure 14-33 in the chapter dealing with Window behavior.
Microsoft may have something similar now for Windows developers to follow; if that's the case, check it out and follow their guidelines since you don't want to behave differently than the other apps on the system (or that your users are used to) for no good reason. However, if there are no guidelines, follow Apple's as they're fairly well thought-through and were originally developed through experimentation and research.
Please Please Please. If you remember window positions for multiple monitors. Please detect if the second monitor is connected. I have a laptop that is sometimes docked. It is very annoying when I try to open a window and it opens off screen.
It's annoying when I drag a window to another monitor, and then if the application generates a popup dialog, or spawns another window, if that popup/dialog gets displayed back on the primary monitor.
I haven't developed for multi-monitors, but I think this can be better handled if you position child windows/dialogs centered on their parent window, rather than on the desktop center (which I'm guessing is what happens in the case I describe above).
I'm going to have to a give a nod in dbkk's direction as they captured a couple of the major points that you need to remember.
Also, I would suggestion paying attention to how you use dual monitors and try to keep that in mind as you are developing. Generally you should try to avoid doing the things that applications you work do that annoy you. Also, don't assume that just because the user has dual monitors that they are going to want to work with your application on dual monitors.
The biggest thing that I would stress is keeping track of where the focus is in the application and making sure that any pop-ups occur within that region, one of the things that people seem to dislike the most is having a window pop-up in a different window then the one they are working on.
Definitely keep dialogs near where you clicked to bring them up. Remember what monitor the window is on between sessions. Be aware that if they have less monitors than the last time your app was run that you need to bring the windows back to a visible area. Provide an icon or button to switch monitors. Depending on the type of app it may be useful to be able to easily tile your app's windows on a monitor or on all.
One thing to keep in mind is that the user may have more than two monitors. My main system has six monitors, and I've run 4+ monitors on Linux, Windows, and Mac OS. Many applications--even multi-monitor utilities--will support 2 monitors but freak out over more than 2.
Applications work best when they know about where their windows are and relate to the locations of those windows. And as someone else mentioned, if you're going to remember where a window was, make sure that geometry still makes sense when the user comes back.
If the OS/window system dispatches an event related to the change of screen geometry, handle it if you're doing anything funky.
I think most applications that are well coded generally work these days.