On Tue, Jun 16, 2009 at 02:39:33PM -0400, Jeremy Katz wrote: > On Tuesday, June 16 2009, Joel Granados said: > > 1. Help dialogs: Have a mouse over help functionality for storage stuff > > in general. There are a lot of concepts that are in the installation > > that might need clarification. Nothing better for the user to have a > > way to find out some additional info. Could be a mouse over or a right > > click on labels (or something). I would like for it to be invisible > > unless the user does something (like move the mouse). > > We used to have help. One of the big problems with help is maintaining > it. None of us are documentation people and _helpful_ in-line > documentation is a bit of a black art. It's also then a fair bit of > work for translators. > > If you start to pare down to very short sentences or the like for help, > then I'm unsure exactly how helpful it is. You also have to be sure its > very obvious or the people that need the help aren't going to find it > > Basically, I'm not sold on having help available at all. Working to > make things as obvious as we can and adding more text where we need it > seems more likely to be more helpful These are all very valid points, but I wouldn't like to leave something undone just because its difficult. Yes, we are not doc writers and yes creating and maintaining this is hard but I think an incremental introduction of "mouse action" documentation can be achieved. Let me expand: We are not going to create documentation for everything, that would be overkill. We should instead create a general mechanism to handle the "help on mouse action" event and start using that mechanism for required help messages (Like the messages that we have when creating raid devices). After this mechanism is created we could add some other doc comments like explaining what the encryption checkbox does. But initially the raid message. > > > 5. Lets not repeat information. In the customization screen we have a > > tree view and a bar view. I vote for keeping both and giving the user a > > choice of how he wants to see the disks. With this we would need to > > create bars for raid and lvm, but I don't see this being very difficult > > as the information is already there. > > We have both now and give a choice basically -- you can adjust the pane > size. Giving a choice along the lines of > How do you want to partition? > [ ] View graphically > [ ] View as a table > feels like it doesn't add much and may even make things worse :/ Note that I meant a couple of radio buttons on top of the view. And when the user clicks on one of them, the view will change to what the user selected. It is not something you select prior to the custom partitioning screen. My argument here stems from the fact that the tree view is enough. I never use the bar view. I would understand ppl wanting to use look at the bar view, so thats why I would give the user a choice. With respect to the current split status of the screen. To me, someone that does not use the bar view, it (the bar view) is taking too much space in the screen. I know one can resize it, but its not obvious that its possible, and form my installs I just work with the handicap (scrolling up and down the tree view to work with my 5 plus devices) So, If we had similar functionality in the bar view and tree view, we could let the user switch between them at his preference. Note that the views are mostly to select and to give info, so I don't see this being too painful. > > > 6. On the bar view, implement a way of getting more information out of > > the bar. Maybe a mouse over could expose the format , the type, if its > > formatable or not.... > > The GTK+ tooltip API is definitely a lot more fully baked now than it > was when we wrote the UI views 8 years ago :-) Using them more is > certainly worth thinking about > > > 11. I believe that we should not have such big type names. > > Specifically: Physical Volume (LVM) and Software RAID. We can call them > > something different (like LVM-PV and SW-RAID) and have a mouse over > > functionality that actually explains stuff. > > I had this discussion/argument with msf years ago and was finally won > over by the fact that the full name written out like we have now is more > obvious I'll answer this with a question. How is "ext3" more obvious than "Third Extended Filesystem"? With this I want to show that the obviousness is quite relative. I grant you that ext3 is well known, but I would argue that LVM is also well known. With that said, I would like to read what was discussed to get a better feel of what you are talking about. Is it on a list somewhere? Can you point me to the right place? > > > 13. Currently, to create a VG, we need partitions formated as PV to be > > in the tree. We could easily (I use easily without really knowing what > > needs to be done :) use free space partitions as well. And > > create the PV format and relate it to the new VG behind the scenes. > > Not entirely following how you're envisioning the flow working here -- > would you be able to specify multiple at that point unformatted > partitions as part of the VG? If so, that could work and probably not > be too painful ACK! That is what I meant. > > > 15. There needs to be a relation between what is chosen in the view (bar > > view or tree view) and the actions. In such a way that when you choose > > a partition in the view and select "create VG", the VG screen will > > appear with all possible drives that could be used to create a VG with > > the ones that the user selected(in the view) selected(in the VG screen). > > This then presumes that we allow multi-select also (probably). One of > the other ideas that we had talked about years ago was more > context-sensitivity with the buttons. The UI people at that point > didn't like the idea much though This is something that would not be very high on my priority list. I posted it because I thought it to be helpful in the partitioning customization workflow. > > > 18. Have the possibility of using the LV screen without having to go > > through the VG screen. So when the user selects an LV and clicks on > > edit, the LV screen (only) pops up. Consider also putting some VG info > > on the LV screen so that that screen does not depend on the VG screen > > being in the background for context. > > Yeah, this has been on my hit list basically forever. We'd need to also > rework things a little as changing the LV can have effects on the VG. > Or could. right on. > > [snip] > > I also understand that this might not be enough information (me not > > being a great artist and all), so I promise to include glade files on my > > next mail :) Hopefully those glade files will contain all the input I > > receive from this mail. > > Feel free to rant, scream, suggest, add (constructively) on each point. > > So a number of these are good small tweaks that we could obviously > implement with relative ease and without rocking the boat too much. So > it might be worth doing them just for the little advantages. > > But I do think it's worth sitting down and really doing a good study of > the interactions that we expect / have users doing and really design our > interface accordingly. We don't have any interaction designers on the > team and certainly the ones we have available are in high demand, but I > think for more than some of the small tweaks, we should really take the > time to sit down and do so because my gut feeling is that there is quite > a bit more we could do. It'd end up being much larger changes, though > and so we almost certainly wouldn't have time to get it done for F12. > But starting the planning for them now might help us to actually have > the time to implement after F12. I strongly agree with this. All these points are from a developers perspective, mainly me, and they would increase their effectiveness with an interaction designer. Also, as I stated at the beginning of the mail, I really think that the UI is mostly functional, and would not like to do "major" changes to it. I'll keep posting my ideas and work. Hopefully with the glade examples I/we can get a better feel for the changes. Regards. -- 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
