Think about how we can build a friendly publishing UI

[keithamoss]

Is a dependency of #61.

How do hosts contribute to Jabberwocky? The two options originally considered to be available were:

1. Through a series of dumb forms (Google/FormStack) that the web team would collectively process and convert into .md files. If time allowed we might semi-automate the creation process of form -> results spreadsheet -> python script -> commit -> sync, so at least it's a once-a-day task for someone on the web team.
2. Through a well documented contributing guide that steps them through using the GitHub Web UI to author .md files (frontmatter and Markdown).

This all represents a change for hosts from previous years where they just logged into WordPress's admin page, bashed out any old free text and images onto their own event page, and that was that. It was easy for non-techos, was quick, and had zero structure.

If the combination of the two approaches above is deemed insufficient then what options do we have for enabling hosts to more easily contribute to the portal?

1. Reduce the scope of Jabberwocky to not include the more volatile information event hosts need to create - i.e. datasets and organisations/sponsors would live on WWW and remain authored in Wordpress. Manage the less volatile information (mentors, prizes, themes) via the aforementioned dumb forms (or manually by email as in past years).
2. Find a way of slapping a smart authoring UI on top of Jekyll. 10 minutes of Googling reveals a couple of options in this space (e.g. GUI/Administrative interface for Jekyll, Prose [See Development Seed's intro blog post], CloudCannon).
3. ???

A note on Prose Prose can do smart auto-complete, but it needs to be pre-configured with the options, or given a JSONP URL.

As such, we'd have to have some smarts so that when somebody submitted, for example, a new organisation, that the JSONP file containing all organisations was updated.

First thought: A small Python web server listening to a GitHub Web Hook.

Downside: We're violating the "Don't require us to run any server-side infrastructure" principle.

[alansfyeung]

Firstly, agree with the "just log into WordPress and throw in stuff" statement – end of the day, that kind of stuff seems placebo for us and (I believe) contributes little value esp. when difficult to read for users.

Will give my thoughts on both points

1. Automation, sounds like a good idea to me. IFTTT, Zapier, etc perhaps (disclaimer; I've never used their services before).
2. This was Jun's thoughts initially. Maybe he'd still be happy to follow through with this? Additionally Jun and I discussed that we wanted to look for each state team's savvy techos, e.g. from LET, who would be happy to perform the chores. From QLD and NSW respectively, I personally know LET members/hosts who are techy enough to write in markdown.

So yes a combination of approaches could be feasible, i.e. where we don't find a techo then we manage between Jun and myself.

---

Re: volatile information, if it were to be www-wordpress, I believe the amount of work I'd spend in QC-ing the quality would almost certainly be offset by the upfront cost of writing some web forms for Jekyll. That's a gut feeling.

Can this be a situation where we solve 80% of the data entry problem with 20% of forms?

---

Re: no server side... well AWS has got an interesting service called Lambda, where you upload just your code snippet (lamda function) and AWS turns it into an API service.

[keithamoss]

Re QCing Wordpress - That would be a new thing too, in the past we haven't done any QC at all :)

Re Lambda - I've been meaning to find a use for Lambda. There's potential here. As far as I can see from reading Prose's documentation the JSONP file would just need the name and id of each entity (dataset, organisation, whatever). The GitHub API may prove useful here too.

Re Dumb forms - I feel like the big downside to the dumb forms will be the lack of any sort of autocomplete/lists for entities.

e.g. Host uses form to submit a new dataset, but the organisation field in the form has to be a free text field because Google/FormStack don't know about Jekyll's list of organisations.

So the host submits the form, one of us QCs it, manually grabs the id of the organisation from the repo, and publishes the new .md file. And if the organisation doesn't exist we have to create it and prompt the host to supply information about them (sponsor level and so on).

Times that by a few hundred datasets, et cetera over a few weeks and it starts to feel like a lot of work :)

At this point my late on Sunday night thoughts are going down the path of:

1. Spin up some dumb forms on Google/FormStack for the immediate short-term. One for each type of entity: dataset, data portal, prize, theme, organisation.
2. Wrap a shorter contributing guide around the forms that also details how to get other types of content (e.g. Event description) updated for their state/region pages on Portal or WWW (basically, email or Basecamp the web team).
3. Spend a bit of time with Prose next weekend to see how nice it makes the Jekyll editing experience for non-techo users.

[keithamoss]

One more small thought -

Any contributing guide should detail everything hosts can change.

e.g. Twitter, Facebook, Instagram, et cetera for your locations.

e.g. Address lat,lon and human-readable address.

Et cetera

Not just the high-level stuff.

[keithamoss]

Renaming to reflect that the contributing guide is done and that this is more of a place to think about how we build a publishing UI.

[alansfyeung]

FWIW, I made up a little Google Apps script that exports Google Docs into markdown, and exposes it as a JSON endpoint. I use this in conjunction with /python/handbook.py to generate the .md files.

This counts as an authoring solution, I suppose.

I'll gist-ify the Google apps script soon (work internets has blacklisted Google Drive)