Categories
Business Platforms

What is the right CMS for your business?

 

choosing-CMS

“I don’t care about the platform, let’s just create our website on something popular and cheap and get on with it”.

Dear IT decision maker, this is wrong. On an infinite number of levels.

This article is going to show you why. It’s not going to promote one technology or CMS platform over another,(well, at least not much, taking the author’s unavoidable personal bias under account). Instead, it’s going to address the issues that usually arise long after the CMS platform has been selected and paid for.

For the purposes of this article, we have picked interesting details about a number of popular and emerging CMS platforms like WordPress, Joomla, Drupal, Typo3, DNN and Umbraco , and we have also included references to Concrete5, Contentful and Rooftop, as well as Wix (a web site builder  that is provided exclusively in SAAS form). Although WordPress is currently by far the most popular CMS out there, this post is not a “Wordpress VS the world” one.

“A lot of people are using it, what could go wrong?”

Let’s take WordPress. It’s got over 24 million installations (an estimate from a relevant article on Quora, but we can’t know for sure what percentage of them regards installations of business websites as opposed to personal sites, blogs, or small business like hairdresser salons, neighbourhood groceries and auto repair shops (that are usually just a couple of pages set up on a free or very cheap theme and that’s about it). Don’t get me wrong – there’s nothing wrong with this type of websites, but they’re not indicative of a CMS platform’s capabilities in any way.

For comparison, Typo3 says it has over 500,000 installations, Umbraco says it has over 380,000 installations, Concrete5 is just shy of 140,000 installations and Drupal has over 1,200,000 installations.

Although other CMS platforms feature a very smaller number of installations, a Fortune 500 company website will – probably –  outrank a local hairdresser’s website in complexity, features and quality.

So one number you should pay attention to is how many use cases are published out there, and for what type of clients. Do not base your choice solely on how many people are using the CMS, but introduce some quality criteria. How many companies in your business sector are using this CMS? What is their preferred choice and why?

“As long as it does its job”

Having been in the industry for about 20 years I’ve seen a lot, including “fake” CMS platforms. Many years ago, around 2001, I met with the owners of a small web development agency who believed in the doctrine that the client should be totally platform agnostic. They showed me the CMS they were using.

It was a glorified web file manager managing static HTML pages! This is what they knew how to do best – static HTML pages. But since clients were starting to demand “a CMS”, they gave them what they wanted.

When you choose your CMS, always make sure that it provides you with the editing functionality you really need. Chances are most of today’s CMS platforms will allow you to do several things (we’re not in 2000 any more), but how far you need them to go is up to you.

For example:

  • Does the website’s navigation system (menus, footer links etc.)  get updated automatically or based on a specific set of rules when you add new pages (provided that you can easily add new pages!) or do you have to do that by hand?
  • How are page URLs generated, are they SEO friendly, and what happens when you change a page’s URL with regards to SEO and links that may exist on your old URL?
  • Does it manage image resizing for you or do you have to resize images before uploading them unless you want your visitors’ bandwidth to choke over that 20 x 6MB image gallery?
  • Are you really protected from “breaking” the layout if you use the CMS’ WYSIWYG editor (assuming it has one!) to update content in an unorthodox way?

The above are just food for thought. There are actually dozens of tiny little things that you should consider in the same regard.

For some CMS platforms, the answer to almost every one of the questions above is “it depends on the developer”, which is actually a good thing since it means that the CMS can be properly customized and extended for your own needs as long as your specs are detailed and correct. Which leads us to our next point..

“I’ll hire somebody to extend it when I need to”

There are agencies out there that provide design and development services using their own proprietary CMS, claiming that it has been specifically developed to address your needs. While this may be true, you’re actually getting tied to a specific agency’s proprietary software, with little chances to find developers outside this agency willing to work on it in the future, even if the agency gives you the full source code of their CMS (which, in most cases, won’t happen anyway).

If you decide to go with a popular open source CMS, you should definitely take the “signal-to-noise” developer ratio under consideration. What I mean by that is that it’s easy to find developers for popular CMS platforms, but you should watch out for fakes or people with very limited knowledge. A rule of thumb is that the more popular the CMS platform is, the more chances you have to hire a person who just learned about it yesterday, or works solely with plugins/add-ons without having ever written a single line of code.

Although there are no known statistics for this, it is obvious that the easier a CMS is to set up and start with, the more possible a greater pool of inexperienced developers is. Open source CMS platforms suffer from this a lot – my experiences are limited to WordPress, Joomla and DNN Community – all three are very easy to set up and get going, but need a lot more when it comes to specific functionality. There are a lot of folks out there that claim to be “developers” using one of those platforms when in fact they just know how to set it up and configure it with a theme (usually a free one) and probably some plugins. Ask them to do something that isn’t covered by the core CMS functionality or the plugins they are familiar with and you’re suddenly open to a whole new world of expenses, bugs, and subsequently more expenses.

“I got it cheap, now it’s ready and I don’t have to pay anything more”

Maintenance costs, unless they are agreed upon from day one, are considered hidden costs and they often end up, in the long term, being higher than the actual cost of developing your web site with the CMS of your choice. If your CMS’ performance degrades over time or if your CMS is often vulnerable to exploits, then you *must* consider maintenance services. The alternative is far more expensive.

So what can you do? First, have in mind that the most widely used a CMS platform is the more “bad” people are going to target it and the more vulnerabilities will be discovered.

Exploit DB maintains a great database of exploits per platform. Let’s see how two of the most popular CMS platforms around today are doing there compared to other, less popular choices. WordPress had a whooping 982 total entries at the time of writing this article, Joomla (a similarly popular but notoriously insecure platform) had 1,152 entries while less popular platforms like, for example, Umbraco (the one I’m working with) had 1, Concrete5 had 16 and ModX had 15.

This does not make popular CMS platforms less valuable – it just indicates that, if left unmaintained, they will have higher chances of being exploited, hacked, defaced and lots of other terms generally meaning “more money to spend on repairs”.

The problem with updating a CMS in order to secure it often lies with third-party add-ons that may not follow your platform’s update path. It is common for popular CMS platforms to have a wide number of add-ons (called plugins or modules or packages or extensions, depending on the platform) made by third parties, and some of them break when the CMS is upgraded to a newer version, or even become the starting point  for exploits in the first place.

At the time of writing this post there were 47,956 WordPress “plugins”, 859 DNN “modules”, 7288 Joomla “extensions”, over 1500 Typo3 “extensions”, 36,031 Drupal “modules”, and over 1000 Umbraco “packages, just to get a feeling of the sizes we are talking about.

If you go with a popular platform, or one that is widely known to often be the target of hackers, you should ensure that your site is developed in a safe manner, its add-ons chosen very carefully, and that it is maintained correctly (either by your agency, your web host or a person you will hire for that). Alternatively, you can switch to PAAS or SAAS solutions, like for example wordpress.org hosting for WordPress or Umbraco Cloud hosting for Umbraco and leave site maintenance to the experts (at a cost). Even Wix is considered a SAAS solution (with restrictions mentioned elsewhere in the article).

“I spent a week doing data entry”

No matter how much you pay for your CMS and/or development, your content is what is most valuable to you and what you are going to be maintaining and expanding for years to come. You must be absolutely sure that you really own your content and that you can have it exported in a way that will allow you to reuse it with minimal cost if you need to.

Wix, for example, is a SAAS platform  that provides a very nice (and cheap) way to have a site up and running in virtually no time – but with a price. Your content is “tied” to their platform and cannot be exported or transferred elsewhere.

 

“It’s OK, but we may need to have more in the future”

Let’s say that the only thing you want done today is have your website built as soon as possible. What about tomorrow?

Often a website needs to get expanded with functionality that was not predicted or planned from day 1. This may include importing data from third-party sources, integrating feedback forms with CRM applications, adding e-commerce capabilities etc. If you have only your website in mind today, you may choose a platform that is hard (or expensive, or both) to extend in the future.

For example, WordPress has an abundance of plugins that make it integrate with third-party systems, and it’s relatively easy to have developers write some additional code to do so. But, if your long-term goal is to use the same platform for your intranet and include SSO capabilities for Windows Domains, then DNN is probably the way to go.

Let’s also not forget that a CMS today is not what a CMS was 10 years ago. A website on a desktop PC or laptop is only one way of presenting information. Your site must be ready for mobile (tablets, phones), and your data should be ready to be accessed by native applications. Well, most CMSs today solve the mobile problem by either letting you implement the responsive/grid layout of your choice or already using one for you (although how they allow you to form your content using WYSIWYG editors and how they provide decent previewing varies greatly). How you can expose data to be consumed (and updated) to native apps, though, is another issue.

If you are primarily interested in having your data consumed by third-party apps / native mobile apps, then a different set of priorities need to be introduced:

Does the CMS of your choice feature an API that is easy to use?

Although almost every CMS today is advertising an API, not all APIs are equally mature. CMS platforms with a rich add-on ecosystem usually feature the more mature APIs since those facilitate add-on development. A generic API may not be always useful for exposing your data to other apps, but it’s a first step towards that.

Does the CMS of your choice provide a REST API?

Some CMS platforms allow you to easily create your own REST APIs where others provide them out of the box (and allow you to extend them). If you need to make your data available anywhere outside the confines of the CMS, your best choice would be a platform with a mature REST API. Thankfully, all popular platforms provide that in a way or another. WordPress, for example, has multiple plugins that provide REST API functionality. Umbraco has a REST API developed internally. Joomla features a REST API in the form of an extension.

The factor that you should pay attention to, however, is how complete the REST API is. The less you need to extend it yourself the better.

For CMS platforms with an add-on ecosystem, a critical factor for your decision is how many of the add-ons you are probably going to use will work well with the existing REST API.

For example, Gravity Forms , a very popular WordPress plugin, is not implementing the WordPress API in a standard way and, instead, provides its very own API, which can lead to a lot of work if you need to seamlessly work with WordPress and Gravity Forms in a unified, RESTful way.

Should you consider an API-first CMS instead of a page-oriented one?

This is the toughest question that you may have to answer. If your primary goal is providing your data to third-party apps, then an API-first CMS like, for example, Contentful or Rooftop  (which, by the way, uses WordPress as its back-end and manages to solve the WP-Gravity Forms API integration problem we talked about above), is definitely the choice to go for.

What an API-first CMS offers as an advantage is the total separation of the data and presentation layers, meaning you have an “engine” that can manage your data regardless of where they are eventually consumed. This can be a blessing or a curse, since it’s up to you to decide which technology to use for a web front-end (which is treated like any other app that consumes its data), while you may have to deal with potential limitations imposed by the number of SDKs available.

“We work with Java, but what’s wrong with launching a PHP-based website?”

Let’s suppose your organization heavily depends on Azure, Office 365 and Active Directory. Why on earth would you select, for example, Django CMS as your platform? Although it is a fine CMS, its technologies will be far out of your organization’s scope and internal expertise and you would have to resort to third parties for every single issue introduced during the lifetime or your web site. You might do that anyway (see the next section), but you have no way to evaluate results if the technologies used are alien to you. Let alone integrate your web site with other things.

This is a highly subjective point of view and you may totally disagree, but my belief is that the CMS you will choose to power your web presence should be in harmony with other technologies already being used in your business, since this opens up a lot of options for its evolvement later. Unless, of course, you’re using an API-first, cloud-hosted CMS, around which you can build additional services.

“We’ll extend it internally”

So you’ve got a couple of IT people that are familiar with some Web technologies and you think that it would be cost effective if you selected a CMS platform that utilizes the technologies they already know so that you can maintain it and extend it internally.

I don’t even have to prove why this is fundamentally wrong, but let’s say that it is analogous to having your graphics designer paint your house.

Conclusion

Your decision on the CMS platform you should use for your site is not an easy one, and it should not be left in the hands of the agency you intend to hire  just because “that’s what they’re working with”. It’s easy to be impressed with the design and visuals and forget there’s an “engine” that powers your website behind the scenes, but that engine is the most important aspect of the whole construct since it’s the one that will restrict you or enable you to do more when that time comes.

You should have a long-term plan about how you want your web site to evolve, what you expect it to cost you in a specific period of time and how you are going to tackle challenges like security and extensibility. There is no globally right answer, it all depends on what your own main objectives are.  

Being conscious about the technology, the platform, its pros and cons and its features will only benefit you in the long term. If you feel you don’t have the technical knowledge or the time to make such a decision, you should hire an expert consultant who will take all parameters into account and suggest the best platform for your own needs. Whatever you do, though, for heaven’s sake don’t buy a website at the price you would buy a new pair of jeans just because “that’s all you need”. You’ll end up paying for a whole new wardrobe really fast.

 

Categories
Business Tips

[Infographic] How to design a growth strategy for your app.

Developers are makers. They solve pains, entertain, enlighten, and enhance productivity. Building an app can be an exhilarating experience and the joys of shipping can linger for… about ten seconds. Then comes the question: “I’ve built an app, now what?” Where do you start with your app growth strategy?

Building strategies for user acquisition and retention are the two major tasks for dev teams after they have built an app. Analytics helps understand exactly what is happening and how to keep building traction. From there, new possibilities can emerge that will help you grow your user community even stronger and help you identify novel ideas that may offer you a winning edge.

Check out our infographic based on our series of articles on User Acquisition , User Retention and Growth Analytics.

Built_an_app_Infographic (3)

Want more insights on app growth strategy?

Check out our State of the Developer Nation Reports, and make sure you understand Analytics for Growth.

Categories
APIs Platforms Tools

Do-it-yourself NLP versus wit, LUIS, or api.ai

 

NPL_bot_

 

Alex and I have been building bots for about 1.5 years and have talked to hundreds of bot devs through our BotsBerlin meetup, which now has over 1,000 members. Something we get asked a lot is whether it’s worth investing in building your own NLP engine, or whether it makes sense to use a third party service like wit.ai, LUIS, or api.ai.

What does a chatbot’s NLP engine do?

Let’s say you’re building a restaurant bot. These tools will help you take a sentence typed by a human, and turn them into structured data, for example:

 

NLP Module chatbots

 

Do you build yours or use third-party tools? Let us know in our DE Survey.

The structure on the right is something computers can actually work with, and you can pass this on to the business logic of your bot. For example, you would probably query the Foursquare API and fetch a list of restaurants. If there are some popular restaurants matching those constraints, you would probably suggest those to your user. If not, you might suggest a Chinese restaurant instead.

NLP-api-chatbots

Foursquare has already done the hard work of finding matching restaurants, so the trickiest part of building this MVP is finding a way to generate structured data from natural language. The great thing about tools like wit, LUIS, and api.ai is that they make this part so easy that you can build an MVP like the above in an afternoon. In our experience, 3rd party tools are an excellent way to build quick prototypes. You could just as quickly build a bot to find videos with the YouTube API, or products from Product Hunt.

Reasons to do it yourself

If your restaurant bot is a runaway success, you will inevitably want to become independent. We see that the more advanced bot teams are all developing their own NLP. Data from the Developer Economics surveys, which polled the opinions of thousands of developers interested in chatbots, are pointing towards a democratisation of chatbots through open source projects (there’s a live survey out now if you want to contribute to this knowledge pool).
Here are three real-life examples of why people switch.

API constraints

databot was a Slack app we built at the start of 2016. Databot would connect your data warehouse to your Slack, so you could ask

what was the ROI like for October’s facebook ads?

and databot would generate the corresponding SQL query and answer your question.

We started off using wit.ai, which would always default to guessing that October referred to the following October, not the previous one. So we had a lot of fun with our date library to build a workaround. Of course wit could add a feature to let you customise this default, but that’s missing the more general point. If you use an API you are have to live with someone else’s engineering decisions, and that friction tends to grow as your project matures.

Data ownership

We talked to a startup building a commerce bot, specifically one which let you look for presents for friends and family and find good deals, e.g. “my sister likes running and craft coffee and I want to spend around $30”. For them, gathering the data around people’s purchasing intentions is core to the value of their business, and they want to make sure it belongs to them. Moreover, for privacy sensitive verticals like insurance, health, and banking, sending every message to a 3rd party is not an option, users and businesses just aren’t comfortable with it.

Performance

Admithub is an education startup. This team actually has one of the most technically advanced NLP modules I’ve seen, it can recognise thousands of intents. Their bot helps university students by updating them about events and deadlines, and can answer questions ranging from “when are housing applications due?” to “can I have a salamander in my dorm room”.

AdmitHub found very quickly that third party tools weren’t up to this task (they tend to optimise for the small data use case, performing well even when a developer is getting started and there are only a few examples). Most also failed to handle misspelled words, which are common when chatting with teenagers. While simple bots are generalizable, sophisticated bots are all complicated in their own way. Every algorithm has trade-offs, and a one-size-fits-all approach can let you down when your use case becomes more advanced.

Bonus: Control your own fate

Ultimately, technological independence is compelling for many teams. It’s great to use free tools developed by big tech companies, but they may not stay free (Microsoft have started charging for LUIS) and they may disappear with little notice (like Parse did).

The rise of do-it-yourself NLP

{wit,LUIS,api}.ai are wonderful tools that make prototyping very quick. But from talking to dozens of bot teams, I’m convinced that everyone will eventually become independent. Early indications from the state of AI survey are that virtually all businesses are uncomfortable relying on APIs for their AI, and that doesn’t surprise me given the examples I’ve just talked about. The engineering case is that web APIs just aren’t the solution to every problem in programming. The business case is that you really want to own your data and be independent.

In 2017 we will see the bots that have traction moving away from 3rd party NLP services. The biggest drawback, until now, has been the engineering investment and machine learning talent required to build a custom NLP engine. It makes no sense every bot team to reinvent the same things, so at LASTMILE we decided to open source ours. You can find out more at rasa.ai

 

Are you involved in ML and/or AI? Take the Developer Economics Survey and shape the future of ML/AI development.