Closed Bug 359624 Opened 18 years ago Closed 14 years ago

Week/Day(Multiday) view hour height(width) controls: expand, shrink

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 366989

People

(Reporter: gekacheka, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061029 Calendar/0.4a1

Week view and Day view (Multiday view) need some way for the user to adjust the height of the hour boxes when time axis is vertical, or the width of hour boxes when the time axis is horizontal.   

No one size is optimal for all situations: when viewing short events, need an hour size large enough to make the event title legible in the short box; on the other hand, a short hour size is necessary for a view over a whole day to fit in a window.  (This problem is even more an issue on smaller/cheaper/mobile/projection screens.)

This bug explores one simple approach: expand/shrink controls.  Each click on expand enlarges the hour size.  Each click on shrink reduces the hour size.

Reproducible: Always




Background: Bug 349509 requests an investigation of possible approaches.

The current approach is to use a fixed size (pixels/hour) in each view.

A previous approach chose the size based on the length of the workday and the size of the window, but this is also inflexible.

This bug takes the approach that the best size also depends on:

* the content: Are event titles legible?  Are the titles meaningful in the first few letters, or does the user need to read more of the text to understand the events?  Are there concurrent events reducing the space available to show the title?

* what the user is doing at the time: Taking an overview, or reading detail?  Scheduling a multi-hour event, or squeezing in a 15minute event?

Therefore, the user needs control over the size.
This bug investigates simple expand/shrink buttons.
(patch -l -p 2 -i file.patch)

Adds two images for buttons to calendar-multiday-view.
Buttons call new methods expandPixelsPerMinute() and shrinkPixelsPerMinute().
Buttons are styled with CSS images, so they are themable.
Adds text for tooltips.

(patch depends on patch from bug 358692)
Attachment #244771 - Flags: first-review?
Please see [http://wiki.mozilla.org/Calendar:Review_Process] and 
[http://wiki.mozilla.org/Calendar:UI_Ownership] for help on how to ask correctly for patch review and UI review.
Comment on attachment 244771 [details] [diff] [review]
v1 patch multiday-view to add expand/shrink buttons

Ask review from someone specific (you know the people), or not at all.
Attachment #244771 - Flags: first-review?
Evaluation:

To me, it is a relief to be able to adjust the hour size so I can read more text when I need to, and reduce it for overviews.  It confirms that the view needs to provide some way to control hour size.

The buttons provided satisfactory adjustment, but not fine control.  So far I haven't needed fine control, so that may be more a matter of giving a polished  feel, not a matter of missing needed function.

There is a slight feeling of awkwardness, maybe partly because of the glitch described below, and partly because resizing occurs in jumps, whereas everywhere else in the UI (resizing windows, resizing split panes, scrolling) similar operations are performed smoothly with fine control by dragging the mouse.  (But I haven't thought of any good ways to drag the mouse for this operation yet; for example, dragging period to be visible might work for expanding hour size, but to shrink hour size, the drag region would go out of the view.)

Future work: If something like this approach is chosen, need to address the following (maybe in future bugs):

1. Minor: The size should persist.  Resizing or reorienting loses the size.

2. Trivial: If the window is large, a display glitch may appear in the grid for a moment whenever expand or shrink is pressed, maybe due to Gecko asynchronously redisplaying between or during resize and rescroll.  I don't know if there is a way to avoid this.  (Since it only happens for me on larger window sizes, might not happen at all for faster processors.)  Maybe because of this glitch, it feels slightly unrefined to have to click multiple times to acheive another size, and some users might want to be able to jump directly to a size and avoid the glitches (maybe with a slider like in Google Maps).  

3. Need to add equivalent actions to the View menu so it will be accessible via keyboard.  (It was easier to just add buttons to multiday-view for this experiment.)
Blocks: 349509
Depends on: 358692
I like the idea, but i think that using normal toolbar buttons would work better. That's where you expect buttons to be.

About the patch: would it be technically feasible to not keep the top line as top line when zooming in, but keep the middle line? I mean, that is what you are most likely looking at.
Comment on attachment 244771 [details] [diff] [review]
v1 patch multiday-view to add expand/shrink buttons

bug 366989 contains current work that implements controls as toolbar buttons and menu items.
Attachment #244771 - Attachment is obsolete: true
No longer blocks: 349509
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: