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)
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.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
