What's the best way to describe what an option does in a program?
I'm working on some guidelines for localization of a computer program. We recently added descriptions to most of the settings, and most of the labels are user contributed and in many cases awful.
Example, we have a Settings menu with a "Saving" submenu This Saving submenu has settings that affect how user-data is saved, for example sorting user data in folders, save data automatically, etc.
The descrption for "Saving" reads:
Change settings for the saving.
Which is horrible in my opinion. I'd like to establish some general localization guidelines for our project so I'd like some feedback on what these guidelines should look like.
I would change that into:
Change settings related to save operations
But it might sound too technical and it doesn't really describe anything. Maybe a better idea would be:
Change settings related to save operations like folder organization, auto-save intervals, etc.
I think using an adequate tense and voice would be a great start for us.
Any help would be appreciated.
Edit: I thought I should add a picture to describe the problem better
This post was sourced from https://writers.stackexchange.com/q/26514. It is licensed under CC BY-SA 3.0.
1 answer
There is actually not a lot of point in describing what an option does, per se. What you should really focus on in both technical communication and interface design is what do you enable to user to do.
The goal is to enable the user to react correctly. So the first question is, given you user base, do any of these descriptions do anything to help the user act correctly that the label "Saving" does not already do.
I'm pretty sure the answer to that question is no for the examples given. By the time the user has worked out that they need to be in the setting menu, they probably understand what "Saving" means.
For some users, you may need to tell them how to organize their work in folders, etc. But that probably does not belong in a description of the setting menu because it is probably aimed at people who don't intuitively think, "I bet I can adjust the default save location in the setting menu!" Unless something thinks that way, they are not going to find that information in a description of the setting menu (except maybe by using search, if they happen to pick the right terms).
The other question to ask about documenting this setting per se is, are there things that a user who has got this far may not be able to do without more information? If there are, then that might be the stuff to document here.
Whatever the answer to these questions, though, documentation that does not add anything to what the UI is already saying (for the anticipated audience) is pretty pointless. UI design is a form of technical communication. Unfortunately, there is far too much documentation out there that simply repeats what the UI is saying. It covers everything you could learn from the UI without its help, and nothing you could not.
EDIT: In other words, there is on one right way to describe what a option does. The right way is to tell users what they need to know in order to act correctly and that will depend on many factors: who the reader is, what they are trying to accomplish, how complex or obscure the option is, and how effective the UI is.
The key question is always, what is the user trying to do, and what to they need to know (that they don't already know, and can't tell from the UI) in order to get that done.
0 comment threads
0 comment threads