Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Session Time Helper #1

Open
chathuraa opened this issue Jan 23, 2016 · 5 comments
Open

Session Time Helper #1

chathuraa opened this issue Jan 23, 2016 · 5 comments

Comments

@chathuraa
Copy link
Collaborator

An intuitive way to find session times for mentors and members in different timezones with different availability.

@serkandurusoy
Copy link

Let's do something just a little complex here as learning experience.

  • Class attendees could have 6 points to distribute among 3 votes they must cast.
    • 3 points for their first preference,
    • 2 for the second and finally,
    • 1 point for their last preference.
  • Each vote should span 3 hours so that we have better room for overlaps.
  • The mentor may get to have superpowers :) For example 12 points to distribute to their own 3 votes.
  • The UI would show each user the date/time in their own timezone if set in the user's profile,
    • but if the profile does not have a timezone set, we detect the user's timezone (browser and ip addresses are good signals) and offer a way to set it.
  • Furthermore, the UI would display the date/time information localized to the user's locale format (as a brief introduction into internationalization)
    • The UI should show the timezones not just by offset, but also by the timezone name, for example Europe\Istanbul GMT+02
    • We should also account for summertime offsets (1 hour difference during predefined dates, not applied to all countries)
  • Voted time slots should not overlap such that a user cannot cast more than one vote for a duration

So an example vote would be:

  • Mentor:
    • 6pt for 31.01.2016 10:00 PM through 01.02.2016 01:00 AM GMT+02
    • 4pt for 29.01.2016 06:00 AM through 29.01.2016 09:00 AM GMT+02
    • 2pt for 29.01.2016 09:00 AM through 29.01.2016 12:00 PM GMT+02
  • Student 1:
    • 3pt for 31.01.2016 08:00 PM through 31.01.2016 11:00 PM GMT-07
    • 2pt for 30.01.2016 07:00 AM through 30.01.2016 10:00 AM GMT-07
    • 1pt for 31.01.2016 11:00 PM through 01.02.2016 02:00 AM GMT-07
  • Student 2:
    • ...
    • ...
    • ...

There maybe some improvements:

  • Mentor can limit the allowed time slots beforehand, for example Mon-Wed 09:00-18:00 UTC
  • At any time during voting, if we can't get a majority (define what a majority is), let users know of the situation and adjust their votes
  • Show the votes publicly so that users can adjust based on peer respect :)

This is just an idea, we may make it way simpler but I think this would be a good exercise to think in terms of time zones, summertime offsets, durations, time calculations, time display formats, arrays, math calculations and fractions, document structures as well as an opportunity to work with packages like mathjs, momentjs and underscorejs.

Let's hear some more ideas, we can make this simpler, more complex or perhpas trash this idea to come up with a better one.

@chathuraa
Copy link
Collaborator Author

This is really good lets have a brainstorm session, may be tomorrow if everyone is free.

@sakulstra
Copy link
Member

"The mentor may get to have superpowers :) For example 12 points to distribute to their own 3 votes."
I think this kind of destroys a voting system. Wouldn't it be better to let the mentor decide which 3/x options the students have to choose from? If we just want to make it complicated we can let the mentor colourize the options(green/yellow/red).

@serkandurusoy
Copy link

I think you are right. The mentor should have normal human powers :)

And yes, the mentor should predefine their availability as I suggested by

Mentor can limit the allowed time slots beforehand, for example Mon-Wed 09:00-18:00 UTC

but I want this more than mere slots because I'd like this feature to require time based calculations and timezone problems. Believe me, most devs I know clearly make very simple mistakes here and paint them into corners when the time comes to open the app to the whole world :)

@sakulstra sakulstra mentioned this issue Jan 28, 2016
@sakulstra
Copy link
Member

The solution which came to my mind was: Simply saving the timezone at first login. As we can’t assume, that the JavaScript Time is always correct, we probably have to somehow ask for confirmation and give the chance to correct a wrong assumption. To over-complicate it, we could also try to get the timezone via IP and check if it’s the same than JavaScript assumes.

  1. Having the time zone we can build a doodle like application where everyone can select possible time slots in his very own time zone. With the users time zone present, we can now normalize the selection to UTC+0 and present it in the UI for the others.
  2. On the other Hand we could have a woldtimebuddy like application which let’s the Leader (Mentor) select a time, but in the same time present him what a specific time means for the others. So he won’t pick a time which is like 3am for some participants.

I personally think a combined solution would be the best. So the mentor can select some time slot’s which are doable for the participants and than the participants can vote for a specific slot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants