Ubiquity usability study

Sun Jul 1 22:12:54 UTC 2007

On Jun 29, 2007, at 5:16 AM, Colin Watson wrote:
> ...
> On Thu, Jun 28, 2007 at 08:05:45PM +1200, Matthew Paul Thomas wrote:
> ...
>> *   "Your new operating system" is comically vague. The installer
>>     knows very well that it's installing Kubuntu, not some other OS.
>>     (I do not think that reducing translation requirements for
>>     derivatives is a good excuse for vagueness in Ubuntu and Kubuntu
>>     themselves.)
> ...
> You're effectively proposing that we maintain a table of all the
> possible translations of all the strings mentioning Ubuntu for each
> derivative into all the languages we support.

No, I'm not proposing that; I don't think we should maintain a table of 
derivatives at all. Derivatives should have ultimate responsibility for 
their own translations, just as they have ultimate responsibility for 
their own everything-else. If they can reuse most of our translations, 
so much the better, but that shouldn't be to the detriment of Ubuntu 
itself.

> We do that for precisely two strings right now in packages I'm aware 
> of, on the CD bootloader screens, and I've already had complaints from 
> translators about that. We have multiple projects on the boil right 
> now involving improving support for more derivatives and reducing the 
> patchsets they need to carry. Translation efforts for more languages 
> are appearing, and most of the new ones are in language families that 
> historically have tended to transliterate the name of the operating 
> system. The problem is only going to get worse.
>
> I also do not think that we are entitled to disregard the needs of
> derivatives or of translators simply because it makes user interface
> design a little easier. User interface design is important to Ubuntu,
> but so is helping out derivatives, and so is localisation.
> ...

I understand that, it just seems that the balance is in the wrong place 
at the moment. When people consider using Linux-based operating 
systems, they often complain about awkward user interface. They do not 
complain about how few distributions there are. (Quite the reverse!)

> ...
>> But if there are more than about half a dozen keyboard layouts, and
>> you're not even showing what they look like, asking people to choose
>> "Which layout is most similar to your keyboard" is completely
>> unreasonable *regardless* of how the options are listed. (So this was 
>> a mistake on my part in the initial design.)
> ...
> I'd hazard a guess that the proliferation of options is confusing even
> if you think you already know what keyboard layout you're using: the
> fact that you can see all this choice means that you have to think 
> about it. Do you think it would help if the UI started out by just 
> displaying the default option for your language and country (the one 
> we already select by default) plus the text box, accompanied by a 
> "Change..." button?

I think that would be aggravating for those who did need to change 
their layout, because they'd see that we were making them open a 
separate window to change something when there was quite enough space 
to show those options in the main installer window.

Would it be feasible to use two option menus instead, with the picture 
of the selected layout underneath? In combination with putting the most 
likely options at the beginning of the menu, that might solve most of 
the problem.

(The layout picture in gnome-keyboard-properties has the problem that 
the keys are too small for easy reading. But perhaps defaulting to 
showing the right end of the main section, i.e. zoomed and scrolled 
such that the "8" key is near the top left corner of the visible area, 
would be enough for people to differentiate most layouts. That would 
show a few letters, plus most of the variable-layout punctuation.)

> ...
>>> 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.
>>
>> Defining the options would be a step forward, but it would be much
>> better if they were reworded instead. For example:
>
> This is roughly https://wiki.ubuntu.com/UbuntuExpress/PartitioningTool,
> the last major piece of the original design that never got implemented
> because it requires turning partman-auto upside-down and shaking it and
> I never found the time.
> ...

So it is. I think asking about operating systems first might be an 
improvement on my 2001 design, though, because it would mean fewer 
steps on average: if you wanted to specify partitions manually you 
could specify which disk(s) you wanted to use on the partitioning 
screen, rather than the disk selection being a separate earlier step.

> ...
>> Definitely. The table would still be necessary, both for accessibility
>> and to cater for alteration of those partitions that were too small to
>> see. However, the table probably wouldn't need a border, grid, or
>> headers any more, so in most cases it would look just like a legend 
>> for the diagram.
>
> This is definitely the sort of direction in which I intended to go with
> the new advanced partitioner but didn't quite make it for Feisty.

Would a more complete functional specification for a partitioner UI be 
helpful?

> Once that's done, LVM and RAID would be possible too ...
> ...

LVM would apparently solve the problem of requiring people to 
understand "/" and "swap". What reasons are there not to use it always? 
Would it make sense to at least use it by default?

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070702/63154402/attachment.sig>