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