Community
Participate
Working Groups
Platform: RHEL 3.0 WS When adding a behavior to a test suite, I have run into a usability issue. Specifically, when I have a loop and want to add an invocation to it, Ithere are two ways which to me should be the same but aren't. One: I can select the loop and right click, then add an invocation. Two: I can use the Add... button. Unfortunately, this doesn't add the invocation to the loop that I have selected in the editor. This seems odd to me. Furthermore, there is no F1 help on the Add button, which would possibly explain to me that this only adds items to the toplevel, not nested within a selected item. In my opinion, this is a bad usability issue and deserves a high BP. One way to fix this would be to simply add F1 help to the Add button or change the text to something that leaves no doubt what function it serves.
Reassigning as requested.
I also ran into this issue with jUnit test suites on windows xp. I agree that this severely impacts the usability of the junit test suite definition. I would suggest working with usability to improve this section. One possibility is add/insert/remove but that can have issues of its own. I would recommend against having the "add" action change based upon how you access it. I do not think that F1 help would fix this problem since some users do not know F1 help exists.
I agree that a F1 help or a tootip is not user friendly to explain the behavior of a button. This behavior should be described by the label of the button itself to be comprehensible upon first display. To solve this issue, two additional buttons will replace the 'Add...' button. The 'Add Sibling' and 'Add Child' buttons (in addition to the existing 'Remove', 'Up' and 'Down' buttons) will clarify the use of the tree section in the editor. The associated add child action will add the element after the last child of the selected item. The associated add sibling action will add a new element below the selected tree item. You can see an example of that behavior in the eclipse schema editor with its 'New Element' and 'New Attribute' buttons.
Dominique, we had a TPTP UI Meeitng November 17th to discuss this issue and Patrick was involved in this discussion. I am copying the meeting notes that were distributed to the TPTP mailing list. Please note there was agreement on a design to resolve this issue. We wish to have all tree-based editors within TPTP (and that build on top of TPTP) follow a same User Experience. Meeting notes from this week's TPTP UI meeting: (Nov 17, 2004) Agenda: 1. Define a consistent approach for flat-look editors that have a tree where you can add siblings and children. Different editors in TPTP (Hyades) are doing this differently, so we need to find the right way to do this and use it across the board. 2. Discuss paging in views. Some of our views, like the log view, have the idea of paging. This is used to limit the amount of data being shown in the view at any time. Because this is something we'd probably want to do in most (if not every) view, we should come up with a standard way to present it. Attendees: Alex Nan Curtis d'Entremont David Hodges Eugene Chan Marius Slavescu Martin Boag Patrick Nedelec Terry Fountoulakis Wayne Ho (incomplete list - I apologize for not catching all your names) Time: Wednesday, Nov. 17, 12:00pm (noon) EST. Notes: Here are the conclusions reached from the discussion on flat-look editors with trees: 1. The following buttons should appear in all flat-look tree editors (in this order and with these specific names): Add, Insert, Remove, Up, Down. 2. The add button adds an appropriate item (editor-specific) one level down from the selected item (a child), at the end of the list of children. 3. The insert button inserts an item immediately after the selected item (a sibling). 4. Tooltips should be present on the buttons, and are editor-specific. 5. The items in the context menus should perform exactly the same operations as the corresponding button in the editor. 6. Cut/Copy/Paste actions should be enabled (drag-and-drop too?) On a related note, it was noted that not all editors follow the same flat-editor look. Eclipse now has guidelines for flat-look editors, which should be followed. It is suggested to use EMF-based editors, as they provide much of the implementation for free, and already adhere to the guidelines (mostly, if not completely). Alex Nan to open a feature request for this. On the topic of paging, the rationale and approaches to paging were discussed, but there were no major conclusions due to lack of time. The discussion will continue in a later meeting. Since we're closing down i2, there won't be a meeting next week unless there are urgent topics to discuss.
I need to clarify my above comment (#4). In my comment in bugzilla #73031, I probably should have only highlighted the relevant portions of the TPTP UI Meeting minutes from November 17th (see below) that discuss the design discussion on buttons in the tree-based editors: "Here are the conclusions reached from the discussion on flat-look editors with trees: 1. The following buttons should appear in all flat-look tree editors (in this order and with these specific names): Add, Insert, Remove, Up, Down. 2. The add button adds an appropriate item (editor-specific) one level down from the selected item (a child), at the end of the list of children. 3. The insert button inserts an item immediately after the selected item (a sibling). 4. Tooltips should be present on the buttons, and are editor-specific. 5. The items in the context menus should perform exactly the same operations as the corresponding button in the editor. 6. Cut/Copy/Paste actions should be enabled (drag-and-drop too?)" Other parts of the minutes are somewhat out-of-date or misleading now. The text in the minutes about "Eclipse now has guidelines for flat-look editors..." and EMF-based editors is somewhat incorrect/out-of-date. It isn't so much that there are guidelines, but Eclipse now supports the flat look editor officially (FormWidget). There is actually a TPTP feature to have all editors using the Flat Look update to the new officially supported Flat Look (see Bug 74949) https://bugs.eclipse.org/bugs/show_bug.cgi?id=74949
*** Bug 83089 has been marked as a duplicate of this bug. ***
Fixed. For the cut-copy-paste actions and D&D, an enhancement has been submitted (see bugzilla #88061).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
