The League of Extraordinary Developers

C4DI and the magical coffee beans

Thu, 05 Sep 2013 14:22:58 GMT

C4DI and the magical coffee beans

If you are not already aware Hull is getting it's own Digital Innovation Centre and in true digital style there is currently a Beta in progress.

I signed up for C4DI Beta membership pretty early on and am already benefiting from the workspace and it's fantastic facilities.

So far, whilst working at C4DI Beta, I've mainly been concentrating on existing projects and working out plans for taking Incentive Maker forwards. I've especially enjoyed the ability to quickly bounce ideas off digital experts who have different backgrounds to myself, who may see things differently to me.

It's all been great, but today I had a different kind of C4DI experience and for me it shows the real strength of C4DI and bringing the digital community closer together, rather than working in silos. I was having a none work related chat with John Connolly, one of the co-founders of C4DI, during a coffee break, and there was a throw away "there's money to be made there" comment that we both picked up on. We ran with it a little bit, and within a few minutes we fleshed out a product idea, possible means of monetisation, ideas for funding prototype development and an ideal skeleton team.

As I went back to my desk to carry on working it really hit me that this was the reason to be involved in C4DI. Those random break time chats that could lead to all sorts of ideas, those unexpected moments that just might take something to the next step.

Who knows if this particular idea will work out or not, but the fact that the chat just happened and there is potential for a small idea like this to even get off the ground is just great. C4DI, and more importantly the C4DI members, are going to help turn those "I wonder if" moments to "let's build it and see what happens next" moments.

Designers - how far should their coding knowledge go?

Thu, 30 May 2013 02:50:48 GMT

Designers - how far should their coding knowledge go?

An admission

Ok, I'm going to get this out of the way now. The title of this blog post is deliberately trying to get your attention. So why am I doing this?

Yesterday evening I put out a short tweet saying I was looking to speak to a designer, who had experience of designing and creating HTML games. I also put out a second tweet asking to speak to a designer who had good JavaScript skills. As yet, I've had no replies at all. Now I'm not assuming this means Designers don't code, in fact I know a few who do and do it very well, the request was probably just not that appropriate to my followers.

What do I want?

Hopefully you're still reading. I'm looking to speak to a designer who can code. I'm not talking heavy Rails development or anything, although bonus if so. Basically I have a project I'm working on that I could do with sharing the work load on. The trouble is I'm the bottleneck in development at the moment and I hate that, so if I could find a really good creative who can help remove that bottleneck then I'd be really, really happy.

The project isn't your usual web development, in fact I can guarantee it's probably something very different from what you are used to, and it will definitely challenge you. As the earlier tweets will have explained the work involves designing and developing games.

If you are remotely interested in what I've said so far, then please get in contact and I'll give you the full details.

Recruiters

Please note, this isn't a job, I'm just looking to work with someone on a project, so please don't spam me.

Twitter Bootstrap - It's not all roses

Fri, 22 Jun 2012 09:07:41 GMT

Twitter Bootstrap - It's not all roses

I just dropped into the middle of a conversation on Twitter, mainly because of this statement "Twitter Bootstrap has proved its worth though. It is to HTML & CSS what jQuery is to JavaScript. It's about standardisation."

My reply was this: "I hope not. Twitter Bootstrap is awful. It's got loads of bad practice in it."

This got me thinking, what is it that I really dislike about Twitter Bootstrap? In the end I decided to write this blog post about my gripes with the framework.

There are two big issues I have with Boostrap.

It forces you to use non-semantic markup
It doesn't reinforce the idea of progressive enhancement.

To be fair, I've only used it once and it was a while ago, so things may have improved, but I doubt it. I decided that I'd like to use it for an existing product I have.

In the first draft of the product I'd spent time crafting the markup, and I was very happy with it. Semantically it was spot on, in my opinion anway. You know the way we are meant to do things, crafted.

I then came to looking at Twitter Bootstrap for 2 reasons.

It would look a lot better than my existing product design / layout
It had responsive built in. (Lazyness on my part)

