We have an enterprise web application where every bit of text in the system is localised to the user's browser's culture setting.
So far we have only supported English, American (similar but mis-spelt ;-) and French (for the Canadian Gov't - app in English or French depending on user preference). During development we also had some European languages in mind like Dutch and German that tend to concatenate words into very long ones.
We're currently investigating support for eastern languages: Chinese, Japanese, and so on. I understand that these use phonetic input converted to written characters. How does that work on the web? Do the same events fire while inputs and textareas are being edited (we're quite Ajax heavy).
What conventions do users of these top-down languages expect online?
What effect does their dual-input (phonetic typing + conversion) have on web controls?
With RTL languages like Arabic do users expect the entire interface to be mirrored? For instance should things like OK/Cancel buttons be swapped and on the left?
As an Arabic speaker, when I do look at Arabic websites, I do expect things like OK/Cancel to be swapped.
When reading Arabic, my eyes read from right to left. So, in situations where you'd want to reader to view an affirmative/action button (e.g. OK, Submit, Yes, etc.) before a negative/inaction button (Cancel, Clear, No, etc.), you'd probably want to put the former on the right.
Caveat: As weird as it sounds, the above only applies (to me personally) when the button text is in Arabic. If the button text is in English (in a mixed-language web page), I'd prefer to see the OK button on the left.
Hope that helps.
Read Globalization Step-by-Step by Microsoft.
I can answer the specifics on CJKV, but you probably want a book on this topic. I haven't read it but CJKV Information Processing is from O'Reilly (2nd ed due Dec, 2008).
I understand that these use phonetic input converted to written characters.
How does that work on the web?
The input is done by a class of software called an IME (Input Method Editor) on Windows, Mac, and Linux (e.g. SCIM). When an IME is turned on, the input from the keyboard first goes to the IME, and the user gets to pick the correct kanji/hiragana combo. When the user commits by hitting return key, the IME types in the kanji/hiragana into the web browser using the current encoding. Encoding situation was a big mess, but if you are writing a web app, go with an encoding of Unicode. I suggest UTF-8.
Do the same events fire while inputs and textareas are being edited?
A Unicode savvy web browser and OS combo handles multiple languages. For example, one can use English normal version of Firefox to browse and post to a Japanese website. From the browsers point of view, it's just an array of "bla bla bla" in Unicode. In other words, if the event fires up in English, the same event should fire up in CJKV if you use a Unicode variant.
What conventions do users of these top-down languages expect online?
CJKV readers expect left-to-right online. Math and science textbooks are written from left-to-right. Most word processors, including localized version of Word, write left-to-right.
What effect does their dual-input (phonetic typing + conversion) have on web controls?
For the most part you should not have to worry about it, unless you are trapping keyboard events. For example, I hate using Japanese keyboard with bunch of extra keyboard. So, when I have to assign IME on/off command to some key on US keyboard. I personally use right-Alt. Also, spacebar and enter key is used during conversion, but not sure if these events are passed to browser.
The directionality question is easy to answer for East Asian languages: websites are left-to-right, top-to-bottom as per usual.
In fact, the general web design layout principles much the same. Have a look at the websites of a newspaper (name top left, navigation bar under with "Home" on the left, headline links below with most important at the top) or a search engine (don't think I need to say which US site you should compare that layout to).
However, just as Arabic/Hebrew/etc right-to-left language users will expect left-to-right progression in some contexts (embedded English fragments and so on), there are situations, even on the web, where top-to-bottom layout is preferred. This is generally done by including an image with the text layout and font desired, or using flash.
Internet Explorer has actually offered tb-rl layout with the CSS writing-mode property since version 5.5 however none of the other browsers have bothered implementing it (or ruby, which is useful for sites aimed at a young audience). IE 5.5 was released in 2000, so that's eight years of support, and there was a W3C candidate recommendation in 2003 but text layout in CSS still being poked around.
As for your worries with text input and IMEs, as long as you're not doing something bogus like trying to manually translate the virtual keys given by keydown events into text strings, you're unlikely to run into problems.
There are some additional issues you've not mentioned however. The minimum comfortably readable font size is larger than for languages written with the Latin script. Bold and italic for emphasis in flow are generally not appropriate. Han unification means to need to be picky about specifying the right fonts for the different CJK languages when working with unicode. You may want to provide both traditional and simplified interfaces for Chinese, depending on what audience you are expecting.
I've been meaning to write up a more comprehensive guide along these lines for a while, if you need more information feel free to kick me.
Related
I’ve been having some inquiries from CJK players of my SDL2-based game on Windows, asking about IME text entry; the candidate list window simply doesn't appear for them, making it impossible (or very difficult) to type certain glyph compositions. Right now I’m using the current latest SDL2, version 2.0.12.
As far as I can tell, I’m doing everything in approximately the right way; calling SDL_StartTextInput() when keyboard focus is moved to an (in-game-rendered) editable text field, and SDL_StopTextInput() when the keyboard focus leaves it, as well as setting SDL_SetTextInputRect() to tell the OS where the text field is. SDL_TEXTINPUT and SDL_TEXTEDITING events seem to come through the event loop as they're documented to do; everything seems to be working, except that the candidate list window doesn't open.
And it all works exactly correctly in Linux and Mac builds, with IME candidate list windows popping up at the right times and right places and functioning correctly to allow entry of composed CJK unicode glyphs, on those OSes. It's only on Windows where the candidate list window just never opens, which is a big problem for a bunch of my players. Does anybody know how one is intended to handle IME compositions under SDL2 on Windows? (I'm doing all of this testing with Windows 10's default IMEs for Japanese and Simplified Chinese)
Can anybody fill me in on how the system is intended to be used? The tutorial page on input methods is really thin on details, and I can’t find a real demo program which shows how IME is actually intended to be handled in SDL2, or I’d just copy what they were doing.
May or may not be relevant, but my game is an OpenGL 3.3 game, using SDL for window management, input, and cross-platform multithreading support; we’re not using SDL’s built-in renderer at all.
EDIT:
I’ve put a minimal example program over here on GitHub, demonstrating what I’m seeing. It’s just fifty lines of C code, so if I’m doing something catastrophically silly, it should hopefully be pretty easy to spot!
I researched a lot on this and seem to be getting conflicting answers on SO and all of the web. I understand that with Section 508 that compliance DOES NOT equal accessibility.
Biggest thing is that the UI/UX designer is being told that keyboard shortcuts for the dropdown menu NEEDS to have keyboard shortcuts to be 508 compliant. I see Windows Forms applications having this, but for web development I do not think that is mandatory to be "compliant"
My other question that was answered is here: MVC 4 site 508 compliant
I partially agree with thinice, but agree with the first two sentences of the comment left.
The sentences I am referring to are:
They should be -reachable- by keyboard for 508. I'm maintaining emphasis on the difference between a shortcut and being reachable
Crixus said:
Biggest thing is that the UI/UX designer is being told that keyboard shortcuts for the dropdown menu NEEDS to have keyboard shortcuts to be 508 compliant.
You need to clarify this. Do you mean a simple <select> or a drop down for a navigation menu? As Thinice stated in comments, Section 508 just says needs to be reachable. The question becomes:
how are you adding shortcut keys to your application? Are you adding them via the accesskeys attribute or how Gmail/Yahoo Mail adds shortcut keys?
I thought I did an answer about AccessKeys, but cannot find it. Essentially accesskeys sounds like a great thing, but if you look at the keys you are allowed to use that do not interfere with either browser or Assistive Technology keys, you are quite limited. Gez Lemon did an overview of AccessKeys, and their issues. If you want to do the Yahoo!Mail approach, you have to do a bit more work. Todd Kloots made a presentation about ARIA, which may be helpful. Which leads me into the second part. If you are using JavaScript heavily on a site to do stuff, people use both 1194.21 (software application/OS) and 1194.22 (web) standards to evaluate a site. If the site uses JS to make a navmenu (YUI menu example), the drop down behavior needs to be reachable by keyboard. I would say this falls under:
§ 1194.21 Software applications and operating systems.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
AND
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
I say both standards are used because (a) says you have to be able to get into the navigation area via the keyboard. (c) comes into play because some menus you can tab to all of the parent items, but you cannot get into the drop down part without a mouse. I have seen menus that you can tab to the sub-menu items, but the menu does not pop open. So if you just use the keyboard (mobility imparments), versus using JAWS, you will have no idea where you are.
I see Windows Forms applications having this, but for web development I do not think that is mandatory to be "compliant"
I would say actual applications, like Word, Outlook, etc., supply shortcuts to frequently used commands. If you are doing this for a web application, I would think about how many you do. This is not a mandatory piece to be compliant. If you are making like a navigation bar, I would recommend using ARIA roles, specifically role="navigation", on the parent element as a best practise.
The problem with some standards (as well as many laws) are that they're open to interpretation...
The only mention I can find in the 508 standards that mentions keyboard use is this (verbatim):
Subpart B -- Technical Standards
§ 1194.21 Software applications and operating systems.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where
the function itself or the result of performing a function can be
discerned textually.
My spin on this is:
A keyboard shortcut for navigation options may be impractical given the amount of operations/features a given section may contain. It is important that they're reachable -somehow- via keyboard.
From a UX standpoint, key features should have shortcuts "just because" it's good UX practice. But to shortcut everything goes from one ditch into the other.
508 != accessibility, but if you work for a gov/edu, chances are it's in your PD to be compliant.
Another end of the spectrum is the WCAG which is pretty much coupled with 508 compliance, and in my book better defined: Keyboard stuff is under 'operable' in WCAG.
In a nutshell:
It's good practice for UX to have custom keyboard shortcuts for important features. But has no bearing on 508 compliance by itself. (With exception that functionality should be reachable by keyboard -somehow-).
There are levels of 508 compliance, if you're talking about a government project. Some departments assign 508 scores to their developers, and it factors into your score for future contracts. 508 Compliance only requires that everything is reachable by keyboard, which is usually true, in a way. Screen readers will read everything that's not hidden, and tab keys will take people through links. But if you want a good score, you must address the intent and not only the letter of the law.
Edit: Screen readers will read some hidden elements. One method is to absolutely position an item above the screen with a negative top position. Another is to use the clip property.
http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/
But if you're using display:none, heights of zero, and javascript toggles, many screen readers will not speak these items.
In the case of a drop-down, you are actively hiding elements from screen readers etc, so you do have to fix it, because most readers won't hear things with display:none.
You will not find definitive documentation on keyboard navigation. The reason no one will specify exactly what to do, is that there are so many potential conflicts - with the browser, the OS, etc. There are also no standards, although Aria is making progress:
http://www.w3.org/TR/wai-aria-practices/#keyboard
I would not put accessKeys on a menu, if that's what you meant.
Instead see: http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget
I would save actual accessKeys for major things like 'Search' and 'Home'. Adding a learning curve to your site wouldn't help the cause, if you had an accessKey for everything. If you put for example, "About Us" accessKey=A, and you had 20 accessKeys assigned to letters, it would be bad.
I've been doing 508 sites for a long time, and personally, I just don't use drop-downs. It's far simpler to add subpage menus. And I personally hate clicking on dropdowns. Dropdowns require a precision in clicking that just irritates me, and doesn't help with accessibility, because remember accessibility also includes people who don't click very well. Plus, dropdowns are limited in the number of levels you can have, not technically but from a UX view.
What I use:
Tab indexes.
Carefully placed menus so that a user won't get a huge list of links before hearing the basic idea of the site or page.
On some projects, tree menus with matching arrow-key page navigation, sequentially.
Accesskeys H for home and S for search, if needed.
The problem especially is in sorting information. Think how quickly you scan a long list of links, and then imagine sitting there and waiting for it to be read to you. Perhaps, organize your content into digestible pieces & let the search box do the scanning. Depends on the content.
Luck. :)
I am trying to debug a tricky situation with auto-correction not getting correctly handled in a TextBox, but I am stuck:
I cannot find how the tapping of an auto-correction suggestion in the SIP gets communicated to the TextBox.
I have traced the KeyUp, KeyDown, TextInput, TextInputStart and TextInputUpdate events, but they do not seem to be involved in the update of the Text in the TextBox object.
Background:
When a language other than Greek is used, auto-correction works as it should for a TextBox in my app. However, when the language is set to Greek, nothing happens when tapping on the suggested word ... On the other hand, in TextBoxes in standard phone apps (e.g. adding text in the Notes section of a contact) Greek auto-correction works perfectly. So, my first guess is that there is something wrong with the TextBox rather than with the SIP. My plan is to subclass TextBox, modifying only its auto-correction handling parts.
Any help would be much appreciated,
Gerasimos
Update:
I made a few tests and this seems to be a problem in all non standard apps. Specifically, I tested the eBay and SkyMap applications and in both cases English auto-corrections work, while Greek do not.
The problem is easy to reproduce:
put a textbox in an application (with an inputScope that has auto-corrections enabled)
use a Greek keyboard layout
tap 1-2 random letters.
tap on one of the proposed auto-corrections. Only the final space is introduced, and in cases that the cursor is between two spaces (as I preferred to test it) nothing happens.
So, I believe that there is a bug somewhere in the framework part and not in the application code. Now, if we could find how this auto-correction tapping is communicated to the TextBox... :-)
You should not be able to interrupt the SIP directly, You can edit the content of the textbox after the value has been entered/changed. Alternatively, you can implement something like an autosuggest if your intentions are to change the content instead of the visuals.
I'm new to developing on the Mac and am looking to implement an interface similar to Spotlight's - the main part which seems to be an expanding table/grid view.
I was wondering if there is a component Apple provides for creating something like this or is available open source else where.
Of course if not I'll just try and work something out myself but it's always worth checking!
Thanks for your help in advance.
New Answer (December, 2015)
These days I'd go with a vertical stack view ( NSStackView ).
You can use its hiding priorities to guarantee the number of results you show will fit (it'll hide those it can't). Note, it doesn't reuse views like a table view reuses cell views, so it's only appropriate for a limited number of "results" in your case, especially since it doesn't make sense to add a bunch of subviews that'll never appear. I'd go so far as to say outright you shouldn't use it for lists of things you intend to scroll (in this case, go with a table view).
The priority setting can be used to make sure your assumption of what should be "enough" results doesn't cause ugly layout issues by letting the stack view "sacrifice" the last few.
You can even emulate Spotlight's "Spotlight Preferences" entry (or a "show all" option) by adding it last and setting its priority to required (1000) so it always stays put even if result entries above it are hidden due to lack of space.
Lately all my UI designs for 10.11 (and beyond) have been making heavy use of them. I keep finding new ways to simplify my layouts with them. Given how lightweight they are, they should be your go-to solution first unless you need something more complex (Apple engineers stated in WWDC videos they're intended to be used in this way).
Old 2011 Answer
This is private Apple API. I don't know of any open-source initiatives that mimic it off-hand.
Were I trying to do it, I might use an NSTableView with no enclosing scroll view, no headers, two columns, right-justified lighter-colored text in the left column, the easily-googled image/text cell in the right column, with vertical grid lines turned on. The container view would observe the table view for frame changes and resize/reposition accordingly.
Adding: It might be a good idea also to see if the right/left justified text (or even the position of the columns) is different in languages with different sweep paths. Example: Arabic and Hebrew are read right-to-left. Better to adapt than to say "who cares" (he says flippantly while knowing full well his own apps have problems with this sort of thing :-)). You can test this by making sure such languages are installed on your computer, then switching between them and testing out Spotlight. Changing languages shouldn't pose an issue since the language switching UI doesn't rely on reading a foreign language. :-)
Obviously a subjective question but I figure this site has built up a multinational audience so hopefully there will be some good insight.
The option I am thinking of going with is a combo box with flag images to indicate which language you want to view your application.
Pros
Everyone recognizes images so you don't have to worry about somebody not being able to select the language of choice because they don't understand what the box is for.
Combo Box supports many (as many as will fit on the page or more if has scrolling capability) using limited screen real estate.
Cons
It may not be obvious to everyone using the application that this is the way to select the language of choice.
The flag chosen to represent the language might offend speakers of that language from another country whose flag was not chosen (Which country's flag do you use for English, Spanish, Portuquese, etc.)
Another option is to use a combo box where each language is represented in its own language so speakers of that language will recognize their language in the drop down.
I am writing this for a desktop application and was curious as to whether a consensus standard has arisen either on the Web or Desktop world that most people "get".
The right answer for me is the control that most user's immediately understand the intended purpose and how to use the control.
My vote: combobox with a list of language name and then dialect in parenthesis.
For example, to list Portuguese:
English (UK)
English (US)
português (Brazil)
português (Portugal)
Language name comes first and alphabetized and written in the native language, that way it will be easiest to find. Name of dialect second so that all the dialects will be together alphbetically, making it easy to see if, for example, there is both UK and US English or just one of them. Little flags sometimes help but sometimes just add clutter.
Another thing: Let the user select language at install time. It must be the first thing that he sees. The Nullsoft installer does this well. Expecting the user to naviagte menus like Tools->Options->Configuration->International->Language in a foreign language is unacceptable!
Never assume that you can glean language from regional settings! Often Windows is configured for the local currency even though the user doesn't speak the language.
Kudos for recognizing that each language should be written in its own language! Often I see a list of languages, all written in some foreign language, and I can't tell which one to pick.
Another option is to use a combo box where each language is represented in its own language so speakers of that language will recognize their language in the drop down.
That's a fairly common practice, and it makes good sense.
Next to the flag, put "Language" and don't localize it. Nearly everyone who is familiar with changing languages in software knows what that means, and having the flag next to it will get the rest :)
This is not an easy problem. The flag idea works fairly well, but I need to train myself to look for the Union Jack. Depending on the application, I might want the Stars and Stripes instead because there is a difference between British English and American. It can get tricky if you try to overload too much meaning onto the flag. For instance, what language is meant by the Swiss flag. Or what if I only speak Spanish, but want the application to use US date and time formats. And don't even think about what will happen if you localize into Chinese. (Example: do you have a Taiwanese flag or not?)
I tend to prefer the languages written out. It gives you a lot of flexibility to specify exactly what language is meant. In addition, you can have a bit of fun sometimes. Facebook has a Pirate English option which is good for a few laughs. Google has even more fun interface language choices. And everyone who needs the Español option will know what it means.
I personally prefer a smart app that makes its best to detect to detect my language. Of course, a languages submenu tight either to a menu item (such Preferences/Language/) or a toolbar button (image is a world icon) must be there somewhere to let user override the automated choice. But in most cases, they shouldn't have to think about it.
Important: The submenu (or combobox, whatever) should contain native language names. That way, users always find their language.
Flags are not such a good idea IMO: Very small flag icons are not very distinctive. Plus it's easier to find a language name rather than a flag. And flags are related to countries, which is not quite the same as language: Some of your English users might not like a US flag that much.
Depending on the technology you use, you might find my codeproject article interesting:
http://www.codeproject.com/KB/locale/LanguageMenu.aspx