On Mon, 2012-07-23 at 15:29 -0700, Jesse Keating wrote: > I spent today thinking through text installs in newui. While I believe > that text installs should have minimalistic configuration options, I > also believe that the little it has should follow the same sort of idea > as the hub/spoke design of newui. Another requirement of text mode is > that the same UI work across all text interfaces (real tty, serial, ssh, > s390 x3270 shell, etc...), targeting the lowest common platform. For > systems like s390x that means no curses, no fancy screen widgets, just > dumb text printed on a somewhat narrow screen with no scrolling capability. > > What I've done is a hacky mock up of how a text install would progress. > Some of these config options might go away (like lang/keymap since we > have good command line argument options for these). The idea is the > same as newui. A hub from which configuration can be done in any order, > but also with some items that are required to be completed. Of note, I > brought back the root password selection because with text mode you only > get @minimal, and thus no firstboot. We don't want people to have to > root their machines just to get a password set. This is pretty much the > cmdline UI slightly re-designed. > > You'll find a series of screen shots at > http://jkeating.fedorapeople.org/textui/ Walk through them as numbered > (yes I'm missing a 2-...). > > I have no idea yet if we can handle many choice screens like lang and > keyboard. Timezone data can be broken down much how tzselect does it. > > Feedback would be appreciated! This is cool stuff, thanks for sharing! == Text display == Not sure if this is helpful, but the only thing that occurs to me is that it's not instantly clear which configuration sections have been completed. The screenshots show a "[ ]". I understand that to be a textual representation of a checkbox, but it seems hidden on the line. My eye doesn't instantly draw to it. > 1) Language [ ] > 2) Keyboard Layout [ ] > 3) Date and Time [ ] > 4) Install Destination* [ ] > 5) Install Source [ ] > 6) Network Configuration [ ] > 7) Root Password* [ ] Perhaps if it was more in a table format? > Choice Configuration Completed? > 1 Language no > 2 Keyboard Layout no > 3 Date and Time no > 4 Install Destination no > 5 Install Source no > 6 Network Configuration no > 7 Root Password no == forced ordering (*) == The asterisk (*) denotes sections which need to be completed first. The text-based hub concept seems to compete with having a required order for steps. Should the (*) steps that have a discrete order not be included in the text hub? For example, should the user be prompted for those steps before presentation of the hub? Or should we have 2 hubs (Required configuration and Additional Configuration options)? == Keypress for (Q)uit and (C)ontinue == Having quit and continue as numbered selections seems odd. Would it make more sense to have the keypress for (q)uit be 'q', and (c)ontinue 'c'? This would keep documentation easier since the keypress would never change. Whereas, if the key for Quit is (9) in F18 ... it might be (8) or (10) in another release? Also, this aligns with my experience with other text-base tools (like yum [Y/n]). Hope that's helpful! Thanks, James
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
