search

ezl / hnofficehours

HN Office Hours
http://hnofficehours.com
MIT License
30 stars 5 forks source link

Handling availability and timeslots #15

Open placer14 opened 14 years ago

placer14 commented 14 years ago

Everyone's configuration of available time is going to be different and I think an important part of this whole thing will be deciding how much resolution should be provided when specifying available time slots. We should get an idea on how much flexibility we should give people with our schedule system.

Proposal: I think 20 minute increments are sufficient without being too fine-grained. This will allow those who are interested in posting regular hours. The increments will tied to :00, :20, :40 on each hour. We will also need to track each user's timezone so we can correctly display the relative time to each user.

Having a simple system like this could make the system much more simplified for everyone to use.

Ex: I can be available from MWF 12-4:20pm EST.

Alternatively:

A suggestion has been made to use http://www.thauber.com/blog/post/django-schedule/ which allows a resolution down to the second. LOTS of flexibility but also LOTS of added complexity.

Thoughts?

rz commented 14 years ago

We should use django-schedule, but restrict the resolution to 20 mins like you suggested.

As for timezones, we should store all our times in UTC, converting at input and display time.

placer14 commented 14 years ago

Best of both worlds. Love it.

ccg commented 14 years ago

I think we only need the complexity of django-schedule if we want to support recurring events, e.g., "I have office hours every Friday from 4-6pm, except next week." A lot of people on IRC seem to be more interested in saying something like "I'm available right now for the next 30 minutes." Also, it's not just a matter of dropping in django-schedule. You need a UI for defining rrule recurrence relations. I've done it before, but it's kind of annoying. If we make the assumption that recurring office hours are uncommon and one-off office hours are the common case, then we can use our own, much simpler model for keeping track of the hours.

So, somehow we need to figure out which case we're optimizing for.

Also, the 20-minute increment thing is a UI issue, right? I mean, is there any reason not to store times in the backend with a standard datetime field and to allow minute or second resolution in the API?

sierranevadan commented 14 years ago

@ccg: I think that sounds good. Reduce complexity and get something going first.

placer14 commented 14 years ago

The 20-minute increment thing is an arbitrary limitation which will (hopefully) simplify the service and the UX.