Building An Opinionated CMS
After using several unwieldy CMSes, I wanted to build one that felt designed by—and for—a writer.
Unlike a traditional static site with a front and backend, Punchcut is a CMS with a reader front page and an editing dashboard, both tied into a database of articles. It was important to me to build out support for scheduling posts, assigning editors to pieces, and creating a collaborative editor. This ended up being a very ambitious project. I hit many of my goals, but not all of them, and eventually used a lot of what I learned to build the Bullet Points Monthly site.
I did preliminary drawings of what I wanted Punchcut to look like, but I focused on the front page pretty heavily. I spent most of the time before deadline on getting the editor to work properly, managing authorization for different user-roles, and moving all my state to Redux. Redux is almost certainly unnecessary for a project of such small size, but adding it was a valuable experience.
I also used ReactRouter to do a lot of routing with individual article slugs, pages for editors and writers, and redirects for users who weren’t properly authenticated.
Punchcut allows users to login, and features two roles: Editors and Writers. Editors assign articles to Writers, and an assigned article is accessible to both dashboards, where Editors and Writers can collaboratively work on the piece through a Prosemirror-based editor. Posts also get a scheduled date of publication, and do not appear on the front page unless today is past that date (I think in the future a draft-status is a better way to handle this functionality).
Visible and Invisible
I learned something valuable here about how to do demo projects. Punchcut has Redux in the background, it has user roles, it has collaborative editing, it has authentication, it has publication dates, it has a measure of article importance that displays headlines in a specific order.
None of these things are visible right off the bat.
This makes Punchcut a hard project to demo! I worked to make sure that these invisible features work as best as they can under deadline, but what a visitor sees at the outset is a front page with no image-urls and an HTML bug in the article previews. I learned a lot about why a CMS is difficult to build, and about the different concerns of editors, writers, and back and frontend developers. In the future, I hope to make projects I intend to show off look a little showier.