Disambiguation changes for RHQ4

Ian Springer ian.springer at redhat.com
Fri Mar 11 17:39:47 UTC 2011


On 03/11/2011 12:35 PM, Ian Springer wrote:
> Jay-
>
> Looking good.
>
> I'm in agreement with your proposal. I also agree the tooltip format
> needs some work. I don't think it's immediately clear that the 2nd line
> is the type hierarchy. Since we're not constrained for space, I'd add a
> label to make it obvious, and perhaps also add a label to the ancestry
> names, e.g.:
>
> Ancestry Names: JVM>  RHQAgent>  jshaughn
> Ancestry Types: RHQ Agent JVM>  RHQ Agent>  Windows


Oh yeah, I also like your idea of aligning the separators, so the names 
and types can be easily correlated, i.e.:

Ancestry Names: JVM>  RHQAgent>  jshaughn
Ancestry Types: RHQ Agent JVM>  RHQ Agent>  Windows


> Also, it's not intuitive that the ancestry starts at the resource's
> parent rather than at its root ancestor. To me, the ">" signs generally
> imply starting at the root of a hierarchy. So I would either try
> reversing the ">" signs, e.g.:
>
> Ancestry Names: JVM<  RHQAgent<  jshaughn
>
> or explicitly calling out the order, e.g.:
>
> Ancestry Names (starting at parent): JVM>  RHQAgent>  jshaughn
>
> or both:
>
> Ancestry Names (starting at parent): JVM<  RHQAgent<  jshaughn
>
> I also like the idea of embedding P/S/S icons in the ancestry, in the
> table and in the tooltip. It would be particularly useful in the table,
> where the ancestry types are not shown, e.g.:
>
> [Service icon] JVM<  [Server Icon] RHQAgent<  [Platform icon] jshaughn
>
> In this case, it would tell the user that jshaugn is a platform, which
> otherwise is not obvious.
>
> - Ian
>
> On 03/11/2011 11:04 AM, Jay Shaughnessy wrote:
>> I moved this info to wiki if you'd rather see it there:
>> http://www.rhq-project.org/display/RHQ/Disambiguation+API#DisambiguationAPI-CurrentDesign%28subjecttochange%29
>>
>> On 3/10/2011 5:51 PM, Jay Shaughnessy wrote:
>>> Where oh where did the pictures go... let me try again
>>>
>>> On 3/10/2011 5:11 PM, Jay Shaughnessy wrote:
>>>> Thanks for the input so far.   What I'm hearing:
>>>>
>>>> - The rhq3 solution favored the ability to disambiguate given the
>>>> on-screen information.
>>>> - There are several corner-cases that make a single display format
>>>> difficult.
>>>> - The rhq3 solution can be difficult to parse and/or understand given
>>>> lack of visual uniformity (the trade-off for putting it all on screen)
>>>> - Try and utilize smargwt as best as possible.
>>>>
>>>> So after playing with this stuff for a bit I've been looking at two
>>>> different formats for the Resource/Name column in various views.  In the
>>>> Inventory Views we have just the resource name and the ancestry resource
>>>> names (note that here we also have Plugin and Type columns but that is
>>>> more the exception than the rule):
>>> inventory view
>>>> And in other places, like portlets, we have a more verbose resource
>>>> field:
>>> portlet
>>>> Currently, in both views the Ancestry provides "hover" information that
>>>> gives type info to supplement the resource name info:
>>> hover
>>>> Note that there has been no attempt made in rhq4 to mimic the
>>>> contextual, varying display, approach used in rhq3.  At the moment the
>>>> column formats for name and ancestry are fixed.
>>>>
>>>>
>>>> I think I'm in favor of the following approach:
>>>>
>>>>       1. The Name/Resource column should be consistently named.    For
>>>>          consistency throughout the UI I would recommend 'Resource'.
>>>>          'Name' is not sufficient  as resource information is often
>>>>          embedded in views of a different contxt, like in the portlet
>>>>          above.  Also 'Resource Ancestry' makes more sense than 'Name
>>>>          Ancestry'.
>>>>       2. On screen we limit the 'Resource' column value to the resource
>>>>          name (like shown above for the inventory view), and 'Ancestry' to
>>>>          the resource name ancestry (as shown above).  This provides a
>>>>          consistent, clean viewing experience that in many cases will
>>>>          provide enough D12N for the user, in the given context. Since all
>>>>          of the values are links the fonts and colors are uniform.
>>>>       3. Provide Hover information for both Resource and Ancestry values.
>>>>          This is more than what we have at the moment, which is just for
>>>>          Ancestry.  Although expanding rows are nice, we use that
>>>> elsewhere
>>>>          in the GUI for different purposes. Typically to provide detail
>>>>          about the above row (like audit info) as opposed to a more
>>>> verbose
>>>>          rendition of the same. Also, it requires a click which is a bit
>>>>          more work than hover for performing D12N between rows.
>>>>       4. For the Resource I think the hover should contain the Plugin,
>>>> Type
>>>>          and Resource Name.  A format like seen above, simple, unchanged
>>>>          for different locales, maybe:
>>>>                    * PluginName TypeName *ResourceName*
>>>>                    * PluginName  TypeName *ResourceName*
>>>>                    * PluginName / TypeName *ResourceName*
>>>>                    * PluginName, TypeName *ResourceName*
>>>>                    * [PluginName] TypeName *Resource Name*
>>>>       5. For the Ancestry things are a little trickier. I don't love the
>>>>          current hover format, the staggered rows are hard to parse. But
>>>>          the separation of name and type into two hierarchies is fairly
>>>>          clear.  Addtional ideas:
>>>>              * Single line (could get very long) :
>>>>                    o [RHQAgent] RHQ Agent JVM *JVM>    *[RHQAgent] RHQ Agent
>>>>                      *RHQ Agent>    *[Platforms] Windows*jshaughn*
>>>>                    o *
>>>>                      *
>>>>              * I'm a bit afraid of a tall, tree-like format, but it may
>>>> work:
>>>>                    * [Platforms] Windows*jshaughn***
>>>>                    *>    [RHQAgent] RHQ Agent *RHQ Agent *
>>>>                    *>    [RHQAgent] RHQ Agent JVM *JVM*
>>>>                    * *
>>>>                      *
>>>>              * or maybe even a table format (if I could figue out how to
>>>>                format that so the columns are even):
>>>>                    o RHQAgent  RHQ Agent JVM *JVM*
>>>>                    o RHQAgent  RHQ Agent *RHQ Agent*
>>>>                    o Platforms Windows*        jshaughn*
>>>>                    o *
>>>>                      *
>>>>       6. For inventory views, keep Plugin and Type columns. It allows for
>>>>          more sorting options and can provide D12N help.  I suggest
>>>>          actually we reorder the columns to be Ancestry, Plugin, Type,
>>>>          Description.  I think this is most useful for D12N,
>>>> description is
>>>>          generally not looked at, I think. Also, in general display plugin
>>>>          to the left of type.  I think it's a bit clearer to prefix the
>>>>          type with its defining plugin.  Although verbose, since plugins
>>>>          can and do share type names, I think we have to keep plugin name
>>>>          in the D12N display.
>>>>       7. In certain views, like selectors, there is only one column, In
>>>>          this case the hover should combine the Resource and Ancestry
>>>> info.
>>>>
>>>> So, the approach is basically to favor a clean, uniform look over
>>>> immediate coverage of all D12N scenarios. And to use hover for more
>>>> verbosity when required.
>>>>
>>>> Jay
>>>>
>>>>
>>>> On 3/10/2011 11:02 AM, Alan Santos wrote:
>>>>> On Mar 9, 2011, at 9:09 AM, John Mazzitelli wrote:
>>>>>
>>>>>> IMO, the main problem with the JSF UI D12N columns is that it is
>>>>>> hard to
>>>>>> understand or interpret those D12N columns easily when there is more
>>>>>> complex hierarchies to be displayed... they aren't "user friendly".
>>>>>>
>>>>>> Even when I see them - I have a hard time understanding what its
>>>>>> telling
>>>>>> me without me staring at it and thinking about it - it doesn't just
>>>>>> "come to me" for lack of a better way to explain it.
>>>>>>
>>>>>> I guess what I am saying is - it should be made more intuitive.
>>>>>>
>>>>> ditto. I'm confused by the order and content of a few columns. I
>>>>> also think putting everything into a single, flat row makes it more
>>>>> confusing.
>>>>>
>>>>> So, some specific thoughts that I hope are helpful:
>>>>>
>>>>> *) I don't understand the point of the resource type in the first
>>>>> column.  The user can't sort on that column and my suspicion is that
>>>>> the user cares much more about the information in the 'type' column
>>>>> than the server/service/platform column. It's also redundant when
>>>>> searching from the inventory report pages.
>>>>>
>>>>> *) Plugin column - does this really matter for the typical
>>>>> use-cases? If I'm trying to debug a new plugin or perhaps deployment
>>>>> I can see the value, but otherwise I don't.
>>>>>
>>>>> *) We've committed to smartgwt, so why not take advantage of it?
>>>>> e.g.
>>>>> http://www.smartclient.com/smartgwt/showcase/#grid_expanding_details
>>>>> http://www.smartclient.com/smartgwt/showcase/#tree_appearance_multicolumns
>>>>>
>>>>>
>>>>> I frequently hear that the UI displays *too much* information.  I
>>>>> don't know if it's possible, but displaying only the important
>>>>> subset of information and retrieving the rest when the user asks
>>>>> (e.g. expands the row) seems like it might solve some problems in
>>>>> the UI as well as the server.
>>>>>
>>>>>
>>>>> *) why not take advantage of grouping?
>>>>>
>>>>> I think it's perfectly reasonable to provide a default grouping
>>>>> (e.g. platform or managed type). If I'm not mistaken smartgwt makes
>>>>> it pretty easy to let the user change grouping.
>>>>>
>>>>> e.g.
>>>>> http://www.smartclient.com/smartgwt/showcase/#grid_summaries_featured_category
>>>>>
>>>>> http://www.smartclient.com/smartgwt/showcase/#grid_grouping_dynamic
>>>>>
>>>>> -alan



More information about the rhq-devel mailing list