Hi! CC'ed are Ryan Lerch (new Fedora UX designer who just relocated to Westford from Brisbane) and Mackenzie Colwell (whom you've likely already met as pseudomonas in IRC, she's my UX summer intern.) We met with Chris this morning (and will meet further later this afternoon) to hash out the current status of the UI design. Here's a rundown of what we covered this morning; I'll follow up with a part II for what we cover this afternoon. #1) KICKSTART DETECTION ======================== So we've had this idea that if you have a USB key with a .ks file on it when the Anaconda UI is started, we would auto-detect it and offer to pre-fill in all the UI fields (and add post scripts and whatever else into the fray) for the install. Mackenzie worked up some mockups (yet to be posted) showing how this might look and feel. Some notes: - If we make this feature infinitely flexible now, it's going to be very hard to whittle it down later because people may come to rely on different aspects of it. So we discussed limiting the scope of the feature initially and expanding eventually based on user feedback. - We talked about only auto-detecting ks files that are: - in the root directory of a USB key - in the root directory of the install media - We made the assumption that a user is highly unlikely to have more than 0-10 ks files auto-detected, and the UI mockups are designed accordingly. - We talked about a feature (that could be delayed release-by-release depending on time / resources available to implement) to allow users to pull in only certain named sections of a KS file. So, we auto-detect the KS file and that it has a %packages and a %post. You could dive in an select to only pull in the %packages section with checkbox, and uncheck the %post to not have it apply to your install at all. - If the stanza-by-stanza pick and choose for KS feature isn't implemented, we default to all or nothing when we auto-detect ks files: you either have all parts of the KS applied to your install or none. - For picking and choosing sections of a ks file, we determined that we should have all sections included by default, and allow the user to 'opt-out' of particular sections. (rather than vice-versa where they would start with none and have to opt-in one-by-one.) - We talked about how opting in to the %package section of the ks file might be a good part of the story for folks concerned that we have dropped individual package selection from the UI. - A kickstart file with just one section will pass validation. Old style kickstarts default to asking for any information not provided in the KS. In the new anaconda UI, we will pre-fill in the defaults for any fields the KS did not provide, and if any section is not provided we will put the user on the 1st hub rather than the 2nd hub. (Not sure if we should push users to the 2nd hub if every required KS option is filled out in the KS file sucked in.) - For picking and choosing KS files, we need a way to view each section so you know what you're signing up for (or know what you're avoiding by unchecking it.) #2) CHOOSE DISKS BEFORE HUB #1 ============================== http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png I know we came up with the "Choose Disks" flow in there to limit the number of disks selectable later on in the UI to 10 or less because of a discussion we had in Westford some months back. I don't remember all the particulars (eek) so I wonder if we still need it? If so we need to mock it up. #3) LOCAL MEDIA PREUPGRADE ========================== We want to choose preupgrade as the one true / supported upgrade path. However! This is problematic for folks with crappy, expensive, or no internet connections. Can we investigate whether it would be possible to offer up a 'preupgrade from DVD media' option? What if the DVD media was live, possible? #4) KEYBOARD LAYOUT IN LANG SELECTION SCREEN #1 =============================================== So, it's been pointed out that while we allow users to select the language the Anaconda UI is displayed in on the very first screen, we don't allow them to select a keyboard layout. This is problematic because we have a network dialog after that, and if they cannot type their AP password or input their network information using the default layout for their chosen language, they can't benefit from any of the geo-ip and network features (like pre-downloading repo metadata) the new UI offers. Ryan has been looking at integrating keyboard layout selection into this screen. As we discussed this a number of issues came up: - We likely won't have geo-ip data for this first screen so it would be really difficult to filter based on geo relevancy, but we can do this on the language screen off of hub #1. - A user may select one language for the display and another language for input. An example of this is an American consultant stationed on-site at a Japanese business, where the AP password is in Japanese but the American (speaking English natively) would prefer to read the Anaconda UI in English.) - Because of the above point, we should display layouts relevant to the selected language first on screen #1, but also allow the option to add any other layout outside of that language. (with type-ahead) - Will ibus work in Anaconda? If not, CJKVI (Chinese, Japanese, Korean, Vietnamese, Indic, maybe others'?) languages' input won't be possible in Anaconda. (We have had a specific user requests to support Japanese input in anaconda so it is needed / useful.) - For ibus languages, we need to indicate what the key combo is to select between 'sublayouts' (eg. for Japanese, switching between Romaji / Hiragana / Katakana.) #5 UP-FRONT NETWORK AUTO-DETECTION ================================== We had a worrisome and complicated discussion of how to handle auto-detected / auto-connected network support (before hub #1) until Ryan essentially pointed out that NetworkManager has a workable recipe for auto-connecting to a network and we should probably just use whatever scheme NM uses :) Diagram: http://www.flickr.com/photos/mairin/7557284668/in/photostream - If you have a wired connection (that can access the internet not just a local network), you don't see any network config screen before hitting hub #1. - If you have a wireless connection, we pop up a 'simple dialog' (to be mocked up by Ryan) where you pick an access point and input the password (if necessary) - If you have a more complicated connection, you can visit the full blown network dialog (before hub #1) by clicking on a 'Network Settings' button in the 'simple dialog' Some use cases we talked through: - You're at a friends house. They have a MAC filter or password. - You're at the office. All the visible APs are password-protected (maybe using RSA tokens or certs) - You're at a hotel / airport / conference show floor and the network has a captive auth system. You are only connected to a local network then, and not connected to the full internet. - Fake 'Free Public Wifi' connection that has no internet uplink. - You need to connect to a phone's network connection via wired (USB) or wireless tether. - You're at a coffeeshop and the AP is completely open, but you'd rather connect to another AP. If you switch APs, the yum repo metadata download will have to be restarted. Other points - - We could detect whether or not APs were connected to the wider internet or not. TO-DOs for people :) Mackenzie ========= - update the ks auto-detect mockups to allow users to view each stanza of the ks on the same screen where they can check / uncheck stanza-by-stanza - update the ks auto-detect mockups to drop the 'choose sections' button. instead of having a separate 'choose sections' screen, integrate the choose sections widgets into the main dialog using a disclosure widget (example: http://xkahn.zoned.net/blog/wp-content/uploads/2007/02/evolution-compose-text.png the 'Show Attachment Bar' in the bottom left of this SS uses a disclosure widget - also called GtkExpander - but in GTK3 they look like little [+] symbols instead of a triangle.) Ryan ==== - (deferred until complete set available) talk to Brisbane docs contents about an audit of the language used in the UI strings to make sure it's internally consistent and consistent with RH style - Update screen #1 mockups to include keyboard layout selection - On keyboard layout screen, for CJKVI languages, provide the key combo for switching between 'sub layouts' (katakana vs hiragana vs romaji in Japanese for example) - Talk to Brisbane contacts about state of ibus and whether or not any alternative input systems are under consideration or if any pending new ibus features are coming up so we're aware - Mock up 'simple dialog' for network connections Mo == - I need to talk to dlehman about the 'choose disks' box we have in the flow chart and whether or not it's still necessary (eg http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png ) Chris & other Anaconda riders ============================= - Search the install media and any USB media attached to the system for ks files, only in the root directory. - Modify kickstart.py as necessary so that it can determine whether or not a given file passed to it actually is a ks file. - If a ks file is loaded in by a user, always take them to hub #1 by default, even if you have sufficient info to start the install. - (low priority) Investigate what it would take to list what ks stanzas / sections are present in a ks file and optionally, section-by-section, turn them on or off. - (dependent on last item above) When pulling in a user-selected ks file, set all ks sections to ON by default. - Investigate preupgrade off of local media feasibility - Investigate ibus in anaconda feasibility - Change code around popping up network dialog before hub #1 to match rules described in section #5 above. Okay more later hopefully :) Any questions etc please reply to list! ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
