Preparation

Follow the instructions on setting up virtual hosts on OS X.

Your httpd-vhosts.conf should look something like this:

NameVirtualHost *:80

<VirtualHost *:80>
	DocumentRoot "/Users/markirby/Sites"
	ServerName localhost
</VirtualHost>

<Directory /Users/*/Sites/>
    Options Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

Make sure you have set ‘/private/etc/hosts’, ‘/private/etc/apache2/httpd.conf’ and restarted apache, as per the instructions.

Create a symlink to link the sites folder to dropbox

Enter the following to create a symlink which will enable you to edit files in either location and have the changes backed up as you work.

ln -s ~/Sites ~/Dropbox/Sites

Download the framework and locate the .a and header files

Download the distribution files for the framework (for OCMock it comes as a dmg) and locate the .a and header files.

Here’s mine on my desktop:

Copy these files into your source folder for your Xcode project

• Make a subfolder in the root of your project folder named ‘Libraries’ (or place it where you wish – I’ll refer to this as {LIBRARIES FOLDER})
• Make a subfolder in this with the name of your Framework, e.g. OCMock – I’ll call this {FRAMEWORK FOLDER}
• Copy the contents of your static framework in here, preserving the original folder structure

When you are done your structure should look something like this:

Create references to the files in Xcode 4

To set up references to these new files:

• Create a new folder in Frameworks called the same as {FRAMEWORK FOLDER}
• Drag all the files inside your actual {FRAMEWORK FOLDER} into this one
• Deselect “Copy items to your destination folder”
• Select the targets you need – in OCMock case it will be the Unit Tests, but generally it will be the main target

You should now see the framework listed.

My project folder now looks like this:

I’ll add any more headers from other Frameworks  in subgroups with the name of the framework.

Add your header search path to the target build settings

• Select the target you added the framework for, in my case, “FrameworkInstallTests”.
• Select the “Build Settings” tab
• Search for “header search paths”
• Locate “Header Search Paths” field
• Double click the field
• Check the “recursive” box
• Add this to the settings:
• $(PROJECT_DIR)/Libraries

Add linker flag

• Select the target you added the framework for, in my case, “FrameworkInstallTests”.
• Select the “Build Settings” tab
• Search for “linker flags”
• Locate “Other Linker Flags” field
• Double click the field
• Add this:
• -force_load $(PROJECT_DIR)/Libraries/{FRAMEWORK FOLDER}/{YOUR FRAMEWORK NAME}.a
• Which should be the full path to the .a file for the framework, e.g. “$(PROJECT_DIR)/Libraries/libOCMock.a”

Restart Xcode and you should be done!

Restart Xcode.

Leave any issues in the comments and I’ll see what I can do.

Are you designing an app which could be composed of native interface elements?

If you are designing an app for a phone, I would strongly consider using native UI components where possible.

• Native UI components provide a unified experience
• The user should already know how to use your app as it features recognisable interface elements
• Time spent redesigning existing components is time that could be spent better on the overall experience and areas that really are specific to your domain

METAR reader for iPhone was built as a packaged web app, and does not use standard UI elements.

It looks very nice, it could be for Android as much as iPhone, but could also easily be created using well styled native UI elements which would make it easier for users to know what to do and give the app a more familiar feel. What are those bottom 3 tabs for?

Some apps don’t really need to use native interface elements…

Apps with neutral designs

If you are designing a tablet app you may find yourself designing something which is neutral, more like a website, which doesn’t use native UI components. On tablet devices apps tend to follow less of a standard UI look, so there is less consistency anyway.

The FT web app looks the same on all devices, and doesn’t lend itself to using native UI elements.

This app can look like this on any device, it uses no common interface elements.

Recreating native interface elements with web technologies is a bad idea

Recreating standard UI components in web can lead to the ‘uncanny valley‘ effect, where the app looks native but doesn’t feel quite right, as this discussion describes.

At the moment you will never get a PhoneGap app with fake UI elements working as well as a native app with real UI components. There is an unobtainable final 5% of performance that can’t be gained.

A native app can work as well any on the device and feels solid and well produced.

Native interface elements differ between platforms

Each platform has a different standard look and feel.

Facebook on iPhone:

Facebook on Android:

Facebook on Windows Phone:

Each version of the app is consistent with the platform running it, and facebook lends itself to this. You certainly couldn’t put the iPhone design onto an Android device without it looking fake.

If you want to develop an app with a consistent UI on the platform running it (and in most cases you should), you need to redesign the app for every platform.

There will therefore be additional CSS work to do on every platform you want the app to run on, but with web you can share the core code. Even if you don’t redesign the app for other devices, browser differences mean you may have inconsistencies which will need to be tested for and worked out.

Neutral designs work well as packaged web apps

If your app doesn’t contain any native UI elements (like the FT app) it can easily be produced with web technologies without feeling fake.

The user has no expectations related to the UI elements you are using, so performance issues are reduced.

It will be easier to create custom UI elements with web technologies than using native tools to do so, so the project can be delivered quicker.

No redesign will be needed when putting the app on other devices, so minimal effort will be needed to target multiple platforms.

To conclude…

Don’t recreate native experiences with packaged web apps.

Use packaged web apps to create platform neutral experiences that can run across many platforms, none of which resemble the native experience on any single platform.

 Some rights reserved by Remy Sharp

For the first time in 5 years of conference going I had no complaints whatsoever. I am often irritated by excessive promotion of products by sponsors, talks which are really little more than product placement, poor quality speakers and a host of other minor niggles which reduce the quality of an otherwise great event. At Full Frontal, this year (I attended the first, which whilst still good, wasn’t quite up to this years standard), I had no such problems. Instead I enjoyed a stream of high quality professional speakers discussing a range of topics at various levels of complexity.

First up we had Jeremy Ashkenas, one time creator of Underscore, Backbone and now Coffeescript, give an overview of what Coffeescript is (write JavaScript in another language, which compiles to pure JavaScript). Like a few others I spoke to, I have some serious issues with using Coffeescript for projects where I’ll be handing to code over to others, but as Jeremy explained, it makes writing JavaScript simpler and more logical, which could be fun to try on a personal project.

One of the days highlights came next, Phil Hawksworth, who delivered one of the best talks I’ve seen in terms of pacing, humour and keeping a high level of engagement. Phil implored us to not use HTML5 as an excuse to return to the long loading screens and inaccessibility of Flash in its shitty heyday. Just because we can, shouldn’t mean me should, and I couldn’t agree more. There is a fashion appearing at the moment for huge single page sites with mock navigation, no urls and no non-javascript support, and like Phil, I hope these don’t become common place and we see a return to standards based websites which use not abuse the new techniques available to us.

Two talks about coding within the browser by Marijn Haverbeke and Rik Arends have made me decide to investigate the cloud 9 online IDE further. If any talk came close to product placement today it would be Rik’s, but rather than irritate me, he managed to tread the line between salesman and technical guy carefully enough to keep my interest.

I learned the most today from Yahoo’s Nicholas Zakas who nailed exactly how to structure a large-scale JavaScript application with his talk on Scalable JavaScript Application Architecture. I am already structuring code in a way that is close to how he described, but not quite close enough for my liking. It felt like he pushed me that last step to total clarity, and I’ll certainly be writing more about this in the coming months.

Prize for the most passionate hacker of the day goes to Glenn Jones, whose demos around Microformats and drag and drop showed what should already be mainstream. It was inspiring to see someone thinking outside of what is obviously possible and pushing the boundaries. Marcin Wichary, the creator of interactions on many of google’s doodles also showed us how to make the impossible achievable, simply by thinking about problems in different ways. Browser limitations mean his code may not be ‘perfect’ and totally clean, but he makes things that work, and they go on the Google homepage.

I’ve never been a big fan of the kind of sites Brendan Dawes and his team creates, but I’m glad they exist. He took us through the thought process that leads to the creation of these exploratory sites, and proved that what works for one person may not work for others. I prefer simple clear navigation, but I don’t tend to stay long on sites. There are multiple use cases, and Brendan showed us this.

A great day, thanks to all who helped make it happen!

#fullfrontalconf

Tesco Food App, Chrome Web Store

• Large shopping app
• All local
• JS, HTML, CSS

Backbone

• Models, collections, structure, underscore wrapped
• Combined with an MVC approach
• Didn’t take advantage of most, could be done differently

jQuery templates for templating

• HTML, so easy to follow
• Limited documentation and hard to debug
• No longer supported
• Used AJAX to load multiple templates in after launching the app, would not recommend – can be slow and needlessly complex

Selenium for automated browser testing

• reduce the amount of mundane user testing
• steep learning curve
• code needs to be as structured as main (almost)
• don’t change versions during a project

jQuery Mockjax for mocking data

• jQuery plugin, intercepting jQuery AJAX calls
• flexible – allows for most scenarios with a little work
• minimal contact with app – load it once and it takes over

Build script with Rake

• Concatenation with sprockets require
• jsLint4java for syntax checking – use strict to get team code consistency
• YUI Compressor for minification

Wish I’d used Google closure compiler

• Uses docs to check type, static etc
• Removes code you don’t use
• Can make mistakes/cause issues under documented circumstances

Indentation, brackets and spaces

We have selected the following standards, but what matters most is not which standard, but that you have a standard. We will use this convention on all new projects. On existing projects, stick with the previously established convention.

Use 4 spaces, soft tabs (so really uses spaces, not tabs when you press the tab key) unless the language requires otherwise. More over on coding horror…

Use brackets on the same line

function functionName() {
	if (shouldDoSomething) {
		doSomething();
	} else {
		doNotDoAnything();
	}
}

Add 1 space between brackets and braces

function functionName() {
	if (shouldDoSomething) {

Add 1 space between operators

var concatenatedString = string1 + string2 + ".";

Use meaningful names

Use meaningful names for variables, functions and classes, select names which describe exactly what the variable, function or class does

• No abbreviations except common ones to be listed here as found
• No single character variables except in loops
• No hungarian notation (including data types inside variable names)
• No acronyms use full names
• Classes are nouns, methods verbs

So this :

function name(b, c) {
    strName = b + " " + c;
}

becomes:

function setName(firstName, lastName) {
    name = firstName + " " + lastName;
}

Use consistent names

Define these patterns at the start of the project

• Is it a manager or a controller
• Is it fetch or get

Functions and classes

• Functions do only one thing, and the name of the function must clearly identify that thing
• Functions should have no side effects, so a function named checkPassword should not also initialise a session
• Functions ideally be no more than 4 lines, certainly no more than 8
• Functions can have no more than one level of indentation
• Functions must work at one level of abstraction, either calling other functions, or performing a single action low level code, such as manipulating a string
• Classes have a single area of responsibility and are as small as possible
• Don’t pass arguments to functions in a class except to alter and return them, or ask a question about them. Instead modify class instance variables
• Don’t pass true or false flags to arguments, instead call different functions
• Where you must pass an argument to a function pass only one or two arguments. Three suggests you need to create a new class

Structure of classes

Classes should be laid out thus:

1. public static constants
2. private static constants
3. private instance variables
4. overridden functions
5. public/private functions, ordered in layers as they are used so used functions are as close as possible to the function calling it (see levels in code example below)

These are controversial, but after trying them, we find code is more readable.

Before:

var splash = (function() {

    var
    _shouldAutomaticallyChange = true,
    _numberOfSlides = 0,

    _getPositionOfCurrentSlide = function() {
        var slidesArray = _getSlidesAsArray();
        var i = slidesArray.length - 1;
        for (i; i >= 0; i--) {
            if (jQuery(slidesArray[i]).hasClass("current")) {
                return i + 1;
            }
        }
        return false;
    },

    _getPositionOfNextSlide = function(currentSlide, numberOfSlides) {
        if (currentSlide === numberOfSlides) {
            return 1;
        } else {
            return currentSlide + 1;
        }
    },

    _getPositionOfPreviousSlide = function(currentSlide, numberOfSlides) {
        if (currentSlide === 1) {
            return numberOfSlides;
        } else {
            return currentSlide - 1;
        }
    },

    _changeSlide = function(from, to) {
        if (from !== to) {
            jQuery('#splash-tabs > li:nth-child('+from+')').removeClass('current');
            jQuery('#splash-tabs > li:nth-child('+to+')').addClass('current');
            jQuery('.splash'+from).fadeOut('slow').removeClass('current');
            jQuery('.splash'+to).fadeIn('slow').addClass('current');

        }
    },

    _getSlidesAsArray = function() {
        return jQuery("#splash-tabs > li");
    },

    _onClickNext = function() {
        var currentSlide = _getPositionOfCurrentSlide();
        _changeSlide(currentSlide, _getPositionOfNextSlide(currentSlide, _numberOfSlides));
    },

    _onClickPrevious = function() {
        var currentSlide = _getPositionOfCurrentSlide();
        _changeSlide(currentSlide, _getPositionOfPreviousSlide(currentSlide, _numberOfSlides));
    },

    _changeIfShouldChange = function() {
        if (_shouldAutomaticallyChange) {
            setTimeout(_change, 6000);
        }
    },

    _change = function() {
       if (_shouldAutomaticallyChange) {
          _onClickNext();
          _changeIfShouldChange();
       }
    };

    init = function() {

        _numberOfSlides = _getSlidesAsArray().length;

        jQuery("#splash .next").bind('click', function() {
            _shouldAutomaticallyChange = false;
            _onClickNext();
        });

        jQuery("#splash .previous").bind('click', function() {
            _shouldAutomaticallyChange = false;
            _onClickPrevious();
        });

        jQuery("#splash .next").bind('touchstart', function() {
            jQuery(this).addClass('active');
        });
        jQuery("#splash .next").bind('touchend', function() {
            jQuery(this).removeClass('active');
        });

        jQuery("#splash .previous").bind('touchstart', function() {
            jQuery(this).addClass('active');
        });
        jQuery("#splash .previous").bind('touchend', function() {
            jQuery(this).removeClass('active');
        });

        jQuery('#splash-tabs > li').bind('click', function() {
            _shouldAutomaticallyChange = false;
            var currentSlide = _getPositionOfCurrentSlide();
            var position = _numberOfSlides - jQuery(this).nextAll().length;
            _changeSlide(currentSlide, position);
        });

    };

   return {
      init: init
   }

}());

After:

var splash = (function() {

    var
    _NUMBER_OF_SLIDES,

    _shouldAutomaticallyChange = true,
    _postionOfCurrentSlide = 1,

    init = function(automate) {
        _NUMBER_OF_SLIDES = _countNumberOfTabs();

        jQuery("#splash .next").bind('click', _onClickNext);
        jQuery("#splash .previous").bind('click', _onClickPrevious);
        jQuery('#splash-tabs > li').bind('click', _onClickTab);

        jQuery("#splash .next").bind('touchstart', _onTouchStartButton);
        jQuery("#splash .next").bind('touchend', _onTouchEndButton);

        jQuery("#splash .previous").bind('touchstart', _onTouchStartButton);
        jQuery("#splash .previous").bind('touchend', _onTouchEndButton);

        if (automate) {
           _triggerDelayedCallToGoToNextSlideAutomatically();
        }
    },

    //Level 1

    _onClickNext = function() {
        _preventSlidesFromAutomaticallyChanging();
        _goToNextSlide();
    },
    _onClickPrevious = function() {
        _preventSlidesFromAutomaticallyChanging();
        _goToPreviousSlide();
    },
    _onClickTab = function() {
        var positionOfClickedTab = _numberOfSlides - jQuery(this).nextAll().length;
        _preventSlidesFromAutomaticallyChanging();
        _changeSlide(positionOfClickedTab);
    },

    _onTouchStartButton = function() {
        jQuery(this).addClass('active');
    },
    _onTouchEndButton = function() {
        jQuery(this).removeClass('active');
    },

    /**
       @return {number}
    */
    _countNumberOfTabs = function() {
        return jQuery("#splash-tabs > li").length;
    },
    _triggerDelayedCallToGoToNextSlideAutomatically = function() {
        if (_shouldAutomaticallyChange) {
            setTimeout(_goToNextSlideAutomatically, 6000);
        }
    },

    //Level 2
    _preventSlidesFromAutomaticallyChanging = function() {
        _shouldAutomaticallyChange = false;
    },
    _goToNextSlide = function() {
        _changeSlide(_getPositionOfNextSlide());
    },
    _goToPreviousSlide = function() {
        _changeSlide(_getPositionOfPreviousSlide());
    },
    _goToNextSlideAutomatically = function() {
        if (_shouldAutomaticallyChange) {
            _goToNextSlide();
            _triggerDelayedCallToGoToNextSlideAutomatically();
        }
    },

    //Level 3
    _getPositionOfNextSlide = function() {
        if (_postionOfCurrentSlide === _numberOfSlides) {
            return 1;
        } else {
            return _postionOfCurrentSlide + 1;
        }
    },
    _getPositionOfPreviousSlide = function() {
        if (_postionOfCurrentSlide === 1) {
            return _numberOfSlides;
        } else {
            return _postionOfCurrentSlide - 1;
        }
    },
    _changeSlide = function(postionToChangeTo) {
        if (_postionOfCurrentSlide !== postionToChangeTo) {
            jQuery('#splash-tabs > li:nth-child(' + _postionOfCurrentSlide + ')').removeClass('current');
            jQuery('#splash-tabs > li:nth-child(' + postionToChangeTo + ')').addClass('current');
            jQuery('.splash' + _postionOfCurrentSlide).fadeOut('slow').removeClass('current');
            jQuery('.splash' + postionToChangeTo).fadeIn('slow').addClass('current');
            _postionOfCurrentSlide = postionToChangeTo;
        }
    };

    return {
        init: init
    };

}());

