[I first posted this on my personal blog as The Sencha Touch 2 Microloader & Sencha Command]

When examining how to build a new Sencha Touch 2 application for production, I wanted to make sure I wasn’t reinventing the wheel. I’d heard of Sencha’s commandline SDK tools but this gave me cause to look into it more. Now that I’ve done so, I’m impressed, but I think the documentation could be doing with a little more detail. I’m concentrating solely on deployment for now, though the tool supports other scenarios.

There were a few things we wanted to do:

• Build, concatenate and minimise our custom SASS theme
• Resolve dependencies (in order!) for our JS, then concatenate and minimise
• Work out how to incorporate those into our index.html with sensible versioning
• Ensure all our caching policies were optimal

With one exception, Sencha’s tool helps us with that. I recommend getting an overview of how to install the SDK Tools at the Sencha Documentation pages first. That guide also gives an overview of the various facilities the tool provides.

Setup

If you’ve used the sencha command to create a new application then you’re good to go – you have all the files you need to get building. If not, I recommend you use it to create a new, empty application, and copy over the bits you need to get up and running, and to make sure you’re adhering to the correct directory structure. The documentation does give a good overview of the directory structure which is required – take a look at the section “Understanding Your Application’s Structure”.

Once you’re there, you’ll have an app.json in the root of your project. It’s important that you complete this correctly in order to be able to build your project successfully; the “js” section needs to have any extra JavaScript dependencies – such as third-party libraries – entered.

You don’t need to add in all of the files you use in your application. The sencha command will resolve all of those dependencies automatically when you build. You do need to make sure you’re using requires in your application to make the dependency tree clear, but hopefully you’re doing that anyway.

Assuming you’ve got app.json ready to go, we can move on to making a build.

Index.html

Generally you’ll access your project via http://localhost/index.html, or something similar. The app.json file will have asked you to specify this URL, and you should have a template index.html created for you if you used the sencha command to generate your new project. Your index.html should have the following line:

This is a key part of the build process, so you need to leave it intact!

Building

The aspect we’re interested in is run via the command:

sencha app build

If you run it without the parameter you’ll see the following:

This gives you an idea of what’s going to happen. Here’s the way the build process works:

1. Copies required resources
2. Resolves dependencies by firing up a headless web browser and running your app
3. Concatenates and minifies your JS in the correct order
4. Builds a HTML5 cache manifest
5. Generates delta files to minimise what changes get sent to the client
6. Generates a new version of your index.html

There’s lots happening here, and it depends on what environment you specify when you run the command. To be clear, you can always keep using http://localhost/index.html, and that’s your development version.

Testing Environment

Testing creates a /build/testing/ directory, and you can access the build at http://localhost/build/testing/index.html. In the testing environment, JS gets concatenated but not minified. It doesn’t do any of the caching/manifest stuff described above, but does resolve all your dependencies into the concatenated file.

Production Environment

In addition to the steps taken to build for the testing environment, production will also minimise your JS, create a cache manifest, and as the documentation says: “Storing all JavaScript and CSS assets inside Local Storage on first load, and patches them via delta updates between releases”. The Sencha blog post goes into more detail on this subject.

Issues

We’re yet to deploy our application to production, so this post is a work in progress. In particular the testing and production builds highlight code issues that aren’t apparently on development – deprecation warnings become errors, and there are various issues with the order in which our code is included. I’m also a little concerned with the delta update mechanism – I need to do further testing to make sure updates are indeed pushed to clients as expected, as we always want to make sure that they have the very latest code.

You’ll also notice that the sencha command doesn’t do anything with SASS. Hopefully this will come in future, but it’s a simple extra command to generate the theme CSS.

Conclusion

The sencha command has become an integrated part of our build process. I’d like to see more documentation, and the proof will be in our final deployment, but it looks like Sencha have provided another key part of the end-to-end development of a mobile application.

[I first posted this on my personal blog as The Sencha Touch 2 Microloader & Sencha Command]

image by twicepix

Both apps and mobile websites have become increasingly important ways for companies – particularly retailers – to connect with people. However, while there have been good arguments put forward for the benefits of both sides – there has been little cold hard data to really compare how many people are engaging across each channel, nor has there been much analysis of user behaviour within them. So how do mobile apps compare to the mobile web?

