349509 - Investigate size of grid boxes in calendar week view

Status: RESOLVED WORKSFORME

(Calendar :: Calendar Frontend, defect)

Description

[Thomas Benisch]

The size of the grid boxes in the calendar week view should be
investigated. In the current build a value of 0.5 pixels per minute
is used, which corresponds to a vertical size of 30 pixels per
box.

An important question is, if a user rather wants to have an overview
of the whole day (small boxes) or is more interested in event details
(big boxes).

Another aspect of this issue is handling of pixels per minute.
In the current build pixels per minute are rounded to a precision
of 0.1. An alternative approach would be to not round pixels per minute,
but only the pixels, which are the result of a calculation
pixel = time x pixelsPerMinute.

Note, that this is a follow-up of Bug #133107, see comments #27 to #31.

dmose says:
There are a bunch of interesting constraints here including screensize,
screen DPI, CSS pixel -> device-pixel mapping (I know hyatt has blogged
about this some in the Safari blog), font size, box behavior for small
events, etc.

jminta says:
The important question is the way that people use these views.  For large
amounts of manipulation/fine-grained control, the larger values are ideal.
For overviews/at-a-glance summary, the smaller numbers are better.  (The
views with larger pixel values here constantly frustrate me because I can
never see more than half of the time I care about.  The time from 6pm-12pm
is just as important in my schedule as 'normal working hours.')  We need
to come up with a solution that addresses both use-cases.

Comment 1

[gekacheka]

Bug 366989 (grid controls) has a prototype that provides controls to 
'zoom in' (expand grid boxes, decrease hours in view) and 
'zoom out' (shrink grid boxes, increase hours in view), 
so users can adjust the view as needed.

Comment 2

[Thomas Benisch]

Probably this issue can be closed due to the fix for Bug 349520.

Comment 3

[cmtalbert]

(In reply to comment #2)
> Probably this issue can be closed due to the fix for Bug 349520.
> 

--> closing (WFM)