[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: UI status braindump, part I
- From: Vratislav Podzimek <vpodzime redhat com>
- To: anaconda-devel-list redhat com
- Subject: Re: UI status braindump, part I
- Date: Fri, 13 Jul 2012 14:35:51 +0200
See inlined comments below, please.
On Thu, 2012-07-12 at 14:48 -0400, Máirín Duffy wrote:
> 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
> - 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
> 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
> 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 :)
> - 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
> - 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 :)
> - 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
> - 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.)
> - (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
> - 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
> - 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?
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
[Date Prev][Date Next] [Thread Prev][Thread Next]