So I quickly sat down and started to re-engineer my markup. Of course I expected to have to change things, but with each thing I changed I was battling with myself over the markup I was having to produce.I suddenly started to feel like the markup I was producing was sub-standard. The care and attention, the semantics was going out of the window, and fast. Ok, so who cares about semantics, I mean really which of my clients is going to read the HTML and say, "Woah! That's not semantic! I'm not going to pay this bill". The thing is, as a developer, I care. I always think, would I be happy if someone produced this markup for me? If the answer is no, then it's not good enough.

I'll show a few examples of what I mean shortly. Before I get to that I want to really hammer home some of my big gripes. Don't worry I'm not going to go into everything here.

Layout information in markup

My thoughts on CSS frameworks and those that force layout information into classes have been discussed in the past. Needless to say, I'm far from keen.

The idea of putting 'row', 'span4', 'pull-left' etc into my markup irks me at great deal, let alone the unnecessary tags that are often required to do things like group content into rows. '<div class="row">'

Twitter bootstrap does this heavily, so that's a big negative for me already.

Icons

Bootstrap has some useful icons built in as part of the framework, but upon deeper inspection there is something very wrong with it's icon markup. For those of you that don't know it uses the tag. Let's just remind ourselves what the tag is for http://www.w3schools.com/html5/tag_i.asp.

The tag defines a part of text in an alternate voice or mood. The tag is typically displayed in italic type. The tag can be used to indicate a technical term, a phrase from another language, a thought, or a ship name, etc.

So why use it from icon placement? My guess is that the devs wanted to pick a tag that wasn't used widely and after all 'i' could be thought of as short for 'icon'. Basically it's wrong, wrong, wrong.

The irony is that the use of is discussed on the Base CSS page. while is mostly for voice, technical terms, etc. Clearly the devs can't follow their own advice.

A few real life examples

So as I said, I've tinkered with Twitter Bootstrap for a product. I'm just going to pick a couple of examples here of before and after. You can make up your own mind which is better markup.

Navigation and Header section


<header>
  <div class="inner-wrapper">
    <a href="/"><%= company_logo %></a>
         
    <nav>
      <ul>
        <li><a href="/">Home</a></li>
        <li><%= link_to "My Account", edit_account_path %></li>
        <li><%= link_to "Companies", companies_path %></li>
        <li><%= link_to "Teams", teams_path %></li>
        <li><%= link_to "Users", users_path %></li>
        <li><%= link_to "My Games", games_path %></li>
        <li><%= link_to "Log Out", destroy_user_session_path %></li>
      </ul>
    </nav>
  </div>
</header>


<header class="navbar navbar-fixed-top">
  <div class="navbar-inner">
    <div class="container">

      <!-- .btn-navbar is used as the toggle for collapsed navbar content -->
      <a class="btn btn-navbar" data-toggle="collapse" data-target=".nav-collapse">
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
      </a>
      <a href="/" class="brand"><%= company_logo %></a>
         
      <nav class="pull-right nav-collapse">
        <ul class="nav">
          <li><a href="/">Home</a></li>
          <li><%= link_to "My Account", edit_account_path %></li>
          <li><%= link_to "Companies", companies_path %></li>
          <li><%= link_to "Teams", teams_path %></li>
          <li><%= link_to "Users", users_path %></li>
          <li><%= link_to "My Games", games_path %></li>
          <li><%= link_to '<span class="label important">Log Out</span>'.html_safe, 
              destroy_user_session_path %></li>
        </ul>
      </nav>
    </div>
  </div>
</header>

Granted in the 'after' example there is the added collapsable navbar so there is some extra markup there, but to be honest that shouldn't even be in there anyway. The collapsable navbar is driven by JS and as such that additional markup that it needs should be written by the JS, and not polluting the markup.

Message alerts / notices


<% if flash[:notice] and flash[:notice] != "nil" %>
  <div class="notice"><%= flash[:notice] %></div>
<% end %>
<% if flash[:alert] %>
  <div class="alert"><%= flash[:alert] %></div>
<% end %>

	
<% if flash[:notice] and flash[:notice] != "nil" %>
  <div class="alert alert-success">
    <a class="close" data-dismiss="alert">×</a>    
    <%= flash[:notice] %>
  </div>
<% end %>
<% if flash[:alert] %>
  <div class="alert alert-error">
    <a class="close" data-dismiss="alert">×</a>    
    <%= flash[:alert] %>
  </div>
<% end %>

