Improving Usability of the Linux Kernel Configuration Tools

Users usually configure a customized Linux kernel to support specific hardware requirements or particular needs. Unfortunately, configuring a Linux kernel has always been a challenge for non-expert users due to several reasons. To better understand those reasons, we carried out an initial user study to identify major usability issues with the current Linux kernel configuration tools (mainly xconfig). We conclude from this study that these usability issues can be summarized as follows:

• Overwhelming menu hierarchy. Menus should be as simple as possible. There are far too many options that could be reduced automatically if the configuration tool targeted a specific user group (novice and intermediate users) and had good reasoning capabilities.
• Cryptic option names and descriptions. The existing infrastructure uses option names that reflect low-level implementation details instead of end-user functionality.
• Poor searching capabilities. Searching worked very poorly since option descriptions were not included in the search space. Having useful search tools becomes increasingly important as the number of configuration options grows.
• Lack of automated hardware detection. Kernel autoconfiguration is important since the majority of kernel options are related to hardware drivers that should be automatically detected by such tool.

So, can we do a better job? Well, to answer that question, we designed several mockups for our tool prototype, lkc, that reflect the feedback we got from the participants of our initial user study. We then carried out a second user study to get feedback from our participants about those design mockups, and whether they meet their expectations for a Linux kernel configuration tool. We were able to conclude the following:

• Users always like to know what is going on. In other words, they did care about getting more information about what the tool is doing while the progress bars are being filled up.
• Although users appreciate access to more information, they do not prefer such information to be displayed by default.
• It is highly desirable to have the tool report any crashes that occur during the hardware detection process.
• Almost all users liked having helpful descriptions for the various kernel features they can select.
• Easy navigation through the various categories of features was also on top of their desirable design features.
• The fewer the number of categories were, the easier it was for the users to find features.
• Most users like having a summary of the configuration file at the end of the process with the ability to review/modify it before quitting the application.
• Many users were in favor of the question format that was presented in one of the design mockups. The reason is that it gave them a better understanding of the effect of selecting/deselecting features.

Based on our conclusions from our second user study, we designed a prototype for lkc as shown in Figure 1. The figure shows the main window that will be shown to the user after the application is launched.

Figure 1. Suggested lkc prototype design

In order to put lkc under test, we carried out a final user study to know if we're on the right track or not. The aim of that study was to compare the usability of xconfig and our lkc prototype. The feedback we got was a mixture of appreciating the suggested tool prototype and some suggestions to improve the design. In general, users saw lkc as an improvement compared to xconfig because:

• It is simple, intuitive and easy to use.
• It offers various convenient ways of navigation: free navigation through the left panel, and wizard-based navigation.
• Users also appreciated the statistics panel because it gave them an idea of how their current selections reflect on the overall status of the kernel that will be configured using the generated configuration file.
• Hiding unnecessary details and not overwhelming users with an explosion of features was another source of appreciation.

On the other hand, some users experienced some difficulties using lkc. These difficulties can be summarized as follows:

• One user did not know the meaning of "features" in the statistics panel.
• Two users did not quite understand what "stability" means in lkc.
• The option minimal configuration was rather confusing for one of our users.
• One of the users commented on the fact that the study we carried out was biased because it was easy to accomplish the task by just answering the questions provided by the tool.

In this study, we only took the first steps and we still have many steps ahead of us to be able to claim that the problem is solved (partially at least). However, we think we are on the right track. Additionaly, we got a very rich feedback from the participants of our final user study about the design of our prototype. Implementing some of those suggestions would add more value to the prototype. The design suggestions include the following:

• Provide progressive disclosure to accommodate both advanced and less experienced users.
• Have the ability to re-detect hardware.
• Provide info about detected hardware.
• Change the position of the Save button.
• Always enable the Finish button. When clicked, it should show a dialog with three options: Save & Quit, Save, and
  Cancel.
• Move the Previous/Next tool bar buttons closer to the left panel because they are ways of controlling the navigation through it.
• Keep track of the history of changes to the configuration file.
• Resolve conflicts.

Project report [PDF]
Source code [github]