On Wed, Jun 17, 2009 at 09:23:44AM -0400, Jeremy Katz wrote: > 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. Well, I'm not looking to introduce a new UI concept. This help could be something similar to the "What is this" message in some GUIs. So, if you leave the mouse over something long enough a clickable "What is this?" message will pop up. The user will choose to select it or not. Its not so intrusive and gives valuable info. IMO, something like this already stuck to users. We don't necessarily have to use the "What is this idea", we should, however, use something well known. > > > > > 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 > Yep. This is something that I imagined as I wrote the answer to your first response. But I still think that we could do a better job. I can see this being really nice for ppl with just one device. The list of partitions appears and you see it on this one bar on top of the screen. Additionally, the bar view does not take that much space from the whole view so you are left with a good chunk of screen for the tree view, which is more specific. But: 1. The bar view is basically useless when one is editing LVMs or RAIDs. 2. If you have a lot of drives (I have 5. Not that everyone is going to have 5 disks...) the bar view does not move with the tree selection. The bar drive gets selected, but if the bar drive is out of site, it will not automatically scroll down. 3. The bar view does not have LVM nor RAID, so that cool connection you are referring to is lost when the user uses them. Consider that we default to LVM, so we don't have cool connection on our default layout. With these point in mind, how about the following: Keep the bar view and the tree view, but only show the bar of the currently selected disk. The bar view would stay basically the same, it would be a list of all the devices. But with a few differences: 1. By default (Always, no matter how many devices the system has) show the bar view in such a way that it will only show one bar. I will still be scrollable and it will still have all the devices. But it will only show 1 device by default. Note that currently we make it bigger when there are more devices. 2. Each time the users selects a device in the tree, the scroll will automatically adjust to show the currently selected device. 3. The views would still be resizable, so if the user prefers he/she could make the bar view bigger. What would we gain? We are making the view that has most of the information (Tree view) bigger. There for providing more info to the user, while still maintaining the connection to the bar view. Note that we do this, mainly, by changing the default and adding functionality to the bar view. > > > > 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 :) heheheh My beef with the names is the amount of space they take in the description. I would be fine to just put this more to the right of the divice tree. Or at least after the size. Also, I'm still not convince with respect to the obviousness. I mean, yes the kernel lists (I assume you are referring to the lists) use "ext3" but thats not going to make a lot of difference to a newbie. Moreover, to a newbie "physical volume (LVM)" is not going to carry a lot of meaning either. "LVM" or "LVM-PV" aren't either. I think the important thing to ensure that the user relates the fact that he/she must have this thing (LVM-PV or physical volume LVM) to create his VG. And that if he/she does not have this descriptor there, he/she must create it. The string itself is unimportant. What is important is the relation made by the user. And the string length take too much space, so I would make it smaller. 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
