[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: First mock up of new text UI



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]