Hello dear readers of Habr! In this article I will talk about the theoretical background and the existing problems in the development of interface for IDE, and in the end I will offer to get acquainted with the result of our work in the form of a plug-in for the Intellij IDEA development environment.
Why we decided to create another tool for developers
For a long time, our team has developed the idea of ​​alternative ergonomics of the interface for the development environment, which would make it easy to cope with complex and intricate projects with a large number of classes and files on board. First of all, we, as programmers, were interested in increasing the level of efficiency and satisfaction when working on the assigned tasks. Here we have in mind the usual programmer tasks like creating new classes, filling them with code, studying existing code, finding the right place to learn, navigating between different parts of a project, and the like.
In a nutshell, the main tasks that this alternative ergonomics should solve can be formulated as follows:
')
- Reducing the number of routine actions, such as scrolling to the right place in the code or to an element in the tree, revealing tree nodes, visual search for an element in large lists, and the like.
- Minimizing cognitive load. The solution of programmer tasks and so significantly loads intelligence and memory, so it would be wrong to require the developer to memorize and analyze additional information. This not only reduces the level of pleasure from work, but can also significantly affect productivity.
- Reducing the number of distractions. Excess information that is irrelevant to the current task should, if possible, either be hidden or have less visual weight.
- Automatism reuse If the interface involves the development of a new skill, then this skill should be used as many times as possible.
Let us dwell on each of these points in more detail.
Reducing the number of routine actions
During the experiments, it turned out that the productivity of access to the target part of the code significantly affects the productivity. Moreover, this influence is expressed not by a linear function, as it might seem at first glance, but by some kind of a parabola.

