5 ms·
I think most CMSes are a balance: how general are they so that they can be useful to many different use cases vs how complicated that makes them. All these CMS
by pierrefar 16y ago
I think most CMSes are a balance: how general are they so that they can be useful to many different use cases vs how complicated that makes them.
All these CMSes bring their own terminology too. WordPress keeps it simple: it's a page or a post. Leaves it up to you to interpret what that means.
Drupal takes that a few steps further with content blocks.
Joomla, when I last used it, was like having pages ripped from a book, shredded into tiny pieces, and jumbled into a pile.
So when judging end user design, I'd also mention the context and the use case: Do I simply want to produce content that is sorted in reverse chronological order? Do I want to be able to handle all types of content imaginable or just text? And what kind of meta data are you keeping track of in conjunction with the content? Meta data is the author, category(ies), various timestamps, etc.
- lovskogen 16y agoI'm also interested in propietary CMSes by web bureaus. Wordpress, Dupal and Joomla does not make for a good custom site experience. Either too generic or having a gui that is too complex and hacky for mere mortals.
- knieveltech 16y agoYou raise an excellent point here. Any custom site implementation is going to require some custom code to nail down the user interaction. This is a fact of life regardless of what CMS you're using.
- lovskogen 16y agoYes. But does a CMS do this in a good way? Custom fields inside a admin interface is not a very modern approach.
- knieveltech 16y agoI'm sorry but I don't agree. Having the ability to define custom data entry forms (including unique field types like calendar dates, google maps location pickers, etc) and the data storage that goes with them via a web interface with no coding required seems pretty modern to me. Can you point out an example of another approach that seems better to you?
- lovskogen 16y agoDoing all those things in context. Imagine the client logging in, and on the About Us page pressing "Add Content". Then chosing "Insert a map" from a drop down of content types. A resizeble map container appears on the site. The client searches or drags the map into the right location and presses "save". Then he publishes the page.
- lshepstone 16y agoI think we're mixing requirements here. Use case 1: I need to create a new page and for many corporate sites, each new page is different than the next for the majority of the body copy...different layout, one has a map etc. I need to choose where this page goes in the site as well. An in-context approach is very well suited. Use case 2: I just need to create a press release quickly, it always has the same template, always goes to the same part of the site and it's always the same process I go through. An in-context approach here isn't that good, you want a template approach where the user fills in some fields on a form, a title, body text, maybe image, checkbox for map yes/no etc. This isn't a page at all really, it is a piece of content that is created and using the Press Releas template, the page is created dynamically at the right point in the menu structure. They'll create the page in 30 secs and be done. There is very little point in choosing from a list of modules to insert when you're dealing with a fixed template. So you're talking about the templated approach vs the page builder approach. Neither is better or worse, just suited to different use cases.