Direct Marketing & Digital Marketing Agency - Ashley Bolser Agency

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.