Related
I'm working on some legacy code. I have a user control with a VtChart (VCI First Impression Library) in it and I'm trying to make changes to it, namely, adding another series to the control. However, every time I make changes to the control, close the form editor, then reopen it, the changes are gone.
I can't find any documentation on this control, so thought I'd ask the community, any ideas?
Ah! Found my answer. Since VtChart is connected to a grid (F1Book), the SsLinkRange needs to correspond to the number of columns needed in the chart. For example, if you want 3 columns, SsLinkRange should be A1:C10, where A and C is the column range. If the SsLink properties don't match it won't save the settings.
This is an very obscure problem, but I'll post this answer anyways for archiving.
I have an application that displays a dialog when the user needs to enter information. The reason for this, is to keep the main form readonly, and only when you need to add/edit data will a dialog appear.
The problem I'm wrestling with is what to display for the label names in the dialog. The application is a WPF desktop app and traditionally desktop apps are very short on label names (usually one or two words). I want to make the dialog user friendly and be more descriptive about the information that is required. Web developers seem to be catching on to this and are much more descriptive with their label names, but most of the forms I've looked at are forms that are only filled in once, whereas I will have data that can be edited.
An example: If I had a label that asked a user if an employee smoked, in most a destop apps the label would normally be something like 'Smokes?' with a checkbox, whereas I want something like 'Does the employee smoke?'. My issue with this is, that the first time you come across this dialog and enter the data, then it seems OK, but what about when you are editing data that is already there. Does this label now make any sense. Past tense and present tense seem to be getting in my way and I was interested in what people think or ways they have approached this. The application I'm writing is a WPF app and I feel that traditional label names are a bit old in the tooth now.
Another example would be entering contact details for a person. Do I just have labels that say Phone, Fax, Email or something more descriptive. i.e. a label that appears before the textboxes stating 'Enter the contact details below' and then the single word labels?
Maybe I'm just being pedantic about all this, but I would like to take a step forward so that my application contains more than single word labels that are sometimes unclear to the user about what is required.
Why not make use of the concise labels and use Tool tips for a longer explanation.
The longer explanation is only required when a user is unfamiliar with the application anyway.
Also, you could re-word a label to make it sound more like a question such as "Is a Smoker?"
Since you are using Stack Overflow, take note of their use of tooltips, I think Jeff Attwood has a blog post or comments in a podcast about the use of tooltips in SO. I can't remember where I heard / read it.
Have you thought about creating a "quickstart" flow or wizard for entering data for the first time? This would give you the opportunity to guide the user through the process, using labels with descriptions, so that they learn to associate the description with the label you've chosen (hopefully something succinct but intuitive). Then when they need to edit data, they have learned the application taxonomy.
If you are running into issues with tenses, steer clear of using verbs or only use the present tense. I would try using nouns - "smoker?" instead of "smokes?"
When you're asking for common data like phone numbers, email addresses, you can probably assume that the user will understand what you mean. Just be clear as to whose contact information you are asking for - using a title for the field set that is explicit is a good idea ("Employee Contact Details"), adding a short description above the field set will help too.
Of course, you should always do some level of usability testing on your application before you launch it to uncover any issues with the interface.
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
This is a wheel that's been re-invented again and again over the years.
The Problem: The user needs to input a Date/Time
Basic considerations
We want to make it as easy as possible for the user to enter the desired date/time
Some applications call for historical dates, some applications call for future dates only, some will need to handle both
We want to prevent the user from entering jibberish data
We want to auto-populate this control as aggressively as possible.
We want this control to be as re-usable as possible.
Popular solutions include:
Text Boxes
Combo Boxes
Pop-out calendars
Server-side and/or client-side validation
Various ways of alerting the users about bad data
There are a panoply of ready-to-eat solutions about, but I'm looking for some more general information. Have there been any usability studies done on the various date-time-control approaches? Is there a "best" date-time control out there? Are there any well-established "Dos and Don'ts"?
Related question: Best GUI control(s) to describe a time range
My preference is for a text input with an elipsis button next to it:
Enter a date [ ] [...]
The elipsis would pop up a calendar to populate the text input, but the user can type in a date if they want. Validation should be done when the "OK" button for the form is pressed - trying to do date validation on a character by character basis is doomed, in my experience.
The validation should be sophisticated and allow expressions like
"today"
"Tomorrow"
"23 Jan"
etc.
Edit: In reply to some comments, one could do validation when the text edit loses focus (though I hate that kind of thing) in which case the edit content could change from "23 Jan" to "23-01-2009" to indicate that the exprssion was understood.
Give me a calendar to select the date with a mouse. And let me type the date in with the keyboard. Accept as many formats as possible. If I need to enter December 21, 2012, let me use:
Dec 21 2012
21DEC2012
December 21 2012
12/21/2012 (or 21/12/2012, pick one, perhaps depending on what country I'm using the software in)
12212012 (same parenthetical fragment as above)
Etc.
Whatever you decide to do to solve the localization issue, make sure it's obvious what you expect. Give me an example, or a template with MMDDYYYY that I can type over.
Please don't give me pull-down boxes where I have to scroll, especially through years. If I'm old, and I'm entering my DOB, I don't have enough time left in my life to scroll down to the bottom of your pull-down box. Pull-down boxes are a good pattern to use when I don't know what the options are, but if it's something I'm very familiar with, like my birth date, then pull-down menus are a hassle.
Now, WRT time inputs (Big pet peeve), don't assume that I meant 3 am. If I enter 3 for the time, assume I meant 3 pm. Make me do extra work to schedule something at 3 am. If you're uncomfortable with assuming that much on my behalf, at least alert me that I've scheduled something for 3 am so I can fix it now instead of later when someone on my event invitation list emails and says "You moron, you scheduled our D&D Meetup for 3 am!"
I think the date range entry on Google Calendar is quite good. You can enter by keyboard or by mouse. The only quibble would be in entering dates for a different year.
You can do it easily enough via the keyboard, but they should have a second set of little arrows on the calendar to jump a year at a time back or forth using the mouse.
EDIT: In response to the question, "What if you want to schedule an event that goes from 11PM on Tuesday till 1AM on Wednesday (say a daily build, for instance)? How do you wrap the time over midnight?"
If the "to" time pushes it over midnight, then roll the "to" date to the next day. That would just be part of the business logic of the component. You'll notice in the second image above, the drop-down indicates both the end time and the duration of the event, which should be a hint.
If you try and put an end date earlier than the start date, you can highlight the background colour of the fields and/or show an error message on save.
Play around on Google Calendar and see how it behaves.
I'd suggest you also allow for users who like to type rather than click on a calendar control, so a combination of text box + popup calendar works well.
We created a custom control with just such a combination. User can type a date in a variety of formats in the textbox, or click on a button to pop up the calendar.
We allow all sorts of input like "today", "wed", or "+2" (for day after tomorrow) and use regular expressions for most of the validation client side. We also do server side validation of course.
The control also has an optional textbox for time which can be enabled or hidden by a property. We felt it was easier to separate date from time. For times, we allow "9pm", "2100", "09:00" etc.
The control caters for a min and max date, so that date of birth can have a range from say -100 years to current year, while credit card expiry might range from current year to +5 years, and so we use range validators.
A text box with an image-link to a pop-out calendar on the side is my choice. Best of both worlds.
If you want something extra you could let a natural language date/time parser like Chronic http://chronic.rubyforge.org/ spice it up.
Also don't forget the international users.
If you're going for the combo-box/list-box option make sure you make the months read "Jan","Feb"..."Dec" rather than "1","2"..."12".
It's rather annoying having to figure out which slot is the month and which is the day according to the ranges of the values.
I'd go for three alternatives depending on the situation:
2 combo boxes. One listing year + month, another the day
3 combo boxes. One listing years, one month, one days
Visible calendar/s and combos like this one from YUI
And I believe there are more options from which I'd choose.
You need to check your UI requirements. If you want script-enabled support only, they you can go with any of your panopoly of scripts and run with whatever date/time format they provide into a hidden field.
However, if you need the user entry in a textbox, then you're faced with some decisions:
Is the date/time format rigid? e.g. mm/dd/yyy hh:mm:ss format only?
Or loosely defined, to allow for the "today", "tomorrow", "23 Jan" style entries?
Will the formats be locale-specific? e.g. mm/dd/yyyy vs. dd/mm/yyyy
Validation methods depend on your decisions on requirements.
I like the jQuery date-picker plugin. It'll allow output in specific formats.
A calendar showing multiple months continuously: http://www.cs.helsinki.fi/u/salaakso/patterns/Calendar-Strip.html
I've always found Google Calendar easy to use in this respect. You could certainly do worse than trying to emulate it. The key is to give the user a lot of flexibility in how they enter information. For example, I can select a time from a drop down list or type it in manually, and when I type, I'm not required to include the colon or the "m" in "pm".
I really like the way QT4's Date/Time widget works.
You can enter dates manually (type in the date, in common formats).
You can use your scroll wheel to quickly change date/time fields.
You have an expandable calendar that has drop down months and forward/backward arrows for the months. You can click on specific days and enter the year manually, or with a combo box (scroll wheel works here too).
Here is a short video (~7.5MB) that shows how the widget works and what some of its features are: Video Here
I would expect any sophisticated application to have some or all of these features.
Being able to enter relative dates (today, last week, 3 days ago) is handy, but I'm not sure how practical it would be, given standard questions like "What is your date of birth?", or "When would you like X emailed to you?".
you can use plugin cxcalendar. It looks like other datepicker. but you can pick year and month in select after clicking year-month title.
While plenty of solutions exist for entering dates (such as calendars, drop-down menus, etc.), it doesn't seem like there are too many "standard" ways to ask for a time (or time range).
I've personally tried drop-down menus for the hour, minute, and second fields (and sometimes an "AM/PM" field, as well). I've also tried several clock-like input devices, most of which are too hard to use for the typical end-user. I've even tried "pop-out" time selection menus (which allow you to, for example, hover over the hour "10" to receive a sub-menu that contains ":00",":15",":30", and ":45") -- but none of these methods seem natural.
So far, the best (and most universal) method I have found is just using simple text fields and forcing a user to manually populate the hour, minute, and second. Alternatively, I've had good experiences creating something similar to Outlook's "Day View" which allows you to drag and drop an event to set the start and end times.
Is there a "best way" to ask for this information? Is anybody using some type of time input widget that's really intuitive and easy to use? Or is there at least a way that's more efficient than using plain text boxes?
I find Google Calendar's approach to be the best. Use a text box, but use JavaScript to make it sort of a drop-down for picking your time. A good demo can be found for a jQuery implementation here
I haven't implemented this on my site yet so I'm not 100% sure, but I think you also need code from this jQuery plugin here:
http://www.texotela.co.uk/code/jquery/timepicker/
Edit
The first link I posted does not require the second link's code. It is simply based off of it. To get the actual JavaScript file from the example, you can view the source of the page to find where the file is, or you can go to the URL directly
http://labs.perifer.se/timedatepicker/jquery.timePicker.js
There is quite a useful time entry tool for JQuery. It provides a 'spinner' type approach, in addition to a standard text field. It also supports the use of the mouse scroll-wheel for adjustment (as well as the traditional 'just type it in' approach) and can be configured to restrict to n-minute steps too if you like. It's pretty customisable, supports localisation and a variety of other settings, I've used it successfully in a couple of projects/demo sites.
I am a huge fan of plain language input (there was a topic on it the other day). I like the way 37signals backpack calendar let's you type things in (08/12 3pm Meeting with tom). I also like the way they handle times with their reminder system (they give you options like later today, tomorrow morning).