3 ms·

A content model is not a design system (2021)

• MilStdJunkie 4y ago
  Oh yeah. Oh yeah. This stuff[1] is my daily bread and butter. His problems with "tabs" was a variant on a problem that I call "The Applicability Trap" in S1000D. Basically, when you go to component content models with conditional blocks, you're abandoning some natural language grammar for the grammar defined in the product architecture. Problem: when you lay out the conditions, you don't know if the architecture resembles the product at all. So you can box yourself into a corner. One of my big side projects is building out a system / process that can determine product equivalence from just design data, in real time. Then you could actually falsify "Le Grande Product Architecture" handed down from mahogany row. It doesn't help that the bigwigs on the steering groups are almost entirely non-technical representatives, of course. [1] Content Architecture
• inopinatus 4y ago
  > We had a breakthrough when we discovered that our customer had a specific purpose in mind I don't mean to shame the authors with this cherry-picked partial quote, because I've fallen into the same trap. We're a profession that delights in the abstract, and it is very easy to find oneself building castles in the air. From the naming of variables and methods, to the structure of data at rest, or (as in the context of the article) the paths of navigation through a UI, purpose must infuse every decision we make, and in analysing what has gone before, the question of why is invariably the most enlightening. This is not the only consideration that matters, but I have always found it a mistake to treat it as anything but the most consequential.
• robertlagrant 4y ago
  I used to read alistapart obsessively 20 years ago. So great to see it's still going.
• OJFord 4y ago
  This is the way to think about any API IMO, (SSR aside of course) not specific to CMS.