Prototype site editing tools/workflow

[jbuck]

In this heartbeat we'd like to whip up some prototypes of tools that the Hive and Teach teams could use to edit content on the Teach site.

Tools list

• davida.io
  • mofo-example-app-ness
  • only publishes changes to firebase, could we look at publishing changes to git/Github?
  • doesn't have any image uploading
  • would be nice to
• Prose
  • This probably needs to be done in context with a jekyll-based setup
• prismic.io
• Ghost
  • a late addition - I thought that putting a more traditional CMS that we wouldn't hate running in the mix would be a good measuring stick as well. If you think we shouldn't give it a shot, let me know!

[simonwex]

Great list. I think Ghost is a good addition as a reality-check. prismic.io is a lot of tool and I wonder if people will find it overwhelming. -- especially since it involves its own discussion and planning tools --worth testing.

[toolness]

I'm a bit concerned about the davida.io approach because it feels like we're building our own product--a very sexy, easy-to-use product, but do we have the resources to continuously maintain and improve it? And provide all the essentials that a decent CMS provides? Could turn into a big black hole...

One of the things I really like about GitHub is its ability to auto-upload images that are dragged to it... Makes me wonder if there's a logical (to our end users) mapping between Teach site content and GitHub wiki pages--if there is, then the users could simply edit a GitHub wiki page whenever they wanted to modify the Teach site (so the Teach site would essentially serve as a "skin" for the wiki). However, that might be very close to what prismic.io or Prose does--I'm unfamiliar with both.

[toolness]

This might be jumping the gun, but what are the security constraints of the editing UI? Should users be able to insert arbitrary HTML that is unsanitized, if they want, or are we actively trying to prevent XSS attacks and such?

[davidascher]

FWIW, I'm not thinking of davida.io (which name I didn't pick!) as a full solution. I see it as a way to do 10% of the edits for content that is mostly authored using github + markdown.

[davidascher]

@toolness re: the security constraints -- We should assume the same security model that I would say github offers us -- assuming someone's authed and we have them in a whitelist of "people who can commit", then they have the full power of client-side tech.

We can explore restricting that (e.g. using a markdown processor that refuses to accept HTML), but I think that needs arguing for, given that we'd lose a lot of capabilities that way, and we actually know who will be editing these things.

[simonwex]

All these prototypes depend on #80

[toolness]

As I've noted in #80 (comment), I'm building out the front page using React, and it's easily exportable to static HTML that doesn't require any JS on the client-side.

I'm hoping this will facilitate exploring some of the concepts mentioned in this issue--for instance, a rich React-based editing experience similar to davida's prototype could power an "admin" version of the site that the learning team uses, while the statically generated version could be what the majority of the public sees.

[hannahkane]

@simonwex @toolness - do you think we can we close this ticket for now?

[toolness]

Yep i think so!

This message was typed with haste on a tiny keyboard with no tactile feedback.

On Mar 10, 2015, at 6:14 PM, hannahkane notifications@github.com wrote:

@simonwex @toolness - do you think we can we close this ticket for now?

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

[toolness]

Just as an update, @iamjessklein is now using GitHub for Mac to do basic edits to the teach site.

I'm particularly impressed with GitHub for Mac (it's also available for Windows) because aside from not having to deal with the command line, it gives users a much better mental model for interacting with git than command-line git does. There's no more push/pull/stash/stage metaphors, instead there's just syncing, branching, and committing.

Given the learning team's existing "github literacy" and the inclination many of them have to "level up" their coding skills, as well as our dev team's extremely limited bandwidth for implementing a really user-friendly static content editing solution, I'm wondering if it's actually feasible for some of the teach team folks to use the GitHub for Mac/Windows app to edit the site and issue PRs. Might be worth bringing up in the future.

[hannahkane]

I <3 this idea so much. We'll still likely want to explore different options for, say, adding new curriculum modules to the site, but I think getting more people on github for copy edits and other similarly-sized things would be great.

I'm going to work on getting myself set up soon!

[jgmac1106]

Before @dajbelshaw became a contributor (again) he made a series of videos
on how to teach people to do what @toolness suggests

On Thu, Apr 2, 2015, 5:18 PM hannahkane notifications@github.com wrote:

I <3 this idea so much. We'll still likely want to explore different
options for, say, adding new curriculum modules to the site, but I think
getting more people on github for copy edits and other similarly-sized
things would be great.

I'm going to work on getting myself set up soon!

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

[toolness]

Ah awesome!

Yes, for the curriculum modules and such things, I am currently thinking that making a model in teach-api and allowing it to be edited by admins only (i.e. teach team staff) is the easiest way to go for that (currently Clubs are the only models in the teach api). It also opens up the possibility for such things eventually to be user-contributed too, if we ever want to entertain such notions--in particular some of the stuff the teach site showcases is quite similar to a curated version of the weblitmapper, and I've been toying with the notion of actually moving the data out of the weblitmapper and into the teach api.

Sorry if that was a mouthful of confusing context, we can talk about it more when we plan for v2 :)

[hannahkane]

Sounds good. I definitely see the weblitmapper connection, and I see the user-submitted curriculum piece as part of the larger Directory project. We'll talk more soon. :)