5 ms·
I believe I linked to our work in Sudan (wiredcraft.com/work/southern-sudan-referendum/index.html). We've also done stuff for the UN (http://reliefweb.int http:
by hunvreus 14y ago
I believe I linked to our work in Sudan (wiredcraft.com/work/southern-sudan-referendum/index.html). We've also done stuff for the UN (http://reliefweb.int http://reliefweb.int), the World Bank, WRI (http://brtdata.org http://brtdata.org) and a whole range of other things my colleagues at Wiredcraft will be happy to mention.
I still think there are relevant use cases for using a CMS. However, from experience I think that:
1. In many cases, CMS like Drupal or Wordpress are seen as the silver bullet for everything and anything; "Why use a 3rd party? Just built it in the CMS!". That's how you end up with expensive, tightly coupled platforms that are effectively locking these organisations in.
2. Many organizations are just engaging in some kind of arms race, copying what their neighbors and competitors have.
- danso 14y agoYes sorry, you caught me in my "reflexively-check-HN-just-as-I-wake-up-groggily" mood...Thank you for the links. I completely agree with you that CMS is seen as an intractable silver bullet. However, I think it is too extreme to say that web development, as we know it, is out the window. While Wordpress is not the silver bullet, the ability to graft on 3rd-party APIs and client-side apps (even something like Disqus/Facebook comments) makes knowing just Wordpress still incredibly useful, for clients who do not need bespoke data solutions. But even with a client who needs data-resources, it seems like Wordpress could still play a key part by being the HTML page server with javascript includes to an external data app...deciding to build a new framework just to accomodate unique data-resources can still be overkill.
- hunvreus 14y agoRight. From the post: "It’s not that we fundamentally disliked the previous approach. We just reached a point where we felt our goals weren’t best served by this model. With lots of dynamic data, complex visualizations and a set of “static” interfaces, the traditional way was hindering our development speed and our ability to experiment." It's very much targeted to our specific needs. Our approach is no more universal than Wordpress or Drupal. We have however harvested interesting conclusions from moving away from these CMS and that's mostly what I was interested in sharing. With regards to using Worpress as a middle man for data centric apps, this is the kind of things we've done. My opinion: CMS are good at doing regular type of content CRUD based apps, but it breaks quickly. Moreover, most popular CMS are becoming bloated pretty quickly. Have a look at Jekyll (http://github.com/mojombo/jekyll http://github.com/mojombo/jekyll), it's a much better fit for that.
- danso 14y agoYes, I love Jekyll and use it (with Octopress) myself...however, how easy is it for non-developers to use? I mean, I know it's easy...but even when non-developers can figure out HTML (nevermind Markdown), they are still more comfortable with a rich-text interface (until they try to embed code, of course...)
- hunvreus 14y agoWe have strong opinions on WYSIWYG and rich-text too: Avoid WYSIWYG Editors (http://wiredcraft.com/blog/avoid-wysiwyg-editors/index.html http://wiredcraft.com/blog/avoid-wysiwyg-editors/index.html).
- snowwrestler 14y agoThere is one huge reason that organizations go with Drupal or Wordpress over an advanced custom solution like the blog post describes: it makes it easier to switch vendors. Lots of people know how to work on Drupal and Wordpress, and it's not hard to find vendors willing to step in and take on the operation and maintenance of an existing Drupal or Wordpress website. In fact there are entire organizations--Automattic and Acquia--dedicated to providing such support services. This provides an essential hedge against poor vendor performance, which, sad to say, is all too common in our industry.