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
not being able to see through the mockups what the end result will be.
But I must say I'm not all that big a fan of these mockups, esp the
custom partitioning screen 1 with the actions on the left looks confusing
to me, the grouping of actions by: "partition" , "raid", etc feels wrong.
To me an action is a verb, so something like "Create (or the alias New)",
"Edit", etc. And then one could get a choice what to create, for example
I can imagine the new button poping up a dialog with radio boxes where one
can select "partition, raidset, logical volume", instead of assuming the
user wants a new partition and having separate raid / lvm buttons as we
currently do. But I really do think that the first choice the user should
make is what "action" do I want to do, Create some new place to install, edit
an existing (grayed out until an existing something is selected), delete an
existing something, etc.
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.
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
any "advanced storage") the refresh will not do a devicetree.py:scan.
It will look into the information provided by the kernel /sys/block
(maybe) and refresh the view. So if the user inserts a USB during this
step, it will probably need to show up in the disk list. The user may
also want to filter this list, so the filter should be usable in these
cases.
3. Since we are (hopefully) running devicetree.py:scan after this
screen [2], the disks that appear in the list are going to be the "base
devices" [3]. This would mean that the dmraid stuff will not appear
there, which it currently does. But I don't think this is a big deal as
VG and LV do not appear there either.
4. I don't know where to put the encrypt checkbox. I really don't like
it in the outside window as it is not valid for all the configurations.
Custom, for example ignores this checkbox. I could (maybe) placed in
Additional configuration, but then it would be quite hidden, something that
I would want to avoid.
5. iscsi, zfcp and all the additional configuration elements would
change the setup for refresh. So if you activate iscsi and then hit
refresh, it should try to activate iscsi and search iscsi devices and
filter them according to whatever was defined in filtering.
6. I vote fo also ignoring the devices that the user unchecks in this
screen. This would mean that the list would have to be considered with
the custom button as well. So when the custom screen pops up, it will
only show the selecte disks.
--- General Custom Partitioning ---
1. Have a split screen setup where we put the actions in the left and
the views on the right.
2. Have two possible ways of seeing the devices: a. a tree view and a
bar view.
3. The tree view will have a big tree view that will take most of the
space of the right section. It will also have a one bar view that will
show the currently selected device.
4. The bar view will show all the storage devices as bars.
5. One can flip the views with a tab or some radiobuttons. The
important thing being that one can change the way of viewing the
devices.
6. The bar views will include raid and lvm devices.
7. The bar views can have some additional info wehn the users puts the
mouse over the bars. Invormation like format type and if its going to
be formated or not, can appear in the tooltip.
8. The tree view and the bar view would be creatly enhanced if one could
right click on a device and the installer would give the possible
actions one might want to perform.
--- Custome partitioning1 ---
1. Here the actions are separated by type of storage and each tupe has the
three main actions: create, edit, delete.
2. Raid will have create raid device, and create raid partition. This
might be confusing and might be a good place to put some help info.
3. LVM will also have create VG and create lvm partition, which means
physical volume. This also might need some additional help.
--- Custome partitionin2 ---
1. Here the actions are separated by action type rather than by device
type. So all the create are grouped into the first section. And the
modifiers (edit and delete) are grouped into the other group [4].
--- end ---
This are some ideas that have been going through my mind. As with my
previous post, I would like anybody interested to comment and criticize
these points.
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
