Anaconda/UX Redesign/Anaconda Language-Keyboard Design
These two images show two separates pages, one for language and other for keyboard. The current language selection of the installer does not allow to specify the language from the country i.e. only plain English instead of English US or English Canada. The keyboard selection . Another problem is the wasted space for both images.
- Wasted field space on both pages.
In this approach, we think about the different types of users who might encounter the dialog and offer those users who have any data to lose an easy way to avoid the entire reinitialization screen and its related stresses.
We only display the radio button dialog If one or more missing partition table drives are detected. If the user says the device is virtual or blank, we reinitialize it without asking. If the user says the drive had been used before or they weren't sure, we give them the scary reinitialization screen.
Some issues with this idea is that it's not very scalable - you have 100 drives you can't read, you get this radio button dialog for 100 drives. Ouch. We could potentially provide a list view of all unreadable drives, but right now anaconda pops them up as it goes. It may be possible to poll all the drives first, cache the data, and then present a list, though. It's simply not possible in anaconda right now. But with a list of multiple drives, the multiple choice selection won't work any more - each drive might be different. Um, so maybe not the best idea - or at least, this approach needs more work.
If you remove all the drives from the install to protect them you get the last dialog - we can't install if there's nowhere to install to. :)
This is a less-weighty approach to apply in the meantime, without a lot of underlying code change. Except, oops, it does require too many underlying code changes. Right now there's no caching of drive data, so the dialog pops up as anaconda scans drives and detects missing partition tables. So anaconda doesn't know, until it knows, that a drive is unreadable. So the multiple list view won't work here.
It's a better approach than the next one though, which is more compromising to the current state of anaconda's functionality. One thing to note here - if you have one drive that can't be read, you see the first screen. If you have more than one drive that can't be read, you see the second screen. So the mockups in this screen are either/or, they are not a sequence.
Text-massaging approach - simplest
This approach caused the least code churn so it's the one we'll go with in the meantime we figure out the larger problems here.
Note the button text has been changed - it says 'Yes, discard any data' and 'No, protect any data.' We say any data because there may not be any data at all. Saying 'discard data' makes it sound like there actually is data to be discarded. We say 'discard' rather than 'destroy' because it's a little less frightening of a word I think.
Rather than having four buttons along the bottom, we have two that apply to the single device in question. For our virt-installing friends, we have a checkbox that will enable the button to apply to any such devices.
So while we have a new layout and new language, the functionality is unchanged.
Where to go from here
My current latest idea to show the list of drives and ask the user if there is any data they care about on those drives, because we can't read them and will need to erase them to use them in install. Then give users the options to remove them from the install process / protect them one-by-one with the option to check off the drives they care about the data on. (or vice-versa, check off which drives they want to use for the install.)
We originally had mocked up the latter - showing all the drives we found and allowing users to check off the ones they wanted. This was removed at the last minute because of complaints that we ask for too much information about storage devices in the UI. I think part of the problem is because we only worked on the storage UI, not the entire anaconda ui, so there was some redundancy or at least the appearance of such. This time around hopefully we'll get this right since we're looking at the entire UI.
Here's some quick paper thumbnail sketches that were used to create the mockups above: