Love of complexity is a programming disease.
Complexity can signify a complex problem on a simple domain, or a simple problem in a complex domain. You simplify one place, you're just pushing the complexity somewhere else.
CMS Trap
21–30 of 65 posts
Re: CMS Trap
#22Just because you use a CMS doesn't mean you have to use it for everything. If you're managing content (blog content?) use a CMS. If you're making PPC pages, host them statically somewhere. If you sell something, use ecommerce software for that part. The right tool for the right job.
If you're making PPC pages, host them statically somewhere. I'd counter recommend this. In my limited experience with it, dynamic PPC landing pages are so effective as to be almost cheating. BCC's AdWords campaigns are not doing well in 2013 for what I believe are unrelated (and mysterious) reasons, but the ~20 lines of Rails code which make URL #1 and URL #2 roughly the same today but will automatically switch URL #…
Can I check I've understood you right, Patrick?
You have some code that infers from usage that, for instance, civil rights cards are popular in late January (Martin Luther King Day is on January 20th)? Neat! :-)
Re: CMS Trap
#23I am SO sick of spending more time configuring the CMS than writing code. Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file.
But the piece was not about using CMSs where code would be more appropriate. It was about turning your bespoke application into something like a CMS by architecting for maximum flexibility and configurability everywhere, building complex "admin" interfaces, and implementing data-driven runtime behavior before any of that is really necessary.
You can do all of these things with 100% test coverage, but that doesn't relieve you from dealing with the weight of the architecture and extra work when you try to add or change functionality later.
Re: CMS Trap
#24Earlier quoted context omitted.
> A pretty web interface isn't a must-have requirement. According to most definitions of "CMS", it is. With static website generators, editing, versioning, publishing, etc is done externally. They aren't systems which encompass all of this. They just punch some content into your templates and write the result to disk. That's all they do.
Are there any CMS that have a "pretty web interface" ? From what I've seen of Drupal, the interface exposed to content creators is awful. It works (mostly), but it ain't pretty.
CQ5 looks better (but isn't).
Re: CMS Trap
#25I think the key question is: At what point is building a user interface more expensive than hiring a full time developer?
or buying a product
Re: CMS Trap
#26Just because you use a CMS doesn't mean you have to use it for everything. If you're managing content (blog content?) use a CMS. If you're making PPC pages, host them statically somewhere. If you sell something, use ecommerce software for that part. The right tool for the right job.
I took this a step further for a recent client with a low budget and used separate social sites to manage the content. I'm certainly not the first to do this, but it's worth mentioning as a viable alternative for a lot of smaller sites.
This particular client produces television advertisements. Videos are pulled in from Vimeo, photos and text updates are pulled from Tumblr. The API data is cached locally with serialized objects to keep it speedy.
Since they already had active accounts on both services, initial content population was minimal. We were even able to use categorization strategies already present on Vimeo to organize content.
Re: CMS Trap
#27I am SO sick of spending more time configuring the CMS than writing code. Oftentimes, I could've built a product from scratch in the time it takes me to Google the undocumented quirks of some stupid YAML file.
Agreed. I've almost given up on using a CMS. Developing on the Drupal platform (as mentioned by the author) was really painful. I've only found a few CMS' that get the heck out of my way and just let me write code.
This days if I have a static site around 10 pages, I just use .Net MVC project and use partial views to store the content. Much easier than using a CMS and I still retain all the control I want.
Re: CMS Trap
#28Overengineered software systems are like sex - every generation thinks they invented it.
Re: CMS Trap
#29@rudyrigot and the team @prismicio http://prismic.io really have a handle on this problem. They believe a github-esq content management system makes the most sense for content creators, and a content API makes most sense for engineers to distribute that content inside of a variety of platforms (mobile, a rails app, whatever). Saw Rudy speak at Zendesk/Rails meetup this month, it was a very good presentation (I am not…
The article is stating that developers should lean towards going static versus using any content management system. Would you like to provide a meaningful comment about how Prismic voids this author's argument?
Re: CMS Trap
#30@rudyrigot and the team @prismicio http://prismic.io really have a handle on this problem. They believe a github-esq content management system makes the most sense for content creators, and a content API makes most sense for engineers to distribute that content inside of a variety of platforms (mobile, a rails app, whatever). Saw Rudy speak at Zendesk/Rails meetup this month, it was a very good presentation (I am not…
The article is stating that developers should lean towards going static versus using any content management system. Would you like to provide a meaningful comment about how Prismic voids this author's argument?
[edit] Apparently we may both be on the wrong page: https://twitter.com/hakunin/status/405874291100901376
Prismic allows you to "go static" for very little dev cost. Your content creators get a nice editor and can publish their content as needed, effectively making it static for you (the dev), as though it went through a build script (Jekyll or something "static"). The CMS gets out of your way, and you get to concentrate on making your app work, not getting into the complexities of building/maintaining a custom CMS.
I mean, that's what the assertion that static is the way to go eludes to, unless I am incorrect about the entire point of the article. It's about not getting dragged into the bog of making a CMS.
The author outlines various scenarios: do it yourself, to building your complex app on a CMS (ugh), or just going back to static because it is the simplest, hardest to fuck up option. I don't think he explored the idea of content management as a service fully, which is why I brought up Prismic—it is another option, and in my opinion, a very good one.