Incomplete removal prevents users from trying out software

A powerful option for selecting which software packages to install is to install several relevant packages, and test them out directly. Participants in a usability study on package manager were reluctant to use this method of selecting between the many available software packages. The main reason expressed for not wanting to install software for trial purposes was a concern that the removal process would be imperfect, leaving residual effects on the computer after it was removed.

This concern was based on experience with standalone installers in Microsoft Windows which often do not fully remove all vestiges of an application when the program is un-installed. On Windows, this has led to the development of a niche for dedicated software that is not a part of any package manager, such as Pitrinec’s CCleaner, that will scan the computer to try to find and remove unneeded files and settings that were left behind by imperfect software removal.

When a package manager un-installs a package, software that was installed to satisfy dependencies of the now-removed software may no longer be necessary. In one case, a user who participated did not want to install software packages to test them out, due to concerns that the removal process would be imperfect and installing the software to try it out would leave some residual effects on the computer after it was removed.

Some package managers, such as aptitude, will automatically remove packages that were installed to satisfy dependencies and are no longer needed. The package managers examined in this study do not provide the same capability, and would leave any dependencies installed when a package was removed. (The exception being Apple’s App Store, which provides no dependency resolution at all.) Thorough removal of software packages that users do not want any more may make users more comfortable trying out packages to help them choose between their options.

Ubuntu 11.04 has taken a different approach: the version of Ubuntu Software Center that it comes with can accept an add-on which adds the ability to access a virtual machine with the application installed on it – allowing the user to interact with the application without installing it. This provides an interesting middle ground between installing the application to test it, and selecting an application to install based only on screen-shots and a description.

Posted in Uncategorized | Leave a comment

Un-installation is frequent when users try many alternatives

Some users installed multiple competing software packages to try them out. In some cases the software packages that they installed were not at all what they had expected. This is an indication that the discovery and/or evaluation processes had failed to find an appropriate package. In other cases the software was what the user expected but the user was not satisfied with the interface or apparent quality of the software they had selected. In both circumstances, the user went back to the package manager to find some other alternative.

This form of trial-and-error evaluation left undesired software packages installed that the user may want removed. Except for QuickPET, which provides no mechanism to remove software packages, all of the package managers examined in this study allow the user to remove software packages by a process which is very similar to that used to install software packages initially.

To remove packages that are unwanted the user must still go through a discovery process to find those packages in the package manager that they want to get rid of. In these cases, the users wanted to remove packages that had been recently installed, but had to navigate the list of all installed packages to do so. It may be useful to the user to have a history of packages recently installed, so the user can more easily clean up software packages that were installed for evaluation purposes that are no longer desired.

Posted in Uncategorized | Leave a comment

Updating is easier than knowing if you are up-to-date

In a previous post, I discussed the results of users attempting to add the Wine PPA using Synaptic Package Manager, so they could download the latest version of Wine. Users found instructions using web search, and followed those directions to add the PPA and update to the latest version of Wine.

Most users followed the instructions easily despite having no previous experience with adding a PPA. After the users had successfully updated to the latest version of Wine, I asked them how confident they were that they had successfully updated to the latest version of Wine.

About half of users were confident that they had successfully completed the task and the others were not certain. All stated that they were fairly confident that the instructions told them how to do what they wanted to do, and that they had followed the instructions correctly, but most users did not know any way to determine if the version of Wine they had was actually the latest version. The version number of the installed package is shown in Synaptic Package Manager, but only one user thought to check there to see if the version number shown there matched the latest version reported by the Wine website.

Providing this feedback is a challenge for package managers. It is trivial for the package manager to determine if the installed version is the latest available in the repository, but it is difficult for the package manager to determine if there is a PPA that has not been added that might contain a newer version. This is problematic because the default repositories used by the open source package managers we tested usually lagged behind the most recent versions available.

An index of known PPAs, as mentioned in the previous post where users attempted to add the Wine PPA, would make it possible to let the user know that the version they were running was truly the latest version available.

Posted in Uncategorized | Leave a comment

Big catalogs need more navigation features

In Jakob Nielsen’s recent article on international usability, he makes the following statement:

