
Flexible vs. easy to use content management
5/4/2009 4:53 PMI’m a currently working on a project bringing the most flexible CMS to life. The project is based in Microsoft ASP.NET MVC and we started the project while the framework was still in beta. We believed (and still do) that they really are on to something. However, this is not the reason for this blog post. I want to express my considerations about the need for flexibility vs. easy to use. First of all, our client needed to consolidate all their customers into one system, making it easier to manage and maintain. In other words they needed a CMS build from their needs. Their primary concern with a CMS was that it would limit their possibilities of using custom HTML in the design, in the automated list, in content in general etc. So the goal was flexibility. Flexibility will in most cases increase the complexity and therefore decrease the ease of use for the web designers that are actually going to implement the website, since they will have to manage some code in order to gain the flexibility goal. We have implemented the core functionality and are at the time of writing making the final changes in order to complete the second wave of user features.
Depending on your time schedule, this scenario might be very familiar to other developers. You have implemented a product (like this CMS) matching the needs, the design and the usability requirements for the project and completed it to the required deadline, but now the focus slightly shifts looking at the possibilities of letting even more people be able to change the advanced features. This will often times mean that we are now targeting people with less technical expertise and less training. Some things will be fixable by simply changing the UI, but the requirements might change as well, as this new type of users will have other views on how to handle things. In order to support a change like this, your framework should be pretty flexible – and this is not the same kind of flexibility as being able to customize the HTML. In our case, we are introducing extra data elements in the model to accommodate these changes in proper way making the advanced features easier to manage while keeping the flexibility.
Therefore make sure that you target the right users for the different parts of your system. Don’t necessarily target every part of the system to the lowest common denominator, as this will take longer time and even be waste of time. Instead make sure that you hit the target user and if possible considers if your model will support a slight change in the targeted user either by changing the system or supplying additional education.
On another note, breaking the link between Twitter and Facebook is working well. I post more freely and frequent on Twitter now, but less on Facebook. I have setup ping.fm to post to Facebook and LinkedIn and when I need something added everywhere I use the ping.fm integration in Twhirl.
blog comments powered by Disqus



