Disambiguation changes for RHQ4

Jay Shaughnessy jshaughn at redhat.com
Thu Mar 10 22:51:45 UTC 2011


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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delete.jpg
Type: image/jpeg
Size: 43987 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110310/6c24ced8/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delete-1.jpg
Type: image/jpeg
Size: 19398 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110310/6c24ced8/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delete-2.jpg
Type: image/jpeg
Size: 17907 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110310/6c24ced8/attachment-0005.jpg 


More information about the rhq-devel mailing list