If you’re designing an e-commerce site for a 5-item product line, you shouldn’t confuse users by offering search or filtering options. Focus on brief descriptions that clearly differentiate the products, facilitating comparisons and choice. Conversely, if you carry 100,000 products, you do need search and filters. You also need to introduce a new level in the IA: the category page, which further helps users compare and choose.

I found the same trend in my research on package managers. Most package managers need to deal with very large numbers of packages. Search and categories were the main methods users used to find relevant packages to install. These topics are examined in detail on a previous post about categories and a previous post about search.

The only package manager that did not have a search function was QuickPET, which had a very small number of packages to choose from. In the case of QuickPET search is not likely to be necessary. QuickPET does have a categorization system that users were not fond of, and given it’s small number of packages, it may have been able to do without a categorization system entirely.

Posted in Uncategorized | Leave a comment

On-line tutorials make usability better, but not good

Sometimes the software a user wants to install is not available in the standard repositories of a package manager. In other cases, the software is available, but is not the most recent version. To explore this case, I had users attempt to download the latest version of Wine from the Wine PPA using Synaptic Package Manager.

The process of adding the PPA requires entering an address similar to an URL into a text box, so the user had to look up at least the address. The address and instructions were available together in a short tutorial on the Wine project’s website.

Users found the instructions to be easy to follow but some had difficulty finding the instructions. All participants attempted to find instructions using web search.

The success of this approach was very sensitive to the search terms used. In some cases the instructions would be the first search result, and in other cases the instructions were not anywhere in the first few pages of results. Users who ended up on the Wine project’s website, but not the download page, tended to gravitate toward the AppDB rather than the download page, which had the information they needed on it. The users who ended up in the AppDB stayed within that section of the site rather than exploring sections and did not find the instructions without guidance.

The difficulty of finding instructions shows one problem of using web search as a crutch for supporting operations that users do not understand how to do. The existence of a tutorial on-line does not fully compensate for the difficulty of adding the PPA.

It does not make sense to simply incorporate the Wine PPA into the default repositories because the developers of Wine are not the same as those who develop the operating system that the package manager serves. None-the-less, the desire to access software outside of the default repositories is something users are likely to encounter at some point, and the current methods for helping users with this task are insufficient. One possible method to remedy this may be to provide (in the main repositories) an index of known PPAs, so that users could add and remove PPAs in the same manner as they add and remove software packages.

Posted in Uncategorized | 1 Comment

Mark-and-apply paradigm is unpopular with regular users, while users who need it prefer command line anyway

The package managers we used had two main methods of interaction for installing software once the user has found it. In one paradigm, there is an install or un-install button provided, and the installation or un-installation begins immediately when the user clicks. In the other, users mark changes to be made, and a separate apply button is used to make the marked changes effective.

Most participants who used Synaptic had issues with the paradigm of marking changes and then applying them.

“I really hate how they do this mark thing. What is marking? It’s not really a good fit for my mental model.”

In a follow up with the participant who gave the preceding statement, the participant elaborated on their mental model of marking:

“If I mark a package, does synaptic grab its dependencies for me and mark them as well? Is there a place for me to go and find out which packages I’ve marked? How can I un-mark something I marked before? Do I have to search for it again? What operations can I perform on marked packages? What do these operations do? To me, marking a package means ”install this”. To me, once I’ve marked something, it should be installed, unless there’s some explicit cancellation of that by me. Performing other operations on marked packages is kind of an alien concept to me… what would I want to do other than install them?”

One user who was experienced with console package managers explained that the ability to mark changes separately from applying them was useful because sometimes the dependencies that are marked for upgrade automatically do not strictly need to be upgraded, and upgrading them may break other packages dependent on the old version.

The core problem here is that novice users are forced to understand something about functionality that is only required by very advanced users. The issue is aggravated by the fact that the users in our study (admittedly a small sample) who knew enough to understand why you might want to mark and apply separately, preferred not to use graphical package managers at all. Instead these users opted to use package managers at the command line, or in the case of aptitude, using it’s text user interface. Synaptic’s usability is bogged down by a design decision that benefits very few of it’s users.

