Hi,
Please review the images of the current implementation and proposed redesign of the main Toolbar.
Responses with your feedback or specific questions about the benefits of either approach are welcome!
Current
Default
Proposed
Default
Project
Debug
Workspace
Issue Tracking
Objects
Tools
We look forward to listening your ideas.
Hi,
Not sure I got the fundamental difference between the current layout and suggested one(s)...
My preferences just in case:
1) I really like all buttons on the given toolbar to be constantly visible and on the same place. This makes the process of locating the needed button to be more fast and predictable and constantly refreshes my memory about available functionality;
2) Context-sensitive buttons applicable to the current context must be within the immediate direct accessibility. E.g. when test code is in the debugging state, the debugger buttons must be on the toolbar but not on the second level of the hierarchy below the 'Debug \/' toolbar button.
Generally speaking, I like the current concept with the common (dynamic) toolbar(s) that are below the main menu and context-specific toolbars that are bound to their windows (Editor, Test Items, Object Browser, etc.). The only minor case here is that some of those dynamic toolbars are not customizable.
Hi Alex, I put these together, hopefully I can clarify things a bit!
The fundamental difference is that, instead of letting users customize every aspect of the toolbars, from individual buttons to whether they appear on screen, I am proposing to make most of their titles constantly visible by default as dropdown headers.
In the current implementation, the right-click menu to activate each toolbar hides which functions are in what groups, and hover text is required to identify buttons. The proposed redesign keeps everything in the same place, with the tradeoff that, aside from Edit and Debug, many items live in dropdowns; although I tried to limit these to ones that don't require "instant" direct access.
I too see the value of common tools below the main menu with context-specific in windows, so this would not abandon that.
Thanks,
Phil
I don't feel particularly strongly one way or the other, but gun to my head, I probably like the new way a touch better.
Hi guys,
First of all, nice to see your job in progress.
My thoughts regarding the toolbars:
1. I like to use my custom toolbars.
2. Some controls have dependencies from the installed extension. e.g. Show Mobile Screen button can be visible only if the Mobile Module is installed on the current instance of TestComplete.
3. From time to time I need to uninstall modules on one of the instances and install it on other. And I am feeling a little pain, because after I have reinstalled mobile module back, my previous custom controls are not restored automatically and I need to restore them manually each time.
Hi,
Good to seen new Toolbar, it look good :)
1- It would be good if "Name Mapping" option is also a part of new toolbar, same like "Objects".
Under "Name Mapping" below feature should be available -
a - Default Configuration
b - New Configuration
c- Configuration Manager .....
Hi Ravik, thanks for the kudos and suggestion! In the coming months, we're also looking to improve workspace-specific toolbars and establish a more direct visual relationship between Name Mapping and the Object Browser, so more accessible controls are definitely under consideration.
