Event time selection should be in 30 min increments

Bug #1297725 reported by Alan Pope 🍺🐧🐱 πŸ¦„ on 2014-03-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Calendar App
Low
brian larochelle

Bug Description

When scheduling an event, the calendar app lets the user choose a meeting event start down to the minute.
It would make more sense (given we plan to sync with Google Calendar) to create events on 30 min intervals.
Please could you make event times default to 30 min intervals but allow the user to override to any time.

Related branches

no longer affects: ubuntu-clock-app
David Planella (dpm) on 2014-03-26
tags: added: bitesize
Changed in ubuntu-calendar-app:
status: New → Triaged
importance: Undecided → High
milestone: none → hackdays-1403
description: updated
Changed in ubuntu-calendar-app:
assignee: nobody → brian larochelle (larochelle-brian)
David Planella (dpm) wrote :

Note that while the default increment is sensible to have in 15-30 mins, we'd still need to have a means of setting the time to the minute.

tags: added: needs-design
tags: added: bacon-dogfood
michelR (michel-renon) wrote :

Here is a quick proposal based on a simple idea already implemented by OpenERP : hour and minute selection can be made with sliders.
If you're interested, we can make this idea more precise by defining exact behavior.

David Planella (dpm) wrote :

What is clear is that whatever the solution, this is something that the SDK's date picker does not support changing the time increment.

So if we want to implement this, we'll have to go back to a custom picker implementation for the time (we can still use the SDK one for the day, though)

David Planella (dpm) wrote :

Michel, thanks for the proposal!

I'm not sure about the part that implies that the UI shifts to the bottom to display a new time picker. Perhaps a popup might be better, as it would not introduce moving parts and surprise the user.

In terms of using sliders, I'm not too sure, especially because of the fact that it introduces 6 new controls, which would clutter the UI a bit. I'm personally more fond of the solution the clock app uses, which is a nice compromise that allows you to set the time precisely but quickly at the same time. Perhaps we could reuse the clock's time picker for setting the time?

michelR (michel-renon) wrote :

For popups, I just taught that they could only contain a list.
But if it's possible, that's ok for me.

About the controls for minutes, it was just a quick proposal : we could refine it to have less controls, or be more aesthetic.
Initially, the proposal had the hour slider and 4 buttons (0, 15, 30, 45), and 'something (tbd)' that hides the 4 buttons and show the minute slider. But it needs further exploration on the visual side.

I really think that a proposal with slider is interesting :
- it's easy to implement (it can be prototyped and validated/cancelled easily)
- the gestures are very simple : horizontal slide ; while in Clock app it's a circular slide, which is more complicated to execute (but still better that the current time picker)
- it works well with touch and mouse, so no special version for desktops

David,

The merge proposal sets the default minutes to either 0 or 30 per the description. I can change it to something like 0, 15, 30, 45 if that is decided. It also allows you to choose any minute value. I'll stick to the description until a decision is made or I hear otherwise from you. I'd be happy to make any changes decided.

Changed in ubuntu-calendar-app:
status: Triaged → In Progress
Changed in ubuntu-calendar-app:
importance: High → Low

Fix committed into lp:ubuntu-calendar-app at revision None, scheduled for release in ubuntu-calendar-app, milestone alpha-1

Changed in ubuntu-calendar-app:
status: In Progress → Fix Committed
tags: added: need-design
removed: needs-design
tags: added: needs-design
removed: need-design
Changed in ubuntu-calendar-app:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments