This post marks the first of what we intend to be a series of short items that hopefully debunk some of the most commonly used terms in application design and development.

Our first post is about Relational Databases (RDBMS) which refers to a type of data store. Most applications will need to store data that they collect such as user profile information. There are different data storage options available; Excel, Microsoft Access and FileMaker are examples of data stores that many people are familiar with. For web applications we need something that can store very large amounts of often complex data that can be accessed by many users at any one time. Today most people choose to use a Relational Database from one of the major vendors such as Oracle, Microsoft, IBM or Sun (MySql). The term relational refers to how data is stored. For example, customers in an ecommerce system may be grouped together in a table called ‘Customers’. Their orders may then be grouped into another table called ‘Orders’. To know which order belongs to which customer the two tables will be joined by a relationship.

Alternatives to Relational Databases are Document-orientated Databases, for example Lotus Notes, or Object Databases that utilise XML.

In a recent post I wrote about the importance of the database in a web application. Continuing the techie theme I thought I should also mention the next most important issue concerning web apps: the architecture.

I still think the database is more important but architecture is certainly a very close second. I remember creating my first websites and everything was in one folder. All of my HTML pages and images sitting together made life simple when coding image paths and links to other pages. As the sites grew however this set-up soon became hard to manage. More pages, more images, and then CSS files and external JavaScript files and the one folder structure soon became a chaotic mess.

Now we have complex web apps consisting of databases, script files, images, Flash movies, audio/video files and more. Storage of all of these files can become expensive so we off load them on to dedicated storage or media networks. Suddenly our apps are distributed across multiple servers and networks and we have to manage scaling issues as storage requirements grow and user numbers soar.

Running today’s web apps with everything in one folder would be insane. So, the physical structure of our app is important if we are to be forward thinking (which we should be). Therefore we need to consider from day 1 how our apps will handle growth both in terms of the amount of data and files and with respect to increasing user numbers.

We have done some work recently with Flickr’s API and it is interesting to note that as part of the data relating to a photo there is information for the server and farm IDs. This indicates how Flickr handle the vast numbers of photos they have and how they are distributed throughout their server network. Imagine if they had tried to build Flickr with all photos stored in one folder, or even on one machine? As soon as that hard drive ran out of space their business would have been over.

One of our clients had a similar challenge relating to storage of files and we addressed this from the beginning. Rather than just storing a file name in the database we made sure we could store other information about the location. This allowed files to be distributed across multiple servers and even across the internet. Had we not considered this initially then we would have had some major changes to make to the file structure, code and database later on which would have been very painful.

Both this and the previous post on databases also highlight one other important consideration when building a web app: planning. Many folks often forgo much planning in order to start coding and get their apps out there as fast as possible. Fast is great but without good planning you could be on the road to nowhere.

The other day I was asked by an industry analyst how our clients are addressing Application Lifecycle Management (ALM). This was a great question for which I had a simple answer: they don’t. Now it would be easy for me to point the finger at our start-up clients but the truth is that no one is talking about ALM. The next question of course was why?

The short answer is that web has always seemed removed from other types of application development. The web is seen as transitory and agile, in Web 2.0 it’s about the iterative approach. If something does not work on a website we will just fix it, no problem. Therefore it is not just ALM that gets ignored but just about any development methodology or even basic questions like “will this scale?” do not get asked. Web just isn’t seen as serious development. Many businesses will throw away their website every few years, so why worry about ALM when the lifecycle is so short.

This is okay if the website in question is so called brochure-ware but today that is rarely the case. More and more business websites are integrating with backend systems to form end-to-end solutions that often go beyond the ‘in the moment’ nature of traditional sites. For example workflow processes are now part of the website lifecycle. Throwing these types of complex systems out every few years is simply not viable from a financial perspective. So surely any company starting down this path should be thinking about ALM at the very least?

With start-ups the picture is more complicated but in many ways more relevant. These are companies with applications at their very core. Unlike a traditional retailer’s website offering ecommerce for a start-up the technology solution is their entire business. The decisions they make on day 1 can have major repercussions on the long term health if not success of their business. Surely under these circumstances methodology and ALM are vital?

The problem is that these companies often lack the resources, time, experience and finances to implement solutions in this way. Start-ups tend to take a far more ‘fly by the seat of your pants’ approach to development. If something does not seem to be working this week we will change it next week and then change something else the week after that. They function on small teams of often dispersed developers sometimes with little long term vested interest who simply deliver in the moment with little regard for the future.

The reasons are understandable as time, money and resource are in short supply and the goal is to get a working application with as many users as possible in as short a time as possible in order to secure funding before their initial budget expires. In this world no one cares much for tomorrow. How many registered users have been added this hour is far more relevant than how the app will hold up 2 years from now?

Unfortunately time catches up and decisions made in the heat of battle often return to haunt such companies. There are some well known names that one could mention. Instead if you look at the companies that have done well such as Google you see examples of people who thought ahead from day 1. They planned well for issues such as scaling and reliability and addressed running costs and TCO from an early stage. Boring stuff in the world of iterative development and mashups but you do not see Google running into the problems Twitter has today.

The truth is that you do not need to be a blue chip tech company to think about many of these issues or even to incorporate ALM into your development workflow. Some of the key considerations I have touched on in other blogs such as good database design and scalable architecture. This adds a little time to the initial build but nothing significant and the benefits can be enormous later on when the user numbers start ramping up.

Addressing ALM could simply mean formalising the processes and roles that you already have in place. I know numerous start-ups who operate modelling, development, testing and deployment workflows. Taking some time to sure these up and apply some form or metrics to manage the movement between stages could reap significant benefits.

Whatever the size or nature of the business it is time for web application development to grow up. We are building more advanced and complex web apps involving numerous technologies and often distributed dependencies that are serving more people. They are becoming more integrated and mission critical and therefore it is time to start applying more traditional development approaches in order to secure a more robust future.

It would be great to hear from any start-ups who have implemented some form of ALM and how you feel that has benefited or not your application and business.

YouTube has been playing around with their UI recently and on the most part seem to be making some well thought through and subtle changes to both the web interface and the video player. With the latest update the rounded corners have been banished and replaced with a more compact and all together squarer interface, which seems to make a lot of sense given that videos can crop up anywhere on the web and square corners are going to make fitting video in different sized interfaces simpler. The UI now also degrades gracefully, dropping lesser used interface elements as the embedded video is reduced in size

However, the most recent changes bring a rather confusing menu system to the bottom right of the video, in which as a user I am required to click a button to open a popup menu with only one button in it, which just seems crazy? Surely just replace the menu button with the one in the menu, they are after all the same size!

There are some really smart people over a google / youtube, so I cant help thinking, is YouTube being stupid or have I missed something rather more fundamental?

I stumbled upon this lovely site today. At first I wasn’t quite sure what I was looking at and It took a good 10 min before I started to suspect that the video wasn’t going to end and I’m ashamed to say a further 10 min were wasted trying to workout if I was stuck in loop or if the events happening where leading somewhere. Normally this would lead to quite a lengthy rant about usability to an unsuspecting colleague. However on this rare occasion, I was more than happy to be subjected to a lengthy UNI QLO advert.

Best viewed on a large screen with the sound turned up and 20 min to waste.

Last week we attended the first Fuel conference in London hosted by Carsonified the folks behind FOWA and FOWD. This was a great event that seemed to reach out beyond the usual Web 2.0 community crowd. We were fortunate to have a short speaking slot thanks to our relationship with Microsoft. We knew that we were going to promote Microsoft but wanted to convey a message that we felt was important. We decided to dedicate our 8 minutes to ‘how to choose a technology’. The talk focused on three areas that we believe are most important in terms of making this decision and then how Microsoft addresses these.

Our three primary objectives when choosing a technology were: reducing time to market, minimising cost and the ability to integrate with other products and services. These were born out of our experience of working with a cross section of clients from start-ups to traditional businesses. The first two cross-over and also raise some other important considerations when looking at different technology options.

Reducing time to market naturally means shorter dev times and therefore leads to reduced cost. At the same time we do not want to sacrifice reliability, scalability and user experience in order to cut the initial dev time. Getting a product to market that has poor user experience or doesn’t work is a waste of time. Minimising cost often leads to a focus on the start-up costs of technology (e.g. how much do the tools and software cost) but I also raised the issue of over time costs such as the price of scaling. The final objective concerning integration may seem to be born of Web 2.0 and the mashup generation but to be honest it has had around a long time with many websites integrating with existing business backend systems for some time.

Talking about technology is always tricky as while it is important it’s never exactly entertaining stuff, despite the introduction of baked beans. I thank those who made complimentary remarks afterwards and to Microsoft for asking us to speak in their slot.

We now look forward to October when Jeremy will be speaking at Future of Web Apps about building desktop apps on your web app.

I was asked recently what the best way to start learning to code is. It’s an interesting question that I have been asked before. This is something which is so much easier to do today than ever before. Technologies are so easy to use and access and there is a wealth of documentation, tutorials, blogs, and forums and so on. Whatever your poison you should be able to get up and running pretty fast with your first “Hello World” application.