The explanation of nonlinear dependence lies, apparently, in the peculiarities of short-term human memory. If the development environment does not allow you to access the necessary part of the code for the cherished seconds, while the short-term memory is still alive, then most likely, the developer will have to switch back or think for some time to restore the task context in his head. Surely everyone is familiar with the situation when we finally found the same method in the very same class, but completely forgot why we were looking for it at all. The positive side of this relationship between access time and work efficiency is that even a small decrease in search time significantly affects the results of work in general.
The key rationalization proposed by us for solving the problem of reducing access time is the use of a multiple project tree. Instead of the usual one tree, we suggest using an arbitrary number of project trees, each of which can be configured for a specific branch of the structure. This approach allows you to fine-tune the "desktop" of the project for specific needs and arrange the elements so that everything is at hand.
Reducing distractions
Not only the search time and the number of movements required to perform it affect the overall cognitive load on the user. Also an important factor is the overload of the working space irrelevant information. Of course, it is not so easy to determine which objects are currently the main ones and which are irrelevant and are only a source of interference, especially considering the variety of ways to use the development environment. Nevertheless, it is very important for us to give the developer the opportunity to hide the extra.
At the code editing level, quite good results were shown by hiding all the surrounding code, except for the current class method. This allows you to concentrate on the refinement or study of the current method, while forgetting about the existence of the rest of the code in this class.
At the same level of navigation in the project tree, concealment of elements that are irrelevant to the current task in the so-called
visual groups gave good results. Groups, unlike folders and classes, do not affect the project structure in any way, but they allow you to quickly and painlessly form a suitable visual location and prioritize.
In addition to hiding unimportant elements, it is sometimes useful to approach exactly on the other hand - to highlight important ones with the help of visual accents (for example, fat, italic or underline). Such notes allow you to catch the eye while skimming the branches of a tree and remembering something meaningful, something for which the emphasis was made.
Automatism reuse
Sometimes, even the most obvious at first glance, decisions on organizing quick access to frequently used elements are doomed to failure due to the fact that the accumulated automatisms of the user take up over the supposed simplicity. An example of this kind of failure is the suggestion of Windows developers to place multimedia files in the folders specifically designed for this purpose: Pictures, Music, and Video. Why does it work badly? The fact is that the user will rather take advantage of the familiar and universal skill of creating a new folder and put music into it, rather than remembering the existence of a specially designed directory, courteously created by the creators of the operating system. And this behavior will be quite rational. Learning a new way of solving a problem is always associated with an additional expenditure of time and effort, and if this skill is useful only in a fairly narrow circle of tasks, then it is quite possible that the cost of mastering it and keeping it up to date will not be justified by the result will be received in the end.
Thus, when developing the interface, it would be naive to expect that all the ideas on work organization proposed by us will immediately find approval among users. Moreover, if we propose to master a new skill or remember a new information, this should really be justified and this skill should be as universal as possible.
For this reason, we did not like the idea of ​​the “Favorites” (Favorites) as a separate dialogue or component. Instead, it would be desirable that each of the project trees could, with a flick of the wrist, turn into a set of necessary classes or packages chosen by the developer for a particular purpose. Thus, a universal tree setting skill could be used repeatedly in the process. In addition, it would allow to deviate from the principle of a
unified global elected for the benefit of the
chosen in context .
Implementations
The first development environment implementing the principles described above appeared in 1996 under the name "Visual Programming Armory". At that time, the most relevant language for us was C ++, and the future flourishing of the Java era was just beginning. The development environment was a standalone Windows application with plug-in support for various programming languages, including an object-relational subsystem, a modeling add-on, and other proprietary tools.
A lot of work was done and many of the ideas were implemented, but, unfortunately, the project was abandoned in 2001 due to force majeure.
Despite this, we continued to improve Armoury for personal use. It is difficult to abandon a tool that allows you to speed up development at times and earn more.
Meanwhile, progress did not stand still. Autocomplete, Find Usages, ctrl + click code navigation and all sorts of smart searches are becoming the norm among popular IDEs.
In 2001, IntelliJ IDEA appears and slowly but surely begins to win the hearts of programmers. Intelligent code analysis helps to find errors before compiling, and refactoring tools allow developers to quickly reorganize source codes of programs. Here, we must pay tribute to JetBrains, they have done a great job in creating a complete structure of the elements of the source code, reflecting it in the so-called
hierarchy of Psi-objects . Based on this abstract model, it becomes possible to perform code checks for compliance (code inspections), code analysis, micro-refactoring and display of the project tree.
Despite our love for this wonderful development environment (Intellij IDEA), some things did not quite suit us, especially considering the accumulated experience in organizing an ergonomic workspace.
The question arose whether it is possible to combine the ergonomics of the old Armoury and the intellect of the IDEA? After examining the source code of the IntelliJ Platform SDK, we found out that the Open API provides access to all key functions of the development environment and such a union is quite possible. The prospect of getting a handy tool for working with all the goodies of the most advanced editor inspired us and we thought, why not share it with the developer community.
As a result of our work, a plug-in for products JetBrains - Armory. The plugin is completely free for IntelliJ IDEA Community Edition and under this platform supports languages ​​such as Java, Scala and Groovy.
How to use the Armory plugin
You can install the plugin either from the official JetBrains
plugin repository , or from the
Downloads page on the program website. Distributions of the plugin are exactly the same, the only difference is that the updates appear on the site a day or two earlier. This is due to the fact that after the publication of the update in the plugin repository, JetBrains must be moderated.
After installing the plugin and restarting IDEA, the Armory window tongue will appear on the right (like the Project window tongue in the left pane). By clicking on it, the main working window of the plug-in will open, containing the project trees themselves, the toolbar and the information panel for the element selected in the tree. Like the entire Tool Window in IDEA, the Armory window can work in several modes: Pinned, Floating, Docked. Read more about managing the Tool Window
here . The default is Docked Mode in conjunction with Pinned Mode. Docked mode means that the plug-in window will “bite off” the work area of ​​other IDE components when opened, rather than overlapping them. Pinned mode means that the Armory window will not automatically hide when it loses the focus of input. Here, you may want to customize this behavior to your taste and monitor size by setting the desired combination of modes.
Now you can begin to customize the workspace. You can create new project trees by dragging a folder, package or class onto special Drop-zones, as shown in the animation.
Other ways to add new trees can be found in the
help for the program.
Now it’s worth mentioning separately the navigation between the project tree and the editor. The fact is that, unlike the built-in Project View component, the Armory window has a much larger horizontal size. The reason is clear - here we are dealing not with one tree, but with several at once. In connection with this, the navigation algorithm in the editor also changes. By default, Armory uses the key combination
Ctrl + Enter to navigate from tree to editor and back. If for some reason you are used to using this combination in the editor to insert line breaks without moving the cursor (this is its default purpose in IDEA), then you can change this key combination in the plugin settings.
If you noticed, when you open a class method from a project tree in the editor, not the entire class is displayed, but only the code of the current method. In fact, all the code before and after the current method is collapsed by two Folding regions. In order to see the whole class, just press
Escape twice while in the editor. In the settings of the plugin, you can also change this behavior, for example, instead of collapsing the surrounding code, you can choose to select it with the specified background color.
Please note that when navigating to the editor by
Ctrl + Enter , the Armory window closes. If you have a large enough monitor and you do not want to close the window with trees when you go to the editor, then you can use the standard IDEA navigation keys:
- Enter - Open the source code of the element without setting the focus in the editor.
- F4 or double click of the mouse - Open the source code of the element with the installation of the focus in the editor.
This basic information is enough to start using the plugin and already receive a certain profit from the use of several trees. Next, we will look at fine-tuning each of the project trees and creating groups of elements.
Setting the root of the tree
As can be seen from the above, the Armory tree can contain a root element that points to a particular node in the project structure. Moreover, each tree can contain several such root elements pointing to different places of the project. This is useful if we want to set up a tree as a favorite, gathering in it certain classes or packages from different corners of the source code. To add an element as a root to any tree, simply drag the element to a special area in the tree header, as shown in the following animation.
To add an element as a root using the keyboard, you can press
Ctrl + Up and use the arrows on the keyboard to specify the tree to which this root element should be added.
Deleting the root elements from the tree is also performed by dragging it into the header area, or by using the
Ctrl + Delete hot key.
It is worth saying that all Armory commands are available through the Armory context menu. You can call it by pressing
Ctrl + Right mouse button or the keyboard
shortcut Ctrl + Menu .
With this approach, both menus (the standard context menu of the IDEA and the context menu of the plugin) are always at hand.
Grouping
Grouping tree elements is an indispensable tool for restoring order within a class with a large number of constants and variables. In addition, it is convenient to use it to isolate some of the class methods, grouping them by meaning. You can group any elements of the tree, including files, folders and packages.
Such a grouping does not affect the source code in any way and is purely visual. Deleting a group only leads to the ungrouping of all its elements. To group the selected items without a mouse, use the
Ctrl + Alt + Page Down hot key. To ungroup -
Ctrl + Alt + Page Up .
Sort items in the tree
The order of the elements in the tree is determined by the current sorting scheme. To change the order of elements, you can either select one of the preset sorting schemes, or create a new sorting scheme in the plugin settings. The following image shows how you can switch the sorting scheme through a button in the toolbar.
You can read about how to create new sorting schemes and edit existing ones in the plugin
help .
Emphasizing wood elements
As mentioned above, in addition to hiding minor elements in groups or moving them beyond the tree's visibility by setting the root element, it is also sometimes useful to visually highlight important elements. At the moment, Armory supports three styles of selection - it is bold, italic and underline. Their combinations are also allowed. To select elements, the key combinations used for editors are used:
Ctrl + B ,
Ctrl + I and
Ctrl + U. You can also overlay the style through the Armory context menu.
The picture shows the context menu of the Armory, and on the left is an example of how the elements appear in different styles.
Conclusion
In conclusion, I would like to say that all the techniques listed above, after some training and habituation, produce amazing results. Having a “map” of the source code at hand, which remembers its state and user notes on the margins, you can very quickly recall the context of the previous work and begin to act. Saves time. Saves attention and strength.
This can be compared with the fact that instead of walking around the city for hours on foot, we suddenly gain the ability to instantly teleport by simply clicking on the desired point on the map.
We hope that this plugin will benefit you and become a reliable assistant in your work.
If you have your own thoughts about what is stated in the article, you disagree with something or you have a proposal for improving the program, please share it in the comments.
Thanks for attention.
Links