It would be pretty trivial to implement individual prefilled options via the URL. Solving the problem generally though might turn out to be harder (i.e. generally allowing you to prefill forms based on URL parameters and available fields).
Time zones are currently all saved in the DB as UTC+0. So that’s what your queries should translate to, though I haven’t needed to test this extensively.
On a higher level: I think it would be more valuable to have a sidebar of nearby local groups instead of nearby events. Most groups don’t get around to publishing all of their events on LessWrong, and while this is something I want to fix in the long-run, right now we only have a single upcoming SSC meetup listed, even though I know of many SSC groups that have weekly meetups and are listed.
Re: local events: Although I haven’t checked this with Scott, my default assumption for the SSC sidebar is that keeping it free of clutter and noise is of the highest importance. As such, I’m only including individual events that a human actually took explicit action to advertise, to prevent the inclusion of “weekly” events from groups that have since flaked or died out.
(This is also why the displayed text only includes the date and Google-normalized location, to prevent users from defacing the sidebar with arbitrary text.)
LW proper may have different priorities. Might be worth considering design options here for indicating how active a group is.
Yeah, it would be great to somehow know how active a group is. Though it’s definitely non-trivial to make that happen. Right now all groups were created in the last few months, so you know at least that if they are dead, they haven’t been dead for long.
My model is that showing a group that is actually in the same city but might or might not be active is more important than showing far away events that are guaranteed to be real. In both cases the user will be disappointed, but I think your hit rate is going to be higher for the groups, since there are so many more of them, and most events don’t get advertised. I don’t think this means you have to show more clutter or anything, as long as you can get the user’s rough location (via IP if necessary) you should be able to show nearby groups with nothing else but the location.
So correct me if I’m wrong here, but the way timezones seem to work is that, when creating an event, you specify a “local” time, then the app translates that time from whatever it thinks your browser’s time zone is into UTC and saves it in the database. When somebody else views the event, the app translates the time in the database from UTC to whatever it thinks their browser’s time zone is and displays that.
I suppose this will at least sometimes work okay in practice, but if somebody creates an event in a time zone other than the one they’re in right now, it will be wrong, and if you’re viewing an event in a different time zone from your own, it’ll be unclear which time zone is meant. Also, Moment.js’s guess as to the user’s time zone is not always reliable.
I think the right way to handle this would be to use the Google Maps API to determine, from the event’s location and the given local time, what time zone the event is in, and then to attach that time zone to the time stored in the database and display it explicitly on the page. Does this make sense?
Yep, that is how it works. This seemed to make the most sense for potential remote events, i.e. when people want to Skype into an event. I think it could totally make sense to instead display the time in the local timezone, but it’s not obviously better to me and would require a bunch of engineering effort. But if someone else feels strongly about it, I would definitely merge a PR and help getting them set up with the codebase and everything to make that change happen. Also if enough people feel that the other way would be better, then I can get around to fixing it.
I do think that in general, focusing on listing events over groups was a mistake. When I get around to fixing our UI, I think the community page should feature groups a lot more prominently than events, which also mostly sidesteps this problem.
Also, two other questions:
Is there any way to link the new event form to have a type box prechecked? How hard is this to implement in Vulcan?
How do time zones of events work?
It would be pretty trivial to implement individual prefilled options via the URL. Solving the problem generally though might turn out to be harder (i.e. generally allowing you to prefill forms based on URL parameters and available fields).
Time zones are currently all saved in the DB as UTC+0. So that’s what your queries should translate to, though I haven’t needed to test this extensively.
On a higher level: I think it would be more valuable to have a sidebar of nearby local groups instead of nearby events. Most groups don’t get around to publishing all of their events on LessWrong, and while this is something I want to fix in the long-run, right now we only have a single upcoming SSC meetup listed, even though I know of many SSC groups that have weekly meetups and are listed.
Re: local events: Although I haven’t checked this with Scott, my default assumption for the SSC sidebar is that keeping it free of clutter and noise is of the highest importance. As such, I’m only including individual events that a human actually took explicit action to advertise, to prevent the inclusion of “weekly” events from groups that have since flaked or died out.
(This is also why the displayed text only includes the date and Google-normalized location, to prevent users from defacing the sidebar with arbitrary text.)
LW proper may have different priorities. Might be worth considering design options here for indicating how active a group is.
Yeah, it would be great to somehow know how active a group is. Though it’s definitely non-trivial to make that happen. Right now all groups were created in the last few months, so you know at least that if they are dead, they haven’t been dead for long.
My model is that showing a group that is actually in the same city but might or might not be active is more important than showing far away events that are guaranteed to be real. In both cases the user will be disappointed, but I think your hit rate is going to be higher for the groups, since there are so many more of them, and most events don’t get advertised. I don’t think this means you have to show more clutter or anything, as long as you can get the user’s rough location (via IP if necessary) you should be able to show nearby groups with nothing else but the location.
So correct me if I’m wrong here, but the way timezones seem to work is that, when creating an event, you specify a “local” time, then the app translates that time from whatever it thinks your browser’s time zone is into UTC and saves it in the database. When somebody else views the event, the app translates the time in the database from UTC to whatever it thinks their browser’s time zone is and displays that.
I suppose this will at least sometimes work okay in practice, but if somebody creates an event in a time zone other than the one they’re in right now, it will be wrong, and if you’re viewing an event in a different time zone from your own, it’ll be unclear which time zone is meant. Also, Moment.js’s guess as to the user’s time zone is not always reliable.
I think the right way to handle this would be to use the Google Maps API to determine, from the event’s location and the given local time, what time zone the event is in, and then to attach that time zone to the time stored in the database and display it explicitly on the page. Does this make sense?
Yep, that is how it works. This seemed to make the most sense for potential remote events, i.e. when people want to Skype into an event. I think it could totally make sense to instead display the time in the local timezone, but it’s not obviously better to me and would require a bunch of engineering effort. But if someone else feels strongly about it, I would definitely merge a PR and help getting them set up with the codebase and everything to make that change happen. Also if enough people feel that the other way would be better, then I can get around to fixing it.
I do think that in general, focusing on listing events over groups was a mistake. When I get around to fixing our UI, I think the community page should feature groups a lot more prominently than events, which also mostly sidesteps this problem.