August 28, 2009

How to choose a web application

More and more often, friends and colleagues are asking me "Which CMS should I use?" or "What is the best document manager/webmail/twitter clone?".
In the end, my answers always follow the same patterns, so here you are my tips on choosing the right web application. What should you evaluate when you choose a web application?

  1. Features

  2. I know, the KISS (Keep It Simple, Stupid) unix paradigm would suggest to have a web application which only does a single task - a best of breed, if you wish. However, while we do have software management tools in Windows or Linux which can somehow keep application proliferation at bay, we don't have such tools when it comes to web applications. Managing 5 or 6 web applications is a real burden when compared to handling just one: updates, dependencies and so on, everything (or almost everything) has to be managed by hand. And don't even make me start with application servers. So, definitely go for more features than you even need. Just watch out for the Notepad effect: while Notepad can edit ANY document and an XML editor will only edit XML documents, you should use it anyway...

    You should not stop ad data sheets or feature lists: install the product if you can, or try it on a virtual machines (most vendors are now shipping demo virtual appliances) and try to build up an idea of the actual features. There's always some gap between what's on paper and what's in the code!

  3. Community

  4. A strong community is really a must have for any web based product, no matter if it is open or closed source. In the opensource world, having a strong community means the product will unlikely die out, while for a proprietary apps it means you will have more than just the official documentation.

    A community also means addons and plugins which almost any modern web product will support. Just watch out, because you should evaluate addons one by one in the same way you evaluate your application.

    Browse the forums, noting the date of the last posts, try to find active sites or blogs about the products and take note of who's using it. Do not trust the "BigCompanyX is using our product" claims, since especially in opensource software, given a large enough company any software is bound to be used in some department.

  5. Security

  6. Security is always an issue when it comes to web applications. You should check the application history (try for a Google query like "YOUR.APP.HERE exploit" or "YOUR.APP.HERE security advisory") to get a rough idea of how many issues the application had in the past. Note that no issue is maybe even worse than a lot of issues: it likely means that no independent reviewer ever took a look at the application...

    Take care, when you assess a CMS: you will find a lot of security issues on external or third party components, and it's often hard to tell if they are there due to the lack of security of the component or of the platform itself.

    Nonetheless, a OneBugAMonth history is definitely a warning sign..

  7. Vision and people

  8. This is very important when it comes to large projects, like Content Management Sytems. Where is the software going? What the company will do with it? This is the most hard part to judge, since you will most likely not have any resource. My advice: go for the people. Search the web for the coders, take a look at their tweeter accounts and their other projects, if any.

    Should you need a way to retrieve some email address, try FOCA: it will automatically fetch email addresses from any document on the company's website.

  9. Standards and integration

  10. Look for proper standards. "We're using Java so we are standard" is one of the most widely heard of claims, and doesn't make any sense. Look for actual interoperability: open source code, web services, open and well documented data format.

    Even the most well guarded, proprietary application can have well documented standards, saving everything in XML and thus being much more easier to integrate in your environment. Remember integration is a must.

  11. Requirements

  12. Last but not least, look at the requirements and the technology the solution has been built around. Deploying a Zope based solution today might not be a great idea from a strategic perspective, no matter how much I like Zope. On the other hand, using a technology you're completely unfamiliar with can slow down deployment and makes management much more difficult. This said, you should reiterate the analysis on the underlying component as well: maybe the application will require Tomcat, maybe Oracle Application Server.

    It really does make a difference: choose the wrong technology you and you will end in a cul-de-sac in no time.

August 24, 2009

The web is in realtime

You know a technology has really became upstream when you see client-side attacks to that technology.

That's exactly what's happening with real-time information flows: even black hat hackers are using real time technologies.

Whike the most well known real time application out there in the internet is twitter, as you most certainly know by now, it's not just tweeter anymore. Users are becoming more and more adept to retrieve data in real time and are actively starting to look for it. Even search giants like Google are getting more and more "real time" search results in their results-set.

However, this comes with a price: real time information is nowhere near as accurate and as deep as "old school" batch produced information. You cannot post an in-depth review on tweeter, so you're most likely going to just write "it works" or "it sucks" and that's it. This is not the sort of clean information organizations want to provide their users. However, and that's exactly the key to understand what's happening on the web, they are forced to do so. Users work and think in real time; your customers are using a real-time web, and you must do so as well, like it or not.

The "real-time revolution" is not a technological one. We've had forums and bb even before the internet as we know it now was born. However, it is a strong change of paradigm: users are now all of a sudden looking for those "contact me in real-time" boxes, they are asking questions expecting answers in real time. Email is just too slow for that.
At the same time, once you write something you've written it, you can't just deny it. So, we're facing a world where you (as a company representative) are expected to answer fast and do so correctly.

This I think, is one of the most important issue. To react, in a world where "when" is always "now", you have to be faster than yesterday, and the first thing you have to cut are decision times. Have the managers, the ones who can actually make a statement, interact with the web in real-time.

Need a good training on the whole real-time stuff? Maybe you should seriously ask your organization whether you understand what's going on in the internet or not. However, you can start by trying Yammer and see that (not if) it makes a difference.