Comments

• Comments should not be needed except to document var and argument types in Javascript
• Instead of comments use smaller, better named functions
• A doc system such as JavaDoc should not require you to duplicate any information, e.g. functions should only be named in the code, not repeated in doc notation
• Never commit commented out code

Testing

We write code with full unit testing and integration/automated user testing (using tools such as Selenium to mock user input)

Repository management

We use git

Code reviews

All code pushed to the main development branch is reviewed by another team member, checking all of the points listed here and making sure code is readable and makes sense

To give a few examples of assumed mobile contexts, and ways sites might work around them:

• I’m an airline, my user is on a mobile, they must be checking in, I’ll remove access to booking and focus on check in features
• I’m a shop, user on a mobile, they must be looking for a store, I’ll serve up the address and a map and remove access to the shop
• I’m a newspaper, user on a mobile, they must be on the move, only want to know the top 3 stories

Perhaps the user was not in those contexts, they were at home, booking a flight, online shopping or wanting to read the local news. On their mobile, in front of the tv or perhaps in bed. Research showing how large a percentage of people use the mobile web at home has been done, lets not ignore this key fact.

The number one crime in the name of mobile context

A number of sites have taken to serving up different mobile content, and allowing no access to the remaining content on the site. Some even redirect users to a mobile site from any link, rendering urls you may want to use inaccessible.