New research published by Nielsen is hopefully the beginning of an increase in insight into both apps and the mobile web. The data focuses on the 2011 holiday season in the US and saw that, combined, both apps and mobile websites reached nearly 60% of smartphone users – around 58m people (judging by Edison’s most recent count of the number US people with these devices).

However, looking at apps and mobile websites separately, there is a considerable difference between the penetration of each. During December, mobile websites reached 51% of smartphone users (nearly 50m people) compared to apps which topped out at 28% (around 27m people). This shows mobile websites taking quite a big lead with US shoppers buying Christmas presents, reaching almost twice as many consumers.

Judging by mobile user behaviour in the US, there is clearly more value to be attributed to focusing on mobile web rather than developing an app. After all, a well-designed website that is compatible for web can potentially reach the entire connected smartphone audience, while certain apps are developed with certain devices – such as iPhone or Android – in mind.

For developers such as ourselves, there are a growing array of tools and frameworks helping us design websites for increasingly mobile-orientated web users. Bootstrap is an open source project engineered by Twitter which has evolved to accommodate major browsers across PC, tablets and smartphones. Additionally, Skeleton is a small collection of CSS & JS files that can help us rapidly develop sites that look beautiful at any size, be it a 17″ laptop screen or an iPhone.

For businesses who are looking at campaigns which have to include one or the other, the latest word from Nielsen looks to favour developing a decent mobile website instead of an app. However, further analysis into the data reveals some interesting behavioural trends which we shouldn’t ignore, including that US men are slightly more likely to try mobile apps than women – and those who do use mobile apps spend more time browsing than those using mobile websites. Surely, the battle is not over yet, and if it’s engagement with your brand you really want to push then perhaps a fully-fledged app is still the way to go. But for reach alone, a mobile website is likely to be seen by many more potential consumers.

We have just rolled out an update to Stubmatic. Although on the surface stubmatic looks the same we have made some major changes to the underlying logic in preparation for some future enhancements that we are working on.

For now one of the biggest changes you will notice is we have updated the way events are published. We have changed the terminology from “published” to “listed” and events can now be listed and delisted from your box office at any time. For example, previously when an event was cancelled or sold out it remained on your box office, you can now optionally de-list these.

In addition to this we have made several fixes and tweaks to the system, including:

1. Sold out events now correctly show as available if more tickets are added
2. Layout tweaks to assist navigation.
3. For new events created from today: Have made it clearer and simplified which email address PayPal payments are being sent to.

We are centralising product blogs back to our main blog so all updates to Stubmatic will be posted here from now on.

As mobile and smartphone camera technology continues to become more powerful, there has been increased speculation into the usefulness of camera phones for driving consumers of offline marketing towards digital content via scannable tags, codes and images.

Mobile tagging adoption

From crowd-sourcing reviews and comments of physical products via barcode scanning, to embedding URLs in QR codes, there is certainly a lot of scope for methods of delivering relevant information to mobile users more efficiently than depending on them to type in a web address or make a Google search.

Yet, despite success in Asia (particularly Japan, where QR codes were created by Denso) since 2003, adoption in the West has been relatively subdued. According to research conducted by Toluna Quick, just 19% of UK consumers have scanned in a QR code (11% have done so in the US, say Simpson Carpenter) and 31% know what they are (36% in the US).

Problems?

There are numerous possible reasons for the relatively lacklustre uptake of mobile tagging to date, such as:

• Lack of standard code. The numerous different types of 2D barcodes available may be confusing and/or off-putting to potential users. For instance, in the US Data Matrix codes are also popular while in the UK, QR codes dominate. Most mobile users need to download either paid or free apps before they can attempt to scan the tag they see (although some handsets, such as Android, come equipped with QR/image recognition tool Google Goggles). There have also been a number of other niche codes released, such as Microsoft Tags.
• Not quick enough. Despite the supposed simplicity and efficiency of using a camera phone to read a tag (QR stands for ‘Quick Response’), scanning can be tricky. If tags aren’t clear enough (particularly when there is little light) it can take a few attempts for scans to work – and certain phones are equipped with better cameras than others.
• Content not worth the effort. It might also be argued that content that is most often beyond the code or tag is rarely of any more interest to the consumer than what can be found at the website anyway. There have even been reported examples of tags leading to websites which aren’t optimised for mobile.

Already beyond codes?

Mobile tagging technology is undoubtedly moving quickly, and it may even be argued that we are moving into a post-QR era, even before they really took hold. Recently launched, Blippar is an app which uses the camera on smartphones or mobile devices to unlock digital content simply by recognising the imagery – be it an ad in a newspaper or even a product itself.

