[Date Prev][Date Next] [Thread Prev][Thread Next]
UI status braindump, part I
- From: Máirín Duffy <duffy fedoraproject org>
- To: anaconda-devel-list redhat com
- Cc: Mackenzie Colwell <mcolwell redhat com>
- Subject: UI status braindump, part I
- Date: Thu, 12 Jul 2012 14:48:02 -0400
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
#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
#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
#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
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
- 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 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
- 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
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
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!
[Date Prev][Date Next] [Thread Prev][Thread Next]