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

Re: Glade files for anaconda UI (storage)

On 06/22/2009 01:38 PM, Joel Granados wrote:
On Mon, Jun 22, 2009 at 11:42:07AM +0200, Hans de Goede wrote:
Hi All,

On 06/19/2009 03:27 PM, Joel Granados wrote:
Hey list.

With the objective on continuing the discussion of UI in anaconda
storage, I have made some glade files.  Its actually one glad file (you
can find it here http://jgranado.fedorapeople.org/anaconda/ui/autopart.glade)
with three Window designs:
autopart: I hope you guys recognize this screen.  Its the initial
            storage screen.
CustomPartittioning{1,2} : These are the screens that are used when the
                             user wants to customize his/her storage
                             setup.  The difference is the action section
                             on the left.  (I personally prefer 2)

I've been waiting a bit with responding, hoping that others would do so
first. I don't want to criticize your hard work, and maybe it is just me

By all means, criticize!!! Thats the whole point of the mail/discussion.
To share points of view and end up whit a better experience for the



The second custom part mockup is better, but I wouldn't put the actions in a
tree construct, that still feels confusing to me. Just have 3 buttons:
New / Edit / Delete, and then have a dialog after that asking for more input
if needed.

Maybe we could also have other actions.  Take the "shrink partition"
action, for example.  One could place this in the "edit" screen.  So if
the user selects a partition that can be shrunk, the "shrink" button
would appear in the "edit" screen.  In this case, the user has to go through
one additional interaction (push the "edit" button) to get to the shrink
functionality.  Not to mention the fact that the user must know that the
shrink functionality is there, which is not obvious.
So to avoid an additional interaction and to be a little bit more
explicit, I would argue that some actions other than "edit", "create"
and "delete" should be placed in the left part of the screen.

Ok, so thinking about this more I agree edit is no good, maybe we need to start
with an old fashioned brian storm session, as said before I believe that
we need to think of actions as the starting point for what ever the user wants
to do and those actions usually are associated with verbs. So lets try to
to come up with a list of verbs associated with partitions, here is what
I came up with:

Destroy / delete
Properties (not a verb I know)

Note I left out edit, editing on a partition makes me think of
using a hex editor, which is not the sort of association we want.





Some comments:

--- The autopart screen ---

1. I would hold all detection of stuff that would otherwise take
anaconda too long to detect [1], until the autopart screen.  Where the
user can choose to go with the "local" detected storage or to use the
additional configuration  iscsi, zFCP ...

2. If the user has not used the advanced configuration (not activated

[1] : This would require actually defining what these system are.
        Some initial filters to be placed in udev or the kernel, to
        explicitly tell them to ignore these types of systems. And would
        also require the possibility of turning these things on and off
        whenever we want to.
[2] : In this case the Boot flag that is contained in the glade file is
        useless.  But we can put this flag in the next screen.  Note that
        this flag controls where the bootloader goes, not if the partition
        has the boot flag (which is sometimes useless)
[3] : Basically means whatever represents "real life" HW.  This
        definitely need discussion.
[4] : I personally like this one the most.  Its very similar to the
        concept we currently have.

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