Direct Marketing & Digital Marketing Agency - Ashley Bolser Agency

Since our first foray into mobile app development in 2008 with Symbian & the Nokia connectors application, we’ve seen a massive increase in projects and clients interested in developing their own applications. We’ve got some really interesting apps we’ve been developing recently for all types of handsets with vastly different functions inc. image recognition, API, GPS & geo-location, for some big clients - all very exciting!

And since the iPhone, there has been an incredible explosion on the iTunes app store, Nokia’s Ovi store is becoming a big player,  Vodafone are jumping on the bandwagon and lots of other network providers and third parties have emerging app stores. However, this rapid adoption has lead me to ask some questions -

• How long is the app rush going to last?
• What is the future of mobile apps?
• Where are we headed?
• Is this really the business/mobile model of the future?

Mobile apps and their stores have been great for leveraging the recent shift from mobile phones to mobile computing, and really signaling the future  of digital technology - but they do have some inherent problems-

• Publishers rely on third party platforms
• Publishing and approval process
• A needle in a haystack
• Dedicated application and API development an added cost
• No one technology really pervasive over all the mobile platforms
• Costly development and update cycles

What do they give us?

• Reduced data requirements
• Better integration of phone hardware - GPS, Camera
• Embedded interfaces
• UI ‘Bling’
• Monetisation of content/service

However, comparing mobile apps with it’s bigger brother, the desktop, we can do all this in a web browser today without the need to develop unique apps for different computers etc. Google already have there own suite of apps, Microsoft are moving the office suite into the browser. With the great leaps in browser technology (xHTML, CSS3, HTML5, jScript libraries) we’ve seen photo editing, multi-track audio recording, video editing and lots of previously installable applications all move to the browser without any OS dependency.  We are even going to see the OS move to the browser when Google Chrome OS is released.

And this is where mobile apps will end up - in the browser. 4g networks, wi-max and demise of data-charges will allow us to move back to HTML technology and allow publishers/developers to build once and deploy across all device and ultimately gain back control. That’s not to say that Bolser are going to stop developing mobile apps, but we won’t be taking our eye of the bigger picture either.

And yes, the web will win! In fact it already has.

Creatives are often asked to produce a number of versions for a client. If the only purpose of this is to provide you with a choice, I’d wonder whether your money was being well spent.It’s the takeaway menu version of the creative process. You’ll receive a choice of toppings for the same idea. And no matter which you choose, it’s still a cheese and tomato pizza underneath it all. The Creatives will be happy to tell you their personal preference. And they’ll probably give you a long and passionate explanation of why they think it’s the best on the menu.

But what if you’re not in the mood for pizza?

If the Creatives are asked to add value to your brief, instead of providing versions, they’ll think of different ways to satisfy your hunger. They’ll consider all the influences on the decision, including how much money you have to spend, how much time there is and how to get the most satisfaction for these. At the end of this process, there may be two very different yet equally appetising restaurant suggestions. They’ll present both ideas and talk you through how each experience differs. You can then choose the one with the menu that most tickles your tastebuds.

Ask the Creatives to give you versions and you’ll get a menu. Ask them to add value and you’ll receive the Michelin Guide. One can be picked up for free almost anywhere. The other is worth paying for.

Here’s an overview of what the developers at Ashley Bolser Agency are finding works well.

Web Frameworks

• The majority of web applications we build use the Ruby on Rails framework. This allows us to get projects up and running in a small space of time without reinventing the wheel each time.
• For smaller projects we use Sinatra, a small DSL for writing simple web applications. Sinatra is a lot leaner than Rails so is great for high traffic services like API’s.

Plugins and Gems

We use lots of open source rubygems and plugins to avoid reinventing the wheel on every project. A selection of our favourites are:

• Authlogic - a framework agnostic library for adding authentication into your application.
• Haml - A templating engine which focuses on improving the syntax of Markup. Haml uses indentation to determine when you want HTML tags to start/end. You therefore don’t actually need end tags, lowering the number of lines of code you need to use.
• Paperclip - easily add support for file uploads within your application
• Nokogiri is what we use for parsing any HTML or XML. when doing any API integration.
• Comma allows you to declare the structure of a CSV file on your model. You can then just call to_csv on a collection to have the data in CSV format.
• Friendly Id allows you to declare a search engine friendly slug for your ActiveRecord models. The slugs are versioned so that old ones redirect to new ones.
• Geokit is great for any location based sites. It allows you to Geocode your models and find them based on location.
• Simple Form - If you just want to quickly add a contact form to your site, this gem makes it a 5 minute job.

Javascript

We have experimented with a number of Javascript frameworks. Jquery seems to be our framework of choice now because of its number of useful plugins and nice syntax.

Testing

We practice test driven development which helps us to write better code, minimise bugs, and make changes without the fear of breaking everything. The libraries that we use are:

• Rspec is a behaviour driven development framework for allowing you to describe how things should work before you build them.
• Cucumber is an integration testing library that allows you to describe the overall behaviour of your application in plain text. You then write ruby code that interprets these steps in the background. Cucumber uses Webrat, a headless browser to crawl the application and make sure that what you want to happen does happen. Cucumber also hooks up with a number of other web browsers so it can even test that javascript/ajax works.
• Using fixtures in testing is fine for small projects but this can often get messy and difficult to manage as the application grows. To get around this, we use the Machinist gem which allows you to define blueprints for a model and create objects with the parameters that you want directly in your test case.
• Email Spec is a collection of Rspec and Cucumber matchers that make it easy to test that your application sends emails when it should.
• We use Shoulda Macros within Rspec which make it easy to test simple cases in 1 line of test code.

Version Control

• We use Git as our version control system of choice. The fact that Git makes branching so easy means we can have multiple versions of sites running at once without any issues. We all work on separate branches and merge changes into the master branch when necessary.
• We store all our repositories at Github
• Any small scripts, we store as a Gist

Deploying

• Capistrano is the tool that we use to deploy our websites and applications. Capistrano connects to your server via SSH, clones the project in a new folder and updates a symbolic link to make that new folder live.
• We use Webistrano which is basically a web interface for Capistrano. We set up all of our projects in Webistrano which allows us to deploy with a few clicks and see deployment history.

Text Editors

• The editor of choice for the developers seems to be TextMate. Textmate has a number of bundles that really help develpment. A few that we use are:
  • rspec-tmbundle - allows you to run a Rspec file or single test case from within Textmate rather than having to use the command line.
  • cucumber-tmbundle - Similar to the rspec bundle but for Cucumber
  • ack-tmbundle - Global search in a project but very fast
  • github-tmbundle - Great for quickly backing up a script as a Gist at Github
  • ruby-haml.tmbundle - Support for the haml
• We also use Vim for editing any configuration files etc on our remote servers.

Whilst at a training course in London there was a lot of discussion about deploying an Agile software development process within an agency. The consensus was that the main barrier to realising this heavenly nirvana was a client will have a requirement to meet a fixed deadline with a defined list of functionality (not very agile).

We all know that the majority of the time designs, functionality and objectives will inevitably change (and usually essential) throughout the course of a projects lifecycle. It dawned on me that our ability to adapt to these changes without continually impacting deadlines and budgets is all about being Agile, and that we have already adopted these principles to some extent.

Principles behind the Agile Manifesto

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So how do we achieve this?  Well, it’s all about making the right technology decisions; such as implementing collaborative working tools GitHub and Lighthouse, and using an agile development language & platform such as Ruby On Rails. These choices combine to provide the perfect platform for the digital team to be Agile in our development, meet the clients changing requirements whilst maintaining budgets and deadlines.