Posted in Uncategorized | Leave a comment

Minimal Interfaces are easier to learn

In what may come as no surprise, my tests with users confirmed the intuition that a less complicated interface was easier to use. In all cases, the users went for either search or category navigation as their first operation, and interfaces with more elements on the starting screen that were not directly related to those functions were harder to use.

Ubuntu Software Center was considered by most of the subjects who tried it to be the most clean, attractive, and clearly laid out of the package managers. None of the users needed to take time to figure out the interface before they could begin using it. In the screen-shot, almost all of the interface elements support either search or category browsing.

Initial screen of Software Center

Initial screen of Software Center

Roughly half of users had to take some time to explore the interface of Synaptic Package Manager before they were confident enough to attempt using it. The other half immediately went to the search bar or the categories. Synaptic has several interface elements on the starting screen that distracted users.

The worst offender was the buttons in the lower-left, under the category list. These change the way that applications are categorised, but only the default, “Sections,” made sense for the users. Users who changed it to something else either from curiosity or accidentally, got confused and had difficulty getting back to the categories that made sense to them.

Initial screen of Synaptic Package Manager

Initial screen of Synaptic Package Manager

Puppy Package Manager also fared poorly. Chief complaints included the amount of text and reading involved in Puppy Package Manager’s various screens, and the single-click behavior of the package manager’s UI controls. Most users were surprised when clicking in what appeared to be a selection box started the installation process rather than merely selecting an element.

“Every time I click on something, something happens, and I don’t want it to.”

“It has way too much text that I will never read.”

“This is ugly, it’s not intuitive. There is a lot of buttons, a lot of windows.”

Initial screen of Puppy Package Manager

Initial screen of Puppy Package Manager

QuickPET calls packages “Pets” instead of “Packages”, “Applications”, or “Apps”. Although users understood what a “Pet” was, they considered the non-standard terminology unnecessary. QuickPET’s categorisation system was also criticised as having unclear organisation and ambiguous category titles. Despite these shortcomings, QuickPET does present the user with only relevant UI elements, and was fairly intuitive for the users despite it’s other shortcomings.

“The pet thing is weird… it’s just weird.”

“I don’t like calling applications pets.”

“Too cute.”

Initial screen of QuickPET

Initial screen of QuickPET

The design implications are clear, but not new: removing unnecessary design elements makes applications easier to learn. This matches the common intuition – but intuition is often incorrect in designing for usability. Having data to back it up puts us in a better position to make informed designs.

Posted in Uncategorized | Leave a comment

Users look for an application installer in the application area

Before a user can use a package manager, they first have to find and run it. There were three locations in the interface that were used for this purpose:

  • Listed as a regular application
  • In the same area as regular applications, but visually distinct
  • In a setup or configuration area of the system

Most participants in the user studies found Ubuntu Software Center easily. The first place people checked was typically the Applications menu, and Software Center was listed at the bottom of the Applications menu. Most did not see Software Center at the bottom immediately, but instead browsed the categories searching for it there first.

The location of Software Center in Ubuntu 10.04

The location of Software Center in Ubuntu 10.04

None-the-less, it was spotted quickly. Many package managers used a similar approach. On systems where the package manager was more visually distinct from the rest of the applications menu, users found it more quickly. In systems where the package manager was made to appear like any other application, such as on Apple’s iPad, users often overlooked it amongst the sea of other, similar-looking applications, but it was found reasonably quickly in all cases.

The most troublesome option was placing the package manager in a setup or configuration area of the system. For example, Synaptic Package Manager was located under the System->Administration submenu, which most users checked only after exhausting every other submenu.

The location of Synaptic Package Manager in Ubuntu 10.04

The location of Synaptic Package Manager in Ubuntu 10.04

Most acknowledged that in retrospect, the placement makes sense, but was not where they would have thought to look for it, and identified the Applications menu as the place they expected it to be. Two participants required guidance to locate Synaptic. One afterward indicated that they would have never found it under System:

“To me, System is somewhere you put things that a novice user should never touch.”

