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(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
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel