Enhance language select form with textbox and other tools

Updated issue summary.

1. I didn't find any reason for the percentage except encouraging translation teams to continue working towards 100%. The user won't give a dime for it, and it's a very tricky one for non-technical people where you have to tell them that this percentage is only core, and it doesn't represent frontend/backend (where many translations have done the frontend part very well). So 1 for me is unnecessary detail.

2. Hiding it is a good thing if we translate the description field "The language you choose ...", in this way, we make sure every person who doesn't understand a bit of English can find his way from the first screen.

3. If we switch to RTL. Do we need to stick with this RTL screen for the whole installer? also, we might need to see it in-action, to make sure it won't be very awful effect.

Other points that might need a little discussion:
- The user can write in the textbox the native language name or the English one? (e.g. Arabic, or, العربية).
- Can user select with the mouse from the selectbox?

#1260716: Improve language onboarding user experience was committed, hooray.

What it looks like now

A quick clean-up

So much too win in clarity and focus if we remove Druplicon here: the task list is much closer to the actual form elements.

I put the 'Learn how to install in other languages' link on the same line with the select list to make it a bit less prominent.

Anyway, mostly out of scope for this specific issue of course, but some initial thoughts about this screen to get discussion started.

doh

I think the main discussion is how to implement the idea in the top in accessible way. Removing or replacing the branding element, such as the Druplicon has a other issue (I cant seem to find).

I am going to mark this major, because this screen is seen by everyone and is currently its interaction hard to use. This is the standard we used in D7 too.

@yoro: could you take a screenshot with multiple languages and the help text inline? I think it'll be better if multiple languages appear on top of the help text, not inline with it, however it's good for one language as in your screenshot.

I know iI know. Just pointing out what you're competing with on this page. Carry on :)

Now I need a help text for me :S anyhow it's looking better.

This sounds like a feature request rather than a task. If there's a reason fixing this should hold up other D8 development, please specify.

Can we please put a label on the form element? See #1356702: Change title on installation pages for why form elements with no labels are confusing :)

Er, I think UX is a pretty good reason it should hold up development. Especially on the *very first* thing people see having to do with using Drupal.
(Please put it back if I'm wrong) :)

I agree with Jen that it is good to have a label above the field for maximum clarity.

As for the #1-3:

1) I personally don't like the percent translated part... I think it's confusing and makes things more cluttered.

2) showing less steps (if accurate) is good so you feel like you are going to be done fast!

3) switching to RTL automatically makes sense to me

Kristen

XPost from #568986: Dynamically update standard language list from localization server
Just a side note: while working on #1189184: Make gettext .po generation its own abstracted functionality I was tempted to allow _all_ available languages to try download the install-langcode.po when selected as the POFileReader accepts an URI to download.
(POFileWriter could write it to public://translations/ and POMemoryWriter facilitates the installer to read it)

This is currently held up on is implementing, download languages from locale.drupal.org

I think the design we want is in the OP, its a select box with a search possibility.

Wait. Before we make this a threshold-blocking thing, can you explain what's wrong with a select box? I get that there are a lot of options in it, but seems like this is a simple enhancement?

Looking at the screenshots, looks like you want to use http://harvesthq.github.com/chosen/ it will transform the selectbox to something fancy

I'm reducing to normal until/unless the case can be made for why adding UX chrome here is worth blocking other peoples' stuff.

This issue is going to be a nightmare to close, IMO, trying to find one of those libraries that's accessible enough for our needs. Also has to work on mobile, don't forget.

Before trying out fancy things let's have a look at #1593964: Allow FAPI usage of the datalist element.

#27
My personal problem with chosen is that it relies on jQuery, I think we can write something similar without having to rely on jQuery.

#28
The problem with datalist is that the user has no clue it is also a select list, in Chrome/FF I have to double click to show me the list of options, and it also allows people to enter something else, which in this case doesn't really makes sense.

PS: Tested on http://adactio.s3.amazonaws.com/misc/datalist.html

Very closely related: #1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter)

Switching between LtR and RtL languages on the fly would betotally disorientating, IMO. If it is being seriously considered it should be prototyped and tested, to make sure that the welcoming experience we're trying to provide doesn't become a seizure inducing one despite good intentions.

I think there's some use to the percentage markers. I wouldn't want to see them all, but maybe showing those under a certain percentage would help manage expectations, which is especially important for first time users.

I think we should do the percentage in a different issue. I have some thoughts, but I don't think that needs to hold this up.
Related: another thing for another issue might be to show with the language name in it's language, is the name of the language in the browser language. That an edge thing and not needed here. No action on that I need to think about it some more.

that should work out let's note add yet anthother js lib: http://jqueryui.com/autocomplete/#combobox

updated issue summary with what is agreed to cover or not cover in this issue and remaining tasks: decide to filter or jump, decide what lib to use.

Updated issue summary lettered the implementations with no agreement

Updated issue summary, small grammar to improve clarity

I updated the issue summary with the current screen shots. took out the original suggestion since we have changed what this issue proposed solution is, but left a link to it.

remaining tasks are updated, but quickly are: decide if typing to search would filter or just jump to, and decide how to implement. a summary in the issue summary shows previous suggestions that wont work, and one proposal not yet evaluated.

There is work in progress to get jQuery autocomplete in core: #675446: Use jQuery UI Autocomplete. In #1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter) Chosen, Select2 and Typeahead are not considered for D8 due to existing accessibility issues. We might have a change if we can use jQuery autocomplete for this language selection.

If it weren't for its accessibility issues, having Chosen (or something like it) in place would make it easier later if we decide to implement #2010008: Multilingual site installation, Step #1: Allow selecting more than one language during installation..

Looks like jQuery UI autocomplete is the winner here even if it isn't the best implementation it's still better than nothing and is already in core afaik.

Yeah, I realize that there's no time and that it'd be best to go with something already in core. I merely tried to emphasize that along the way we'll likely need a solution that combines autocomplete and multiple selection.

The custom data demo actually comes pretty close I think... we might not be able to make the language name bold but we can definitely add the extra description indicating completeness %... and if we wanted to really get cute we could add flag icons too :)

