Tag Info

Hot answers tagged

64

Auto capitalization is impossible. What algoritm would you use to auto capitalize when a lady enters "cléopatra diane de mérode" as her name? You would probably end up with things like: Cléopatra Diane De Mérode Cléopatra diane De mérode The only correct spelling however is "Cléopatra Diane de Mérode" (wikipedia). As you can see, capitalization of ...


25

I would suggest no. Treat a person's name - in terms of capitalization, spelling, punctuation and spacing - exactly as the person does. [1] There are a variety of cultures with names that does not use capitalization in all parts of their names. It's true that most traditional English, American, north/central European names are written with ...


16

As others have mentioned, Dutch names like mine, even after they've been mangled into something English-like, can still have strange capitalization. If you tried to change my name to "Teneyck" after I entered it, you'd just irritate me. If your clients are unwilling to spell their own names correctly, it's not your job to correct them.


14

Auto-correction shouldn't occur. It takes control away from the user, is often wrong, and is even worse if it's changing the content of the message silently. You cite localization as one of the area in which it behaves badly. It's also the case with old or dead languages, citations, programming languages, medicine or very technical terms... Actually there ...


12

What is the context of your application? Context really matters for dates. Consider the two following situations. A budgeting application where users plan spending for future years A college reunion signup where users enter their graduation date Clearly if people are planning, they would be annoyed to get a date in the past and if people are entering ...


6

Typing on the phone is much more difficult than on the keyboard, so people make more mistakes and the phone autocorrect has to work much harder. Keyboard mistakes come from actual grammar mistakes and from typos, which are usually caused by typing an adjacent key by mistake - in most cases the wrong key is the one immediately to the right or to the left of ...


5

Yes, it's good to suggest the autocapitalization, letting the user change something if that gone wrong. Just be sure to define who your audience is: there are several algorithms to deal with particles like "de, da, e" in Brazilian Portuguese, for example: Lula da Silva, Pedro Bento e Silva, etc. Similar rules can be used for "van, de, la" etc., and even ...


5

No, for the simple reason that though you might have users who enjoy using terms like that as ways of endearment, there is always going to be a user base which is going to be offended. Also another reason is that texting is often done on the fly and there are numerous examples of where people have typed something else and autocorrect messed it up resulting ...


4

There's two factors here; the first is brand image, the second is that autocorrect isn't perfect, and mistakenly swearing at people is a pretty city thing to do. First and foremost, brands want to project an image. That's probably why, aside from legal concerns, Youtube doesn't allow pornography. Legal issues aside, Youtube can't be taken seriously by a ...


4

As Stephen already said: the purpose of the entered date matters a lot. I recently developed a date entry widget that also does this (and more). It allows entering the dates in basically any format. When it recognizes the entered data as a date, it shows a passive popup under the widget with the possible matching dates for the entered text. The ordering ...


4

How about a simple rules-based defensive approach if a user takes the time to capitalize his/her name -> assume it's correct else (if all lowercase) -> if name consists of 2 terms -> assume firstname + lastname -> capitalize first letter of both firstname and lastname. This is not correct for lastnames like 'MacLeish' but 'Macleish' is arguably 'not ...


3

If the text your users is entering is "normal" (not specific language for your site), the least intrusive option would be to trigger the user's browser spell check, as defined in the HTML 5 spec. The user is used to the behavior of their browser's spell check, which is typically unobtrusive.


3

How uniform is the content that your customers will be entering, and will they all be from the same part of the world? If they need to enter names, or other irregular words like place names, then spell checking is a bad idea. If it's just general text where they won't need any non-dictionary words, and they all use the same spelling system (e.g. UK v US ...


3

Firstly, don't use two character years. We finished with the Y2K horrors, so please let's learn from them. Then, assuming there is some critical reason to use two character years: If your users aren't entering future dates, or if those future dates are bound to something near the current date (say a few years in the future), then you should not use the ...


3

This is as far as I can tell not a matter of auto-correction, but rather how you have set up your keyboard/regional/language settings. I'm on a norwegian keyboard and we too use the comma (,) as a decimal point. The decimal point key on the numpad has a comma (,) printed on it and it will always type a comma (,), no matter what application I use or what ...


3

If such words are used often, it would be handy to have them in the autocomplete lists. However, UX is more complicated than simple mechanics of efficiency. The brands releasing such software would want to prevent any association with this kind of language. Having swear words in autocomplete features could suggest that Apple or any other organization ...


1

Although I don't necessarily agree with including swearwords by default, I will play devil's advocate and say yes, swearwords should be included. I think the first, most important reason is that swearwords are extremely common words. It is estimated that 0.5-0.7% of spoken words are swearwords -- that's about 90 words per day. For comparison, the common ...



Only top voted, non community-wiki answers of a minimum length are eligible