Skip to content

Instantly share code, notes, and snippets.

@nelsonpecora
Last active November 28, 2018 21:43
Show Gist options
  • Save nelsonpecora/7d87808b91ddc27ebf6b76981f2ade8e to your computer and use it in GitHub Desktop.
Save nelsonpecora/7d87808b91ddc27ebf6b76981f2ade8e to your computer and use it in GitHub Desktop.
My thoughts on Clay after three years

Clay Retrospective

The Good

  • allowing maximum flexibility in component design
  • standardized editing interfaces across components
  • style variations!
  • page templates were a good idea (but needed better organizational ux)
  • simplified permissions structure was a good idea
    • with friction for certain changes
  • render plugins was a pretty good idea, but could be done better with a stricter api
  • megabundler was good (for this specific use case)
  • "User has edited this recently" message
  • synched fields (entities) was a good idea, needs an easier way to figure out keys
  • bootstrapping was good in the beginning (e.g. when building new sites from scratch), but cannot be maintained (should use actual db backups instead)
  • simplified page history was better than granular versioning
  • claycli was generally good and useful
    • needed better error handling, non-http API (e.g. to do stuff with db dumps)
  • simple-list and complex-list were generally good UX, could be better
    • simple-list should just be an array of strings
    • complex-list could have variations
      • cards
      • text w/ primary selection (same as current simple-list)
      • table-row
      • table-column
  • magic-button was good, but even better with tooltips

The Bad

  • components got too complicated and large (should have been split into much smaller reusable pieces, like Vue/React components)
  • unidirectional component references prevent a lot of functionality
    • composition at the app layer is slow, use a db instead
    • graaaaaph db with a caching layer would be best
  • page vs layout was never clear
    • should have used page templates + allowed much less flexibility in their composition and editing (i.e. should have not had "layouts" as a separate concept from "page templates")
  • component sunsetting + conversion was unsolved
  • no unified style guide contributed to component duplication
  • meta/head components were never understood properly
  • invisible component lists were underutilized
  • kiln / edit mode components were a bad idea, they should have been baked in
  • publishing: url generation and publish flow had too many restrictions, was too abstract for end users ("what will my url be?")
  • indexing / feed generation / elastic implementation was brittle and overcomplicated
  • spaces was a brittle solution to the problem of layouts
  • component bookmarks was a brittle solution to the problem of re-referencing
  • ux was not designed mobile-first
  • terrible accessibility outside of individual forms
  • no true multi-user editing / realtime support / offline support
  • single admin api key rather than per-dev api key generation
  • split wysiwyg required a WHOLE lot of code, next time do content-list from the start (and find a way to embed components inside the wysiwyg itself)
  • pubsub only worked client-side (need to know the context in ALL environments, e.g. by using a graph)
  • amphora craps out if components don't exist (better handling of error states across the board, including handling of model.js errors)
  • "dynamic pages" were implemented weirdly, didn't make use of express's built-in param stuff
  • lack of amphora documentation
  • poor test coverage

The Ugly

  • components should be single-file vue components
    • public-facing stuff utilizing server-side rendering
    • allows rich SPA interfaces
    • edit-facing stuff uses config.js
  • multi-site config and styling isn't worth the hassle, isn't something a single implementation of the cms should solve for
    • site/global config should all be editable in the UI, not on the filesystem
  • schema.yml should be a config.js (allows sane defaults + dynamic configuration), a combination of this idea and things like babel.conf.js/postcss.conf.js/jest.conf.js
  • instead of state snapshots, use proper CRDT with much more granularity than just the component level
    • this allows for multi-user and realtime editing, as well as real offline-first support and history
  • build the entire backend around eventbus + push rather than state setting + pull
  • multi-lingual support / localization must be a first-class citizen
  • user data and interaction feedback must be baked in from the start
  • types of content: page (contains metadata, "layout" stuff, publishing logic), component, entity (might actually be able to do proper component back referencing in a graph db)
  • have a universal solution to pubsub (e.g. by updating information using the graph)
  • expand the clay menu more (it should be the centralized place for dashboard-y plugins)
  • component logic (model.js) should be able to trigger messages to users when run client-side (for errors, warnings, etc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment