On Tue, Jun 16, 2009 at 08:43:28PM +0200, Hans de Goede wrote: > Hi, > > All in all I like your ideas, but if we stuck with the current UI, > then I'm against showing only the BAR or only the tree, both > have different functions IMHO, one is a pie chart view of things, > where the other one is a table view. The pie chart view gives > a much better idea of how much space each "partition" uses, where > as the table view is much better in showing other information > (like how the partition will be used / formatted, etc). They are different ways of giving information. The same information. You are correct in stating that the bar view does not give format or mountpoint, but this could be solved with some right click functionality or some mouse over. In such a way that when the user interacts with the device, the UI will pop up a little window giving extra info of the device. Additionally both views are used for selecting. This is similar in both of them. In the sense that one just clicks on the devices that needs to be edited or deleted. Regards. > > Regards, > > Hans > > > On 06/16/2009 07:37 PM, Joel Granados wrote: >> Hey list. >> >> Been analyzing the UI partitioning stuff and here is an initial mail to >> get the discussion rolling. Before anything I'd like to state that IMO >> the UI (in general) does not need a rewrite. What I think should be >> done is make the UI better using the current state of the code. I also >> know that describing this in a mail could lead to confusion, so I >> promise some glade code in my next post. >> Ok, here goes: >> >> 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). >> >> 2. As stated before, my vote is for putting all the partitioning code >> together. (since most of the bugs come after partitioning anyways. >> Package installation, bootloader, grub installation). This will also >> solve the updates problem with isci and zfcp. >> >> 3. Gladeafy everything that is gladeafiable. >> >> 4. Try to separate the logic from the drawing whenever possible. I had >> already started this some time back. It make the code more >> understandable and less prone to mistakes. >> >> 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. >> >> 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.... >> >> 7. Change the way we separate the actions from the information. ATM we >> have the actions between the bar view and the tree view. Thats OK, but >> IMO it could be much better to have an action bar in the left of the >> screen with a list of actions (more on this on another point). And have >> one way of looking at the disks at the right of the screen. The right >> part of the screen will be bigger of course. And will have all the space >> to put the disks and partitions and crap. (remember, the user can >> choose tree view or bar view) so imagine one big view. >> >> 8. The left view, AKA, action view, should be separated by storage >> types. So there will be actions for LVM, for partitions for raid VG for >> raid LV. We can even have a misc group to put stuff like Shrink current >> system. One would be able to expose or hide each group. So when the >> user enters all the groups will be hidden. Only the group name will be >> visible and the actions will be hidden. When the user hits the group >> name, the group actions show. We can have the partition group visible >> by default. >> >> 9. Maybe (just thinking out loud here). Have a feature that enables the >> user to access each action (the same ones from the left), from a right >> click in the information view (tree view or bar view). In such a way >> that when the user right clicks some device in the bar view, the possible >> actions he/she can do with that device appear in a list. >> >> 10. Be helpful. There are situations where we could be a little >> more helpful with the user (when the user make a mistake). Say for >> example he pushes the RAID button and has not configured any raid >> devices. Instead of just telling the user he is wrong and returning to >> the main screen, we could offer some partitions that he might use to >> create the raid device. In general, if the current work flow is not >> possible, try suggesting alternatives that are related. >> >> 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. >> >> 12: I think the tree view should be organized as follows: >> Device - Size - mountpoint - type - format. The idea behind this is to >> order them by diversity. The ones that are more diverse are placed >> closer to the name of the device. So you can relate size and device in >> a better way. The format being the less divers of the group >> (true/false). >> >> 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. >> >> 14. Same goes for Raid devices. We could offer to create a raid device >> on top of free space partitions and partitions that have the raid >> format. >> >> 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). >> >> 16. We can go a little further than 15 and provide a feature that lets >> the user select various devices in the view (bar view or tree view) and >> have the same effect when an action is selected. Furthermore if the >> user selects an action that only needs one device, then we will select >> the last selected device. And if no devices are selected and the user >> selects an action, then we should pop up the actions screen with a list >> of all devices that are modifiable where each is unselected. >> >> 17. Put all the nice RAID explanation in a help dialog. Mouse over or >> right click. >> >> Note: I like the LVM dialog setup :) >> >> 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. >> >> 19. Don't use an intermediate step to create raid devices. Put all that >> functionality in the action section of the main screen. >> >> These 19 points contain the brain dump of what I have seen from my tests >> with rawhide since yesterday. I have more ideas. Mainly concerning the >> first screen (before customization), the list of devices (discussed in a >> previous mail), the filtering mechanism, and a way to control the >> scanning of devices. But I don't have them clear yet. >> I do, however, have some sketches I did on a note book that I have >> scanned and uploaded to my fedorapeople page for your viewing. Most of >> the written stuff I have included in this mail. I posted them because >> they contain the UI sketches that I did for the screens (Sorry, I'm not >> much of an artist) >> http://jgranado.fedorapeople.org/anaconda/randomThoughtsUIpartitioning.pdf >> >> 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. >> Also add stuff that I have missed and give your point of view. >> >> 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
