Planning a content model for a CMS build? Read this excellent thread started by Aaron Bradley. There are gems of experience from folks like Michael Andrews & Jeff Eaton. While reading it I realized some of my views are shifting. Early on I discovered that my "dev" brain led to overly abstract types that led to poor author experiences. However, aiming for the perfect author experience could also lead to maintainability challenges. Newer platforms are making it easier to find a balance between author experience and developer experience. For example, Alaaddin Alweish points out how modern CMSs are providing smooth author experiences when creating content references. I'm enjoying that capability in Xperience by Kentico and it's changing my perspective. Ultimately, I favor advocating the values technical team members (like me) often overlook: • Author experience (I like Rachel Doria's simple answer to the question about overloading users: "Don't overload users.") • Semantic models that emphasize content meaning over presentation, emphasized by Richard Bausek & Jaydee Devine. BTW, Don't miss Jaydee's 5 guiding principles. Read this discussion!
Hey there, a question for my content architect chums out there - and concerning a conundrum I'm sure you too face, like, daily. That question being, what is the correct degree of separation between types when building a content model? Does any difference between elements warrant a new type, or is it better to consolidate types as much as possible - even if this means overloading it for some users? To what degree should content authoring be a consideration, and should authoring requirements allow duplicative types for the sake of comprehensibility? Image and Icon, or just Image? Link and Call to Action, or just Link? For the record I favor parsimony in model design, and am loathe to mint overly-duplicative variants. But I also understand that Carousel, Tabs and Gallery are all more comprehensible types than Item List. Yet I don't want to have to update and otherwise maintain three types when one will do the trick. (BTW, if ye olde CMS's model was based on formal semantics you'd be able to spit out new classes simply with subclasses, where changes to a parent would be inherited by its children.:) So how granular are your types? Looking forward to everyone's thoughts - and war stories!
Web consultant, analyst and developer. Deep experience in open source and web architecture, anchored on large Drupal and government projects. Love data and complex business problems.
9moI always think of the saying "The map is not the terrain." These decisions can be kind of arbitrary, there are inevitable compromises, and I prefer to see things in terms of how hard it would be to fix if you make the wrong choice.