So to have a close message button in Twitter Bootstrap you have to add in a meaningliness <a> tag. I mean from an accessiblity point of view, what does 'x' mean? Surely it would make more sense to have some meaningful text like 'Close' in the <a> tag? Seeing as the close action is reliant on JS it would make even more sense to use Progressive Enhancement and get the JS to produce the close tag.

Conclusion

This is in no way a comprehensive list of issues with Twitter Bootstrap. I've definitely picked the easy targets here, but that is mainly because my experience is limited. I've seen other developers talk about issues with badly written JavaScript, and poor usage of Less. We use SASS here, so I didn't even bother to investigate that.

What worries me is that I've barely scratched the surface with Bootstrap, what other horrors can be found deeper? A lot of people seem to regard this framework as best practice, where as in reality it doesn't contain much best practice at all. The only reason the framework is so popular and gets so much coverage is that it's from Twitter. With the recent announcements from Twitter regarding client-side MVC rendering not being as fast as server side rendering, which most devs have known for a long time, it's pretty clear Twitter is quite a way off when it comes to best practices on the front-end side of things.

Don't get me wrong I can see why people love Twitter Bootstrap. It certainly makes it quick and simple to produce a decent looking page layout, but at what cost? It's certainly not a sacrifice I wish to be made here.

Keep your requests thin

Fri, 06 Jan 2012 05:14:25 GMT

Keep your requests thin

When creating websites or web apps we give due care and attention to making sure pages load fast enough. We minimise our CSS, JS and compress images as much as reasonable to make sure page load times are kept to a minimum. How often though do we think about the impact of what's going on during a server response? Sometimes it can be a simple contact form submission which sends an email, sometimes it can be way more complex making large DB updates, image processing and calls to external APIs. These tasks need to be done, but do they need to be done there and then, or can they be off-loaded?

Image Processing Example

If we look at the simple example of a user uploading an profile image for some new fancy social site. The image probably needs to be processed into different sizes for later use. The thing to consider is if it's actually important that the processing happens right at that very second, during the postback process, or if it can be done via a background task. Does the user really need to wait while the postback completes processing the image into 4 or more different sizes? In reality they don't and so a task like this should be done in the background. Sure the postback needs to handle the file upload and the user has to expect to wait for that, but nothing more than this.

Bulk emails Example

In Incentive Maker, when a user creates a new game for their team the code sends out individual emails to each game player, to inform them of the new game. Depending on the size of the team playing the game this can be a large number of emails. It's important that this part of the game creation process doesn't slow anything up, so the email sending is done as a background task. This speeds up the process dramatically as the postback isn't waiting for a successfully sent message for each email. If an email fails to be sent the background task will attempt to send the email again.

External APIs

As more and more of the things we build are reliant on external API's we really do need to give more thought to off-loading the work done by a request to a background job. Sure there will be times where this can't be done as it's an important part of the process, but something like posting a message on a users Facebook page, or sending out a Tweet etc then it can be done separately.

A benefit of off-loading is that the user doesn't receive an "something went" wrong error message. So for example if Twitter is having a few issues, there is often no benefit to stopping the user on our site in their tracks and saying, "hey, Twitter is broken, please try again later". Move the Twitter api work into the background and let the user move on, oblivious to what's going on with the Twitter API. The background job can attempt to hit the Twitter API later if necessary.

Background job does not mean delaying things

Just because a task gets moved to the background, it doesn't necessarily get done later, it can be done asynchronously once registered. It just means those longer tasks are not holding up our users as they use our website or web app.

What should be done as a Background job

That's completely up to the developer. Sure, some stuff just has to be done as part of the request, but there is always parts that can be done separately. So basically, if the next part of the app is reliant on the tasks within the current request, then leave it there, if not, consider moving it into a Background job, and let the user have a better experience.

Storing a Product Catalog for eCommerce with a Document Database

Mon, 21 Nov 2011 03:00:40 GMT

Storing a Product Catalog for eCommerce with a Document Database

We have recently started developing our own eCommerce system that we hope to role out over a number of up coming projects. In the past we have always used things like Spree and Magento, but we have always had niggling issues with other systems, such as very complex DB structures.

Our overriding goal is to create a flexible system, that we can extend as we need for different projects. This blog post aims to cover our initial thoughts on how we are handling the modelling of the product data.

The first hurdle has been in deciding how to store the potentially very different types of product data. Clearly there are some common fields like name, sku, price but once you get further down modelling the details of different items, the data structure can look very different.

Modelling options with a RDBMS

In a RDBMS setup we really have the following modelling options for Products.

Entity Attribute Value (EAV)
Single Table Inheritence
Class Table Inheritance
Generic Columns
Serializing data into a blob

EAV

EAV is the technique used by solutions such as Magento. It offers a huge amount of flexibility, however if you've every looked at the DB structure of a EAV solution you'll know it soon gets very complex. On top of the complex schema, any queries to get data to the front end are also very complex, not to mention the issue of lack of database integrity.

Single Table Inheritance

Single Table Inheritance is pretty much a no-no in anyone's book. Once you start to have any more than a couple of types of products you end up with a pretty wide table full of NULL fields. Once again database integrity goes out of the window.

Class Table Inheritance

Table Inheritance is where you have your common data in a 'Product' table and then any variations are stored in separate tables such as 'FilmDVD' and 'MusicCD' tables. It would work pretty well for this, except for certain things like search queries. Sure querying on commons product fields is easy, and searching for results on a specific product type field is easy (e.g. search for all books by an author), however searching across different product types on a specific field is more hassle.

Generic Fields

Using generic fields is really not a neat solution at all. It means throwing data type enforcement out of the window, which is not something we're keen on. You can't apply indexes either, which will become an issue later.

Serializing data into a blog

The final option is to serialize all the non-common fields into a blob field. This option is pretty much pointless. It's basically trying to force the RDBMS into being a Document Database, except you get none of the benefits of using a Document Database. For example searching the data directly in the database and indexing just are not possible.

Modelling with a Document Database

Having already worked with MongoDB in the past for Incentive Maker, we knew it could give us the flexibility required for modelling product data. For example, in Incentive Maker all the generated games are all stored as different types of Game objects, which makes it easy for us to write code to search for specific details about the games, even though they don't all share the same data structure. We'll explain this a bit more below. The same principles of differing games can be applied to differing products. As stated earlier we know we have some common fields, but after that products can have all sorts of varying fields. MongoDB handles this flexible schema well though.

Before fully deciding on the MongoDB path, we did a little bit of a search and found this excellent presentation on using MongoDB for ecommerce. We'd definitely recommend you add this to your current reading list.

N.B. To help us model our data in Ruby on Rails we are using MongoMapper.

To model the common Product fields we have a class


class LedCommerce::Product
  include MongoMapper::Document

  key :sku, String, required: true, unique: true
  key :title, String, required: true

  key :description, String, required: true

  key :pricing, LedCommerce::Price, required: true

end

Each product type that we need inherits from the base Product object e.g. for film DVDs we'd have


class FilmDVD &lt; LedCommerce::Product

  key :directors, Array, required: true
  key :writers, Array, required: true
  key :actors, Array, required: true
  key :studio, String, required: true

  ...
end

and for music CDs we'd have


class MusicCD &lt; LedCommerce::Product
  key :band, String, required: true
  key :label, String, required: true

  ...

end

Although we have two different documents here, they are both stored as Product documents in our database


{
  [
    {
      _type: "FilmDVD",
      sku: "Film101",
      title: "Our Film DVD",
      description: "This is our stored film DVD",
      pricing: "1.99",
      directors: ["A Person", "A Nother"],
      writers: ["A Person", "A Nother"],
      actors: ["A Person", "A Nother"],
      studio: "TheLED",
      rating: 5
    },
    {
      _type: "MusicCD",
      sku: "Music101",
      title: "Our Music CD",
      description: "This is our stored music CD",
      pricing: "0.99",
      band: "The band",
      label: "The band's label"
    }
  ]
}

So basically whenever we have to work with a new product type, we just need the object to inherit from our Product object. This modelling really starts to show it's strength when we start to query the database. Note the complete lack of crazy joins etc when doing these queries that you'd get when modelling data with a RDBMS.

These examples are once again using MongoMapper.

Find all products


LedCommerce::Product.all

Find all music CD's


MusicCD.all

Find a single product by sku

