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