Ubiquity usability study

[Evan Dandrea]

Celeste was kind enough to do a usability study of Ubiquity, and in
doing so pointed out a number of issues that should be resolved.  I have
the following thoughts on how the installer can be improved to fix these
and other issues, but I am interested in getting input from other
developers, especially ones with a background in usability.

The report has plenty of shots of the offending parts of the interface,
should you forget what they look like.

On Tue, Jun 12, 2007 at 09:20:07AM -0400, Celeste Lyn Paul wrote:
>
> Hi Matt, Colin, and Jonathan -
>
> Sorry about the delay, but I have finished compiling results from the
> usability test I conducted of the Kubuntu version of Ubiquity:
>
> http://obso1337.org/hci/kde/Kubuntu_Installation_Usability_testing_June_2007.pdf
>
> Comments and questions are welcome.  Some of the more major issues
> (such as partitioning) will take some discussion and thinking about
> before we can resolve it.  I have also written a blog entry as a place
> for public comment:
>
> http://weblog.obso1337.org/2007/results-from-kubuntu-install-usability-testing/


> If the number of users who download the Live CD with the primary goal
> of installing are the primary user group, it is recommended a welcome
> dialog appears when the system is fully loaded to prompt users to
> install or explore the system.

I think the welcome dialog would be a good idea.  Perhaps we could
include text in it that lets the user know that unless they click
install, they will not modify their existing system, but any changes
they make to their Ubuntu desktop will be lost on reboot.

> This difference in usage between "disk" and "drive" should be
> investigated to see if there is a common difference which may cause
> confusion as seen in usability testing.

> Consider changing the phrase from "This will destroy data..." to "Data
> on partitions you remove is irrecoverable.." or something similar

I think these are both reasonable changes.

> It is recommended that future versions of the Time Zone Picker
> interface always include the drop­down menu.  Alternately, separating
> the timezones by a line and allowing the user to click within that
> time zone rather than on the small city dot may improve interaction on
> the map.

The timezone changes seem to be what we're already planning on doing in
the UbiquityForumIdeas specification.  This is partially blocked on
finding a free source of time zone boundary data.

> To help reduce confusion of a large number of options, consider adding
> an indication of the "most common" or "safest" options, in addition to
> making them default.

I'm not sure how we could convey the "most common" options.  I'd suggest
possibly rewording "US English" to "Standard US English" to make it
stand out more.

> Try to provide some sense of time in minutes, percent completed, or
> packages installed.

Putting in a countdown seems reasonable.  Packages installed doesn't
work as the installer is copying files, not packages.

> Be more clear on what action users should take after installation is
> complete. Break up large chunks of text so users can more easily scan
> directions and information.

Perhaps it's just been from using the GTK UI all the time, but I found
the absence of "continue using the CD or restart" buttons on the dialog
a bit confusing, so I would definitely like to make this change.

> A simple, but not as effective, solution would to provide an
> introduction or explanation of partitions to help educate users.  This
> will still be difficult for newer users, however, preserve control for
> advanced users.
> A more complicated, but much better usability­wise, solution would to
> obscure the concept of a partition so uses do not have to have
> knowledge of them. This is excellent for users who are newer and have
> no concept of a partition, but destroys the model used by advanced
> users.


Obviously this is where we fall on our face, though great work is
already being done to fix this.  The advanced partitioner that landed in
Feisty was a first cut and we plan to add blocks to represent the
partitions (already done in the KDE UI), much like what gparted does.
It's worth noting that the InstallationFromWindows specification keeps
users away from the concept of partitions by installing Ubuntu into a
file in Windows.

> By making the safest option the default option, the risk to
> accidentally destroy information on another partition could be
> reduced.  If the safest option cannot be identified, we would suggest
> to provide no default option and force the user to examine the options
> and make a choice.  Dual booting also seems to be the most likely case
> for less technical users, and so the Manual option would be the best
> default.

On the first point, I agree with Celeste that making a complete reformat
the default option when resizing is not available is scary.  However,
I'm hesitant to send users into the advanced partitioner unless they
really want to go that route, so I'd say we should go with no default
option.

Perhaps we should add a note next to the resizing and use free space
option about it allowing you to keep your existing operating system?  In
the absence of the resize option we could let the user know that it
wasn't possible, but that they can always reboot into their other
operating system and delete files and defragment to make more room.

> An alternative would be consider changing Guided to "Automatically
> partition the entire disk".. and Manual to "Configure partitions
> manually".

I also agree "automatically partition the disk" is clearer than
"guided".

Building on Celeste's ideas, I think we should have the first page of
the partitioner include the existing radio buttons and titles for each
option, but also a long description below each option that explains what
it does.

> Move the action buttons so they are in closer context to what they act
> on.  Do not change elements in the interface, but disable elements
> which are not available.  A toolbar, rather than buttons, may also be
> a design option.

> Run code after an interaction is complete.  Consider alternatives to
> the popup status dialog, such as running the code in the background
> and hiding it (if interaction in the interface can continue) or an
> embedded interface status bar.

> Consider providing tool tips or easy to access documentation to help
> educate users on these terms.  An alternative and more extreme change
> would be to make the technical requirements transparent and provide an
> interface which allows them to configure these options without needing
> to know the terminology.

> Providing documentation or directions on what to do with swap and
> root, or making these technical requirements transparent would
> alleviate the high learning curve necessary for completing this task.

As far as the design of the advanced partitioner goes, perhaps we should
make a row of buttons for editing and deleting under, or alongside each
partition?  I'm not sure if that's what Celeste is suggesting.

I agree that the interface should active or deactivate buttons rather
than show or hide them.

I'm really not sure how we can simplify the concepts of root, swap, and
filesystem type.


One thing that wasn't discussed in depth, but I've heard complaints
about and we might as well tackle while we're redoing other parts of the
interface, is the resize slider.

The resize option is probably the most common use case, but the current
slider is a bit confusing.  I seem to recall a bug report that Colin
replied to about fixing this, but I don't know the number offhand and
I'm sure he can speak of his thoughts on the matter much better than I
can paraphrase from memory.

Still, ideally I'd like to see something that gives you a better visual
representation of what's going on, such as two boxes with their size and
percentage of the disk that they occupy labeled on them (perhaps even
including an icon of the operating system present).  The interface would
then allow you to resize from the point where they touch, updating the
size of both as you drag.



What are your thoughts on these ideas?  Do these changes sound
reasonable and appear to address the usability issues presented, or do
you think we should go in a different direction than what I'm
suggesting?

Thanks,
Evan