2:15 p.m.
John Mazzitelli wrote:
I like the metric display range on the summary :) The aggregations of
the different counts is nice too (are those counts relative to the
display range? So, if I see "5 operations executed" and my display
range is 24 hours, does that mean 5 executions in the last 24 hours?
yes, the quick
counts reflect the measurement display range, which means
it also supports going back in time and viewing quick count historical
data (not just "last X units" relative ranges). if we end up keeping
this summary tab, i'd go in and fix the timeline display to match, and
thus display items on the timeline that happened within that display
range as well.
I really do hate all these tabs in here. On my monitor here at home,
its not a wide-screen. Those of you with wide-screen monitors probably
don't see a problem, but with a normal monitor, it doesn't look great.
the
dual monitors i do my primary development on are standard aspect
ratio (though, my resolution is 1600x1200). yes, there are a lot of
tabs, but i'm less worried about the quantity of data shown than i am
about the placement of data and how intuitive things would be to find.
case in point: microsoft word is a "busy" application with it's ten or
so default menus, and the 40 or so icons on the two default toolbars,
but having access to all of those things at a glance because of they
properly named and have somewhat intuitive icons to identity what they
do helps tremendously. i could see us in the future perhaps even
replacing the text of "monitor", "events", "configuration",
"operations", "alerts", "content" with more easily
recognizable icons
altogether (or maybe that would be a user option [icon+text vs.
icon-only vs. text-only]).
But - if we are to add a new tab, I do like the idea of a summary tab.
That should probably be the landing tab when selecting a new resource
from the Browse Resources (or any link when moving from a page without
a resource in context).
i would agree, it would be an ideal place to place links
that don't
explicitly navigate to one of the other tabs via the "mica" icons.
Joseph Marques wrote:
> ask and you shall receive. ; )
>
> you can either comment on the screenshot attached to
> http://jira.rhq-project.org/browse/RHQ-1575 or svn up to rev3061 and
> play around with it. currently, since this *is* a prototype, i
> haven't done anything for autogroups or resources groups yet. i'm
> open to any and all ideas on what each summary tab should show,
> including the one that i took a screenshot of in RHQ-1575.
>
> John Mazzitelli wrote:
>> My concern with another top level tab is the width of this. The
>> width of the resource view is too long as it is right now (IMO).
>> Adding *another* tab makes it wider no? At least, it widens the
>> number of tabs. Guess I'd have to see it.
>>
>> Having a summary landing page sounds like the best idea yet! This
>> way, the events mica icon/tab can be hidden from view when needed
>> (which helps my first point about keeping the # of tabs down), adds
>> more similarity to emb jopr (not that that matters all that much,
>> but, its a nice touch) plus like you said its a good fit for the
>> timeline (thus, it doesn't seem like we shoe horned it in
>> somewhere). Of course, I reserve final judgment until I see a
>> prototype :)
>>
>> Joseph Marques wrote:
>>> i still like the separate tab idea better. i want to emphasize
>>> again that the timeline view isn't just events, it's for display
>>> data from multiple subsystems simultaneously. the timeline view
>>> didn't feel right when it lived as a child under the monitor tab,
>>> and i guess it doesn't feel right living as a child under the
>>> events tab either.
>>>
>>> svn up and take a look at the resource browser; it's much cleaner
>>> right now. since only a few resources actually implement the event
>>> facet, the 'e' icon doesn't show up very often, which is a huge
>>> benefit to the "mica" icons in the first place.
>>>
>>> how about an entirely different strategy. greg, you know how we
>>> were thinking of mimicking the embedded console by providing a
>>> landing page. why don't we have a "Summary" tab that provides
>>> quick info about the resource, but where the timeline view will
>>> also live. this way, we'll 1) have consistent navigation for
>>> subcategories (and subsubcategories) because their default click
>>> action from the nav tree would hit this new summary tab, and 2)
>>> we'll have a perfect spot for the timeline page which due to the
>>> fact that it encompasses data from all different subsystems is a
>>> rather good fit for a summary view.
>>>
>>> John Mazzitelli wrote:
>>>> > My suggestion is don't hide the events tab. Why not just disable
>>>> the "history" subtab under events
>>>> > for resources that don't have events... and default the views to
>>>> the timeline?
>>>>
>>>> That sounds good.
>>>> _______________________________________________
>>>> jopr-dev mailing list
>>>> jopr-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jopr-dev
>>>
>>> _______________________________________________
>>> jopr-dev mailing list
>>> jopr-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jopr-dev
>> _______________________________________________
>> jopr-dev mailing list
>> jopr-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jopr-dev
>
> _______________________________________________
> jopr-dev mailing list
> jopr-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jopr-dev
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev