I need to let end users specify a time range, to be stored and used internally as a starting date/time and ending date/time. The range could be minutes or it could be days.
Has anyone discovered an interactive control that can handle this elegantly?
Most GUI toolkits have a calendar control, so I could specify "start" with a calendar for the day and a text field for the time...and the same for "end".
I could also replace the "end" controls with a single text field or slider that simply describes how many seconds/minutes/hours after start "end" is.
What I don't like about these ideas is how much clicking, typing, and more clicking is required to describe such a simple concept. Also I have to slap the user's hand if a time is typed in that isn't recognizable as a time.
Is there a cleaner implementation that I'm overlooking?
I tend to look at common design patterns for inspiration when I'm pondering problems such as this.
The Yahoo Pattern Library offers some potential solutions.
The UI Patterns site also give some suggestions, and is worth a browse.
For good measure, here's another solution at the Welie pattern library.
Another source of inspiration might be other sites and applications. For example, think of all the use-cases where recording short and long time time durations is required. As an example, company TimeSheet recording, company car mileage log software, task recording software, stopwatch applications, calendaring apps, etc. Then see how they've handled the GUI controls for capturing time ranges.
I haven't personally found a favourite solution for picking date and time. But, I think I'd want something like this.
User clicks to show calendar popup
Popup shows 2 side-by-side calendars (start date/time and end date/time)
Calendar 1 shows todays date, and the other also shows todays date.
Calendar controls allow usual navigation and selection of day month year.
Below each calendar is a hh:mm box, which defaults to the current time.
User can edit value in this time box using up/down arrows or by typing.
Alternatively, show an analogue clock below each calendar. It takes 2 mouse clicks to set time( click 1 for hour and click 2 for minutes).
Hope this helps
I am a fan of an old control I saw used WAY back in the 90's with Inventor (and later Open Inventor) on SGI machines (and then on PCs, etc): an infinite dial.
Some screenshots, a little on the small side, are here. Course, its been done on a variety of platforms since, including similar things on the iphone.
I think a date/time picker would work well with two dials, each representing an order of date/time magnitude. In ASCII art, with each dial between [square brackets] it might look like:
[20 Oct | 21 OCT | 22 Oct ] [11:15 .. 11:30 .. 11:45..]
or with 3:
[20 Oct | 21 OCT | 22 Oct ] [11 .. 12 .. 1pm] [12:31 .. 12:32 .. 12:33]
There are a number of variations you could try (vertical/horizontal, date/time, date/hour/minute, etc).
Dials, though somewhat rarely used, are a natural device for humans to interact with, and their infinite rotation option (unlike a slide which must always stop) suits dates/times well.
FWIW
User interface design is heavily application dependent. "Best" implies some kind of metric that can measure solutions. In UI design such a metric can be "home many clicks/key-presses does it take to complete the task?" where a smaller number is better. So once you've defined your metric you can start to sort solutions into good, better and best.
You also want to reduce cognitive burden for the user. If the user has to enter the final day on which a product can be exchanged based on a 90-day return policy then asking for start and end date would force them to do date math which is no fun. In this example a start date with a "delta" of x days would place less of a burden on the user.
Depending on you application you could consider and approach like the Google Finance time range selector on their charts: http://finance.google.com/finance?q=.dji
There is no single answer, it depends on the context. For many places good text controls are enough. Of course such things can still help by supporting pasting and some increase/decrease actions. Maybe it can even do some validation for the value.
Then there are places that need something more. Calendar can be really helpful for entering dates and some kind of slider could be used for time. (Lotus Notes calendar has a slider.)
My advise is:
Think what you need. Don't put complicated widgets to a less used dialog.
If you need these nice helpful widgets, check if there are ready made in the library you are using and take some time to see how others have done these.
Always have the text controls with support for pasting.
Check out the VisualHint date control. It can be configured a multitude of ways including a timespan. This would allow you to use one control instance to show the start time and another to set the timespan until the period is complete. The control also supports an extensible base framework so you could possibly combine both start/end or start/span into a single control.
Here are also some solutions: http://quince.infragistics.com/html/PatternView.aspx?name=Date+Time+Range+Input
Unless there is a more advanced time control in your GUI toolkit of choice, two calendar controls representing start and end is the most straightforward. Also, you need to decide how you want to use the information. For example, if you used a start date and an interval to increment that date, changing the start date wouldn't change the meaning of the interval. It really depends on what you're wanting to do.
One way I've seen work very well is using a gantt chart:
http://en.wikipedia.org/wiki/Gantt_chart
You can create a single line chart and then you can scale it across months, days, hours and minutes depending on how wide or zoomed in you make the control. The problem is I don't know of any control out there right now that does just one line, so you may need to create a custom one. You could possibly look for a gantt chart control and just do one task/item.
Observe what people are doing with your time range control. Then write it so that it's most suited towards doing what the people want to achieve with it. For instance, leave away past dates if inputting future dates only makes sense.
Jonathan Leighton has made a nice date inputter -element in jquery that I've found very nice for inputting dates. This is beneficial in a way that user can both input the date by clicking or type it in directly. The user also directly gets the hint about typing it into the box. If you couple this with some kind of timeline -object, you may actually go far afar. Just avoid making UI elements that are confusing or angering!
This comes in late, and it's not a control per se. I read this idea on a blog I can't find anymore (in fact, I found this post while trying to find it). The idea is to use the metaphor of a wall clock. Here's what I implemented for the fun of it. It's not a functional control. You could use something like this as a starting point for capturing times naturally. Three clicks at most, two most of the time. Only dials come close.
http://www.viridium.ro/clock-sample/
Use a HTML5-aware browser; that is, Chrome.
Related
I want to make a little free calendar program to help me and others calculate how much time we have got left in a project. I mean real working time, not just time. Time in a raw form is not saying much.
Typically when my boss tells me that I have time until 05-05-2011 it doesn't tell me really how much time I have to do my job.
You know...so many things stop me from work:
A) beeing at home, not at work (so called "free time" or "spare time"). That is in my case I work exactly 8 hours a day and then the cleaning ladies throw me out of the office with their incredible loud industrial vacuum cleaners every evening (my boss accepts that as an excuse to go home in time, regularly).
B) weekends, or more precisely saturdays and sundays
C) official holiday rescuing me from having to go to work.
what I want to do is make a little utility which tells me how many working hours I really have in a given time period.
The first two things A and B are pretty easy to implement. But the last thing C scares my pants off. Holidays. OOOHHH man. You know what that means. Chaos. Pure chaos.
The huge question is: HOW TO CALCULATE HOLIDAYS?!
Since I want my program to be useful for anyone anywhere in the world, I can't just hardcode all holidays for my little town.
So which options do I have?
I) I could hand-craft downloadable lists of holidays. Users search them within the application and download them from an webserver. Or I ship all of them in the package. But I would get very, very old if I tried that by myself for every country, state and town.
II) I make an initial data sheet with holidays for my town, and don't care about the rest. However, I make that sheet with an how-to public, so that everyone who feels like beeing very nice can provide holiday data for his country / region / whatever. Those are made public on a webserver and everyone can get the data packages he/she needs for the app.
III) ?
I care a lot about usability. I don't want to make an ugly linux hack style hard to use app that only computer freaks can use.
So you need to tell me more about holiday science. I was never really clever at this. I assume every single country in the world has it's own set of holidays. In every country there may be several states. For example the US has some, and Germany has also some states. Holidays vary from state to state. But I know from an good programmer he told me never assume anything. So the questions about holiday science are:
Which categories do I need to make holiday-data-packs searchable? A guy from India should find quickly his holiday data pack, and a guy from Sillicon Valley should find his pack as equally fast. It makes most sense to me to filter for COUNTRY > STATE > WHATEVER. Like a drill-down-search. Did I miss something?
What would be the best data format to hold holiday information? A holiday has a start and end date and a name. That should be enough. Would I put all this stuff in thousands of XML files?
How would you go about this? Any hint / help is highly welcome! Thanks to everyone!
We use a table.
It should not be that hard. If you look at your corporate holiday schedule you should be able to calculate the list of around 10 days. The only problem is that many of these are arbitrary. i.e Christmas falls on a Saturday so give the Friday before off.
Have you looked at this site to calculate the list of known Holidays ?
Many organizations post their holiday schedule on the web, it might be possible to read that and get the schedule ?
In this case, I would suggest that you are encountering less of an engineering problem and more of a data collection problem.
Rather than define a "definitive set of holidays" for each possible user, allow the user to easily setup his holidays. By offering a (usable, quick, easy) way for users to select holidays, you do not make any assumptions.
You could even make it "social" by allowing users to upload their selections - imagine your HR department takes 10 minutes to setup and upload a set of holidays for all your company employees. Now you just need to provide a way for everyone to find that set.
On another topic, I would suggest using a common format, like iCal to store your calendar data. Here's a page with some example iCal files.
I am looking for some ideas on enhancing a trial-user's user experience when he uses a product for the first time. The product is aimed at a particular domain and has various features/workflows. Experienced users of the product naturally find interesting ways to combine features to get the results they want (somewhat like using an IDE from a programmer's perspective).Trial users get to use all features of the product in a limited fashion (For ex: If there is a search functionality, the trial-user might see only the top 20 results, or he may be allowed to search only a 100 times). My question is: What are the best ways to help a trial-user explore/understand the possibilities of the product in the trial period, especially in the first 20 - 60 mins before the user gives up on the product?
Edit 1: The product is a desktop app (served via JNLP, so no install required) and as pointed out in the comments, the expectations can be different in this case. That said, many webapps do take a virtual desktop form and so, all suggestions are welcome.
Check out how blinksale.com handles this. It's an invoicing app, but to prevent it from looking too empty for a new account, they show static images in places where you'd actually have content if you used the app. Makes it look less barren at first until you get your own data in.
if you can, avoid feature limiting a trial. it stops the user from experiencing what the product is ACTUALLY like. It also prevents a user from finding out if a feature actually works like they want/expect/need it to.
if you have a trial version, and you can, optimise it for first time use. focus on / highlight the features that allow the user to quickly and easily get benefits for useful output from the system.
allow users to export any data they enter into a trial system - and indicate that this is possible/easy. you don't want them to be put off from trying something because of a potential for wasted effort.
avoid users being required to do lots of configuration before using a trial. prepopulate settings based on typical/common/popular settings. you may also want to consider having default settings for different types of usage. e.g. "If you want to see what the system is like for scenario X, use configuration J. If you want to see what the system is like for use case Y, use configuration K." where J & K are collections of settings best suited to a particular type of usage.
I'll speak from personal experience while evaluating trial applications.
The most annoying trial applications are those which keep popping up nag screens or constantly reminding me that I'm using a trial. Trials which act exactly like the real product from the beginning till the end of the trial period are just awesome. Limited features are annoying, the only exception I can think of when you could use it is where you have rarely used feature which would allow people to exploit the trial (by using this "once-in-lifetime" needed feature and uninstalling). If you have for example video editing software trial which puts "trial" watermark on output, I'd uninstall it as soon as I'd notice it. In my opinion trial should seamlessly integrate into user work-flow so that once the trial ends they would think "Hey, I have been using this awesome program almost each day since I got the trial, I absolutely have to buy it." Sure some people will exploit it, but at the end you should target the group which will use your product in daily work-flow instead of one time users. Even if user "trials" it 2 times per year, he will keep coming back to your product and might even buy it after 2nd or 3rd "one-time use".
(Sorry for the wall of the text and rant)
As for how to improve the first session. I usually find my way around programs easily, but one time only pop-up/screen (or with check-box to never show it again) with videos showing off best features and intended work-flow are quite helpful. Also links to sample documents might be helpful. If your application can self-present itself (for example slide-show about the your slide-show program) you could include such document. People don't like to read long and boring help files, but if you have designer in your team, you could ask him to make a short colourful intro pdf. Also don't throw all the features at the user at the same time. Split information into simple categories and if user is interested into one specific category keep feeding him more specific information. That's why videos are so good, with 3-6 x ~3-5 minute videos you can tell a lot. Also depending how complex your program is you could include picture with information where specific things are located on the screen.
Just my personal opinion, I have never made a trial myself. Hope it helps.
An interactive walk through/lab exercise that really highlights the major and exciting offerings of your application.
Example: Yahoo mail does the same when the users opt to use new mail interface
There are so many ways you can go with this. I still can't claim to have found the best approach.
However, my plan from the beginning with my online (Silverlight) software was to give away something thousands of people will find useful and can use for free. The free version is pretty well representative of the professional product, with only a few features missing that enhance productivity (I'm working on those professional features now). And then I do have a nag popup that comes up every 5 minutes suggesting that you should buy it. That popup can be dismissed as many times as you want. I know that popup will annoy some people but I suppose that's the trade off. There is no perfect plan. But I don't think the occasional nag popup scares that many people away, especially when it can be dismissed with a single click.
I was inspired by Balsamiq Mockups, which has been hugely successful over the past couple years. My trial/nag popup way of doing things was copied almost exactly from Balsamiq. I honestly don't know if this is the ideal plan, but it has obviously worked for them. By the way, I think another reason for Balsamiq's success is that the demo doesn't have to be downloaded & installed. Since the demo is in Flash, there's a very high conversion rate of users actually trying it and becoming addicted to it.
I have a form that asks users to enter a start and end time for an event. For many years, we have allowed them to enter the times by selecting the hour (1-12), minute (1-60), and AM/PM from three drop down boxes. This has worked fine without complaints from customers. However, today I was hit with a request to change the input to one text box for the user to enter time in military time (aka 0000 - 2359). In my gut I believe this is a bad idea but am having trouble coming up with any hard facts.
What are the best reasons I can give that this would be a bad idea?
If there is a better solution for entering time, what would it be?
Also, FYI the users filling out the form run the gamut from very little skill with computers to advanced users. They are in no way military related.
Update: All my users are local and no other forms (web or print) use military time as the standard.
Three dropdowns are a nightmare usability-wise. You can cut these down to two by eliminating AM/PM and moving to 24-hour format, but still: a dropdown with 60 items is overkill.
I'd much prefer to enter time "manually", provided that these input boxes will be intelligent enough (say, they should be able to convert 18 to 1800, 0 to 0000, allow : as a separator, etc.). Plus do not allow users to enter incorrect data in the first place.
To answer your question: I see no reason to disallow your users to do what they want. After all, they are users.
Well, from a user interface standpoint, this could be a mistake simply according to some of Jakob Nielsen's user interface heuristics:
"Match between system and real world." If your users are not used to entering dates in military time, asking them to do so for your app can be distracting at best, and frustrating at worst.
"Error prevention" You are not eliminating error-prone conditions, but possibly introducing them.
There is also the question of why this change is being made. Are customers complaining? Is data coming in incorrectly? As mentioned by others, are your users used to military time? Any interface change should happen for a reason, IMO, because you're going to change the user experience and there will be ramifications for that; it's just a matter of how large those ramifications will be. My assumption is that data entry errors are supposedly going to be avoided -- but are they? Asking a user to enter a time as "XX:XX" and parsing out the semicolon (or, as Aaron Digulla stated, ANY non-number characters) and then converting it as needed seems less likely to result in errors than asking a user to enter a time in a format they are not used to using daily.
My concern would be that a user wants to enter 3:30 PM, and, while not paying much attention, simply enters 330. This is now 3:30 AM, and the user will never know the difference, because the app takes the information and happily assumes that this is what is meant. However, allowing the user to enter the time in "XX:XX" format and having an "AM/PM" selection makes much more sense.
As far as hard facts, well, I don't have them either. But if your boss/client won't be swayed by Nielsen's heuristics, I'm not sure what can change their mind.
Oh my.
My advice is to quit and find a different project.
We did a scheduling app for a "military customer" - and even they could not agree on what constituted "military time". Half of them wanted something called "Zulu Time" - the other half wanted "GMT plus offset" - then some wanted local time in 24h format. Contrary to what our contract specified, a Colonel insisted we use "Zulu" - we made the change for political reasons (in violation of our contract) - and then HE missed showing up for a scheduled event, because he thought it was in local time. Then contract management came down on us like a ton of bricks.
(never mind that the published schedule also used an obsolete "offset" that was a cold-war holdover meant to "fool the Russians").
In that this is just me sharing a war-story. . .
The real answer is to Elicit Requirements from your customer. Get those requirements SPECIFICALLY written into your contract. Make sure that the stakeholder who is actually writing your check, agrees. Develop to that specification exactly. When someone complains tell them to pay for a contract mod. You'll probably be changing this back and forth among many different settings for the next 10 years. You'll have steady work, and you'll understand why military contracts frequently go way over budget and are never on schedule.
"They are in no way military related."
That's a good enough reason for me. It's an uncommon format that, while not exactly "user-hostile," is nonetheless not the way most of us are used to seeing dates, and requiring your users to do the conversion in their head will lead to arithmetic errors eventually.
That said, drop-down boxes aren't great either. Best to go with 2 input boxes and an AM/PM dropdown, in my opinion.
It may not be a bad idea. Imagine the case where users must enter that bit of information lots of times, for example because they are in call support. Or they may find the dropdown boxes not usable enough, even after having tried them. They may prefer that other format.
It is usually a good idea to talk to the stakeholder and ask him: "Why do you want it this way?" you can then contrast their ideas with yours, but if yours are only that you have the "gut" feeling that this is not right, guess who will win the argument. The gut feeling is not a valid business argument - especially when the business is not yours.
So in short, do what your customer wants - just make sure that they understand their options well, and point out to them any inconvenience that they may have foreseen - once you find one, that is.
Honnestly, I think using AM/PM format is a bad practice, but that may be because I'm used to the 24 hours scale.
One reason against is that if all your users are used to the 12H scale, then most of them might still enter 1:00 instead of 13:00 for 1:00. Since the PM is not here, it will result in mistakes.
However, one good reason to do the switch is simply because it's the international standard.
Depending of what you want to put the emphasis (speed or functionality) you can use a time picker that would rely on regional setting to diplay the time in the user format or use a clock-like control. If speed is important, you might prefer a simple mask-textbox.
Hmmm, describing the 24 hour clock as "military time" and then noting that the users are not military makes me a more than a little twitchy.
It will depend on your users but I think that it is more than reasonable to expect people in contemporary society to understand the 24 hour time format and to be able to enter times using that format (given that I would - possibly naively - expect that format to be in use for bus, train, plane and other timemtables almost universally for the simple reason that its unambiguous). Perhaps this is not true worldwide - but it is certainly true across Europe.
That said, changes need to be made for a reason - "if it ain't broke..." is a very sound maxim for a working site and whilst I wouldn't ever willingly use am/pm for time entry I don't have a problem with use of dropdowns for time entry - especially as one can type "into" them. In this case I think that going from drop downs to text boxes is most likely an opportunity to introduce errors (although again it rather depends on the users).
I can see why you think this is a bad idea, silly users input wrong format etc.
However have you considered a jQuery Masked input box?
In my own frames, I accept times and dates in a wide variety of formats. When the field loses focus, I'll try to parse the input and format it into the "correct" or "official" format. This gives the user a nice way to enter the data and a visual cue when something is wrong.
For example, in a date field, I'll accept "1" as "01.12.2009" (current month+year). In a time box, I'll accept "1030", "10 30", "10.30" (i.e. I just filter out anything which isn't a number). "010409 1125" becomes 1. April 2009, 11:25am.
Few outside the united states knows the words "military time". They also prefer 24-hour format.
If you want globalization, you can do one of the two:
use accepted and de-facto standards, such as ISO8601 date format, 24h time and speak English
dive into the nightmare of the vast regional-based localization complexity (some unfortunate programmers have to do it anyway. Then they support AM/PM, unicode and never-showing-yellow-color for certain cultures)
I cannot believe how much consideration this idea has gotten.
Forcing your user to do things your way, because it's "more efficient" is a terrible idea.
Your forms should be both streamlined (power users can enter data quickly from the keypad) and comprehendible (first time users can navigate successfully). The conversion to 24 hour time will throw people immediately. I lived in Quebec for almost six years and still had troubles switching back and forth from 24hour time. DON'T DO THIS.
Just in addition to all the rest of comments you should thing about one more thing.
Programmers and designers usually think the client pays us just for creating what he tells us to... That's only half true. They pay us, even if they don't realize it, for telling them what they need, what's best for them.
Of course, the final decision is always theirs, as the pay, but if you feel it is wrong and you think you know the business model better than them, then do not blindly accept whatever they told you to do.
You might want to consider using the jQuery timepicker (or Telerik DateTimePicker in Time-only mode for WinForms) and also build in support, on the backend, for multiple formats in the event that javascript is disabled.
date/time input through select boxes is a horrible UI design.
but, if some of your users come from the few countries that stick to AM/PM for time format, then forcing the "military" format on them without assistance from the program is also bad.
use something like the jQuery masked input plugin.
if i was doing this, i would use a masked text input and a "PM" checkbox: if the value is more than 1259, the checkbox is disabled. otherwise, it's clear by default.
Why not use a TimePicker control of some sort?
You shouldn't force non-military users to user a strange to them time format.
In any case, assuming that all input is by logged-in users, you can provide multiple mechanisms (and certainly multiple ways if displaying time) and make the choice a user preference. But I'd strongly recommend that whatever you do, for any given user times should be entered and displayed in a consistent manner.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are some key UI design tips that every developer should know?
While there are a number of UI resources for developers (for example, Joel Spolsky's User Interface Design for Programmers), I'm interested in more of a bullet list that can be communicated in 1 to 2 pages.
I'm interested in more tactical, day-to-day UI tips, as opposed to overarching UI design goals that would be covered in a UI design meeting (presumably attended by at least one person with a good UI sense). A collection of these tips might cover about 80% of the cases that an everyday programmer would come across.
use a standard menubar (amateur GUI designers seem to like to chart their own course here for some reason). Make sure the first items are File, Edit and View, and the last one is Help
don't worry about color themes or skins; stick to a standard look that is consistent with your platform
use the default system font
use menu accelerators that are consistent with your platform
stick to the tried and true layout with a menubar on top, a status bar on the bottom, and if required, a navigation pane on the left
never do a system-wide grab
If you have a choice, make all windows resizable.
use groups of radiobuttons for "choose exactly one". Always make sure one of them is selected by default. If you want the user to be able to not choose any, add another radiobutton for "no choice"
use groups of checkbuttons for "choose zero or more"
constrain input if necessary (ie: simply ignore non-digits in a numeric input field) rather than waiting for a user to enter data, submit, then throw up a dialog saying "hey, letters aren't allowed!". If they aren't allowed, don't accept them in the first place.
be liberal in what you accept as input. For goodness sake, don't throw a fit for a SSN field if they leave out the hyphens, or put then in when you don't want them. The computer is smart, let it figure out that xxxxxxxxx and xxx xx xxxx and xxx-xx-xxxx are all valid social security numbers.
always allow spaces in long fields such as serial numbers and whatnot. Data quality goes way up if a user is allowed to group numbers in sets of three or four. If your data model can't handle the spaces you can remove them before saving the data.
Avoid pop-up dialogs like the plague. Never display one unless you absolutely must. If you decide you must, stop and rethink your design before continuing. There are times when they are necessary, but those times are considerably less frequent than you might imagine.
pay attention to keyboard traversal. Most toolkits make an attempt to get it right, but always double-check. A use should be able to use the tab key to traverse the widgets in a logical manner.
All of these rules can, of course, be broken. But only break it if you are breaking it for a justifiable reason.
Remember, the software is there to aid the user, it should be doing what they want, rather than making them do what it wants.
When you are about to perform an action that will change or delete information, don't ask 'are you sure' - users will learn to click the button as part of the action. Try to allow for an 'Undo' in the system design.
Make the default choice the one most users would be happy with.
Always give your user a "way out" from wherever they are that does not require the use of the back button.
The best example:
If an error occurs, give them a link back to where they were (or at least to where they can start over).
Use tool tips as much as possible. It is amazing how these little guys can add a large amount of help to the end user and they are unobtrusive to the application itself.
When designing a UI make it as simple as possible, but no simpler.
ask the user, don't just make things up
simplify - remove a step, eliminate clicks, etc.
get familiar with the principles of usability
I think that this link would be a good starting point, from Microsoft's "Windows Vista User Experience Guidelines:
http://msdn.microsoft.com/en-us/library/aa511328.aspx
And this might be very close to the two page bullet point list you are looking for: "Top Violations":
http://msdn.microsoft.com/en-us/library/aa511331.aspx
Very down to earth tips like: "Set a minimum window size if there is a size below which the content is no longer usable."
Correct tab-stops are a must.
Do not increase "discoverability" at the cost of basic clarity and usability.
Find the thing the user will do the most often, and then make that the easiest thing to do.
For example: I have a long running personal gripe with microwave design.
Many require you to set a clock you never use for anything prior to using the microwave, and it forgets everytime it loses power AND requires 10 key-presses on those hard-to-use button pads to do so.
A simple usability test would realize the most common cook time used on microwaves is the standard 'minute' and multiples thereof. An Ideal microwave should thus be able to cook an product for 1 minute on high power in 3 or less actions.
For times outside a minute, but within 5 minutes of the golden "1" minute, there should be slightly more steps, but not significantly so, and only significant numbers of actions required for cook times > 5 minutes. ( which are rather rare )
2 examples of great microwave design
1. 4 parts. Door, temperature dial, time dial, time-lighting sequence
Temperature dial is analogue and persists from previous setting, with a varying sliding range.
Time dial is digital, but simulated analogue, turning dial clockwise increases clock time( shown by a lighting sequence under the dial). Turning dial counter clockwise decreases clock time. Cooking decreases clock time.
Door being closed and time being on clock starts cooking. Door opening pauses cooking.
standard operation: open door, load, turn time dial, close door ( or optionally, close door first, and cooking starts as soon as >1s is on clock )
2. 6 Parts, Door, Dial, Power Button, Start Button, Clear Button, Digital Time Display
Start button with no time chosen starts cooking for 1 minute on high power.
Start button while cooking adds 1 minute to time.
Time dial persists between sessions. Turning dial causes the time stored on the dials position being copied to the digital timer.
Pressing "power" prior to starting cooking will
in the event the dial has not been turned, copy the current time stored on the dails position to the digital timer.
in the event the dial has been turned, decrements the choice of power level by 1, or if on lowest power level, return to highest.
Pressing power while cooking decrements the power level on the fly.
standard operation:
1 minute high = press start.
1 minute medium high = press start, press power.
2 minutes high = press start twice.
<anytime> on high = turn dial until happy, press start.
<anytime> on <anypower> turn dial until happy, press power until happy, press start.
<previously chosen time> on high = press power, press start
<previously chosen time + 1 minute> on high = press power, press start twice.
As you can see here, adding a small amount of extra buttons, can add a great degree of expressive and functional design.
Any design with a numeric keypad for time specification, tends to fail my criteria for good design.
Its noted that these designs may, for some people have a higher learning curve, but once learned, muscle memory makes it instinctive. As opposed to more ( obvious? ) but overly complicated designs which even a learned user will repeatedly have to spend tedious amounts of time performing tedious arbitrary operations, simply to attain common goals.
Do some hallway usability testing (in the same way you would do code reviews).
Even a really quick "Hey! try this" usability test (if you can call it that) with the guy next to you will make a big difference. The main thing is to have somebody other than yourself try the bit of UI you've just built.
It's amazing how many times other people get stuck using your new UI, and it only takes a couple of minutes (usually) to find the biggest problems.
If you do use a popup from an editor, make sure to return your insertion point or state to whatever it was before the popup. Too many programs just leave you "hanging" and having to find your way back.
Instead of the arbitrary "OK" and "Cancel" buttons, which, given context, can be ambiguous, and users blindly click one, the buttons should contain a brief description of what they do.
[Ok, Please Cancel my subscription ], [ Please do not cancel my subscription ]
is far better than
Cancel my subscription?
[ OK ] [ Cancel ]
( these sort of failures often surface on the dailywtf )
Minimize number of clicks
Uniform look(text size, buttons.. and other controls )
Minimize free edits... (ex: in an address entry... provide states in a dropdown...etc etc)
In a drop down for country list... list the residing country first...(how many of you frustrated with USA being listed at the bottom and you have to scroll down?)
General drop downs can be ordered as the users choice
No Spelling msitake ;) at all
Pay attention to labeling text: for email address (have the caption as email... believe me... i have seen it as e_mail address:)
Currency symbol for amounts. uniform digit display in amount.. ex:
$12.15 ==> $12.15
$10.9 ==> $10.90
9.Progress/Status bar
Buddy label to indicate the error field before the user clicks OK/Save button(ex: for an email address if there is no "#" there is no need to wait until user clicks OK then tell them invalid email Address)
Avoid repeated inputs... (ex: remember me option in login screen)
global application option to let the user continue from where left off in the previous instance)
when showing data on a grid... excel style filter options
default values for inputs.
Folks...feel free to flush down any of the point above with the valid reasons!!!
Grandmaw Testing.
This is my term for the conceptual question, "Can your grandma, who's never used a computer beyond email and checking www.cutecats.com, use it?(Assuming that she has the real-world knowledge to use that particular app)".
Everything common should be obvious; nothing should be black box magic with side effects. Uncommon things should be accessible in a common format that the user has used before.
Clear labeling, clear route to a help file, clear actions with clear effects.
If Grandma can't use your Paint program, you need to really think about your UI.
My basic rule of UI design is to have each "page" do one task and one task only. It keeps pages simple, which keeps design clean and makes the application more understandable.
This type of design is called Inductive User Interface. Here is a document that Microsoft put out in 2001 on the topic. The text may be a little dated, but the principles are generally pretty good. The only caveat is that there is a balance to be found in designing like this. If you oversimplify too much users will have to navigate all over the place to accomplish simple tasks, and the gains in understandability will be lost to underproductivity.
Some simple tips for daily user interface web design and application design:
Use simple static sketches to begin preliminary web app development plans.
-Dont allow users too many choices. instead, use cater design to send users down a path they'll benefit from.
-Define key user groups and the journeys they made
-Practice iterative design as a part of UI to ensure ROI
I like to follow these guidlines:
Standard - follow known standards/patterns, reuse ideas from all products you respect
Simple - keep your solutions simple and easy to change (if needed)
Elegant - use less to accomplish more