Re: Glade files for anaconda UI (storage)

[Joel Granados <jgranado redhat com>]

On Mon, Jun 22, 2009 at 01:47:03PM +0200, Hans de Goede wrote:
>
>
> 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
>> user.
>>
>
> Good.
>
> <snip>
>
>>> 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:
>
> Create
> Destroy / delete
> Format
> Resize
> Properties (not a verb I know)

Edit properties
Modify properties
Modify
Adjust
Change
Edit (It does not sound so "hex editor" to me)
     (And we currently have it there, so users are used to it)


>
> 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.
>
> Regards,
>
> Hans
>
>
>>> Regards,
>>>
>>> Hans
>>>
>>>> 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
>> ...
>>>> Regards.
>>>>
>>>> [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.
>>>>
>>

-- 
Joel Andres Granados
Brno, Czech Republic, Red Hat.