Disambiguation changes for RHQ4

Lukas Krejci lkrejci at redhat.com
Wed Mar 9 12:48:38 UTC 2011


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#Disambiguati
> >>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search-results-old-vs-new.jpg
Type: image/jpeg
Size: 353228 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110309/13ee00f4/attachment-0002.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search-results-new-reordered.jpg
Type: image/jpeg
Size: 158526 bytes
Desc: not available
Url : https://fedorahosted.org/pipermail/rhq-devel/attachments/20110309/13ee00f4/attachment-0003.jpg 


More information about the rhq-devel mailing list