as of last night, the events tab will now only show up when the resource (or compatible group) you're viewing supports the events. the result of this, in short, is that we need to find a new home for the timeline view. if you go to the events tab for some JBAS instance in inventory, you'll see the timeline subtab. the problem lies in the fact that the timeline view displays data from several different subsystems: availability history, logged event, executed operations, triggered alerts. as a result, if we kept timeline under the event tab, you could only get to it if your resource supported events...but then you lose the ability to view the other types of data this composite view can display. so, the question is...where should this view go? some options so far: 1) as it's own tab for a resource (alongside monitor, events, configuration, operation, alerts, content) 2) as a subsystem view (alongside config updates, problem resources, etc at /rhq/subsystem/layout/main.xhtml path) for option #1, the fit is rather natural, but there is some concern that "timeline" doesn't correctly implement what a resource tab is attempting to model (a resource-wise view of each subsystem). while i agree with that assessment (because timeline is a composite view) i nonetheless think this is a good target. for option #2, the fit is less than ideal, but it still might have value. the problems i see here is that we would still need a way of selecting a resource before the timeline view could be displayed. subsystem views are supposed to be cross-cutting views (and, in that respect, it's similar to timeline) but subsystem views are single subsystems across all resources in the system (whereas timeline is multiple subsystems across a single resource). clearly, the timeline view lies somewhere in the middle. so, what do other people think? should it be a new tab on a resource, or should it be a subsystem view that allows you to select different resources?

-joseph _______________________________________________ jopr-dev mailing list jopr-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jopr-dev

> 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

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

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?

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.

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).

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

Am 15.02.2009 um 21:15 schrieb Joseph Marques: > the dual monitors i do my primary development on are standard aspect > ratio (though, my resolution is 1600x1200). yes, there are a We should cater for people with 1280 px in screen width. The following is from the web server of one of my domains: 1280*x makes 45% of all views and 1024*x makes for another 23%. 1280x800 29.9 % 1024x768 23.5 % 1280x1024 15.9 % 1440x900 8.2 % 1680x1050 7 % Others 15.2 % One may estimate that IT ops have the big screens, but we should not count on it. > 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 This lots of tabs worries me. And the lots of meicoa icons > 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", On the other hand, there are many people out there, that especially see Word as the prime example of complete feature overload. > "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]). Icon only is bad. There are a few standard icons (e.g. disk symbol to save), but otherwise most of time the same icon has three different meanings in two programs. >> 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. Yes indeed. Adding the display timerange there would allow to see historic data. RHQ-1496 has code to dynamically load availability data and to autorefresh the timeline, so that users could change the range and a refresh of the timeline would show the right stuff. Simile also has a tiemeplot library, that is timeline + graphs, so one could even put some indicator charts in it. Heiko