Learning to code and building a solid, robust, scalable app are two different things. The ease of access to technology has driven the recent web start-up wave but often these new companies run into technical problems that seriously impact their chances of success. So, the question is not what the best way to start learning to code is but what the most important area of building a web app is.

For me the answer is the database. Almost all web apps will have a database at their core and its importance should never be under-estimated. Create the underlying database well and you have a fantastic foundation for both the short and long term. Much of the way in which the rest of the application is coded will be dictated by the database structure. Any mistakes you make in your code logic can be fixed later relatively painlessly but get the database structure wrong and changing that can be very painful indeed, especially when you have a few thousand or more users in there.

Equally the database structure can significantly impact on the performance and scalability of your application. I have often been faced with slow running systems only to find that the problem is due to the way the data is being held. The database becomes more and more important as technology abstracts the developer from much of the code plumbing. For example, a number of technologies now offer very visual ways to getting data onto the screen with databound controls such as grids, forms and so on. The developer no longer writes code but just points these controls at the underlying data source.

I cannot tell you here how to structure your own database as it is so dependent on the application you are building however I can offer some basic advice.

Think about the future; consider functionality that you may not have in version 1 of your app but that you may need later. This may impact the way you structure your data and could require additional tables for use later that should be included now. Think about the areas where you may have large numbers of records and how these will affect performance. Think about primary and foreign key relationships in the context of keeping queries simple and indexing data for better performance. Finally, use table and column naming conventions that will make sense 6 months or a year from now and that will work in the context of any objects you create or code you write later.

Get the database right and the rest will follow.

We sometimes find ourselves involved with a startup application before a name has been chosen. It’s always flattering to be asked to contribute at this early stage and naming an application, company or product involves one of the most enjoyable meetings you will ever have. If you didn’t have fun at yours, you might have been doing something wrong!

I’ve worked on both large teams naming products for huge institutions and organizations as well as one man startups and the process is always the same. The key to any creative process is a good brainstorming session and the key to any brainstorming session is to first banish any negativity from the room. More often than not the best ideas come from thoughts being bounced around a room and that can’t happen if your idea it shot down at the first hurdle. It’s so easy for just one person to stifle the creativity in a room.

For example part of a recent brainstorming session went a little like this.

We need a name that says Notifications and ‘Everything on the web’

Like some kinda Alert Machine

A mixture of alerts

Alert Soup!

AllMyAlertsInOnePlace.com

StuffOnTheInternetThatYouCanNowHaveOnYouDesktop.co.uk

AlertThingy!

Wether you like the name or not, it was important to go though the down right ridiculous in order to get to a name we loved. One idea fed of another until we got where we wanted to be. Obviously there was an hour or so before we got there, but you can see what I am getting at?

So how do you get started?

Don’t start in front of computer hammering names into a domain checker. It will slow you down and you won’t get the banter you need. Instead check your ideas at the end of your meeting or when you think you have one you’re really happy with. If it’s not available but you like the idea behind it, there will probably be a variation that works just as well, if not better.

I kick start every brainstorming meeting with the same process. Get as many people in a room as you can, not just your creative types, but your account manager, accountant, developers, friends etc. Grab an A1 pad of cartridge paper and a thick marker and just let everyone shout words that they associate with the project, product etc. Clear the room after about an hour and just leave your core creative team to take over. Pin all the suggestions up on the walls for everyone to see. To get the second phase going start shouting out pairs of words “Notification System”, “Alert SIte” and so on… keep the ball rolling, share every idea you have, no matter how silly and most important of all, dont pass judgment on ideas you don’t like.

In Part 2: I will look at how you know when you have reached the right name.

In a post on 28 May Do no google! we put the challenge to ourselves and anyone else to not use any Google product for 1 week. It has been a couple of weeks now and some of us in the office not only managed week 1 but have continued to do no google ever since. Google search has to be the major test in this experiment and to be honest I’m not sure if I miss it or not. Certainly I miss the layout (bizarrely) but I do not feel I’m missing anything in terms of results. Could it be that we are just all familiar with Google now rather than it being that much better?

A quick shout out to anyone interested in hearing us talk!

Clive will be speaking at Fuel about ‘Choosing the right technology platform’ next Friday 13th June. It’s late notice, but they still do have tickets available.

Fuel is a one-day conference for entrepreneurs and marketers who want to make their companies, services and products truly remarkable

…and I will be speaking later in the year at FOWA about ‘How to build a desktop app for your web app’ in October (8th - 10th).

The Future of Web Apps showcases the successful web technologies and business trends of the future, delivered by the pioneers of today. Attended by all the major European and US start-ups and industry experts, it’s the best place to learn directly from the developers, designers and entrepreneurs behind the web’s brightest stars in a relaxed and fun environment.