Disambiguation changes for RHQ4

Lukas Krejci lkrejci at redhat.com
Wed Mar 9 14:53:58 UTC 2011


On Wednesday, March 09, 2011 15:09:50 John Mazzitelli wrote:
>  > To continue the debate about the disambiguation providing as much
>  > info about a resource as possible at a glance
> 
> 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".
>

That's why I'm glad we have this discussion. There are reasons behind the look 
and feel that I tried to describe, but the last thing I'd like to do is to 
claim it perfect.

> 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.
> 
> For example, I see in a row, this Resource column (where a link is
> denoted with underscores like _link_):
> 
>      Memory Pool (RHQAgent plugin) _Tenured Gen_
> 
> And this row:
> 
>      _Operating system information_ (RHQAgent plugin)
> 

This is how the singleton resources looked like in the JSF. The reason for 
this is that for singleton resources the resource type name and the resource 
name usually are very similar or outright the same and thus copying the 
approach taken with "normal" resource would result in something like

Operating system information (RHQAgent plugin) _Operating system information_

> Looking at it quickly, I do not know why, or understand the significance
> of, the fact that in the first row "(RHQAgent plugin)" appears BEFORE
> the link but AFTER the type ("Memory Pool") but yet in the second row
> the plugin name appears AFTER the link and there is no type information
> at all.
>

Yes, it is confusing but I found no better way of formatting it.
 
> I'm sure there is a very logical and perfectly valid reason why we only
> show the type in the first row and why the plugin is listed before/after
> the links in the different rows, however, from a users perspective, its
> very hard to parse the meanings of these and they just look different.
> In fact, I still don't know why they look the way they do above, it is
> confusing to me (certainly not intuitive to a user taking a quick glance
> at it). I could find out why they look the way they do, but I really
> shouldn't have to think too hard looking at this data to understand it.
> 
> I guess what I am saying is - it should be made more intuitive.
>

Agreed.
 
> That said, the GWT ancestry UI isn't done yet - the formatting of the
> ancestry column needs to be refined and we need refined tool tips as
> well and we need to look at the JSF D12N implementation to figure out
> what to take from it. The JSF UI conveys a lot of good information that
> we probably still need - its just that we need to reorganize the
> information in the UI so it a) still looks good (the JSF UI does look
> good, albeit confusing) and yet b) still convey the information we need
> to convey without making it too complex.
> 

As I said in the email, I just wanted to point out the decisions we took in 
the JSF D12N. With understanding the problems and decisions from the past I 
hope we will arrive at something better for the GWT UI.

