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. > not being able to see through the mockups what the end result will be. Any specific question with respect to the glade way of showing this. Note IANAGE (I Am Not A Glade Expert) :) > > 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. Ack. This was my first draft. And I totally agree with you that it feels wrong. This was the main reason why I did the second one. > > 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. This is totally valid. I had actually thought about this approach as well, but chose the one I posted because I wanted to avoid further user interaction. With "delete" and "edit" things are quite simple because we expect the user to choose what he/she wants to modify. But with "create" we need to know what type of storage the user wants to create and we cant get that off the storage view. And, thinking of avoiding an extra step (the one you described), I chose to explicitly put those create actions in the left. > > 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. > > 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. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
