As mentioned in previous posts, the main feature that users of a package manager rely on to determine which of many possibly-relevant packages to install is the long description. A previous post discussed some of the findings on long descriptions and the design implications for long descriptions.
The problems observed in that post were most severe on Apple’s App Store, and the open source package managers did better. This post focuses on a problem that primarily affected the open source package managers: a level of jargon inappropriate for many users of the package manager.
Even in mild cases, the use of jargon can be problematic. As mentioned in a previous post, users expressed skepticism that a “media manager” would play music, and the descriptions, emphasizing those application’s organization features, did not convince users that the application supported music playback.
Many packages in the open source package managers had more extreme uses of jargon. Several users openly raised concerns about the level of jargon used. The most prevalent of these were daemon and references to specific libraries that the software uses, such as curses-based.
For expert users these terms provide useful information for evaluation. As an example, an application which is described as curses-based indicates to an expert user that the application uses a text user interface, which is a graphical user interface displayed using ASCII art. To less expert users, who do not know what curses-based means, the term did nothing to assist in the user’s evaluation of their options and only increased confusion.
For the most part, users avoided software whose description used terms they did not understand. In the case of daemon and curses-based, this is likely what the user wanted. However, many descriptions of music players made references to the back-end libraries they use to support media playback, such as GStreamer. In these cases users the confusion caused by the use of jargon directed users away from software that would have been a useful choice for their task.
There are several potential improvements that could alleviate this problem. In the case of curses-based applications, the use of a screen-shot could make it clear that the application is curses-based without requiring explicit mention, and make it clear to users who do not understand the terminology that the software they are looking at runs in a terminal.
Unfortunately, this solution does not translate well for other jargon terms such as daemon or GStreamer because these characteristics have no visual representation. Applications that are daemons could use more approachable terminology, such as “runs in the background” which is understood by a larger group of users.
Details such as the specific libraries used could be relegated to a technical details section of the description. Whether or not an application uses GStreamer may be relevant for some users, so should probably not be removed from the description entirely. Putting it in a section clearly indicated as containing technical details may prevent it’s appearance from deterring less expert users while still making the information available to those for whom it is relevant.