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_cat...
>>
>>
http://www.smartclient.com/smartgwt/showcase/#grid_grouping_dynamic
>>
>> -alan
>>
>>
>>
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel