FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 06-10-2011, 08:05 PM
Máirín Duffy
 
Default Anaconda UX redesign / status update

Hi Bill!

On Fri, 2011-06-10 at 18:30 +0000, Bill Nottingham wrote:
> > - Are there additional screens we'd need before we display the hub? (So
> > far in IRC we've come up with potentially adding a language selection
> > screen as the very first screen)
>
> Does 'language' here mean UI language + input language + keymap/keyboard, etc.?
> I.e., is this just moving the 'localization' screen before the main hub &
> spoke UI?

Today in IRC we talked through the following:

- Up front the first screen you'll see will just ask you what language
you'd like (default to English, but lets you pick other languages
written in their native name) The languages offered will be the
languages the Anaconda UI has translations for.

- The Anaconda UI will then load the corresponding translation so moving
forward the UI will be in the language you picked up-front.

- When you get to the hub, there will be two much smaller items in the
list than there are in the current mockup:

- One for picking language (just the language tab of the current
control center locale applet) - we provide this so you don't have to
reboot to change your mind about the language you want to install (I
think maybe it should determine both the language the Anaconda UI is
presented in, and the language that's installed if that language is
available for install)

- One for picking keyboard layout (the keyboard layout tab of the
current control center locale app) - and it'll default to the layout
that makes most sense for the selected language (how it does this is
voodoo to me atm)

I guess in actuality there are 3 language-y things to choose here:

A - What language is the Anaconda UI displayed in

B - What language do you want to be the default post-install?

C - What layout is your keyboard in for Anaconda UI and post-install
purposes?

And I think we are merging A & C to mean the same thing.
>
> > - What key features that happen pre-install do we need here?
> >
> > (so far, I think it's install vs upgrade, all the storage stuff.... and ?)
>
> Well, what is the purpose here? To only ask what's required for
> installation, and do all other configuration post-install? Would this other
> configuration be at firstboot/InitialSetup, or after installation but before
> rebooting?
>
> Given that an installation can take a reasonably large amount of time, many
> people like the idea of fire&forget - once you hit the 'Install' button, it
> does not ask for anything else until it's finished entirely and is usable.
> If we go down that road, then we would want more configuration done
> pre-install, even if it's not necessarily needed for install.

Well, there are certainly at least four ways to go here:

1 - Only ask stuff required for install pre-install. Fire & forgot, come
back after you've gone to the kitchen and had a snack, and fill out
firstboot. (Pretty much what happens today.)

2 - Only ask stuff required for install pre-install, while the install
progresses, ask the stuff needed post-install (this is apparently what
ubuntu does) Reboot and you're ready-to-go. If you're doing OEM
pre-loaded installs you put some flag in the KS so that firstboot will
start up and ask the questions that would have been asked during the
actual install progress.

3 - Ask everything pre-install. Fire & forget, come back and your
machine is done done. Same option for OEMs as in #2.

4 - Maybe a combo of 1 & 2 - you can skip the questions that pop up
during the install progress and opt to complete them later (in which
case you'll see firstboot) Same option for OEMs as in #2.

I think it's most important to figure out which pre-install stuff
(especially for special case scenarios) is essential to ask up front
that the mockups don't cover yet.

The other stuff - I'm not sure we've really made a solid decision on
what approach is best. I kind of like 4 best because I feel like neither
camp of user (I just want to be done in one go vs. I'd rather fire &
forget ASAP) would have an issue with it.

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-11-2011, 01:20 AM
Jon Masters
 
Default Anaconda UX redesign / status update

On Fri, 2011-06-10 at 14:06 -0400, Máirín Duffy wrote:

> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png
>
> The kind of feedback that would be helpful, looking at this mockup:
>
> - Do you think the hub & spoke model could work?

So the screen one would see first would be the one in the middle, and
one would click on the others to set options? I'm all for that.

Minor nit so far, the "What's your name?" screen talks about creating
"your account", but doesn't spell out that this is a login account on
the local computer, as opposed to some online cloudy thing or whatnot.

Jon.


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 01:47 PM
Radek Vykydal
 
Default Anaconda UX redesign / status update

On 06/10/2011 08:06 PM, Máirín Duffy wrote:

2 HIGH-LEVEL UI PLAN
====================

Secondly, the approach we're looking at is to swap Anaconda's current
wizard-style, linear screen-by-screen interface with a hub-and-spoke
model. (a lot of mobile devices have hub and spoke style settings
interfaces, more info on the model at [4]).

Here is the latest hub-and-spoke mockup - consider the storage portion
pretty much not started yet:

http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png

The kind of feedback that would be helpful, looking at this mockup:

- Do you think the hub& spoke model could work?


I like this approach and if we are able to go the way we want
- "First make all choices, then apply them" I think it can work
nice. Some notes regarding network configuration:


1) network in hub?

I'd consider adding network configuration to the hub - just a simple
status info that makes the configuration accessible from the hub. Note that
in http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/userflows-elad.svg
"Internet connection" should be linked also to "Install Destination"
or "Advanced Storage" (e.g. iSCSI).

Another option would be making network configuration spoke accessible
from spokes that may require it with a button/icon. Opening
network spoke based only on simple network status (up/down) and
action required (using netwok repo/network storage) as we do it now
is not sufficient because repositories and storage (or say kickstart) can be
served by different connections/devices. Plus, we see network as up
via NM also in case of wrong static configuration (e.g. bad nameserver).
There could be another configure network button in the action
failure dialog but it starts to seem too complicated compared to
just going back to hub and fixing network configuration there
(or adding a connection there prior to the action).


2) gnome-control-center network integration

