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.

Myself and Rich made a trip down to London last week for the Open Mobile Summit. 2 days of keynotes and panel discussions covering all aspects of mobile technology, from carriers to handset manufacturers, and app developers to content providers.

We were there primarily as ambassadors for Nokia who had their own ‘Nokia Lounge’ area for us to showcase some of the apps we’ve been developing for their phones. We seemed to generate a lot of interest, particularly for our forthcoming app ‘PriceGenie’ - a barcode scanning, price comparison tool which has been developed specifically for the N900 using Nokia’s latest technology: ‘Nokia QT’.

When we weren’t demoing apps to people and comparing notes with other developers (and praying the WiFi connection held up) – we tried to get to as many of the presentations as possible – some highlights being a talk from Richard Windsor (Sr. Analyst, Nomura Securities) on open mobile ecosystems and another on mobile experience from Mark Rolston (CEO, frog design).

Nokia Lounge - Open Mobile Summit 2010, London

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.

A lot gets said about mobile Apps, most of the things you read are from uber hip creatives, Journalists, planners and media people and it’s all about the iPhone. Lots of companies are launching for this high end smartphone.

Not surprising because they all have them, but it’s a small segment of the market.

Here at Bolser headquarters we know that the iPhone is a very important “totemic” device but it’s not the most important Brand in the market, that honour goes to Nokia because more people in the UK and in the world have them!

There are some really important things to consider when planning an App rather than flying in and producing one…

Here’s my quick checklist for Mobile Applications:

• Do you have a serious need for the App, or is it a gimmick (This is ok just be honest with yourself)
• Can you build a business case that makes money from a mobile App? – Either from a paid app or from increases in sales?
• Will customers actually use the app rather than the mobile web? And does the app improve the general usage experience?
• Does the App encourage user interaction? 
• Is it a one off or ongoing usage?  Most Apps are downloaded and used just a few times!
• Does your target market have the latest Google Android or Apple iPhone? What phone should you develop for?

The other question to ask is who should develop the thing?

I’m biased because that answer should be Bolser, here’s why:

• We’ve done lots of them, over 150k downloads so far
• We understand both the business need and the consumer perspective
• We know what the phones can do!
• We know about getting consumers to interact with brands so it’s not dry brand exposure or ultra technical backend stuff

There are some really lovely Applications that will integrate with lots of aspects of the phone, Nokia’s gig finder is one of them, Why?

• It checks the music you have on the phone and the ones you play
• It knows your location from the GPS built in to the phone
• It references your local venues to see when gigs are happening and when the people you like are playing
• It finds available tickets from the largest ticket companies on the net, like Ticket Master and Seatwave.
• It allows you to interact with their systems to book

What a lovely App from Nokia Betalabs http://betalabs.nokia.com/apps/gig-finder

We’re producing some super technical Apps and looking for major brand partners so why not get in touch and see what we can do for you….

Ashley

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.

A couple of us went over to the Leeds GeekUp meet last night at Old Broadcasting House for a presentation on javascript accessibility by Dirk Ginader from Yahoo. Some interesting points raised, especially important to the future development of the web and how people interact with sites. The main focus was on making sites that can easily be read and understood by screen readers using new technology that will also be along in HTML 5. The underlying message though was that accessible javascript should always be used to enhance accessible HTML and properly formatted CSS.

These days there are loads of companies claiming to be experts at everything from direct mail to ecommerce. It’s a fact that marketing services are one of the most “over served” business areas in the whole economy. I think that’s because there are almost no barriers to entry in marketing and advertising .Too many companies running after limited client spend.  On the other hand most agencies will admit to a certain amount of frustration with clients not doing what they are advised to do.

So we decided that we would run our own ecommerce site to give us the practical knowledge of setting and up and running of a shop on the internet. This included all the things you might expect - digital elements like web site design and build, functionality, style copy etc. Also areas like secure transactions and accounting, notification of despatch, delivery etc. had to be thought of and solved.

Unlike most of our clients we also had to come up with a product and range, we had provided a simple web site for www.off-the-wall.tv and like the fact that they were a UK manufacturer with their own design.  So it was then that www.justtvstands.co.uk was born.

We buy product from them and some other select suppliers, load it up to the web and let the customers do the rest. We’ve had the opportunity to develop and learn in areas we don’t normally get involved with like credit card fraud. And to put it bluntly it’s been interesting, very interesting.

Top tips to prevent fraud

1. Look for stupid customer names especially ones without capitals and lazy ones like tuppie tuppie.
2. Look for emails that make sense with the name of the customer, some elements of the name are good
3. Look out for repeated mobile numbers on your customer information with different names and of course repeated delivery addresses.
4. Let bona fide customers call you on an area code number, we have one for Leeds because we are in Leeds
5. Hold dodgy looking orders and call the numbers provided, real customers don’t mind the call.
6. To date we’ve been very successful with Tens of thousands of pounds of sales being made to UK customers.
7. And we’re happy to keep developing tools like the customer feedback and review sections because they help confidence and sales.

Check out the site and let me know what you think?

I often get asked how to guarantee deliverability on the many email campaigns we work on. Unfortunately there are no guarantees to hit every inbox 100% of the time, but you can make sure that you give it the best chance. We have rigorous testing for all email campaigns and follow best practices in our own designs. Some examples of these are:

• Correct balance of text over imagery
• Call to action in the preview pane
• Rendering tests for online and offline email clients
• Testing against spam filters
• Live tests on our own email accounts and clients
• Subject line testing

But even then you can’t always guarantee it will reach the user. One example of this is an email newsletter I receive from www.returnpath.net, a company specialising in email monitoring and deliverability. Ironically, this email always goes into my junkbox time and time again.

I’ve never marked it as ‘not junk’ just to see if it ever lands in my inbox correctly without my intervention.