This leads to a broken web, on mobile.

The download speed argument

One main argument for reducing content on mobile is that the download speed is less, or bandwidth is more limited.

I often use my mobile at work and home to browse sites. I am sure I’m not the only one.

I also often use my desktop in hotels and with a dongle.

Mobile != low download speed

Other ways of guessing context

Recently I’ve heard suggestions of other, harder to measure ways of guessing context.

• Detecting location using GPS
• Detecting motion using GPS
• Detecting download/connection

These are harder to measure, and still don’t accurately confirm context. If it were possible to accurately know the context the user is in, we still have a problem.

Context != intent

I’m definitely moving, I’m definitely in a car. I’m going to look at your website.

This still doesn’t mean my intent is to find an address, or quickly use a news site and check the most popular stories. Context can’t predict the way a user is going to use the site.

Mind reading is no way to base fundamental content decisions

So what can you be sure of?

You can be sure the user has a smaller screen. Content may need rearranging, using techniques such as Responsive Web Design.

Content may need to be somewhat repurposed or refocused. This should relate to the priority you set things in on the desktop.

Low priority items may need to be removed. Examples include:

• Duplicate navigation
• Large adverts
• Superfluous imagery
• Large interactive features

You may wish to give higher priority to certain features research has shown people are more likely to need when on a small mobile device (your own research, into your users).