I see three levels of network UI.
- simple status info (hub) - level of panel icon in Desktop
- status and control - level of gnome control center
(status, turn on/off, select access point, wifi authentication)
- device/connection configuration - level of nm-c-e called from g-c-c
This one seems to be pulled into g-c-c in the screenshots [1].

I am afraid we'll need to go with g-c-c as writing and maintaining
our own UI is not good. (Unlike with partitioning UI vs gparted.)

I was looking at possibility of integration of g-c-c into installer [2].
It would need to run as separate process (C app). I found some
UI issues, see: https://fedoraproject.org/wiki/Anaconda/Network#nmapplet
but it seems you are working on its UI redesign where they will be
addressed in thorough way. The one worrying me most is (5).


- Anything else you can think of, honestly.




3) askmethod

With stage 2 gone can't we dare to remove loader network
cofiguration TUI [3]?
- for ks, updates.img, ssh, gdb, dd let's require setting in boot
options or ks

- (ask)method is reduced to source selection in GUI, no?
(https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion#Add_askmethod_options_to_UI)

One note for
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion#Install_updates_by_default

Network status as condition of default seems rather random to me
(e.g. network can be set up just for storage).


4) hostname

What about host name setting? I think this could be easy, we just
need to find proper place for it. If all the actions/commits are done
post UI we don't have to bear in mind storage dependencies
(software raid and volume group default names based on hostname)


Radek

[1]
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Screenshots/new-gnome_network-panel_mockup.png
[2]
https://www.redhat.com/archives/anaconda-devel-list/2011-May/msg00152.html

[3] http://fedoraproject.org/wiki/Anaconda/Network#Loader_text_UI


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 01:47 PM
Radek Vykydal
 
Default Anaconda UX redesign / status update

On 06/10/2011 08:06 PM, Máirín Duffy wrote:

2 HIGH-LEVEL UI PLAN
====================

Secondly, the approach we're looking at is to swap Anaconda's current
wizard-style, linear screen-by-screen interface with a hub-and-spoke
model. (a lot of mobile devices have hub and spoke style settings
interfaces, more info on the model at [4]).

Here is the latest hub-and-spoke mockup - consider the storage portion
pretty much not started yet:

http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png

The kind of feedback that would be helpful, looking at this mockup:

- Do you think the hub& spoke model could work?


I like this approach and if we are able to go the way we want
- "First make all choices, then apply them" I think it can work
nice. Some notes regarding network configuration:


1) network in hub?

I'd consider adding network configuration to the hub - just a simple
status info that makes the configuration accessible from the hub. Note that
in http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/userflows-elad.svg
"Internet connection" should be linked also to "Install Destination"
or "Advanced Storage" (e.g. iSCSI).

Another option would be making network configuration spoke accessible
from spokes that may require it with a button/icon. Opening
network spoke based only on simple network status (up/down) and
action required (using netwok repo/network storage) as we do it now
is not sufficient because repositories and storage (or say kickstart) can be
served by different connections/devices. Plus, we see network as up
via NM also in case of wrong static configuration (e.g. bad nameserver).
There could be another configure network button in the action
failure dialog but it starts to seem too complicated compared to
just going back to hub and fixing network configuration there
(or adding a connection there prior to the action).


2) gnome-control-center network integration

I see three levels of network UI.
- simple status info (hub) - level of panel icon in Desktop
- status and control - level of gnome control center
(status, turn on/off, select access point, wifi authentication)
- device/connection configuration - level of nm-c-e called from g-c-c
This one seems to be pulled into g-c-c in the screenshots [1].

I am afraid we'll need to go with g-c-c as writing and maintaining
our own UI is not good. (Unlike with partitioning UI vs gparted.)

I was looking at possibility of integration of g-c-c into installer [2].
It would need to run as separate process (C app). I found some
UI issues, see: https://fedoraproject.org/wiki/Anaconda/Network#nmapplet
but it seems you are working on its UI redesign where they will be
addressed in thorough way. The one worrying me most is (5).


- Anything else you can think of, honestly.




