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. 27, 2004)


Topic:

- Continue the discussion on profiling filters in hyades. There are still some issues to resolve on the UI side such as how to present the "common" filters from piAgent so that the user understands, and how to deal with different filter pages for other profiling types that don't use the same filtering options (or possibly don't even have filters). There are also some improvements needed on the view end.

Attendees
:

Allan Pratt
Curtis d'Entremont
David Hodges
Eugene Chan
Glenn Weidner
Terry Fountoulakis
Wayne Ho

Time
:


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

Notes
:


This was more of a brainstorming meeting and to get everyone up to speed with the current state of filtering and where we should be going. Many problems were raised and noted in this meeting, for which we need to come up with solutions. Here is a list of some of these:

1. Some profiling types have their own separate filtering, but the 3 hyades profiling types share common filtering (how to present this to the user). It was said to be unfeasible for the piAgent to have the notion of profiling types.
2. The RAC always always sends back certain special classes like java.lang.Class even if we explicitly try to filter them out. Since there is no filtering in the loaders to handle this, the user always sees these.
3. View filtering is too weak. You can only filter by name.
4. Profiling types outside Hyades do not necessarily use the same filtering options and UI, and some profiling types might not have any filtering at all. So we can't just always show the same filtering UI - it has to vary by profiling type.
5. We can't simply use the same filtering UI for the views as the data collection filters. Different profiling types can use different filtering UIs, but the views don't know (and don't care) how this data was collected - so we don't know what kinds of view filters to show.
6. Filter sets are handled differently than profiling sets. One shows all the content there and it's editable, but the other requires opening a separate dialog to edit it. Users may be confused as to whether changing the contents in one location affects only this case or all other things that use the filter set.

Some terminology was put forth:

Pre-filtering: Filtering done at data collection or loading time (before the data gets to the model).
Post-filtering: Filtering done at viewing time, after the data is in the model. These can be changed and undone, but pre-filters can't.

We went through Geary's requirements document and agreed that these are all good ideas. Some of the key points listed are consistency, persistence and team (sharing filters). The next step is to start prioritizing which of these are most important, and come up with some solutions. I know I didn't get all the details of the meeting in these notes, so if I missed something important please remind me. If we don't have an agenda for next week's meeting, we'll continue on with the filtering discussion.

Thanks
Curtis d'Entremont
Problem Determination Tools
IBM Toronto Lab

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


Back to the top