On Tue, 2012-07-24 at 10:28 -0700, Jesse Keating wrote: > On 07/24/2012 07:38 AM, James Laska wrote: > > 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 > > I agree that the "checkbox" can get kind of lost in the flowed text. > The problem with trying to do any sort of structured table is that > translations will cause the text spacing to get all weird, and we're > working with some pretty constrained sizes, 80x25 (80 chars wide, 25 > lines on screen max) Yeah, that could be "fun" handling translations and string formatting. > > == 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)? > > I'm following the design of newui gui, which has a main hub that does > have some items that must be completed. > http://www.linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/02-preinstall-hub.png > > There are so few things to do with text mode that it seems overkill to > me to have multiple hubs. Agreed > The ordering of hub choices can change so that the required stuff is on > top, I didn't put any thought to ordering when I slapped together the > mockup. Gotcha > > == 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]). > > q and c might make sense in English, but not so much in other languages. > Do we translate that option to match the language? Perhaps use F12 to > continue, F11 for back, F5 to redraw the screen (might be very important > on x3270 when console refreshes cause half your displayed text to be lost) Great point on translations and using non-numeric keys. I hadn't considered that. Despite the x3270 conflict, I do like the existing text-mode support for F# keys. 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