3) askmethod

With stage 2 gone can't we dare to remove loader network
cofiguration TUI [3]?
- for ks, updates.img, ssh, gdb, dd let's require setting in boot
options or ks

- (ask)method is reduced to source selection in GUI, no?
(https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion#Add_askmethod_options_to_UI)

One note for
https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion#Install_updates_by_default

Network status as condition of default seems rather random to me
(e.g. network can be set up just for storage).


4) hostname

What about host name setting? I think this could be easy, we just
need to find proper place for it. If all the actions/commits are done
post UI we don't have to bear in mind storage dependencies
(software raid and volume group default names based on hostname)


Radek

[1]
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Screenshots/new-gnome_network-panel_mockup.png
[2]
https://www.redhat.com/archives/anaconda-devel-list/2011-May/msg00152.html

[3] http://fedoraproject.org/wiki/Anaconda/Network#Loader_text_UI


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 03:15 PM
Mike Khusid
 
Default Anaconda UX redesign / status update

On 06/10/2011 02:06 PM, Máirín Duffy wrote:


2 HIGH-LEVEL UI PLAN
====================

Secondly, the approach we're looking at is to swap Anaconda's current
wizard-style, linear screen-by-screen interface with a hub-and-spoke
model. (a lot of mobile devices have hub and spoke style settings
interfaces, more info on the model at [4]).

Here is the latest hub-and-spoke mockup - consider the storage portion
pretty much not started yet:

http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png

The kind of feedback that would be helpful, looking at this mockup:

- Do you think the hub& spoke model could work?

Does the hub & spoke model automatically double the number of clicks
(e.g. save changes/click to move to the next step)?


Mike


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 03:54 PM
John Reiser
 
Default Anaconda UX redesign / status update

On 06/13/2011 06:47 AM, Radek Vykydal wrote:
> On 06/10/2011 08:06 PM, Máirín Duffy wrote:

>> - Do you think the hub& spoke model could work?

> I like this approach and if we are able to go the way we want
> - "First make all choices, then apply them" I think it can work
> nice.

It seems to me that such an approach is equivalent to
"generate a kickstart file on-the-fly, then install
from the kickstart file". It would be nice to leave
that kickstart file as documentation somewhere in
the installed /root.

--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 04:01 PM
David Lehman
 
Default Anaconda UX redesign / status update

On Mon, 2011-06-13 at 11:15 -0400, Mike Khusid wrote:
> On 06/10/2011 02:06 PM, Máirín Duffy wrote:
> >
> > 2 HIGH-LEVEL UI PLAN
> > ====================
> >
> > Secondly, the approach we're looking at is to swap Anaconda's current
> > wizard-style, linear screen-by-screen interface with a hub-and-spoke
> > model. (a lot of mobile devices have hub and spoke style settings
> > interfaces, more info on the model at [4]).
> >
> > Here is the latest hub-and-spoke mockup - consider the storage portion
> > pretty much not started yet:
> >
> > http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png
> >
> > The kind of feedback that would be helpful, looking at this mockup:
> >
> > - Do you think the hub& spoke model could work?
> >
> Does the hub & spoke model automatically double the number of clicks
> (e.g. save changes/click to move to the next step)?

In many cases it will reduce the number of clicks since users don't have
to click through every screen if they are accepting the defaults. An
all-default install would only require specification of repos and name
as opposed to the current process of clicking through at least five (?)
screens.

Dave

>
> Mike
>
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 04:19 PM
James Laska
 
Default Anaconda UX redesign / status update

On Fri, 2011-06-10 at 14:06 -0400, Máirín Duffy wrote:
> Hi folks!
>
> We've been ramping back up on the UI redesign discussions for Anaconda
> that we'd originally had in Tempe back in January [1, 2] over the past
> 2-3 weeks so I wanted to:
>
> * Provide some status on how that's going so far
>
> * Introduce you to the designers involved
>
> * Outline a design approach for to continuing to move forward
>
> * Kindly ask for your feedback

Awesome! Thanks for organizing and creating mock-ups.

Just a general comment about the buttons used for different screens.
The main hub screen appropriately has a 'Quit' and 'Install' button. My
expectation was that only the hub would allow for 'Quit' and 'Install',
so that seems right on the money. The UI mock-ups for various detailed
configuration screen (aka spokes) also have 'Quit', 'Cancel' and
'Save/Apply' buttons.

Following the lead of the GNOME3 control-center design, would it make
more sense for the detailed configuration screens to only have a 'Back'
button? Any changes in those screens are activated immediately, there
is no need to 'Save' or 'Apply' changes.

Thoughts/concerns?

Thanks,
James
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 05:48 PM
David Cantrell
 
Default Anaconda UX redesign / status update

On 06/10/2011 02:06 PM, Máirín Duffy wrote:

Hi folks!

