5:54 p.m.
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
8:20 p.m.
Joseph Marques wrote:
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?
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?
-joseph
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
8:40 p.m.
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
8:44 p.m.
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
10:38 p.m.
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
5:22 p.m.
I think we're confusing the names of our internal modules with the
terminology that a user will think about. Yes, we have a very specific
events subsystem, but I never thought of the events tab as being
exclusive to that subsystem. The user doesn't care about the internal
workings, they just want to look at "events" on a resource. I think that
can include all alerts, and operations and other subsystem events in
addition to our internal event management mechanism.
Not that I don't like the idea of a summary page... In fact it was one
of the recommendations of our UI review. But then my other concern would
be getting summaries of the other pages displayed (probably in a
multi-columnar layout) and the fact that the timeline isn't yet
historically browsable.
-Greg
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
7:32 p.m.
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
9: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
10:19 p.m.
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
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
10:28 p.m.
1.
1280x1024
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
28.65%
2.
1024x768
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
17.12%
3.
1680x1050
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
15.63%
4.
1280x800
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
13.29%
5.
1440x900
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
8.25%
6.
1920x1200
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
5.61%
7.
1400x1050
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
4.12%
8.
1600x1200
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
2.48%
9.
1152x864
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
1.64%
10.
1280x768
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
1.09%
Stats from our docs server
Heiko W.Rupp wrote:
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
10:31 p.m.
Darn rich editor....
1. 1280x1024 28.65%
2. 1024x768 17.12%
3. 1680x1050 15.63%
4. 1280x800 13.29%
5. 1440x900 8.25%
6. 1920x1200 5.61%
7. 1400x1050 4.12%
8. 1600x1200 2.48%
9. 1152x864 1.64%
10. 1280x768 1.09%
Greg Hinkle wrote:
1.
1280x1024
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
28.65%
2.
1024x768
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
17.12%
3.
1680x1050
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
15.63%
4.
1280x800
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
13.29%
5.
1440x900
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
8.25%
6.
1920x1200
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
5.61%
7.
1400x1050
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
4.12%
8.
1600x1200
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
2.48%
9.
1152x864
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
1.64%
10.
1280x768
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr...
1.09%
Stats from our docs server
Heiko W.Rupp wrote:
>
> 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
>
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
11 p.m.
For the record, I'm at 1280x1024. Today I can see all the tabs iff a) I
maximize the browser window and b) the left nav is not overly wide.
5555
days inactive
5556
days old
12 comments
4 participants
participants (4)
-
Greg Hinkle -
Heiko W.Rupp -
John Mazzitelli -
Joseph Marques