Re: Revisit "your name on the top bar"

[Joshua Wulf <jwulf redhat com>]

Good point. Design anti-patterns are often discovered when they result in documentation anti-patterns. 

If it doesn't have a clear name, it's often because it doesn't have a clear identity. 

+1 to inline pop-up definitions, if the system supports a single point of updating the term-definition mapping. 

- Josh

~ Kirtan is Life! ~
Sent from my iPhone.

On 07/07/2011, at 9:42 AM, Phil Bull <philbull gmail com> wrote:

> Hi guys,
> 
> On Tue, 2011-07-05 at 23:11 -0400, Joshua Wulf wrote:
>> Apart from the question of "what name to use", the "single point of
>> definition" pattern is good. One consistent name for an item, with a
>> link to the definition - then if the appearance or location of the
>> item changes, the definition only needs to be updated in one place,
>> and voila! the docs are still good. 
> 
> A couple of thoughts on this issue:
> 
> If it's so hard to reference this menu in a way that (a) is immediately
> intuitive and unambiguous to users and (b) isn't extremely cumbersome,
> perhaps that's telling us something about the design of the menu? Maybe
> the purpose of the menu itself isn't intuitive to users? It does group
> together at least three disparate types of activity at the moment, after
> all. (Remember the good old System menu, where we had settings, power
> actions and help all bundled together, seemingly at random?)
> 
> I agree that consistency in terminology is important, but deciding on
> terminology that doesn't really mean anything to users is lazy on our
> part. I believe that "User menu" and "Me menu" both fall into this
> category. Sure, it makes it easier to refer to something if it has a
> name, but picking an approximately meaningless name is crap.
> 
> If we choose some name and link to its definition everywhere, we will
> have help topics that *force* people to leave the help topic to be able
> to understand and complete the instructions, thus breaking their
> (already interrupted!) workflow. We also *force* them to learn something
> that isn't really relevant to why they're reading the help topic. In my
> opinion, good useful help avoids doing that - links are fine when they
> provide extra, optional information, but it should never be compulsory
> to follow them in order to complete the instructions. Help topics should
> be self-contained.
> 
> A possible counter-argument here is that the user will only have to
> follow the link once ever to understand what the term means. But I
> question whether that will actually be the case - people tend to use the
> help infrequently, and if the menu name isn't memorable (or intuitive!)
> then it's easy for them to forget. Also, following a link isn't a
> particularly onerous task, so it's hardly a major inconvenience. But I
> still think we can do better than that. It's the difference between
> providing "logically consistent and technically accurate" help and
> "awesome" help.
> 
> My suggestion would be to query the purpose of the menu with the
> designers, and to see if usability studies have said anything insightful
> about how users think about it. If that's not helpful, we continue to
> refer to it in the current long, wordy form or implement inline (popup)
> definitions.
> 
> Thanks,
> 
> Phil
>