This query applies to any of the base Product object properties. There are a couple of ways we can look for a product with a specific sku. Firstly we can search for a specific product type, like a MusicCD.


MusicCD.find_by_sku('Music101')

Or we can search more generically


LedCommerce::Product.find_by_sku('Music101')

In either case we will get the same object back.

Search a product for a specific key/value

We can also do queries like search for products from specific labels. Again notice how we can search on any field even from the base Product document.


LedCommerce::Product.find(:all, label: "The band's label")

Conclusion

As you can see from the above, Document Databases, such as MongoDB, are especially good at handling these kind of flexible database schema's very well.

As we get further down the line of building our new ecommerce software, we'll blog more on how we've used MongoDB. We've still got a lot of decisions to make, such as how to handle transactions effectively.

At the moment our code isn't open source. We may well change that as we get more of the project done, once we are happy with the core elements of our code.

Success for Incentive Maker - Hull Digital Post

Fri, 08 Jul 2011 02:17:07 GMT

Success for Incentive Maker - Hull Digital Post

We were very kindly invited by Jon Moss to do a guest post for the Hull Digital website to talk about Incentive Maker. We jumped at the opportunity and decided to talk about our experience of using "The cloud" to build a cost effective, scalable product.

If you are interested in reading about the development story of Incentive Maker so far, please view the post - http://hulldigital.co.uk/success-for-incentive-maker

SASS, Compass and some clarity

Thu, 16 Jun 2011 03:52:36 GMT

SASS, Compass and some clarity

Having recently read HOW TO: Get Started With the COMPASS CSS Framework, I realised there is still a lot of confusion about SASS and Compass and why developers should be using them. The Mashable article is very brief and the comments below it highlight show some of the confusion surrounding the tools.

My issue with the article is that it really talks about SASS and not Compass, it doesn't even show one example of the CSS3 features and it doesn't explain the separation between the two and the benefits of using them.

Hopefully in this post I want to try and clear up what SASS is, what Compass is, and why, as a developer, you should let them into your life. This post won't go into detail about each tool, but will hopefully just give you enough of a push to investigate further. The post will also try and deal with some of the common misconceptions I've heard and read from other developers.

What is SASS

SASS is simply an extension to existing CSS features. Some of the main features include:

Variables
Mixins
Nesting
Selector Inheritance

Some of features are so useful that they are being proposed to the CSS Working Group - CSSOM, Vars, Mixins, Nesting, and Modules.

Other useful features include:

Control Directives (if, for, each, while)
Colour operators
Colour functions (incredibly useful for tweaking your colour palette)

Some developers originally ignored SASS because it used a different syntax to CSS, but a while ago this all changed with the release of the SCSS format. SCSS uses the exact same formatting as standard CSS, so if you can write CSS, you can write SCSS.

SASS isn't the only tool that extends the capability of CSS, however once you add in the power of Compass it should be clear why developers should be choosing SASS above the other tools.

What is Compass

Compass is an open source CSS authoring framework that makes a developer's life much easier.

If you want a simpler way to maintain your grid layouts, an easier way to remember all the variations in CSS3 syntax, and a way to reuse lots of standard CSS patterns quickly, then Compass is for you.

Compass is built on top of SASS, so you get all the benefits of SASS as well.

At it's most simplistic level, Compass provides a huge amount of mixins that developers can use of to reduce the maintenance of their CSS.

Some of the main features of Compass include:

Cross browser CSS3 mixins (stop trying to remember all those CSS3 browser variations)
Common typography patterns
Common styling patterns
Built in spriting capabilities
Blueprint module

Compass also has a number of plugins that can be added to the core features to give you even more to simplify your CSS. Some of the plugins are listed here, however doing a quick search on github will reveal quite a few more.

Misconceptions

"But I don't want to use Rails"

This is a pretty common argument for not using SASS or Compass. Yes, SASS and Compass rely on Ruby, but you don't have to be using Ruby on Rails to use them. They are completely stand-alone tools and I've even used them when developing simple static pages. The only thing you do need is Ruby, as they are Ruby gems. The download page of the SASS site explains how to do that.

"But I don't want to install Ruby on my server"

Don't then. Yes, you do need Ruby on your development machine, but that's as far as you need to go. SASS compiles down to bog standard CSS so all you actually need to put onto your server is the generated CSS files.