Good call, back to the drawing board...

Sifting through some admin modules I was recalling this thread looking at the technique of the Better Select module.

That's – albeit not as pretty as Chosen and the likes – a pretty intuitive way to work through long lists – and easy to implement as well. You could even use radio buttons and still have a better user experience then with those mega select dropdowns.

Accessibility should be doable – especially comparing it to the more fancy solutions mentioned above. The only thing that came to my mind is the clumsiness of using this on a touch device, as this is not a standad form function and involves framed scrolling. Some sort of switch (to a standard select/multiselect element?) for touch devices and accessibility could be a solution.

Olright, here is a patch that will add a new textfield and increase the selectlist size to 8 elements as shown here: https://drupal.org/files/installer-01-language.png

When searched, the list will remain full (its not filtered) but the option matching the search string the closest will be selected.

Few things

when declaring and assigning values, one var per line.
$select.find('option') is looked for every keyup. That should be selected and cached out of the event handler.
replacing string.match(regex) with regex.test(string)

Beside that, i'm happy with it.

I'm sceptical about how useful this is. The additional languages shown are there because they alphabetically follow English, which is not relevant. I'll have to try out the patch first but I suspect this change makes the form look more as if you *have* to choose a language before you can continue. Don't make me think! :-)

In related news, I opened #2099577: Follow-up: First installer page has initially needless description for how translations are handled

try it out, the default language is prefilled and preselected.

@yoroy: what if the actively selected language would look more prominent like in the styleguide: https://groups.drupal.org/node/283223#Dropdowns_and_Popovers

This way i think the user would be better informed that there is a "selection" and that he doesnt necessarily has to change it. Maybe the search box can also be changed so it looks a bit more "connected" to the list itself.

I guess I'm not sure what this design means to portray:

Are those languages auto-complete suggestions or an always-on select box?

For the past few years we have been advocating using "standard select" of http://harvesthq.github.io/chosen/ for interactions like this. Although we know this is a little hard to implement, there are fewer tradeoffs. I remember agreeing to that, I probably interpreted Kevin's design wrong.

The design as proposed here and I agree with yoroy, introduces two interactions to get to the same thing (which will probably cause confusion) and exposes a very big box that is not relevant to most users (preselected using browser defaults).

I hope that the great people who have been working on this, could implement that new direction. It looks like this would greatly enhance the first page of Drupal :)

and missing tag.

From my point of view is there is a very big gap between the experience offered through Chosen and that of the native browser. It should be a priority for you to resolve, because the initial UX of this screen was not as bad - because we only offered a few choices. So you introduced a UX regression.

Will it be hard to solve? Yes, thats why we wanted it to be part of the initial patch instead of a followup (we knew it would be hard). When its a followup there are always priorities that go over fine-tuning the UX, and that is also why D8 in many area's gotten worse from a UX perspective, most hard UX issues where pushed to followups. Given that this is the first screen people see, I'd advocate for still making it part of your effort - making it really usable will be a pleasant start of the Drupal experience.

@Gábor I find this discussion rather silly. You can implement the spec, and make something that is hard to use. Our end-goal is making a highly usable system, its not reaching spec.

I am suggesting we do something that takes work. I am also arguing why it is important, and how it will be a usable solution.

as long as contrib doesn't use it too much (who am i kidding, of course they would) here is a first stab. The styling is all broken and the interraction isn't great either but it's a start.

Using http://jqueryui.com/autocomplete/#combobox

jQuery autocomplete is accessible so this ought to work to some extend.

I think the only way we can get that done at this point is blocking a day or two of sprint with me/jesse/Bojhan to be able to deal with JS/CSS/a11y/UX issues on the spot and not over 6 months and 300+ comments.

Screen shots.

Suppose better to wait for #675446: Use jQuery UI Autocomplete and make it on top of JQ

I think a browser-native select box works fine here. The list is long, but it's something that has to be interacted with exactly once in the lifespan of a site. The browser-native select box already has type-ahead behaviors. I'd vote we drop this task.

+1 to what @jessebeach said.

Using select2 for this works pretty well #2346973: Improve usability, accessibility, and scalability of long select lists

Something like : #2442699: UX improvment on autocompletion would also make the deal, with the multifields possibly displaying the language name in english, the language name in it's own language and a percentage of expected translation for instance.

Realistically it's been 7 years and never came up again. I know it doesn't mean it's not important but I consider it more important to not have an overwhelming queue so tentatively closing this one.