Disambiguation changes for RHQ4

Ian Springer ian.springer at redhat.com
Fri Mar 11 17:35:31 UTC 2011


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

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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rhq-devel mailing list
>>>> rhq-devel at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com



More information about the rhq-devel mailing list