"I don't like SASS, I prefer LESS"

In the Mashable article, one of the comments compares LESS and Compass. They are two completely different things. Sure compare LESS and SASS, but LESS and Compass are not comparable.

"But I can write proper CSS from scratch, I don't need something to do that for me"

As web developers we can all do that, but the point is that SASS and Compass offer us a way of writing more manageable code. I can guarantee you that when using these tools, you will be writing less code, changes will be quicker and easier, and therefore cheaper.

Additional reading

This blog post deliberately doesn't show many code examples, as there is just too much to cover. If you want to see some more specific examples, here are some useful references.

Finishing up

So in short, SASS and Compass are here to make CSS creation and maintenance simpler and quicker, leaving you with time to do other things to make your sites even better.

This post doesn't even scratch the surface of the capabilities of SASS and Compass, but hopefully it explains what they are and gives you a hint as to why you be using them as part of your development stack.

The big question is do you want to be maintaining code that looks like this?


.box-shadow-example div {
  width: 40px;
  height: 40px;
  background: #eeeeee;
  margin: 20px;
  float: left;
}
 
#box-shadow-default {
  -moz-box-shadow: 0px 0px 5px #333333;
  -webkit-box-shadow: 0px 0px 5px #333333;
  -o-box-shadow: 0px 0px 5px #333333;
  box-shadow: 0px 0px 5px #333333;
}
 
#box-shadow-custom {
  -moz-box-shadow: red 2px 2px 10px;
  -webkit-box-shadow: red 2px 2px 10px;
  -o-box-shadow: red 2px 2px 10px;
  box-shadow: red 2px 2px 10px;
}
 
#box-shadow-custom-multiple {
  -moz-box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
  -webkit-box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
  -o-box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
  box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
}

Or like this?


@import "compass/css3";
 
.box-shadow-example div {
  width: 40px;
  height: 40px;
  background: #eeeeee;
  margin: 20px;
  float: left; }
 
// Default single box shadow
#box-shadow-default {
  @include single-box-shadow; }
 
// Box shadow with custom settings
#box-shadow-custom {
  @include box-shadow(red 2px 2px 10px); }
 
#box-shadow-custom-multiple {
  @include box-shadow(rgba(blue, 0.4) 0 0 25px, rgba(green, 0.2) 0 0 3px 1px inset); }

The League of Extraordinary Developers : Year One

Fri, 01 Apr 2011 05:28:10 GMT

The League of Extraordinary Developers : Year One

A year ago today, The League of Extraordinary Developers officially opened it's doors. I thought I'd take this opportunity to write a personal blog post to talk about how things have gone in year one, and to thank a few people for helping year one to be a success.

I guess that last statement gives the game away a bit, but yes, I do count year one as a success. Don't get me wrong, it's not been perfect, there's still a very long way to go, but in general I'm happy with how things are going.

The Beginning: The Whys and Hows

Previous to setting up The League, I had worked for several marketing agencies around the country. Some big and some small. I've always enjoyed the marketing side of things, and taking the time to understand "the bigger picture" (urgh) when it comes to the work I've been involved in. I don't think sitting in the corner of an IT department tapping away on my keyboard has ever been for me. I think if I did that, I would definitely suffer from that "Sunday night feeling" that people seem to talk about. By the way if you do suffer from that "Sunday night feeling" you're in the wrong job. You spend a high percentage of your life working, you may as well do something you enjoy.

So I guess you're wondering why I set The League up if I've always enjoyed my past jobs so much, and that's a fair point. Well the reason is simple - control, and no I'm not a control freak, I just wanted to take control of my life and my career more. I have a young family, and I wanted work to fit around my family, not the other way around. On top of this, the area of the UK that I live in doesn't exactly thrive with opportunities for Senior Web Developers, so I decided to create my own opportunity.

There was one other major driving force for me. It's something that has bugged me for a long time. As a developer I've spent hours upon hours writing code for other people and producing websites / applications for them. What have I got at the end of each project? A nice thank you and a monthly wage. Now that's not a bad thing, but as developers we really are missing out. We are the ones with the tools in our hands and heads to create things for ourselves and yet so often we choose not too. We don't take the opportunity that is right there in front of us. Sure this isn't for everyone, but for me personally it was really starting to bug me. Don't get me wrong, there are aspects to the service industry that I like, however I hate being solely reliant on client work. Being solely reliant on traditional client work is not a good thing. Clients come and go, we need other streams of income.

