Just reading the help file for a particular piece of research software (which will remain nameless). The point is that the help file and the UI that it describes is operating at a very low level of granularity. Each of the controls does some tiny cryptic operation that only makes sense to the original programmer/designer. So to configure it to do one high level function, you need to manipulate a whole slew of tiny, fine grained controls that by themselves are semantically meaningless and completely logically disconnected.
Don't get the idea that my software is so much better, the very fact that this is a bit of a revelation to me probably means I have been committing the same crimes... (probably? Definitely!) but admitting you have a problem is the first step....
So how would I do it better?
Well for starters, I think rather than having many low level settings that can be used to construct a higher level abstraction, start with the high level abstraction ( like a template or profile of settings) than can then be modified if required. This provides context for each of the settings and allows the user to build an easy mental schema and then to modify it and derive variations easily. Much easier to understand the system and provides a simpler way for the developer to cater to the needs of the users.
The other issue is documentation. By working from the high level abstraction down to a low level, its easy to build the users mental schema. However its hard when the task the user is trying to accomplish is not like the high level abstraction that you are using as the basis for the explanation. So in the case where the research software is kind of a "build an experiment toolkit", its important to do both. Provide a number of high level case studies, to communicate the high level context that all the settings and bits fit into as well as a low level description of each individual component and how they might interact with every other component. Easy... lol.
No comments:
Post a Comment