> We need it to be easy to understand and intuitive to the typical user
> (or even advanced user :)
> 
> On 03/09/2011 07:48 AM, Lukas Krejci wrote:
> > Great job at getting this out so quickly, Jay!
> > 
> > To continue the debate about the disambiguation providing as much info
> > about a resource as possible at a glance, I'm attaching an image that
> > contains screenshots of search results of the old and new UI. I realize
> > that what you did in GWT is by no means finished, but by contrasting
> > those two screenshots I want to highlight the design decisions that were
> > made in the old UI and explain them a bit.
> > 
> > I completely agree with you that the old UI looks crowded but on the
> > other hand, it contains more information than the new UI and more
> > importantly the relevant information is *much* closer together, which I
> > think is easier on the eyes and in the end enables the user to "see"
> > what they're looking for more quickly (once they mentally get used to
> > the layout).
> > 
> > The old UI removed the "Type" and "Plugin" columns in favor of inlining
> > that information in the resource name. That put the name and the type
> > right next to each other which makes it easier to find out what that
> > particular "localhost" is. This could be done just by reordering the
> > columns but the reasoning behind merging the columns together was that
> > the plugin column wouldn't be needed most of the time. Another reason
> > for doing this was that not all tables that needed disambiguated names
> > provided the type and plugin columns and it was found easier not to
> > "crowd" the tables with 2 new columns but rather provide a lengthier
> > resource name that could break along more lines. Consider for example
> > the tables in portlets where a bigger number of columns causes the
> > information to be essentially illegible.
> > 
> > On Tuesday, March 08, 2011 20:38:11 Jay Shaughnessy wrote:
> >> The first pass has just been pushed to the git repo.
> >> 
> >> THIS INCLUDES A DB UPGRADE to schema version 2.106.   The upgrade adds
> >> the rhq_resource.ancestry field and also populates it for existing
> >> inventory.
> >> 
> >> Other comments inline...
> >> 
> >> On 3/8/2011 5:10 AM, Lukas Krejci wrote:
> >>> On Monday, March 07, 2011 19:50:36 Jay Shaughnessy wrote:
> >>>> On 3/7/2011 11:49 AM, Charles Crouch wrote:
> >>>>> Looks good. Some thoughts/questions...
> >>>>> 
> >>>>> 1)So an example value in a resource_ancestry column for a Datasource
> >>>>> resource could be?:
> >>>>> 
> >>>>> 10100_:_10101_:_JBoss EAP_::_10010_:_10011_:_mylaptop.test.com
> >>>> 
> >>>> That looks feasible.
> >>>> 
> >>>>> 2) Plugins can't change existing resource names after resource
> >>>>> creation right, even after an upgrade? So that shouldn't be a
> >>>>> problem
> >>>>> 
> >>>>> 3) I know it will be take some crazy set of circumstances to hit the
> >>>>> 4k limit, but can we make sure that if we do hit the limit, that we
> >>>>> just stop writing at the highest complete ancestry level, and don't
> >>>>> end up with "....10100_:_101"
> >>>> 
> >>>> alright, I'll add that check.
> >>>> 
> >>>>> 4) Will this new approach make any changes from RHQ3 in how the
> >>>>> displayed resource's names actually look? IIRC the displayed resource
> >>>>> names change right now based on what other resources are in the list,
> >>>>> we basically do just enough to ensure uniqueness? i.e. we don't show
> >>>>> the full resource hierarchy for every resource in every list view.
> >>>>> Will this remain the same?
> >>>> 
> >>>> No, the approach is different. At least initially.  In RHQ3 we
> >>>> typically saw a "Resource" column.  The value in that column was
> >>>> different depending on the resources in the list. The resource name
> >>>> was always shown.  The type name was added when multiple resources
> >>>> for the same type were present.
> >>> 
> >>> multiple resources of the same name
> >>> 
> >>>> The plugin name was added to that if the type name
> >>>> could come from multiple plugins.  Perhaps more was done, I'm not
> >>>> sure. Additionally, the "Location" column contained ancestry
> >>>> information and also could have varying detail.
> >>>> 
> >>>> In my opinion the RHQ3 approach has some drawbacks.  The varying
> >>>> detail in the "Resource" and "Location" columns is visually
> >>>> disorienting and somewhat hard to understand.  Also, It can be quite
> >>>> verbose in the column layout.
> >>>> 
> >>>> In RHQ4, at least initially, we've gone back to having a simple "Name"
> >>>> column with the resource name wrapped in a navigable link.  The
> >>>> "Location" field is now "Ancestry" and shows the parental ancestry, by
> >>>> resource name, also wrapped in links.  Furthermore, we're integrating
> >>>> hover in various ways.  In the inventory lists you can hover over the
> >>>> "Ancestry" value and also see the parental *Type* ancestry.
> >>> 
> >>> One of the goals of the original disambiguation was for the user to be
> >>> able to distinguish between the 5 "localhost" resources in the result
> >>> lists at a glance.
> >>> For example apache, postfix, samba, jboss-as(5) and maybe even others
> >>> can be called "localhost:port" and have the same ancestry (i.e. the
> >>> platform they're installed on). The user will only be able to
> >>> distinguish these on hover unless they remember what port each of them
> >>> is available on, which I am not sure is ideal.
> >>> 
> >>> Yes, in RHQ3 the contents of the column could vary in the level of
> >>> detail but each element of that "detail" had slightly different
> >>> visuals (type and plugin names in italic, resource name in bold with a
> >>> link) to "guide" the eyes.
> >>> 
> >>> I'm not saying that that is better than what you propose, I'm just
> >>> trying to put the two approaches next to each other so that we can
> >>> pick and choose the good things from either.
> >> 
> >> That's good information.  I like the intent of what was done.  I think
> >> we can probably tweak things to arrive somewhere in between what's there
> >> now and what was in RHQ3.  Hopefully now that it's getting rolled out
> >> more folks will contribute their feedback.
> >> 
> >>>> This is where things stand right now, four days in.  Having said the
> >>>> above, taking the RHQ3 approach, or maybe something in between, is
> >>>> probably doable (paging maybe a problem?).  Given a result set of
> >>>> resources it's possible to process things in various ways, client-side
> >>>> for GWT.
> >>>> 
> >>>> Although not done yet, we'll need to provide the CLI with some utility
> >>>> to decode the ancestry values.
> >>> 
> >>> Also we're going to need some utility in the server code itself so that
> >>> serverside plugins can use this. Alert::Email I think can insert the
> >>> ancestry info in the emails.
> >>> 
> >>>>> Thanks very much
> >>>>> Charles
> >>>>> 
> >>>>> ----- Original Message -----
> >>>>> 
> >>>>>> The proposed changes for disambiguation in RHQ4 have an initial
> >>>>>> design section in the following wiki page:
> >>>>>> 
> >>>>>> 
> >>>>>> http://www.rhq-project.org/display/RHQ/Disambiguation+API#Disambigua
> >>>>>> ti on API-RHQ4Changes
> >>>>>> 
> >>>>>> Please review and question. Thanks,
> >>>>>> 
> >>>>>> Jay
> >>>>>> 
> >>>>>> _______________________________________________
> >>>>>> 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
> >>> 
> >>> _______________________________________________
> >>> 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
> 
> _______________________________________________
> 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