We've been ramping back up on the UI redesign discussions for Anaconda
that we'd originally had in Tempe back in January [1, 2] over the past
2-3 weeks so I wanted to:

* Provide some status on how that's going so far

* Introduce you to the designers involved

* Outline a design approach for to continuing to move forward

* Kindly ask for your feedback

It´s organized into smaller chunks hopefully for better readability:


1 IMPORTANT URLS
================

First, there are a couple of places the designers working on this are
going to be posting stuff:

- WIKI PAGE https://fedoraproject.org/wiki/Anaconda/UX_Redesign This is
the main UX redesign wiki page, which is a bit messy at the moment but
I'm hoping over time we'll get it in order.

- DESIGN REPO http://linuxgrrl.com/fedora-ux/Projects/Anaconda/ This is
a shared file space Joseph, Owen, and I are using to collaborate on
mockups (via Sparkleshare). Mockups will land here first, before we
use them to put together spec documents (like this one [3]) If you'd
like to use git to pull it down, you can clone:

git.fedoraproject.org/git/fedora-ux.git

(let me know if you want commit access. I'll need your FAS username.)

2 HIGH-LEVEL UI PLAN
====================

Secondly, the approach we're looking at is to swap Anaconda's current
wizard-style, linear screen-by-screen interface with a hub-and-spoke
model. (a lot of mobile devices have hub and spoke style settings
interfaces, more info on the model at [4]).

Here is the latest hub-and-spoke mockup - consider the storage portion
pretty much not started yet:

http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/hubandspoke-preview8.png

The kind of feedback that would be helpful, looking at this mockup:

- Do you think the hub& spoke model could work?


Looks reasonable to me.


- Are there additional screens we'd need before we display the hub? (So
far in IRC we've come up with potentially adding a language selection
screen as the very first screen)


One that may or may not come up is the ability for RHEL to display a
EULA screen at the beginning of installation. Right now this lives in
firstboot, which makes little since as you've already installed the
produce by then. I've been talking with legal on where we should move
this...possibly even just having RHN own the EULA acceptance screen
entirely, but I would like for us to have the ability integrated in to
our redesign.



- What key features that happen pre-install do we need here?

(so far, I think it's install vs upgrade, all the storage stuff.... and ?)

- Anything else you can think of, honestly.


One that Chris Lumens is most interested in removing is our current
package selection interface. Changing that to what we had been calling
a "spin selector" but is essentially just canned installations for
Desktop, Development, and so on.


Chris is currently on PTO, so I'll let him comment on that when he gets
back.


An idea that I thought would be interesting would be to allow people to
do either the spin selection thing -or- provide a kickstart file (via
the network, via a USB flash drive, etc) that we then use the %packages
section from. To me that seems like we could handle the cases where
people want the finegrained package control, but we've reduced the
installer to having as simple of an interface as possible while still
giving usable installed systems.


Another thing worth considering is a location screen over the time zone
screen. This was filed as an RFE initially and I moved it to the
anaconda feature planning wiki today:


https://fedoraproject.org/wiki/Anaconda/Features/LocationQuestion

Taking an approach similar to Ubuntu where we ask for the user's
location and then use that information to determine time zone, maybe
langauge, and maybe keyboard. Or at least the default values.



4 DESIGN PROCESS OUTLINE
========================

I´m serving as the lead designer of the project, with some help from
other Fedora design team members:

- Joseph Reni (gejoreni on IRC), who is putting together a user
research plan for both an informal study interviewing users and
a more formal one sitting in front of a system running through
an actual install.

- Owen Coutts (ocoutts on IRC) who is going to be working with me on the
mockups and developing user stories.

- Elad Alfassa (elad661 on IRC) who is a member of the websites team and a
Hebrew translator for Fedora; he´s been reviewing the mockups from a
localization POV as well as helping with the storage section.


Thank you all for working on this project!

--
David Cantrell <dcantrell@redhat.com>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 06-13-2011, 06:19 PM
Bill Nottingham
 
Default Anaconda UX redesign / status update

David Cantrell (dcantrell@redhat.com) said:
> >- What key features that happen pre-install do we need here?
> >
> > (so far, I think it's install vs upgrade, all the storage stuff.... and ?)
> >
> >- Anything else you can think of, honestly.
>
> One that Chris Lumens is most interested in removing is our current
> package selection interface. Changing that to what we had been
> calling a "spin selector" but is essentially just canned
> installations for Desktop, Development, and so on.
>
> Chris is currently on PTO, so I'll let him comment on that when he
> gets back.

Ideally, this would be designed in concert with any work for
post-install package selection (via gpk-app, etc.), so that we
have a consistent, coherent interface as much as possible.

(And if we do go down this road, essentially dropping one of the
larger functions of comps, we may need to revisit how the groups
are organized there.)

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 11:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org