- 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
- 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
- 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)