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