UI Changes in the IDE's View menu
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.
Comments
-
Tuesday, 7 March 2017You're quite right, those are possible place for them. We tried to change fairly little, so that in general, one or two menu items excepted, it would be obvious where to find them after they moved. But we could continue to change if there are better alternatives. Feel free to enter a QP with your suggestions, we'll have a look.
-
Wednesday, 22 February 2017I like the new changes proposed. Somehow I felt that this is a little late in coming. Though as the saying goes, better late than never.
-
Wednesday, 22 February 2017
We're also open to making other UI changes (not just menus, anywhere, so long as there's a good reason for them.) We need to balance consistency and user's habit/productivity interruption while learning a change, with improvement.
Feel free to email me (firstname dot lastname at Emb) with feedback. -
Saturday, 18 February 2017
Nice!
Another thing that might make sense in the View menu is Project Source. I know View Source has been under the Project menu forever, and it can also remain there, but you'd be hard pressed to find a person who hasn't struggled to find this and wonder why it's under Project, but not View. -
Monday, 20 February 2017
Yes - also a list of all open files.
Bit by bit; to keep the changes small, we won't add anything else this release, but please file QPs and send emails with all ideas and requests you have! -
Saturday, 18 February 2017
The obvious way is to have a 10.2/earlier switch in Tools>Environment options.
Unless, of course, the selections could be made user-editable so you can brew-your-own with the menuS -
Monday, 20 February 2017
To switch between the old huge View menu and the new one? I don't think we'd want to do that: the menu changes are beneficial enough to either make or not make. Do you prefer the old version?
-
Monday, 20 February 2017
Well, I don't use the view menu often, so really I don't care.
What would be better for me is to move the compile/build[All] from Project to Run - ask ten programmers, get eleven different opinions.
With such arrangements, there's no one-size-fits-all. For instance, some people prefer the old-style component toolbar, others the new pallette. Sadly, I've even had an EMBT employee claim that the component toolbar is deprecated - no doubt because he prefers the pallette.
A friend of mine always indents begin and end excessively. What drives me insane is that to copy a code block, he'll select from the `b` to the `d`, copy and spend the next half-hour aligning the result, rather than selecting from the start of the begin line to the start of the line after the end and copying - no realignment required and you don't have to hunt for the `b` and `d`. But he won't change - to the extent that he'll deliberately 'prove' his method is quicker by counting the time taken to hold a federal inquiry about where to start and end the copy as part of the copy-time.
Everyone's different - different cultures prefer different groupings. People who have learned to use a clumsy layout over twenty years will no doubt have difficulty re-learning a new layout - no matter how 'more convenient/logical' it may seem to you or I. Personally, I believe I'd prefer to have the menu in order of frequency-of-use.
But since my subsciption has run out, I'm stuck on 10.1.1 anyway. There was a claim that if you were on 10.1 then you could install 10.1.2, but this seems not to be. The cost for a hobby programmer to go to 10.2 is prohibitive, hence my opinion on this matter will probably carry as much weight as it has on many suggestions to Borland/Inprise/Codegear/EMBT over these last 20+ years. -
Wednesday, 22 February 2017
> There was a claim that if you were on 10.1 then you could install 10.1.2
You need to have active subscription, but yes, if you subscription was active at the time you should have been able to install. If not, please contact Support.
I know the price is expensive, but maintaining subscription and getting new features is better than paying a larger price to upgrade after dropping it, later.
Re the component toolbar: the Tool Palette is definitely the most common option now, but the old-style component toolbar was re-added to the product for a reason: people like it. By definition, it's not deprecated. -
Monday, 20 February 2017
You should tell your friend about the built-in code formatting.
-
Saturday, 18 February 2017The example which Palle refered to solves the function I want for "split editor".
In C++ it is very convenient to have a way to view the corresponding headderfiles (.h/.hpp) to your .cpp/.c file. This can be done in multiple ways. One solution is of course to launch another (full ?) editor. Anyway, since your topic is "small workspace"... it could also be solved by a multiple split pane way. Since most of us seldom has a workspace with more than 80 characters, there should be space on the right side of the workspace to show the (local) headderfiles. -
Monday, 20 February 2017
That's a good point, and would be a nice feature.
-
Friday, 17 February 2017
" 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. "
Amen! - Microsoft product managers should be required to have this tattooed on their foreheads... -
Friday, 17 February 2017(About 800 pixels, many laptops are still 1366x768) an "emergency" merge/regroup could be done until fit.
On the order of items, most commonly used at top is fine, but alphabetical order sometimes lets you arrive faster the brain is faster than the eyes -
Friday, 17 February 2017
Hi David, I think this change is good. I don't often use that menu as I tend to use keyboard shortcuts but when i do us it, it can be difficult to quickly find the item you want.
-
Friday, 17 February 2017
I like this!!!
Consider also functions like 'split editor' like the early versions of Borland editors, 'duplicate editor' like Android Developer style, and C++ specific like 'header file extend...' I think I have mentioned it before...
Anyhow, some tidying up helps of course.. -
Friday, 17 February 2017
Glad you like it!
Can you expand on what 'duplicate editor' and 'header file extend' do, please? Re the first, you can already have two editor windows open for the same file. -
Saturday, 18 February 2017
And last time I mentioned this, maybe you remember
https://plus.google.com/115781991851837617898/posts/ZVBQnJG3Zdf -
Saturday, 18 February 2017
You should work out to include drSplitEditors as standard:
http://blogofonesource.blogspot.dk/2011/09/spliteditors-v10.html -
Please login first in order for you to submit comments
I like the regrouping. However, burying a bunch of items under sub-menus isn't necessarily the best answer either. Maybe we need to look at what is on the "View" menu and determine if this is the best place. "View" could be an adverb for just about anything, including "View Project Source". For example, "Project Manager", "Project Statistics" and "(Project) Configuration Manager" might be better suited on the "Project" menu. "Welcome Page" could then appear at the top of the "IDE Layout Management" section. Maybe the "Project" menu would also be a better place for "Broadcast to devices" and "Multi-Device Preview". Something to think about.