With Delphi and C++Builder 10.2's release coming soon, I'd like to preview an interesting UI tweak we're planning in the IDE. This change wasn't present in the latest beta drop (if you have update subscription, you have access to the 10.2 beta!), and we're interested in overall feedback.
UI changes need to be made with caution. Productivity is often based on consistency and expectation, which means that once a UI element is placed, users are used to where it is and use it and access it subconsciously and by habit, and so changes can interrupt a user's workflow. Even if a change is "better", that interruption can make it a bad change - and so many products can end up with a suboptimal user interface, but one that cannot be changed because of the effect it would have for those who are used to it. Delphi is very conservative in its UI changes, and will remain so, but this one is a change we believe is worthwhile.
Background
The View menu in Delphi and C++Builder is large. We get a reasonable amount of customer feedback that it's too big, and for some users, especially once a few plugins have been installed, the View menu is too tall to fit onscreen. This is a severe usability problem.
Interestingly, when speaking to users, "too large" also often meant not that it took too much space on screen, but that it was difficult to find an item. This was a fascinating analysis and a great example of driving to the core of a reported problem: the issues was expressed as size, but actually about discoverability.
The end result is that we have two goals:
- To make the menu usable even on small screens (say, a small laptop with a 1600px high screen, at 200%, ie 800 nominal pixels)
- To make all items discoverable: if you open to View menu, to easily and quickly and non-confusingly find the item you're after
The size is easy to examine, but #2 is more complex. The menu items in Berlin and earlier are not organized into related areas; that is, a search for an item is effectively a search of the entire menu. Good UI design lets you expect something, and find that your expectation is true. A natural expectation is that a menu item will be found in the vicinity of items of related functionality. You should find an item without much thought or effort, ie without a distraction from your coding. You should not have to scan the entire menu in a search because the order is random and unrelated. Unfortunately, that's the situation with the current, pre-10.2, View menu.
Here's an illustration of the menu in 10.2 Berlin with related items color-coded:
There are a number of ways to categorize the menu items; this one splits by type (dockable windows / other) and function (editor, form, project, other). It's not necessarily the best way to group items, but is illustrative of the non-related layout. It is not discoverable, and even after years of use and memory, it is not easy to find the item you need.
Specific problems highlighted by the above diagram:
- Window organization menus that arrange the layout of the IDE like "Debug Windows >", "Desktops >", and "Toolbars >" are not near to each other
- "Debug Windows" collects dockable windows that are to do with debugging, but there's no similar categorisation for other dockable windows. They are not placed in any apparent order. To Do is at the top. Live Bindings Designer is also randomly placed. The others are scattered throughout the menu
- Items to do with the code editor and form designer, such as toggling form/unit, navigating back or forward, or directly to do with the code editor such as invoking Help Insight, are not grouped together
- Help Insight is not the only invokable editor action that displays something onscreen, but it is the only one on the View menu. In fact, arguably many other editor actions should be displayed in a menu rather than being hidden and requiring the user to know their shortcut keys.
The menu takes up 854 pixels of vertical space. That's already well over 800, making several menu items partly or completely invisible on a "light" laptop of the Chromebook type, which often have 800-900 pixels of vertical space. Even on a larger screen, it's perilously close to taking up the entire screen height or more, especially once a few plugins have added their own menu items.
Therefore, it's clear that user feedback about both size and organization, or findability of any specific menu item, is valid.
Changes
As a reminder, we have two goals:
- To make the menu usable even on small screens (say, a small laptop with a 1600px high screen, at 200%, ie 800 nominal pixels)
- To make all items discoverable: if you open to View menu, to easily and quickly and non-confusingly find the item you're after
In 10.2, we've currently made the following changes:
- Move related items so they are adjacent to each other (addresses #2)
- Move some items into categorised submenus (addresses #1 and #2)
Specifically:
- Items related to units, forms, edit windows etc are grouped together
- IDE layout items Debug Windows >, Desktops >, and Toolbars > are located next to each other.
- "Window List" is moved to the Windows menu, where it exists in almost all other applications.
- Miscellaneous items, like the Welcome page, at at the bottom of the menu. "Broadcast to Devices" is there as well; it is not a View item for the IDE but does affect Live Preview on connected devices.
- General dockable windows, which were scattered throughout the menu, have been collected into a new "Tool Windows >" submenu which is located right next to "Debug Windows >". The most commonly used of these are at the top
- "Help Insight" is moved into a new submenu, "Editor >", and a number of other useful editor actions have been added to that menu, such as code completion and showing code insight parameter hints. It also duplicates some of the most useful items from the editor shortcut menu, including bookmarks.
- This menu is in flux and might change in future releases. The aims is to make more editor actions discoverable (Help Insight has many peers, all of which should be visible), and to make it obvious that functionality exists which might not be discovered if it was not in a menu. Users new to Delphi, for example, might not know bookmarks or parameter insight exists - yes, for efficient use they should use the shortcut keys to invoke the functionality, but the features need to be obvious, with shortcuts shown, to do so.
We feel menu items are now easily discoverable and the View menu is much faster to navigate and to find the item you're looking for. Its organisation should help habitual memory, and validate the mental expectation model of finding a menu item near related items.
Preview
Here are some screenshots, lightly edited to show some changes still in progress:
This is the new View menu. Note that unit and form items are grouped together: "New Edit Window" is right next to "Toggle Form/Unit", for example. The non-debug dockable windows have been collected into a "Tool Windows >" submenu, just like the existing "Debug Windows >" submenu. "Window List" is now on the Window menu (not shown). The remaining items - surprisingly few, four - are at the bottom of the menu.
The "Tool Windows >" menu expanded. Note that the most commonly used windows (Project Manager, Object Inspector, Structure, Tool Palette and Messages) are at the top.
The "Editor >" menu, expanded. Note this is the most in-flux menu and its contents might change in future releases, too. "Help Insight" is the top item, as are a few other code editor actions. Below those are some high-value editor actions: these are the most likely to change. Possible feedback might include not to have them at all, or to have others.
Final words
Any UI change has the potential to be contentious, and changes have to be judged carefully. Here, we feel we've addressed a significant usability problem that affects many users, with a design that is clear, fast to use, discoverable, and surprisingly minimal for a large effect. It also exposes functionality previously hidden in a context menu. Feedback is very welcome: we make these changes so that you can work better. Let us know how we're doing.
Read More