By eliminating the need for a code or tag at all, services such as Blippar (other Augmented Reality tools, such as the Layar browser, exist too) have overcome the hurdle of the lack of a standard barcode. And although it remains to be seen whether ‘blippable’ content imposes any restriction on what can be included in the image, it is likely that many designers will be keen to see an alternative to the ugly black and white pixel boxes of QR codes.

Real opportunity?

There is also increased versatility with non-code mobile tagging, giving advertisers and marketers the scope to develop impressive augmented reality animations and games as well as links to URLs and more compelling content such as discount vouchers.

With more opportunity for developing inventive examples of augmented reality, Blipper and others look likely to become quite significant, particularly for multichannel and mobile commerce campaigns by larger organisations and businesses which can afford to develop such ads. If this happens, then mobile tagging will certainly reach a larger audience, and QR codes may continue to have a place too – with their remaining sole USP as the mobile tag which anyone can generate.

One of the biggest stories in the world of the iPad last month centred on the success of the app released for The New Yorker.  By turning their back on interactive features and the ‘Bells & Whistles’ approach to digital versions of offline media, The New Yorker’s developers essentially put all of their efforts into making the app clean and readable.  Simple, huh?

Impressively so.  With over 100,000 readers (and 20,000 paying in excess of $50 for subscriptions) these numbers are dwarfing those being reported for others in the magazine app category and are signalling to developers that app consumers – for all our keenness to adopt emerging technologies and try new things – are still creatures of simple tastes.

So, is simplicity the key to a hit app?  And if so, why?

These are intriguing questions.  After all, in this era of ‘the long tail’ do we really care about hits anymore?  Surely, there are as many folk buying a variety of the numerous niche and complex magazine apps available as there are buying The New Yorker for iPad.  With no limitations of shelf-space in an increasingly niche-orientated world, developers, in theory, could invest the same amount of time and money into a variety of non-simple magazine apps to similar success as they might putting the same efforts into one very simple hit app.

I needed to do a little more research so I reached for my iPhone 4, clicked through to the App Store and went in search for the hit app of the moment.  Although I wasn’t expecting something overly complicated, I was perhaps expecting something kind of new – or at least something with more than one function.  But lo and behold, at the time of writing this, the top free app (and second to top paid-app) on the iPhone is none other than… Snake ‘97 – not only a very simple app (it doesn’t even have a menu screen), but a version of perhaps one of the simplest games that remains popular to this day (at least 30 year since its original release).

Unsurprisingly, the trend is similar across paid and free apps on different devices and I believe if we were to take all the applications produced to date and plotted them on a graph, the left side (head) of the curve would be home to more of the simpler apps, while the tail would be where we’d see the non-simple apps.

So, is the reason for this simply because the majority of app buyers are keen on simple things – in the same way that the straightforward pop of Justin Bieber appeals to more people than the latest prog-funk album by Destroyer?

Maybe.  Yet additionally, I think the fact that apps are still a new media to most people means that when we start searching around the market (where we are, of course, initially presented with ‘the hits’) we’re keen to test it out with things we can understand quickly.  What might be a surprise to developers, is that this young market may need to go through a period of hit making with ultra-simple apps – especially when looking at emerging app categories like magazines – before ‘the tail’ is long enough to really invest in ‘non-simple’ niche apps.

This is a quick post to all my old subscribers of my personal Clockwork Objects blog. The old Google Feedburner feed from that site has been deleted and redirected to our GoTripod blog. Google will maintain the redirect for 30 days after which point if you would like to continue receiving our exciting content you will need to check/update your subscription feed to unsure it points to http://www.gotripod.com/feed/rss

Thanks, Jon

Rails 2.3 delivered a new feature that allows you to easily write forms in rails that can process nested attributes for related objects using the accepts_nested_attributes_for method in your models. Now there is a plugin to make adding and removing nested forms a walk in the park!

I am not going to go into detail about this feature as Ryan Daigle has an excellent write up on his blog.

However I have been looking at ways to easily add and remove nested form blocks using Javascript/RJS and came across a good method of achieving this by Marsvin on the RailsForum website.

We have used this method a few times now, so thought we would roll it up into a plugin. Simply install the plugin to give you two new view helpers that allow you to create links to add and remove these nested form item partials using RJS.

Visit the plugin’s page on GitHub to install or view the documentation.