Usability issues in IntelliJ IDEA

Usability issues in IntelliJ IDEA

By Kangqing YU

Introduction

IntelliJ IDEA (https://www.jetbrains.com/idea/) is a widely-used Integrated Development Environment (IDE) used nowadays in industry by a lot of developers. It is released on Windows, Mac and Linux operating systems, which supports Java and most other JVM programming languages as well as many frameworks and tools used within community. It is bundled with a lot of powerful features to facilitate the software development process. Those features include code refactoring, version control system integration, database integration, live reload, hot deployment and so on. Such features can, to a great extent, improve the productivity of developers.

Despite its powerful functionality for coding and software engineering, it suffers some usability issues just as other software tends to. Some of these issues are quite serious and therefore could result in a big handicap when using it. This post will present some of the most serious usability issues I found in the software when working on a Java based project. Those issues were identified using the cognitive walkthrough evaluation method.

Product and technical information

Software version: 15.0.6

Operating system: macOs Sierra(version 10.12.3)

Usability issues

1.     No visible control on ‘Import project’ once another project is open

The first problem is that there is clearly NO visible control to perform ‘Import project’ action once there is already an open project. IntelliJ IDEA differs in its design from many other IDEs in that once the software is launched in its very initial state of the application, rather than opening the full editor, it pop-ups a dialogue box to let user either create a new project, open and existing one or import a new one as seen in Figure 1 IntelliJ IDEA initial dialogue box. Once a project is open, there is no explicit option to let user import another project within the current open one unless user close the current project, forcing the application to return to the initial dialogue box and select ‘Import project’ from within there. There is simply no “Import Project” option in the File menu as we can see in Figure 2 IntelliJ IDEA file menu after opening a project. The side effect of this is that user will have to explicitly close the current project in order to import a new one into IntelliJ IDEA, which is not ideal in some cases because sometimes, developers would need to keep the current project open while working on others.

Figure 1 IntelliJ IDEA initial dialogue box

Figure 2 IntelliJ IDEA file menu after opening a project 

Recommendation

Always provide the ‘Import project’ action so that the user would be able to import and open another project from within a current project.

2.     Inadequate feedback from the system status once user finish importing

The second defect I found is about the inadequate feedback from the system once the user finishes importing the project. Specifically, if something happened in the background, such as failing to fetch dependency libraries, failing to build the project internally, the system won’t inform users of such failure and it lets the user carry on further tasks until he tries to compile the project and eventually gets an error. This is problematic as users do not get enough feedback regarding the result of the importing task at an early stage, which can lead to errors eventually.

Recommendation

Provide useful feedback regarding the status of importing task. If anything fails during importing, error messages should be forwarded to user in a timely manner so that they can investigate the problem and fix.

3.      ‘Add task’ subtask is not obvious and can potentially be left over

A third problem is that once the task configuration dialogue box (as shown in Figure 3 IntelliJ IDEA task configuration dialogue box) is open, most users would not recognise that clicking the “Add task” icon(the plus sign) be necessary. The icon itself is hardly noticeable on the top left and most users would simply ignore it and select the relevant task template from the “Defaults” dropdown menu, configuring the task and then click to run it, which would result in the task configuration not being saved and the user would have to re-configure it following the same steps before if he wants to run this same task again. This will add extra work loads and cause frustrations for users.

Figure 3 IntelliJ IDEA task configuration dialogue box

Recommendation

There should be an obvious message to tell users about clicking “Add task” icon FIRST, or reminding users to perform this action if they want this task configuration to be saved in the future, or make the ‘Add task’ icon in the task configuring menu at an obvious position or hide the ‘Default’ dropdown menu so that the user will always recognize that clicking the ‘Add task’ icon is necessary.

4.     No validations on configuration inputs after clicking ‘Ok’ or ‘Apply’

In the task configuration fields following the selection of task template. This is no validation on the input values the user has typed after clicking the ‘OK’ or ‘Apply’ button. The system will return to the main screen and carry on without any error messages or warnings. This can create some potential problems in the future. For example, if the user put a wrong goal name which the build tool won’t recognise, there will be no validation errors and when user click to run this task, the build tool can’t execute it and get an error in the console. Or if the user configures a task without giving the task a name (leaving the field empty), the system won’t prevent this and your task will just have a blank name. This would create confusion if other users try to run this task and he would not understand what this task is trying to achieve.

Recommendation

A clear error message should be shown, and the user should be prevented from leaving the task configuration dialogue whenever the user is done editing the configuration if validation errors occur. Validate the user’s input on task configuration box once user click ‘Ok’ or ‘Apply’ so that invalid inputs won’t be allowed

5.     Unclear goal structure and affordances when refactoring method/variable name

When refactoring field variable, local variable and method names, the selected variable or method name will be highlighted with a red border. There is no clear control element or instructions to inform the user what they should do next nor any indications that whatever they are typing inside that red border is defining a new name for this variable or method name and it is going to take effect immediately. After typing in the new name, the user has to press ‘Enter’ key to exit this ‘refactoring mode’ and the red border will then disappear to finish this refactoring task. But they may not realize that this step is necessary, leaving this refactoring task open and they may carry on doing other refactoring task, until when the system will prohibit them from doing so with a given warning message (Figure 4 Refactoring another variable with an open refactoring task will get a warning message).

Figure 4 Refactoring another variable with an open refactoring task will get a warning message

Recommendation

Always present a dialogue box with a text field to allow user type the relative information such as new method, variable name etc. if user want to initiate any refactoring. 

Conclusions

Generally speaking, the usability of IntelliJ IDEA is quite good compared to other IDE software I used despite some defects I found. Designing a highly usable IDE software for developer is very challenging and there are some aspects that IntelliJ IDEA does quite well in usability. However, I believe the usability could be further improved if the above recommendations and suggestions could be incorporated.