Disambiguation changes for RHQ4

Jay Shaughnessy jshaughn at redhat.com
Fri Mar 11 16:04:14 UTC 2011


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


More information about the rhq-devel mailing list