I've heard plenty of people always say "There's a book inside everyone", well I'm a firm believer that there is a product idea inside every developer. Even if your idea isn't that great do it anyway, and force yourself to learn something new to create the idea with. Stop relying on the safety nets all the time.

That's my little rant about developers and their use of their skills overs. I promise to not mention it again, well, not in this blog post anyway.

So that's the "whys" over with, here come the "hows".

No I don't have a secret formula, there are books you can buy for that. Each day I'm learning new things about running a business, building a client base etc etc. I'm just going to mention how I got things going. The answer is simple really, slowly. There was no rush. The important thing was to do things right, and rushing things would make that a lot harder.

Year one objectives

I remember attending the first ever Hull Digital Live in 2009, and whilst the event as a whole was really good, there were a couple of talks that really stood out for me. One was about working Noded, by Jaan Orvet, and the other talk was entitled "Time to Start Up" by Mike Butcher. In his talk Mike said something that has stuck with me. "Consult, consult, product". By the end of HDLive09 I knew I wanted to run a Noded web development business, and as part of that business I wanted to build products.

To build products The League needed capital, this meant that the objectives for year one were simple. To build a solid client base that could provide regular work. Fortunately having worked with a few marketing agencies in my time, and built up a good list of contacts I was able to put the idea of The League to my contacts. Most liked the idea and The League has been able to win a varied range of projects. Unfortunately there are many we are not allowed to talk about, due to NDA's!

Some highs

Working with Nodes has been a fantastic experience. I've had the opportunity to work with some really talented developers and it's been great building up a reliable network of developers that I can rely on to get work done, and done well.

What I'm most proud of, is that for several clients The League has become the first port of call for when they need extra resource. We've even had several referrals, which is always nice.

At the beginning of this year, we received a very nice email from a client, with this glowing report in.

The League has certainly provided a very valuable and reliable service over the last year so I am certain we'll be working with you guys whenever we have the chance. I've outsourced to lots of places with mixed success but the level of professional consistency you guys have provided is a credit to your team.

Some lows

The worst part of running your own business is all the admin side of things. Each bit of admin eats into time that could be spent being productive. This is the one area of the business that I would love to improve upon, as I feel too much time is wasted. However, I doubt there is a lot that can be done about it, so it's just something we'll have to put up with.

Some thank yous

I'd like to take this opporunity to thank two groups of people.

Firstly, the clients that have used The League in our first year, without you we'd not have been able to pay the bills.

Secondly, the Nodes that have worked for The League and helped to grow the reputation of the business. So here is a big thanks to Adam, Andrew, Ashley, Darren and Hamilton and I look forwards to working with you guys even more in the second year of The League.

Plans for year two

The big push for this year, is to get several products developed and launched.

Slightly ahead of schedule The League launched its first product at the beginning of this year, called Incentive Maker. Incentive Maker is a online game based employee incentive application that we hope to get into sales teams and call centres. Of course it can be used by any company wanting to incentivise their work force. For this product we have partnered up with Wildfire Advertising.

The plan is for The League to increase it's product portfolio in year two, and we are already working in partnership with Experience Internet to build a recruitment system, that we hope will change peoples' opinions on how recruitment within the IT sector should be done. We hope to release more details about this product in the near future.

Final word

Year one has been really rewarding and setting up The League is the best thing I've done so far in my career. If you are thinking about setting up your own business this year, then I wish you all the best, and I hope it's as good for you as it has been for me.

A Client, a Sales Team, Incentives and the development of a Commercial Application

Tue, 01 Feb 2011 03:53:58 GMT

A Client, a Sales Team, Incentives and the development of a Commercial Application

It's been a while since our last blog post, so we figured it was time to let the world know what we've been up to and why.

Where it all began

About six months ago, Wildfire Advertising, spoke to us about one of their clients who wanted an online quiz game to help as part of a sales incentive. The initial idea was to create a quiz that the individual sales people could enter based on the number of products they had sold. The more they sold, the more time they got in the quiz.

