Disambiguation changes for RHQ4

Jay Shaughnessy jshaughn at redhat.com
Thu Mar 10 22:11:07 UTC 2011


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):



And in other places, like portlets, we have a more verbose resource field:



Currently, in both views the Ancestry provides "hover" information that 
gives type info to supplement the resource name info:



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
>


More information about the rhq-devel mailing list