Hey list.
Met with Mo at FUDCon and got lots of great ideas. This mail is intended to share some of these.
1. First of all she gave me a cool reference that can be used for general Human Interface design purposes. http://library.gnome.org/devel/hig-book/stable/. This is the most recent one I found, I believe its from 2008, if there is a more recent one, pls scream.
2. Help information. This refers to text that explains stuff that is not be trivial to understand. Instead of doing a help mechanism we could create a small explanation label, where needed, that goes under the concept that needs explaining. Much like http://library.gnome.org/misc/release-notes/2.26/figures/rnusers.brasero.png... or http://library.gnome.org/misc/release-notes/2.26/figures/rnusers.epiphany.pn... where the buttons have the name and the explanation in some other size and are slightly clear.
3. Have simplified device names. To have "sda" instead of "/dev/sda" and we would place the whole path "/dev/sda" as a small comment on the bottom of the device name. I'm guessing this would ease the user experience with dmraid type devices.
4. Use verbs for the actions. We have already been discussing this in the list.
5. Use Gig for the sizes. I had missed this in previous posts. But it be a good idea to have the size in Gb after 999 Mb. We can have a function that returns the show-able string.
6. Merge tree and bar view (This is my personal favorite, And I'll probably include it in a glade file in future posts. :). To have the bar information on the tree view. It would be on the far right and it would just have minimal information as most of it is contained in the tree view. I have to give Mo all the credit for this one :)
7. Put the type of installation (where we select "use entire drive", "Replace existing Linux system"...) in a separate window with additional comments on the options. This has two advantages, IMO, 1. We give the user more info so he/she can make an informed decision. 2. We don't show the encrypted check box when it is not needed (less confusion for the user). I still don't know exactly where to put the advanced configuration button in this case though.
8. Giving the user the possibility to select more than one device to shrink by using a checkbox instead of a drop down menu. Don't really know how much of a good idea this is, since I don't really know how that is coded, but its worth considering IMO.
9. The location of the action buttons would be better on the bottom left. This goes better with the look and feel of other gnome applications. So we would have the tree view, then the action buttons and then the "continue" & "Back" buttons.
10. We should pop up a window with all the "create" possibilities [1] for the customize partition "create" button. They would be handled with a comboboxe and would have a little explanation beneath the choice type. The user would select what he/she wants and a screan that creates the device would pop up.
Mo: If I am forgetting something, pls chime in.
Finally, considering that this will not be a complete re-write of the GUI for the storage section. I will probably start cleaning up the GUI files to get a better modularization and to easily move things around for the changes that we are planning.
As always, suggestions are very much appreciated.
[1] -> "LVM - physical volume", "LVM - Logical Volume" ....
On Mon, 2009-06-29 at 11:11 +0200, Joel Granados wrote:
Mo: If I am forgetting something, pls chime in.
So far this looks good, thanks for writing up your notes and sending them out! I left my notes at home, so I'll check tonight to see if I've got anything written down that isn't in this list.
I created a page on the design team wiki with these notes as well as the quick mockups we threw together at FUDcon:
https://fedoraproject.org/wiki/Design/AnacondaStorageUI
More mockups to come, but I wanted to make these available ASAP.
~m
Hi Joel,
On 06/29/2009 11:11 AM, Joel Granados wrote:
- Have simplified device names. To have "sda" instead of "/dev/sda"
and we would place the whole path "/dev/sda" as a small comment on the bottom of the device name. I'm guessing this would ease the user experience with dmraid type devices.
Simplified names are good. For disks of type DASD (yeah, I know, it's an s390 specific thing), it would be cool to (also) show the device number in the small comment. The numbers have a very short format, e.g. "0.1.beef". This way, the users would always know the mapping between I/O devices of the system and those of Linux for sure. In contrast to other platforms, this mapping on s390 is very dynamic and the user's choice, i.e. it depends on the order in which the user activates (sets online) DASDs (and not on the assembly of the hardware).
- Put the type of installation (where we select "use entire drive",
"Replace existing Linux system"...) in a separate window with additional comments on the options. This has two advantages, IMO, 1. We give the user more info so he/she can make an informed decision. 2. We don't show the encrypted check box when it is not needed (less confusion for the user). I still don't know exactly where to put the advanced configuration button in this case though.
Since the advanced configuration dynamically adds new disks to the system, I would have thought it should go before selecting the type of installation. It would be nice, if we could always go back there, in case the user forgot to add the right disk which might only be noticed when seeing the details in the tree view later on. Alternatively, the advanced configuration could be displayed in a dialog brought up by a corresponding additional button in the actions row at the bottom. That would even safe the user going back a few steps just to add another disk.
Steffen
Linux on System z Development
IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 29 Jun 2009, Joel Granados wrote:
- Use Gig for the sizes. I had missed this in previous posts. But it
be a good idea to have the size in Gb after 999 Mb. We can have a function that returns the show-able string.
I think something along the lines of what you get from 'ls -h' or 'df -h' would be better. We don't want to show GB for the /boot volume, for example. And some people may just really want to use MB.
Could we give users the option to select a display unit and perhaps by default do something similar to 'ls -h'/'df -h'. I like the two or three significant digits approach and scale the units as necessary:
99.0M 2.00G 0.96k
Everything else in your message sounds great.
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
On Tue, 2009-06-30 at 11:35 -1000, David Cantrell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 29 Jun 2009, Joel Granados wrote:
- Use Gig for the sizes. I had missed this in previous posts. But it
be a good idea to have the size in Gb after 999 Mb. We can have a function that returns the show-able string.
I think something along the lines of what you get from 'ls -h' or 'df -h' would be better. We don't want to show GB for the /boot volume, for example. And some people may just really want to use MB.
Could we give users the option to select a display unit and perhaps by default do something similar to 'ls -h'/'df -h'. I like the two or three significant digits approach and scale the units as necessary:
99.0M 2.00G 0.96k
I think having a preference for what units to display in the GUI is overkill [1]. The idea to display by default in the units that make most sense for the quantity involved is a great one though, and much better than displaying everything in GB.
~m
[1] Unless there is a Really Good Use Case for this, that would be helpful to 90% of users. I can't think of one, but I'm not as well-versed in this domain and the use cases for it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 30 Jun 2009, Máirín Duffy wrote:
On Tue, 2009-06-30 at 11:35 -1000, David Cantrell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 29 Jun 2009, Joel Granados wrote:
- Use Gig for the sizes. I had missed this in previous posts. But it
be a good idea to have the size in Gb after 999 Mb. We can have a function that returns the show-able string.
I think something along the lines of what you get from 'ls -h' or 'df -h' would be better. We don't want to show GB for the /boot volume, for example. And some people may just really want to use MB.
Could we give users the option to select a display unit and perhaps by default do something similar to 'ls -h'/'df -h'. I like the two or three significant digits approach and scale the units as necessary:
99.0M 2.00G 0.96kI think having a preference for what units to display in the GUI is overkill [1]. The idea to display by default in the units that make most sense for the quantity involved is a great one though, and much better than displaying everything in GB.
~m
[1] Unless there is a Really Good Use Case for this, that would be helpful to 90% of users. I can't think of one, but I'm not as well-versed in this domain and the use cases for it.
I can't think of a reason to expose this as a choice either even though I brought it up, though I'm sure that won't stop people from asking.
If we sanitize the units we display, that would be the best I think.
Oh, and I should have mentioned 'ls -lh', not 'ls -h'.
- -- David Cantrell dcantrell@redhat.com Red Hat / Honolulu, HI
On Tue, Jun 30, 2009 at 11:35:12AM -1000, David Cantrell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 29 Jun 2009, Joel Granados wrote:
- Use Gig for the sizes. I had missed this in previous posts. But it
be a good idea to have the size in Gb after 999 Mb. We can have a function that returns the show-able string.
I think something along the lines of what you get from 'ls -h' or 'df -h' would be better. We don't want to show GB for the /boot volume, for example. And some people may just really want to use MB.
Could we give users the option to select a display unit and perhaps by default do something similar to 'ls -h'/'df -h'. I like the two or three significant digits approach and scale the units as necessary:
+1 on the 3 significant digits!!
99.0M 2.00G 0.96kEverything else in your message sounds great.
- -- David Cantrell dcantrell@redhat.com
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpKhRAACgkQ5hsjjIy1VklbxQCfQDittCTuyYiNr8fcIH4/iPMz ow8An1xPO3twWe7JzlaMoglxq0WcqJjF =W335 -----END PGP SIGNATURE-----
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
anaconda-devel@lists.fedoraproject.org
-
David Cantrell -
Joel Granados -
Máirín Duffy -
Steffen Maier