Towards the end of our initial discussions with the Wildfire team, we realised that this quiz could not only used with this one particular client, but with several other Wildfire clients. In the past, Wildfire have run quite a few sales incentives for their clients, but the majority of these have always been one-off print based solutions.

With this in mind we started to think about how we could create a more flexible quiz system that could be easily re-skinned and changed appropriately for each individual client.

By the time we had our next meeting with the Wildfire team, we have a fairly good idea of how we were going to go about creating a solution. In this second meeting, we talked to Wildfire about their previous experience with sales incentives. The more we talked, the more both parties realised we could take this project a larger step forwards and we could build a incentive games system for use by pretty much anyone looking to make their incentive schemes more fun and interesting.

The Wildfire team mentioned figures to us like:

up to 48% increase in employee performance (Source: HR Management Magazine).
96% of employees think that 'incentive games are fun'.
only 45% of the employees who participate in an "ordinary" incentive programmes are happy with those.
tangible rewards (like cash, gift vouchers, holidays and additional days off work) increased performance by 26%, compared with just a 13% increase in performance for incentives that solely used non tangible rewards, like a points based system (The Incentive Research Foundation).

With data like this we knew that if we could create an online incentive application that there had to be a market for it.

After a short amount of investigation by ourselves and Wildfire, we realised there was a general lack of good, online based employee incentive applications out there. We had hit on a real world problem that needed a solution.

Early steps and investigations

Having agreed we were going to build an online employee incentive application for use by anyone needing to incentivise their sales teams, call centre staff, or any other groups of employees, we started to look at the technology side of the project. Two key words came to mind, flexible (to client requirements) and scalable (we didn't have a clue regarding the numbers of users of this system).

For the initial part of the development of the project, we concentrated hard on creating a solid core system. Our main aim was to create something that did a lot of the basics, like user management and permissions, team management, and basic game functionality, such as leaderboards and reward handling. Last, but certainly not least, the other area of development was the creation of a plugin architecture for all the different types of games that we were planning to build on an ongoing basis.

The majority of the functionality was developed and tested very quickly, but the game plugin system underwent a few rewrites to get it to a stage we were happy with. We now have a system where we can plugin games very quickly. We have initially concentrated on grid based games, with the plan to move into other types in the near future. Each of the grid based games is customisable with different numbers of squares and rewards. The games also have individually designed emails to give each game a unique feel.

The scalability of the project was actually fairly easy to handle. We decided upon using Heroku for the hosting of the application and MongoHQ for hosting the database. Heroku is a really good hosting solution for applications like this. It comes with a number of really useful tools, such as New Relic for profiling, Hoptoad for error collection, but most importantly it provides us with the ability to add more power at the flick of a switch. As the application grows and the number of users grows, using a mixture of profiling and adding more power, we will be able to keep the application stable.

Naming the product

Wildfire and ourselves didn't decide on a name for the product until about half way into the development stage. In the end the Wildfire team came up with Incentive Maker with a number of advertising concepts for it. We all instantly felt that Incentive Maker would be a strong brand name.

Next steps

We officially announced Incentive Maker a few weeks ago, with the idea of getting a few clients to do private Beta testing of the Incentive Maker. The initial feedback has been great. The majority of the feedback has been in regards to additional functionality. We've also had some great feedback in terms of how to improve the usability of specific areas such as game creation, and points awarding.

We've taken on board all the client feedback and spent time improving Incentive Maker. We feel the product is even stronger for this period of private Beta testing.

We are hoping to officially launch Incentive Maker in the next few weeks. We are in the process of putting together a website to replace the existing holding page, with far more information about Incentive Maker.

jQuery Mobile SASS Alpha 2 released

Fri, 12 Nov 2010 03:53:15 GMT

jQuery Mobile SASS Alpha 2 released

jQuery Mobile Alpha 2 has just been released and thanks to Eric Fields our SASS version of the CSS has been updated also. Eric has also taken our first initial release and improved upon it considerably, so huge thanks to him.

Each area of the SASS has now been separated out into separate partials. This makes it easier to style the individual components. For example if you want to style the dialog, you only have to work/think within the scope of the _dialog.scss.

If you want to contribute to the project please feel free to fork away and submit pull requests.

http://github.com/pollingj/jQuery-Mobile-SASS