feat(android/app): language selection during KMP installation

darcywong00 commented 4 years ago

This feature request is to add a language picker during keyboard KMP installation (maybe UX similar to #3437 for iOS) No UX change for lexical-model KMP installation.

Currently, only keyboard installs from a language search on keyman.com will install the keyboard package with a pre-selected BCP 47 language tag.

We can re-use SelectLanguageActivity (used to add a language to an already installed keyboard) to change the KMP installation workflow:

while kmp is still in a temp path (no change from current behavior)
Display readme.htm with Cancel and Install buttons
If kmp.json has > 1 language in the package --> a. readme.htm has Next button instead of Install which goes to language picker b. Display language picker (back arrow goes back to readme.htm) c. User selects n languages (click "Next" to advance)
PackageProcessor extracts kmp to /packages/ and installs keyboard package with the selected BCP 47 language tags
Display welcome.htm when finished

PackageProcessor still has a "silent" mode where none of the documentation is displayed. If no language is passed, it'll just install the first one.

Revised Mockups (taking comments into account)

readme.htm

readme

language picker

select language

welcome

Original Mockups (which the comments provide feedback for)

readme.htm

readme

language picker

welcome.htm

welcome

darcywong00 commented 4 years ago

@mcdurdin What would the workflow look like for a keyboard package containing multiple keyboards (e.g. https://keyman-staging.com/keyboards/install/galaxie_greek_hebrew_mnemonic)?

I believe when we pass the selected language ID (e.g. he (Hebrew)), it will get assigned for the Galaxie Hebrew keyboard. The Galaxie Greek keyboard won't match for he so whatever language is listed first gets installed.

mcdurdin commented 4 years ago

The process looks good. A few comments on the UI design:

The title is a little messy and unclear. It needs to be larger, and be Install <name> <version> probably. See next points for layout.
The Next button should be at the top, and instead of Cancel it should show the < back button on the left, which is the Android style. The title should be next to the < button.
On the second page, the language picker should be a list from which you can check one or more languages. It should not have arrows on the right hand side. Furthermore, we can probably hide the BCP 47 codes here.
On the second page, add an Install button at the top right to match the first page, and a < button at the top left.
On the final page, the OK button can be at the top right, and no < button should be visible. The title on this page should show Welcome to <name> <version> or similar, not Install Keyboard, as the keyboard is now installed.

What would the workflow look like for a keyboard package containing multiple keyboards (e.g. https://keyman-staging.com/keyboards/install/galaxie_greek_hebrew_mnemonic)?

In theory you show the second page for each keyboard (with Next instead of Install as necessary). In practice, I hope that multi-keyboard packages don't have multiple languages for each keyboard, and the second page isn't shown at all.

darcywong00 commented 4 years ago

In practice, I hope that multi-keyboard packages don't have multiple languages for each keyboard, and the second page isn't shown at all.

Of the 6 multi-keyboard packages (ignoring fv_all) galaxie_greek_hebrew_mnemonic has 2 keyboards, each with 2 languages galaxie_greek_hebrew_positional has 2 keyboards, each with 2 languages syriac_aramaic has 3 keyboards, each with many languages

darcywong00 commented 4 years ago

More from discussing with @mcdurdin

Keyboard Packages with multiple keyboards:

For multiple keyboard packages, let's just display the language picker for the first keyboard (and use the default/first language for all the other keyboards).

In the future, we'll remove the "modern" languages from the galaxie_greek_hebrew keyboard packages.

PackageProcessor

It's fine to have redundant parsing of kmp.json (before install for UI choices, and again for installation)

Pass in a list of language ID's to use with the first keyboard in a package

SelectLanguageActivity

Hide the BCP 47 language codes and sort the language list by language names

mcdurdin commented 4 years ago

For multiple keyboard packages, let's just display the language picker for the first keyboard (and use the default/first language for all the other keyboards).

Sorry, I think I meant "for multiple keyboard packages, don't display the language picker at all, and just use the default/first language for all keyboards)"

darcywong00 commented 4 years ago

The title is a little messy and unclear. It needs to be larger, and be Install probably. See next points for layout.

Can I just keep the title to match the current string "Install Keyboard Package "? a. If the package contains a readme.htm, the displayed readame likely will have the name of the keyboard package in the title. b. If the package does not contain a readme.htm we already display a template that has the package name (see screen below):

generated readme

mcdurdin commented 4 years ago

Can I just keep the title to match the current string "Install Keyboard Package "?

How about just "Install Keyboard" (no need to say 'Package' as well here)

darcywong00 commented 4 years ago

How about just "Install Keyboard " (no need to say 'Package' as well here)

I didn't get the Markdown correct. There's a version at the end so it would be: "Install Keyboard <version>"

mcdurdin commented 4 years ago

"Install Keyboard "

"Install Keyboard (version <version>)" and I'm okay with that 💯

darcywong00 commented 4 years ago

As for the "back" button and "forward / next / install" UX

The Material Design spec used to have steppers but afaict it's an archived spec they haven't implemented. The closest component now seems to be bottom navigation but that doesn't exactly fit us either.

I think I'll just have a button bar at the bottom like below ("NEXT" interchangeable with "INSTALL") Screenshot_1597719297

mcdurdin commented 4 years ago

afaict it's an archived spec they haven't implemented.

Material Design is more a set of design principles and not always implementations. The following discussion is helpful: https://ux.stackexchange.com/a/130233

Implementing a Stepper design with a button bar is appropriate. Showing one, two, three dots at the bottom helps users to know how many steps they will encounter:

1 dot: package has one language, no welcome.htm. 2 dots: package has one language, has welcome.htm. 2 dots: package has multiple languages but no welcome.htm. 3 dots: package has multiple languages and welcome.htm.

When the welcome.htm page is shown, the back button is disabled but it should still be part of the same UI flow.

darcywong00 commented 4 years ago

Here's some screens for the 3 dot scenario.

readme

Screenshot_1598008904

select languages

Screenshot_1598008915

welcome

Screenshot_1598008925

I still need to implement handling scenarios with less dots, and checking the lexical-model package workflow...

mcdurdin commented 4 years ago

Looks good (although "COMPLETE" is not a standard button caption so might confuse users; probably just go with "OK")

darcywong00 commented 4 years ago

Fixed with #3498

keymanapp / keyman