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