On Wednesday, June 17 2009, Joel Granados said: > 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. The problem is this "help on mouse action" is going to be some anaconda-specific construct and people don't use anaconda often enough that a new UI concept is going to stick with them. > > > 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. But being able to see both is really useful for a lot of people -- you can select in the tree and see "where" it is visually. That connection is huge and although you don't use it, that doesn't mean that a lot of actual users don't. We actually sat down and watched relatively novice users at one point and it was one of hte things they were big fans of > > > 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? The kernel always refers to ext3 as ext3. And LVM is well known, but PV isn't unless you're intimately familiar with the tools. SW RAID might be, but if we were to change, the way to go there might just be "RAID". The discussion years ago was almost certainly just an in-person one -- the anaconda team was at most three people at that point and we all sat within a 50 foot radius :) Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
