This talk sounds interesting, it’s about the potential death of databases and CMS systems and how the government is paving the way for these content editing systems that shoot out flat HTML I’m curious to see what they have to say about this…
Speakers: Danny Chapman @dannychapman, Ben Balter @benbalter, Jessica Teal @tealmedia, and Julie Herron @slowdripcrazy. We’ve got a good variety of people here.
We started to use servers to build tools to make content editing easier with CMSs. You have the application code (e.g. Drupal, WP, etc), the templates, and the content database (e.g. MySQL). The challenge here is that these are constantly building the website every time that a user comes to it, and this adds a lot of complexity in order to make it work faster and more efficiently with caching and load balancing. There are a lot of pieces that could fail, which could cause the entire site to fail.
Going back to static sites reduces some of the complexity.
Version Control Software
The workflow of version control doesn’t have to be limited to code, editorial workflows can also be completed with version control, which means you don’t necessarily need a database to keep track of those changes or change proposals.
Content as Code
Subject Matter Experts— Write > Commit > Pull Request
Stakeholders— Review > Propose > Discuss
This simplifies the process for quick working teams since they didn’t have the time to teach a team how to use a CMS. She’s talking about Healthcare.gov. She’s talking about how the people there started using Prose.io as a web-based text editor for collaboratively editing static websites through GitHub. Seems like a really neat idea actually.
The team, even the not-so-tech-savvy, were able to learn markdown. They don’t have the ability to use things like WYSIWYG editors, and there’s a little bit of a learning curve for those content managers and editors.
This led to an organizational mind shift. This allowed the workflow to actually work offline as well, not just through an online CMS. A static site workflow can work better offline for the content creators.
Now we’re getting a little markdown overview.. @RobertRM would be loving this talk.
How does this workflow work when you have a lot of people editing the same content? You would write the post in whatever text editor you’d like and when you’re ready you can commit it and do a pull request to publish it. Then everyone else can propose changes, make edits, comment line-by-line, etc. or the content can be published. It’s just using version control to track changes.
This is actually pretty neat, they are able to show higher-ups how the content will look even before it’s launched because of the nature of the static site.
Talking about UI and UX. Good UI being simple, clear and legible, lead to task completion, uses CSS rather than images when possible. Being consistent to make things as lean as possible, creating reusable patterns for buttons, tabs, icons, styles, and sticking to those systems.
A good UI should also be familiar.. e.g. the 3 lines in the upper left or right on a mobile site should be a menu. Meet people’s expectations. Be forgiving if someone makes a misstep. There should be a way to reverse mistaken actions or still be able to get where they wanted to go.
Talking about the separation of content and design.. content creators can really focus on the creation of the content and not have to think about trying to design things at the same time as they’re writing. Forcing content into markdown really forces them to focus on the content itself and not on the formatting.
They’re also talking about how on a magazine, you’ll see a beautiful combination of design and content since they’re so merged together, but on the web you end up with this amorphous blob of white space where the content will eventually be pulled in from the database which makes for a bit of an unknown when it comes to predicting what the final product would look like.
Hawaii.gov is a primarily static website that’s got dynamic elements like news or weather, and it’s generated by jekyll. The content doesn’t change frequently, so you only generate the site when the content changes rather than when the user requests it.
Things to Consider
- Great for sites that don’t update frequently
- Tools lack polish / ease of use
- Forces parts of the workflow ‘offline’
- Content owners may miss safety nets
- Learning curve
How to get started
- Learn markdown: guides.github.com/overviews/mastering-markdown
- Understanding open collaboration guides.github.com/overviews/flow
- Jekyll jekyllrb.com/docs/quickstart
- Prose prose.io
- Hack this presentation github.com/benbalter/the-dynamic-site-is-dead
How to determine whether to use a static site or a dynamic one? Thinks of it as an x/y axis. How often does the content change vs how often is the content accessed? Some sites it won’t make any sense for, but others it will. Dynamic content can be created and pulled in dynamically. Prose.io for instance has the ability to handle that type of content and uses APIs that you have a front-end tool that pull from a dynamic service.
What do they think about ember.js which sort of blurs the line? Also MiddleMan, which takes all the good parts of Rails, but allows you to edit the content separately and renders in HTML. They’re fans of these, they think we’re going to see more of these.
How’s the backlash for converting a large team to markdown? Julie was the skeptic in the room when they started the discussion on this in her team. There are a lot of good online resources and communities, and we really just have to make a change. We need to have structured content with headings and using the right tags, rather than just formatting.
Smaller sites might work well, but often they have some sort of form to collect information, are there easy options for data collection? Google forms could do it, or you could just set up a separate dynamic option for just the one page like forms.website.com. You can have a single complex page rather than make all of them complex.
@brettsing and I decided this was a great talk.