"A centenarian is a person who has attained the age of 100 years or more." - Wikipedia
There are several ways to prompt a user for Date of Birth, but let's say we've chosen the drop down method.
How would you handle the oldest selectable date? Do you pick an arbitrary year (such as 1875) and populate to present?
Or, do you consult some resource for a record breaking age (Jeanne Calment, age 122), add a couple of years, and populate backwards?
Why not a text input box where they type in "1899" or whatever? When it is received you can validate that it is a legitimate number based on whatever criteria you use. I get annoyed by listboxes to select year of birth, because listboxes should not have that many values in them.
Rereading the question, you are assuming that listbox is the only option. In that case, 130 years ago seems like a good enough cutoff to me. If you're worried that the next world-record breaker will happen to be using your system, why not go with something like 200 years ago. Although I'd still say you should just use a text box.
As you're going to have to perform server-side validate the input regardless of the control used, why not use a standard text input?
`<input type="text" maxlength="4"/>
This:
Eliminates the centenarian problem.
Easier to use, especially for older individuals (Assuming the list is in descending order).
Smaller page size (don't need to include 100+ <option>....</option> tags.
If you must use a <select> box, I agree with your Wikipedia methodology. Ceiling the age of the oldest recorded person (126 -> 130 or 140) would be fairly risk-free.
It depends I think. Are you creating an application for young people?
If the application needs to be accessible for everyone, just create a configurable check and update it now and then. Look at http://en.wikipedia.org/wiki/Oldest_people#Ten_oldest_people_currently_living for the oldest possible date.
A date picker is preferable, don't use irritating listboxes with 100+ values.
My opinion on data entry like this is to cater to the user, not the programmer.
While, yes, a drop-down causes the least error handling, it's also tedious for the users.
Go for text entry that you need to validate. More code is needed in the back [allowing for both 2 digit years and 4 digit], but it's an easier experience for the user
If you want to stick to drop downs, just pick an old enough date. Personally I think drop downs are bad both for the user and you. I find selecting my birthday from a list of hundred numbers annoying (even though firefox lets me select the date by typing it). But also I think a selection makes people tend to input fake years more than if they had to type it in.
If you can live with Javascript, a Combobox might be the best of both worlds. You can list 100 years in the list, and let older people type. This only has minor ethical problem, i.e. you purposefully make elderly people type =)
Related
Here is an example of the data I am using:
"Q7: How does gender income inequality manifest in the communities in which you live and/or work? What do you believe is needed to help close the wealth gap between men and women as well as among women of different races in the county?
Wouldn’t go into pay equity because that would get dismissed. The wealth gap is a more compelling argument.
Equity is more emotional. And wealth gap is more numbers. It goes toward the same thing though."
I am running Rstudio and using library(RQDA) and library(tidyverse).
I am trying to analyze several qualitative interviews formatted in question/answer form as in the provided example. I finished the coding process and now I'm trying to find themes. While coding, I created code categories that correspond with each interview question with the hopes that I would be able to pull out all the codings per code category now. Unfortunately, I cannot figure out how to do it and would appreciate some assistance!
thanks
I am not sure about this but I understood code categories to be helpful for structuring your work by your theoretical perspective. If you create a code category for each interview question (i.e., the topic of the question is your theme/code category), you may have various codes belonging to one "code category", which might not have that much in common. Alternatively, you could create cases (case 1 might be the answers to the first interview question, etc.): "b) Open a file, select part of the file, select a case name, then click button "Link" in "Cases" tab, you can thus link the selected part of file to the selected case" (http://rqda.r-forge.r-project.org/documentation_2.html).
assuming that I know nothing about everything and that I'm starting in programming TODAY what do you say would be necessary for me to learn in order to start working with Natural Language Processing?
I've been struggling with some string parsing methods but so far it is just annoying me and making me create ugly code. I'm looking for some fresh new ideas on how to create a Remember The Milk API like to parse user's input in order to provide an input form for fast data entry that are not based on fields but in simple one line phrases instead.
EDIT: RTM is todo list system. So in order to enter a task you don't need to type in each field to fill values (task name, due date, location, etc). You can simply type in a phrase like "Dentist appointment monday at 2PM in WhateverPlace" and it will parse it and fill all fields for you.
I don't have any kind of technical constraints since it's going to be a personal project but I'm more familiar with .NET world. Actually, I'm not sure this is a matter of language but if it's necessary I'm more than willing to learn a new language to do it.
My project is related to personal finances so the phrases are more like "Spent 10USD on Coffee last night with my girlfriend" and it would fill location, amount of $$$, tags and other stuff.
Thanks a lot for any kind of directions that you might give me!
This does not appear to require full NLP. Simple pattern-based information extraction will probably suffice. The basic idea is to tokenize the text, then recognize/classify certain keywords, and finally recognize patterns/phrases.
In your example, tokenizing gives you "Dentist", "appointment", "monday", "at", "2PM", "in", "WhateverPlace". Your tool will recognize that "monday" is a day of the week, "2PM" is a time, etc. Finally, you can find patterns like [at] [TIME] and [in] [Place] and use those to fill in the fields.
A framework like GATE may help, but even that may be a larger hammer than you really need.
Have a look at NLTK, its a good resource for beginner programmers interested in NLP.
http://www.nltk.org/
It is written in python which is one of the easier programming languages.
Now that I understand your problem, here is my solution:
You can develop a kind of restricted vocabulary, in which all amounts must end witha $ sign or any time must be in form of 00:00 and/or end with AM/PM, regarding detecting items, you can use list of objects from ontology such as Open Cyc. Open Cyc can provide you with list of all objects such beer, coffee, bread and milk etc. this will help you to detect objects in the short phrase. Still it would be a very fuzzy approach.
I've read somewhere (can't remember/find where) an article about web usability describing when to use drop downs and when to use autocomplete fields.
Basically, the article says that the human brain cannot store more then the last five options presented to choose.
For example, in a profile form, where there is your current occupation, and the system gives you a bunch of options, when you read the sixth options, your brain can't remember the first one anymore. This example is a great place to use an autocomplete field, where the user types something that he thinks that would be his occupation and then select the better from the few options filtered.
I would like to hear your opinion about this subject.
When should I use a drop-down and when I should use a Autocomplete field?
For a limited list, don't use an autocomplete edit box or combobox, but use a listbox where all values are visible all at once. For limited lists, especially with static content of up to about 8 items, this takes up real estate, but presents the user with a better immediate overview.
For less than 5 items a radiogroup or checkbox group (multiple selections) may also be better.
For lists whose content is dynamic, like a list of contacts, a (scrolling) listbox or combobox are appropriate because you never know how many items will be in the list. To keep it manageable, you will need to allow for some kind of filtering and/or autocomplete.
Autocomplete usually suffers from the fact that what the users types needs to match a string from the beginning. I hate those except for when they are used to complete a value based on what I typed in that (type of) field before. E.g. what browsers nowadays offer when filling out online forms.
Allowing a user to start typing in a combobox usually suffers the same drawback. But admittedly it doesn't need to if the filtering is based on "like %abc%" instead of "starts with abc"
When dealing with lists that can have many similar items, I really like the way GMail's "To" field handles it. You start typing any part of someone's name or e-mail address and GMail will drop down a list presenting all the contacts whose name or e-mail address contains the characters you have typed so far anywhere within them. Using the up and down keys changes the selection in the dropped down list (without affecting what you have typed) and pressing enter adds the currently selected item to the "To" field. By far the best user experience I have had so far when having to select something from a list.
Haven't found any components yet that can do this, but it's not too hard to "fake" by combining an edit box and a listbox that drops down when you start typing and has its contents is filtered based on what has been typed so far.
I would use 2 criteria,
1) How long is the list, if the list contains 5 elements you better use a combobox as it will be easier for the user (better UX)
2) In case the list is long, how easy for the user to remember the prefix of what he/she is looking for... if it's not easy, using autocomplete is irrelevant..
I'd say it depends on the diversity in the list, and the familiarity with the list items.
If for example the list contained over 5 car brands (list items I'm familiar with), no problem.
If on the other hand the list has over 5 last names, it could take me some more time before I'd make a selection.
You should probably just try out both options and trust your gut on which you find easier to use.
Here's the opposite approach:
The worst time to use an auto-complete box is when you have a finite and relatively small set of options, and the user doesn't know the range of valid options. For example, if you're selling used cars and you have a mixed bag of brands, simply listing the brands in a combobox is more efficient and easier to browse than an auto-complete method.
Being able to remember the last 5 options is most likely irrelevant unless you have a giant list of options and are requiring the user to select the most relevant item.
An alternative approach is to use both. I believe Dojo has a widget that acts as both a combobox and an auto-complete field. You can either choose to start typing and it will narrow down the possible options, or you can interact with it with your mouse and browse it like a combobox.
I usually look at how big the list is going to be. If there are going to be more than 15 options then it just seems easier to find if they can just start typing.
The other circumstance for me is when there is an other option and they can free type it. This essentially eliminates the need for two controls since you can combine in one.
The main difference has nothing to do with usability but more to do with what defines the acceptable inputs.
You normally use a ComboBox when you have a predefined list of acceptable inputs (e.g. an Enum or list of occupations).
An auto-complete field is best used when there are many known inputs BUT custom input is accepted as well. The user will become frustrated if they type "Programmer" in as their occupation but it wasn't one of the pre-defined, acceptable inputs, and they are given a message that their input is not valid.
Keep in mind that ComboBoxes do allow you to type in them to select the first matching option. Some types of ComboBoxes (depending on the UI framework you are using) even allow free-form text fields at the top or side of the field to search or add to the list.
Of coarse the best way to determine what YOUR user will prefer is testing: A/B, field, user, etc.
Hope this helps you solve your dilemma!
I have received requirements that ask to normalize text box content when the user changes the focus to another control on the same data input form. Example normalizations:
whitespace at the start and end of the input is trimmed
If the text box was made empty and this is not valid, replace the content of the text box with the default value
I have a feeling that this is not in line with good GUI design. I have read the Windows UX Guidelines for text boxes but I did not immediately find any relevant rules.
Is normalizing text box content in this way acceptable?
I have definitely seen this before (examples elude me right now) but I personally don't like it when the UI changes my input.
If the UI is smart enough to change my input on me then it should accept it as is and change the value when it needs to process it.
When the input changes auto-magically you are now forcing the user to stop and ask themselves why it changed and if they did something wrong or if the application has an error. Don't make the user think!
Generally, you should accept user input exactly has they entered it. Chances are users did it that way for a good reason. For example, imagine a user entering a foreign address, and then your app screws it up trying to format like a domestic address. At the very least, users entered the input the way they’re used to it being, so changing it can make it hard for them to cross-check it.
However, there are several exceptions:
Add defaults to incomplete input. Adding input the user left off (e.g., years to dates, units to dimensions) provides good feedback on how the app is interpreting the input that would otherwise be ambiguous. This also encourages the user to use defaults, making their input more efficient.
Resolve other ambiguities. Change to an unambiguous format if the user’s format is open to interpretation. For example, if you have international users, you may want to change “9-8-09” to “Sep 8 2009” (or “9 Aug 2009”) to provide feedback on what your app considers the month and day to be.
Add delimiters when none provided. Automagically adding standard or even arbitrary delimiters to long alphanumeric strings (e.g., phone numbers, credit card numbers, serial numbers) provides an input display that the users can crosscheck more easily. Sometimes users may enter a string without delimiters in order to go faster or because they are the victim of web abuse by sites that refuse to accept even standard delimiters.
Spelling, grammar, and capitalization correction. Users often appreciate this, but only if there’s also a means to override it. Some users like to use "i" as the first person pronoun.
If the field is used by more than one user, then you probably should automatically format the value in some standard way that accommodates the majority of your users, but that should be done when the value is stored on the backend, not when focus leaves the field. For example, if a user enters a time of 15:30 it should remain as 15:30 as long as the user views the page. However, the next time a user (any user) retrieves the data, it should appear as 3:30pm (if that’s how most of your users are used to seeing time).
Such backend formatting applies to trimming whitespace so that all users can search, find, and sort on the field consistently. It’s probably not a good idea to replace a blank value (or any invalid value) with the default because users are unlikely to anticipate getting that value. An exception would perhaps be changing blank to 0 for numeric fields in situations where obviously blank == none == zero, but again this probably should be done when storing in the backend, not in the field itself. If blank is ambiguous, (e.g., may mean 0 or may mean "I don't know") then the second bullet above applies, and you may want to autocorrect in the field when focus is lost.
Of course, if your users vary in how they need to have a data type formatted, then you can have different variants of the app that display the data type in different ways for different user groups, or you can make the format of the data type a user preference, but that’s really another issue.
If the user wants it, and the Stakeholder ask for it, then is perfectly safe.
Trimming is very common. and the replace is common when you are talking about filling textbox with numbers. (a 0 instead of a blank).
It's a fairly standard feature, especially the whitespace trimming. The default value replacement raises a larger flag just because it is less common.
I'm pretty sure that I've seen versions of Microsoft Office that do this - putting "pt." after a value in points, for instance. Microsoft's endorsement should be a good sign.
We have quite a few of these kind of requirement. The reason given for forcing a default value rather than a blank space is that it looks better in reports or if the client wants to see the live system. A blank looks a bit like "couldn't be bothered to enter anything". For a similar reason, we often upper-case the text for consistency as the users never use consistent formatting.
Very simple question: should a dropdown list be used to populate state abbreviations? From my experience, I think most e-commerce sites do this so I would expect that it's acceptable. However, Jakob Nielsen has something to say about this.
I think I disagree; I use the tab key then type the first letter of my state. Heck, even if it wasn't the first entry, I've done this enough times, I would hit the letter repeatedly and get to what I need. I never need the scroll wheel or mouse.
Is there any additional concrete guidance out there on this particular question?
I think this will become less of an issue now that most modern browsers scroll the drop down lists based on each consecutive letter you type, not just reading the first letter as they once did. So, If you type N-Y, the drop down list will scroll directly to NY and you do not have to hit N a bunch of times.
Since a state is a two letter abbreviation, I wouldn't put a drop downlist, I would put a textbox, but I would validate it using AJAX or Javascript to warn the user about an error, right after he entered something wrong.
DropDown / Auto-completion (in my opinion) is useful when the data to enter is longer / more error-prone.
If you insist on using auto-completion or dropdown, you should put long state names, not just the abbrev.
I don't know about concrete guidance, but one alternative I would consider is using an autocomplete text box that forces you to choose from one of the available choices. I agree that a 50-item drop down list is too long and using autocomplete with enforced choice accomplishes the same purpose -- consistent data -- and has the advantage that it is much easier for the user to navigate. If you don't want to limit the choices to just US states you could drop the enforced choice and just let the autocomplete work as a suggestion with the user being able to enter free-form input.
EDIT: As #Martin suggests, I would probably have the autocomplete show the full state name, even if it only entered the abbreviation. This would solve issues of people getting the abbreviation wrong as well, though you could do the same thing in a drop down -- display the name with the abbreviation as the value.
I was going to post NYSystemsAnalyst's answer, but he beat me. I will instead add a caveat... If you use a dropdown list, it must be complete. Do not forget the obvious DC, or the less common but plausible PR or AE/AA/AP, or the rather improbable but still valid AS, FM, MH, MP, PW, and VI.
The official list
I think it depends on if you are asking a user to enter their own address or someone else's address (ship to address). Everyone knows their own state abbreviation, but may know all the state abbreviations.
So for entering your own address a textbox is the quickest and easiest way, but if you are asking the user to potentially enter someone else's address a drop down is probably best.
Of course, if you site has a combination of both types of address, you want your UI to be consistent and use the drop down for both. Also, if you are using a drop down, I would suggest using the state abbreviation and name (AZ - Arizona) when the drop down is expanded (but just show the abbreviation when it is collapsed).
I'm willing to bet that half the users of online e-commerce sites don't know the abbreviations for the states. Think if you're shipping a gift to someone and you can't remember whether its MS, MO or MI. Dropdowns are fine.
I've never had an issue with state drop down boxes (and this is from someone routinely at the bottom in West Virginia). I've gotten into the habit of just tabbing and pressing W and then it will either recognize the "E" and give me the correct state, or it will not recognize the "E" and then I have to hit the down key once or twice (depending on sort order) to get the proper state.
So all in all I am looking at 5 key presses max to get to my state. I don't think it's that bad.
How about a textbox with validation, and a drop-down list if the state abbreviation is invalid?