Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[hyades-dev] Hyades UI meeting notes (Oct. 20, 2004)


Meeting notes from this week's Hyades UI meeting:

Topics
:


1.  Discuss datapool data entry and Hyades editor overview tab. There are a few things not covered in the user experience document for the datapool editor because there hasn't been an agreement on requirements or it's a Hyades-wide issue not limited to datapools. Specifically, these are equivalence classes and overview tabs in editors. (bugzilla 73178, 74864)

2. Filtering improvements for launching in profile mode. Currently in Hyades we allow users to filter out packages, classes, and methods to profile, but the UI for this is hidden. The user has to edit the profiling set and click next in the wizard that appears. One idea put forth was to associate filters with each profiling type. The problem with this is that the Hyades piAgent does not support this - you can only set one filter for all the data coming in. We need to discuss alternative and better ways to present filtering to the user. (bugzilla 53760, 74857)

Attendees
:
Ashish Mathur

Bianca Jiang
Bill Tobin
Curtis d'Entremont
Geary Ridings
Glenn Weidner
Joe Toomey
Jonathan Hoover
Martin Boag
Serge Lucio
Wayne Ho

Time
:

Wednesday, Oct. 20, 12:00pm (noon) EST
.

Notes
:


1. Datapool UI:

(Thanks for the notes, Wayne)

Equivalence Classes
( https://bugs.eclipse.org/bugs/show_bug.cgi?id=73178)

Creating a new Datapool:
  • On creating an empty datapool, users are prompted for the initial table size by prompting users for the Number of Variables (Columns) and Number of Rows (Records).  Do not use the term "Equivalence Class" when prompting for the dimensions.
  • On creation of a new datapool, an initial and default equivalence class will be created for the user.  This supports novice users as they need not concern themselves with equivalence classes and simply use the default one.
  • The datapool editor will open to the Data Table by default upon creation of a new datapool with only a single equivalence class.

Creating additional equivalence classes:
  • Equivalence classes will appear as tabs of the Datapool editor.  When multiple equivalence classes exist, the tabs would be:
    | Overview | EquivalenceClass1 | EquivalenceClass2 | EquivalenceClass3 | ...
    (shown at the bottom of the Editor)
    Serge noted Myers' original concept of Equivalence classes and that we would expect users to use 2-10 of them
  • Creating additional equivalence classes can be done via:
    * the Overview Page
    * main editor pulldown menus (e.g., the "Edit" menu)
    * context menu on the tabs similar to Excel worksheets (need to investigate further):

    * Context menu in the Test Navigator (on a Datapool resource)
    * consider Editor toolbar buttons

Overview Page
  • Continue to use the Overview page
  • Enhance to allow creation of new equivalence classes
  • Enhance to allow selection of the default equivalence class

Editing a Datapool
  • Simplify the context menu: remove Equivalence Class items from the menu.  The context menu should contain Cut, Copy, Paste.  
    Note: additional consideration is required to define the exact contents of the context menu (e.g., should we continue to allow users to add rows/columns via the context menu in a similar fashion to spreadsheets or word processing tables?)
  • During the meeting we discussed sorting the data by clicking on the column heading should sort the data by the selected column in ascending order.  Clicking on the column heading again will then sort the column in descending order (clicking will alternate between ascending/descending as in other Hyades table views).  Another suggestion was to use the context menu to enable sorting.  Sorting may be limited when considering some complex types.
    Note: Does the ordering of the data in the datapool have significance to any products?  If the order of data is important, it may be important to consider when implementing sorting functionality.  We may need to consider allowing users to return the data back to an 'original' order.
  • We also discussed the possibility of reordering columns via drag-and-drop
  • To rename a column, we discussed right-clicking on the column heading.  This might allow users to open up a properties dialog to rename, change type, etc.


2. Filtering UI:

Currently the profiling filters are difficult to find for users. You have to click on Edit in the Profile->Overview tab to edit the profiling set, then click next to see the filters. The original idea was to have filters associated with each profiling type. However, the data collection agent currently has no notion of profiling types and uses a single filter set to apply to everything it collects. However, this is not true for all agents that are contributed to Hyades. There are also problems with other profiling types contributed to Hyades that use entirely different filtering UIs.

There were two approaches proposed:
  • Request functionality from piAgent to be able to use different filter sets for collecting different types of data. This may not be feasible on the data collection side - I will follow up on this and start a discussion with the data collection folks. Each profiling type would have a filter set independent of all profiling types, and can contribute any UI they wish (or use the one we currently use in Hyades). In addition, for more exposure, the filter set for each profiling type would be listed in the profiling set details in the overview tab. Thus, the user could see which filter sets they are using and would then know to edit the profiling set in order to change it. Also, instead of using another wizard page for the profiling sets, we should make this more visible by using tabs - one tab for the settings, and one for the filter. Both of these would be contributed by the profiling type.
  • Keep the 'common' filters for the Hyades profiling types memory, execution, and coverage, but still allow other profiling types to contribute their own. It would have to be made clear to the user that these common filters apply to those 3 types (still not clear how this would be done). We would also expose the filters in the same way by using tabs instead of wizard pages and showing which filter set is used by the profiling types in the profiling set description.

A few other points that were mentioned:
  • Ideally we want the first approach (this was the original design).
  • There needs to be a way to see which filter sets we were using in a launch. This would mean right clicking on a profiling type in the profiling monitor and selecting Properties, or by doing the same on the agent.

There were no clear conclusions as to what the right way to do this is, so we will likely follow up with another meeting on this next week.

Thanks,
Curtis d'Entremont
Problem Determination Tools
IBM Toronto Lab

Phone: (905) 413-5754
E-Mail: curtispd@xxxxxxxxxx


Back to the top