[jopr-dev] request for comments - timeline view

[Greg Hinkle]

    1.  	
1280x1024 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	28.65%
2. 	
1024x768 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	17.12%
3. 	
1680x1050 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	15.63%
4. 	
1280x800 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	13.29%
5. 	
1440x900 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	8.25%
6. 	
1920x1200 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	5.61%
7. 	
1400x1050 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	4.12%
8. 	
1600x1200 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	2.48%
9. 	
1152x864 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	1.64%
10. 	
1280x768 
<https://www.google.com/analytics/reporting/resolutions?id=8816868&pdr=20090115-20090214&view=1#lts=1234733093738> 

	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
>