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

Google Forms API harvester #75

Closed
queryluke opened this issue Aug 31, 2015 · 20 comments
Closed

Google Forms API harvester #75

queryluke opened this issue Aug 31, 2015 · 20 comments
Assignees

Comments

@queryluke
Copy link
Contributor

Create some form of parser to harvest presentation / presenter submissions

@queryluke queryluke self-assigned this Aug 31, 2015
@queryluke
Copy link
Contributor Author

From my email to the working group. Here is a working model for using Google Forms for speaker / presentation submissions.

What I've thrown together:
There are 2 forms - Speakers and Presentations
Here are the responses: SpeakerResponses and PresentationResponses

Hurdle 1, editing form responses
Add a speaker. Notice that in the responses, the "Edit Url" is automatically generated. Try clicking a link! It should take you to your response so you can edit it. The urls could then be exported and displayed somewhere. There are some guides to sending email confirmations as well, but I didn't go that far down the rabbit hole. At the very least we could make a link to the responses page.

FYI - Same thing happens for the presentation form.

Hurdle 2, connecting speakers and presentations.
Now try adding a presentation. Notice that the speaker you just created is in the dropdown list (you'll need to refresh the page if you have the presentation form open in a different tab). So when a speaker form is submitted, they're added to that list. Works when names are edited as well.

Hurdle's not solved:

  1. Multiple speakers. At the very least we can make multiple dropdowns (Speaker 1, Speaker 2, etc).
  2. Speaker names. The data stored on the presentation is just the speakers name, it's not linked by any index. So this create some issues when exporting (if two speakers have the exact same name) or if a speaker edit's their name AFTER they've been linked to a presentation.

Both of these hurdle's are solvable. I just didn't want to make a complete system if we decide to do a different direction.

Anyway, this should at least give you a working model to share with the other committees, and get feedback on if using google apps will work. Additionally, if you want mess around with your own setups, here are the docs.

@queryluke
Copy link
Contributor Author

Possibly use tabletop.js to harvest.

@queryluke
Copy link
Contributor Author

Thanks to @cdmo for finding
http://sheetsu.com/

Multiple options available.

@queryluke
Copy link
Contributor Author

Fruitful beginnings @ http://roastduckalamode.github.io/fromSheetsToJekyll/

@sdellis
Copy link
Member

sdellis commented Sep 24, 2015

This is awesome. 💯

@cdmo
Copy link
Contributor

cdmo commented Sep 24, 2015

slow 👏

@hackartisan
Copy link
Contributor

I think this approach is problematic for a person submitting a talk proposal (or, more importantly to me, a preconference workshop proposal). I don't think we should make those people fill out two different forms. I'd like to see the required data be generated from a single form that includes both talk / workshop info and contact info.

We plan to put out our call for preconference proposals this week. Our committee lead is starting to work on a google form. Please let me know who she should talk to in order to make sure the form will work for both submitters and the website group!!

It may be moot if workshop presenters won't be included on the 'speakers' list. Let me know. Thanks!

@sdellis
Copy link
Member

sdellis commented Sep 30, 2015

@HackMasterA The only problem with using a single form for submissions is that if there are any fields associated with the speaker, and they are submitting more than one talk, they will have to enter the same data multiple times. And then if there's a typo, they will have to edit it in all of them. Perhaps there are not enough multiple submitters to matter here?

We are collecting more data than we normally do with regard to speakers. Normally, it's Name, Email, and Org. But twitter handles, bios, etc can come in handy and follow other conference conventions.

If you still want a single form after this explanation, let us know.

@bibliotechy
Copy link
Member

@HackMasterA @sdellis Do we need to collect all of that data when the propose a talk? We'd be gathering info on lots of people whose info we won't need. Why not just send out a google form to the people who's talks / sessions have been selected when that time comes?

@sdellis
Copy link
Member

sdellis commented Sep 30, 2015

@bibliotechy++
Great idea. Let's just collect a speaker's name and email when submitting Presentations. We can use email as a "foreign key"; email will also have to be entered into the Speaker form, if they get selected.

@hackartisan
Copy link
Contributor

+1 was going to ask the same question; great solution!

@queryluke
Copy link
Contributor Author

@bibliotechy 's plan looks fine to me.

the person working on the form for proposals can contact me if they have any questions. The only feature they should include is the script that generates an automatic "edit response" url

@dlacy
Copy link

dlacy commented Oct 1, 2015

I understand what you are attempting to do here, but there's something about the workflow that's bothersome to me. I think it's the timeline, 1) submit a proposal, 2) several months later submit a bio and link it to a proposal? Yeah, I'm not feeling this...

A point was made that the traditional procedure amounts to collecting biographical info about people who will not end up being part of the program, but I don't necessarily see that as a problem. It just seems cleaner to 1) create a profile, 2) submit a proposal.

As far as multiple submissions go, can we not treat these as edge cases and configure them manually?

@queryluke
Copy link
Contributor Author

@dlacy I think the workflow is:

  1. Submit a proposal (with your name and email)
  2. Several months later, when we are sending out "You've been selected!" notifications, we will include a link to a form with biographical inputs
    The presenter won't need to make any proposal connections because we'll have that via their email (a "foreign key," as @sdellis suggested).

Does that help clarify?

However, have bios been included on the proposals during the voting process? If so, might as well get everything in one swoop.

@dlacy
Copy link

dlacy commented Oct 1, 2015

@roastduckalamode Thank you for the clarification, and I understand completely the desire to have this data controlled dynamically through google sheets.

So is this workflow solely intended to spare the user from filling out 2 different forms in a row? What if the submission instructions were written as a series of steps:

Step 1: Create a profile
Step 2: Enter a proposal and include the email address from your profile
Step 3: Enter another proposal or preconf idea.

Sorry to muddy the waters, I just don't like the idea of collecting bios down the road.

@hackartisan
Copy link
Contributor

@dlacy @roastduckalamode Seems like if the profile form exists, people could either fill it out at submission time or at acceptance time.

Do we need a central "submit a proposal" page on the site with links to these various google forms?

@queryluke
Copy link
Contributor Author

@dlacy @HackMasterA I'm fine with that approach. If you provide the links to the forms you want to use, I'll create a page on the website that outlines that workflow and links to them.

Additionally, if you look at the second page of these docs, you could have the email input from step 2 as a select list, populated with email addresses from step 1 (or names, for privacy's sake). I can help out with that if you need. But again, not necessary. A regular old text field will work. Even if there is a typo in the email address, we can fix manually.

@hackartisan
Copy link
Contributor

Cool. I'd vote against the drop-down, since that makes things less flexible.

@hackartisan
Copy link
Contributor

@roastduckalamode I assume, from the info you are collecting on the speaker form, that everything except the email address will be published on the site. Can you confirm or correct me?

@queryluke
Copy link
Contributor Author

There hasn't been an official discussion about what information to collect about speakers. At minimum, name and short bio. I think pictures would be nice. But the picture would need to be hosted elsewhere. Institutional Affiliation makes sense as well. If they leave anything blank, it won't show up.

@sdellis, what do you think?

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

No branches or pull requests

6 participants