The Puppy Package Manager can be run from the application menu, but there is also an Install icon on the desktop. Six of the seven participants who used Puppy Package Manager went for that icon. The participants found the location of the icon intuitive but found it unintuitive that the same “install” button contained operations for both running the package manager, and for installing the operating system to a hard disk. Puppy Linux brings up a dialog box to allow users to choose between the operations. Only one user mistakenly chose the wrong operation, but all lost a considerable amount of time reading the wordy dialog box.

Lucid Puppy's "Install" dialog box

Lucid Puppy's "Install" dialog box

QuickPET is located in a sub-menu for configuration, similar to Synaptic Package Manager. Participants found the sub-menu easily, but were confused between QuickPET and other options in the sub-menu, which included an option to install the operating system to the hard drive, and a configuration wizard.

Sub-menu containing QuickPET

Sub-menu containing QuickPET

The usability implications from these results point to a clear preference for locating the package manager in the same area of the system as the applications that it installs. Making the package manager visually distinct from other applications helped usability, but having it as a regular application listing was not particularly problematic as long as it was a top-level item and not buried in a sub-menu.

Posted in Uncategorized | Leave a comment

Packaging separately leads to better discovery and less fart apps

In the open-source package managers I studied, there is typically a distinction between the person who develops a package (the developer) and the person who adds it to the package manager. (the packager) In package managers like Apple’s App Store, the developer and packager are the same person. This may go a long way to explaining the differences observed in long descriptions.

The incentives for the packager are different in the two situations. When the packager and developer are the same, the packager’s motivation is generally to get as many downloads as possible, even if it degrades the quality of the repository. (Tragedy of the Commons) There is little-to-no incentive to avoid users inadvertently downloading the package even if it is not relevant to the user’s interests.

On the other hand, when the packager and developer are separate, the packager’s incentive is to maximise the quality of the repository by making additional packages available and making it easy for users to find the package, if they want it, and to skip over it if it is not what they want. In addition, each package added to a repository requires some effort on the part of the packager. This provides an incentive to only add packages that are likely to be useful to the community.

This difference may go a long way to explaining the difference in the style and usefulness of the long descriptions in the open-source package managers versus Apple’s App Store. There is also evidence that packages in the package managers with a separation between packager and developer are installed more frequently.

As pointed out by AppsFire, 80% of packages in Apple’s App Store are not being used, and even the 1000th most popular package is installed by only 1.76% of users. (data from October 2009) This is likely a result of both weaknesses in the discovery process (discussed here, here, here, here, here, here, and here.), and a glut of so-called “fart apps” that provide very little to the App Store aside from inflating it’s statistics.

Comparing to data for Ubuntu, the top 5600 packages are installed by the same percentage of users, and almost all packages are installed by at least one user, with a much shorter long tail – 51% of packages are installed by at least 1% of users. This can be partially attributed to better performance by users in finding the packages they need. The burden on package managers also likely serves as a filter, keeping out the “fart apps.”

Although the model used by the open-source package managers is unlikely to be adopted by Apple, it produces a repository that is both more usable and has contents that are, on average, more desirable to the users.

Posted in Uncategorized | Leave a comment

0x800A0062 when using COM Interop on ASP.NET

Like many exceptions related to COM Interop, the exception COMException(0X800A0062): Exception from HRESULT: 0X800A0062 can have many causes. The information is out there on the web, and I was eventually able to track down a solution for my application. However, there is a fair trail of bread crumbs one must follow from searching on the original error to finding a solution for this problem in ASP.NET. To spare other developers the hassle, I have posted my solution here.

Generally, this error results from an attempt to access a STA (single-threaded apartment) COM component from a context with a different threading model. VB6 DLLs are generally STA COM components. ASP.NET pages, by default, do not run in a single-threaded apartment. As a result, this error can easily occur if you try to access a VB6 component from ASP.NET.

The easiest solution is to set the ASP.NET page to run in STA mode. To do this, add AspCompat=”true” to the <%@ Page … %> directive on the page that uses the COM component. This flag is set on a page-by-page basis.

Microsoft has a page about this, but it is hard to find because it does not mention the error that occurs if you don’t include the AspCompat flag in your page directive.

Posted in Uncategorized | Leave a comment