Created an upcoming events widget

[rhewitt22]

Addresses #105.

Updated site.js to query a google spreadsheet using tabletop.js for maptime events. The script ditches events that have already occurred, and sorts them by date before rendering them in a list in the sidebar.

Events list is hidden by default on mobile, they are shown when you click the Upcoming events header. Shown by default in a scrollable list in the sidebar on larger screens.

Caveat: since last november when the google form was created Google changed they way they save dates to the spreadsheet. They used to save in an ISO format that moment.js liked. Now dates are saved in the following format 6/8/2015 18:30:00, which causes moment.js to throw a warning:

Deprecation warning: moment construction falls back to js Date. This is discouraged and will be removed in upcoming major release. Please refer to https://github.com/moment/moment/issues/1407 for more info.

[rhewitt22]

@mapsam or @geografa want to take a look?

[geografa]

Looking awesome. We'll need to figure out the workflow for editing the event should it change. It will sorta suck tracking down the admin to make an edit to time/location/etc. Is the spreadheet going to be shared with all admins or controlled by just a few?

[rhewitt22]

I'd say any organizer should have access. We can also set the option on the form to have it email the responder a link to update their event if they need to.

[rhewitt22]

@geografa @geobrando

bump.

There's a setting on the Google form that will send an email to whoever completes the form with a link to update their response. Will that suffice from an admin/management perspective?

[geografa]

I'm a 👍

[geobrando]

After an obscene amount of time figuring out why I couldn't preview the site locally I was finally able to check this out. Looks great to me. My only concern would be I'm anticipating difficulty getting organizers to routinely fill out the form. Eventually, it would be nice to automate this for those chapters using a platform that has an API (e.g. eventbrite, meetup). But this works well for the time being.

Thoughts? @jonahadkins @maptime/owners

[danswick]

Looking good, @geobrando! Problems getting Ruby dependencies lined up I'm guessing? I totally wasn't up all night doing the same thing last night...

Anywho, for Maptime Chicago's events, I'm using the YAML header date variable that (I think?) @geografa set up in the starter template. I bet we could pull that info into the widget, though it might be more work than it's worth.

---
layout: event
category: event
title: OpenStreetMap for Humanitarian Response
rsvp: https://www.eventbrite.com/e/openstreetmap-for-humanitarian-response-tickets-17129945127

---

The event info is mostly here and the date comes from the filename as is Jekyll's wont.

[rhewitt22]

Using the meetup api would be nice but using meetup is optional due to cost. Would be something cool to target for funding by hq when the time comes.

Roy

On Jun 1, 2015, at 3:45 PM, Brandon Knight notifications@github.com wrote:

After an obscene amount of time figuring out why I couldn't preview the site locally I was finally able to check this out. Looks great to me. My only concern would be I'm anticipating difficulty getting organizers to routinely fill out the form. Eventually, it would be nice to automate this for those chapters using a platform that has an API (e.g. eventbrite, meetup). But this works well for the time being.

Thoughts? @jonahadkins @maptime/owners

—
Reply to this email directly or view it on GitHub.

[geobrando]

Gentle nudge on behalf of @kkowalsky to get this plan and site change reviewed by some HQ folks so that we can start implementing it. We'd like to include an event calendar in the monthly series in xyHT. Roy set this up. But basically, organizers will be asked to fill out a google form when they plan events and this will populate a google sheet and the events calendar on the site as shown above.

@lyzidiamond @bethschechter @almccon @camilleanne

[rhewitt22]

@mapsam Should we go ahead and modify the google form to get it ready for production? It currently says "TEST":

https://docs.google.com/forms/d/1OfA8sV0Vs0-WlCwRBALC8p_RR1zMFS-WXYtXnyDzTA0/viewform

[mapsam]

Oh, hehe. Feel free to make a new form if you'd like - otherwise let me know what you'd like the form to say.

[rhewitt22]

@mapsam I just can't seem to find it in my Google Drive. I know you shared it with me...

[mapsam]

Here's the link to edit

[rhewitt22]

Hardcoded chapter names will be a pain to maintain 😢

[geobrando]

@rhewitt22 Hmm.. you could keep it sync'd chapters.json. But not sure of any of us have the bandwidth to figure that out.

[rhewitt22]

Google App Script HTTP request to raw git?

https://cdn.rawgit.com/maptime/maptime.github.io/master/_data/chapters.json

Not sure if it's even possible to update a choice list programmatically.

[mapsam]

Remember you can change that form to whatever you want - it was just created as a proof of concept a long time ago! Might as well start with a text field.

[rhewitt22]

Yea I'm just thinking how this might be used on Chapter pages to limit events to only those hosted by their chapter. If this is a text field that adds some degree of user error with capitalization and spaces. I guess that could all be handled by JS on the client (toLowerCase(), trim()).

[geobrando]

I assumed this was only intended as a worldwide aggregator for maptime.io. Not sure how desired this would be for chapters as if they're using the starter template it already highlights the next event and will link to a meetup site.

[rhewitt22]

I don't see any reason why modularity is a bad thing.

If a chapter wants to implement this in order to show more than one upcoming event why shouldn't they be able to? It's not a requirement, it's an additional option.

[geobrando]

Oh I agree Roy. I'm all for that. Was just saying if it's going to create additional headaches it might be best to keep it simple. But yeah, you could probably figure out how to handle some fuzzy matching.

[rhewitt22]

It's a balance. I'm guessing a little fuzzy matching would be the easiest/most maintainable option compared to hard-coded chapters, or spending the time to figure out if you can programmatically update a pick-list on a Google form.

Will look into this soon.