See inlined comments below, please. On Thu, 2012-07-12 at 14:48 -0400, Máirín Duffy wrote: > 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. Mentioning the geo-ip, I would like to remind everybody that we still have no server to query for the geo-ip data. At least I don't know about any. > > 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) Layouts won't be configured at this point. Obviously this is a "chicken egg dilemma". > - 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. I believe this check should go to pykickstart itself, not to kickstart.py > - 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 I will look at this part. > - 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! How important are these things for the Fedora 18? I believe they are somewhere at the bottom of the TODO list. Aren't they? -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