My guidelines to safely changing sites based on device:

• All urls should resolve and present the core content available on that page to any device
• That’s it really!

Something a little different today. I wanted to let you know about a new blog I’ve started, The Oscars Project, where I’m watching and reviewing all the best picture winners. For a while now I’ve decided I haven’t seen enough older films from the last 100 years, and so to give my plan to see more a direction, I decided to watch ever winner of the best picture oscar since 1928 when they began.

So far I’ve seen 4 films, but I’ll be adding a new one every few days as I work my way through them. Once I’m done I plan to move on to watch all the Palme d’Or winners, Golden Lion winners and possibly even the AFI top 250 films of all time. Anyway the blog is up and running at theoscarsproject.com so check it out if you fancy some recommendations of classics.

TinySrc is a service provided by Sencha which dynamically shrinks your images according to the device accessing them. This helps shrink images for mobile, and will cut down the size of a site with a responsive design.

This plugin replaces all image tag src’s within your content with the tinysrc src (http://mysite.com/myimage.png becomes http://i.tinysrc.mobi/http://mysite.com/myimage.png), and provides a function to call in your themes to optimise those images.

To use the plugin, run through the following:

1. Upload `auto-tinysrc.php` to the `/wp-content/plugins/` directory

2. Activate the plugin through the ‘Plugins’ menu in WordPress

3. Place

in your templates to display any template images optimised, e.g.

4. To get a variable containing the url of an image with the tinysrc url use

• I lead development for Ribot on the Tesco Grocery App for Nokia which allows customers to shop from their phones, released back in the summer.
• I had 2 articles published for .net magazine – a PhoneGap tutorial and an opinion piece on Responsive Web Design (expect to hear a lot more on that subject in the new year!).
• I gave a well subscribed talk on PhoneGap at a local JavaScript user group, asyncjs
• We grew the development team at Ribot, and were lucky enough to snag Jason Fry – an Android developer in high demand.
• I popped along to the fantastic mlove festival in Germany, something to look out for next year
• The rest of the time I worked on some secret projects, one of which will be released early next year

In summary a year of mobile web, including plenty of JavaScript, PhoneGap, responsive web design and testing.

Outside of work I moved into a nice little 1 bed apartment with my girlfriend, cat and 2 hamsters, watched some great films with @ribotminimus, invested in some of the worlds best kitchen equipment and subsequently did lots of cooking. In an attempt to keep RSI at bay, I did very little blogging and personal projects this year, but lots of exercise. RSI stayed away, so this year I might tempt fate a little…