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 _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
