After a brief intro the evening kicked off with Patrick Hamann giving us a fairly pain free (tech ‘lite’) introduction to the Touch framework and giving us his opinions on where he thought it fitted within the plethora of development tools available.

Firstly giving us a bit of a low down into the development stack and providing us with some incites into when using the Touch framework might be a consideration, he went on to provide some useful examples of apps that have successfully utilised the framework and touched upon the useful templating and leveraging of SASS that is inherent in the framework.

Slides for Patrick’s talk can be viewed here:

Following Patrick, Matt Spence from the University of Kent providing us with an interesting view of how their dev team were pushed to consider developing ‘something’ mobile for the university. Whilst he admitted this wasn’t the best approach to starting a project he went on to demonstrate how, with little development time available, his team were able to produce some rather useful student tools such as building locator (using maps), desktop availability (how many desktops are available in the various public spaces) and timetabling accessed via a student login. Matt demonstrated how the readily available university data can be made available as a useful mobile service for their students and how the rapid application development nature of Sencha Touch enabled them to get their mobile ‘something’ out to a testable market within a 4 week period. We look forward to seeing the results of the next 4 week sprint on the project.

Slides for Matt’s talk can be viewed here:

Rob Squires completed the trio of talks with a discussion primarily focussed on building cross-platform mobile apps using Sencha Touch 2.0 but also giving us a more technical ‘under the hood’ view of the framework. Rob showed us a re-usable technique he had developed utilising the MVC nature of the framework to tackle various challenges that building cross-platform apps can throw such as differences in UI/UX that mobile users come to expect with their particular flavour of devise and OS.

Slides for Rob’s talk can be viewed here:

Our user group can be joined here: http://www.meetup.com/London-Sencha-Touch-User-Group

We’ve been lucky enough to have Forward host the event in their amphitheatre in the heart of Camden. Details of how to get there are below:

Forward Technology
Floor 2, Centro 3, 19 Mandela Street, London, NW1 0DU, United Kingdom
http://forwardtechnology.co.uk/venue

Transport Links:

• Underground: Camden Town, Mornington Crescent (Both Northern Line)
• Train: Euston, St Pancras International, Camden Road
• Bus: 274, 46

Being our first event we will be starting off soft with overviews into Sencha Touch and mobile development with an aim of getting a feel from the community as how we want to structure the events and what we all want to learn and share with each other. With that in mind we are on the look out for those of you who want to give a talk at this or future events. They can be anything from 5min lightening talks up to 30min in-depth slots: show us something you’ve worked on or something neat that we’d find useful. Please do get in touch if you want to contribute (it means you wont have to listen to us too much!)

We’re really looking forward to meeting the rest of the Sencha community in London and learning more about mobile development.

UPDATE…. WE HAVE AN AGENDA:

We have 3 sessions planned for this event each lasting 20-30 minutes with an open floor Q&A session following each. We will start the group with a beer and a slice of pizza and move onto the 3 main sessions detailed below:

An Introduction to Sencha Touch

Patrick Hamann is a Front-end developer living and working in London with a keen passion for creating great mobile experiences using HTML5 frameworks. His talk will be a taster session introducing you to Sencha Touch giving some insight into why you might consider it as a solution.

• What is Sencha Touch?
• A walk-through of the Sencha Touch structure
• Capabilities and UI features
• Real-world examples of it out in the wild

Kent Mobile: Building a mobile “something” for the University of Kent

Matt Spence is from the IS web team at Kent University and will be providing some incites into their experience with Sencha Touch.

• The pressure to deliver something on a mobile platform
• How we arrived at Sencha
• What we’ve done
• Where we’re going

Building cross platform apps using Sencha Touch

Rob Squires is a Lead Developer with UVd with a penchant for utilising well established programming methodologies with new technologies. He is a Sencha fan and keen squash player.

His talk will focus on some techniques and considerations involved in building cross platform apps using Sencha Touch

• A quick look at common cross platform challenges
• Some techniques that could be useful for a Sencha project requiring cross platform deployment

Having spoken to our SEO specialist last night I was intrigued enough to do a bit of digging around Google’s position on ranking the usability of websites when viewed from different devices and how this fits in with their ranking algorithms. From an SEO perspective, our guy claimed that very soon Google will start penalising websites which are detrimental to mobile experiences.

First port of call for me is Google’s very own initiative GOMO, a pretty straightforward but useful site which lays out the business case for making your website mobile friendly, describes some of the basic principles of how to go about producing mobile friendly experiences and links to various resources for further reading/research. As a side note, when you get a chance, take a look at their site on your mobile devise as they have gone for a separate mobile site as opposed to a responsive solution and you can tell by the user experience and performance: it’s a nice example of an effective mobile website (yes I know that sounds like stating the bleed’in obvious given the context).

The ‘Gomo-Meter’ is a useful tool for testing how mobile friendly a given website is. It provides a scoring mechanism, summary report and visuals as well as a rather useful detailed pdf report providing guidance on improving the mobile experience of the site you are testing. If you are digital agency such as us trying to sell your mobile website design/development services there is nothing better than a report generated by Google, demonstrating how (badly) a potential client’s website performs on a mobile device and outlining how best to remedy the problem/s. To give you an idea I ran the BBC website through the metre (see below):

At first, when our SEO guy mentioned Google might start penalising websites with poor mobile experiences we were unsure how they would go about it. To quote Pete “How do you write an algorithm for that?” but Patrick’s response “If anyone can write an algorithm for that it’s Google” just about hit the nail on the head. This is bread and butter for Google.

Having thought about this some more, there are a number of rudimentary tests which could be easily performed, testing the 2 fundamental principles of good mobile experiences:

• How fast does it load?
• Accessibility (is the content fluid and viewable on a mobile without scrolling all over the place and are interactive elements given enough space?)

As we know, the former is already performed by Google and the latter is not so difficult to envisage. Other good design practices for mobile web experiences include search, contact and location information being easily accessible from the first page. This is due to the nature of mobile users who want to access information quickly (through the search) and are often looking for contact or location information in the first instance. An automated test for these elements could be achieved if Semantic Web principles (utilising the W3C’s Resource Description Framework or RDF) are adhered to and then tested for by Google.

I’m pretty sure Google are far cleverer than I so I’ll leave it to them to discuss my suggestions further and come up with a beautiful algorithm

For those who are still wondering why Google might introduce ‘mobile friendliness’ to their rankings, the expanding use of mobile devices is becoming something they cannot ignore: growth in smart phone usage, sales via smartphones, engagement via smartphones and growth in web browsing on smartphones is at an exponential rate and as a consequence this is changing the way we all experience the web:

• Smartphones sales surpassed the combined global market of desktops, laptops and notebooks in 2010 http://bit.ly/gCkOt4
• Traffic to mobile websites in 2010 grew 600% after tripling between 2009 and 2010 http://bit.ly/cYWwJj
• Google’s mobile searches grew 130% in the third quarter of 2010 http://tcrn.ch/haMlZm

So to conclude, it looks like our SEO guy might be right, Google appears to be moving toward some sort of introduction of ‘mobile friendliness’ into their rankings. Good news for those of us who have been banging on about sites needing to be accessible across all devices.

Patrick discovered TestFlight during the end of our phase 1 development of a mobile betting application for one of our clients ABETA International. As we’ve mentioned before, we build mobile web applications and native mobile applications using the SenchaTouch Framework; enabling us to produce intuitive mobile user experiences (UX) and user interfaces (UI) with the expertise and technology we have gained over years designing and building websites. Not wishing to repeat myself too much (it’s all here) we then package this up using PhoneGap for delivery to iPhone, iPad or Android devices.

One of the hurdles once the App is ready for client testing, bug testing or user acceptance testing (UAT) and the subsequent rounds of incremental version releases is how to achieve this in the most efficient way possible: obviously with website and web applications it’s a matter of setting up a staging or testing environment and providing a link, following that can be several rounds of testing – bug fixing – testing (I have paraphrased this process for illustration purposes only) but with Apps it’s a bit harder as we have to be able to distribute the App to the devices that our developers, clients and testers are using and in the case of our clients they are not in our office.

TestFlight is brilliant for this; from a single entry point you can distribute to predefined groups, set up new users within a group and create custom distribution lists to send new builds over the ‘air’. In simple terms, we can release a new iteration of an App and it gets distributed to the group who are alerted to the new version. Users can send feedback directly through the app (with in-app questions using their new SDK) or by replying directly to TestFlight automated emails, and this feedback is distributed to the developers assigned.

Its early days and we have only scratched the surface of what TestFlight can do but I thought I’d give my first impressions as it might be of use to others.

I’ve recently been discussing a mobile web app module we have in development for our CMS with a number of existing clients and potential new ones and I’ve learnt a few things of late about peoples understanding of mobile applications; that is to say, as soon as I mention ‘native apps’ in the same breath as ‘mobile web apps’ I confuse at least 80% of my audience. It has been an interesting learning curve for me establishing just what level of understanding people have on these two distinct (but similar… confused already?) methods of reaching an audience and delivering content so I thought I’d write a bit more to help clarify a few things in an attempt to aid an informed choice of which direction to take.

What is a Native App?

Generally speaking, if a customer comes to us with a requirement for a ‘mobile app’ most (99%) will be thinking about a Native app. By Native I mean an application built for a specific mobile handset (they will be picturing a shiny iPhone), purchased from and delivered by a central store (they will be picturing Apple’s App Store), installed on the mobile device with an icon on the homescreen with updates managed through the store from which it was downloaded.

Do your clients Actually Want a Native App?

When you delve into what it is the client actually needs, it is not always apparent that a native app is the most suitable or appropriate tool for the job, especially if it is one being developed in a specific language (Objective C for instance in the case of an iPhone) which then needs porting to other target devices (for example BlackBerry, Android and Nokia).

As is often the case, what a lot of people think they need is down to a preconception (often established through marketing, advertising, trends and fads) that one way of doing things is the only (and best) way of doing things. The alternatives are not explored because they only appear on the periphery whereas particularly with the iPhone, iPad and the App Store people have perceived understanding of the end–to-end delivery and usage of a native app.

What is a Mobile Web App?

On the other hand, when I discuss mobile web apps it is clear from an early point in the conversation that most people think I am discussing a native app whereas what I am actually describing is an application developed on the web specifically for mobile devices (at present many sites use the ‘m’ subdomain to host their mobile web apps); to all intents and purpose this website (mobile web app) might look, behave and feel much like a native app but it is accessed through a browser and doesn’t have to be downloaded via an app store. In a lot of circumstances mobile web apps are actually advantageous:

1. You can better manage development across multiple platforms
2. They can look and behave like a native app (even having an icon on the homescreen) so UI/UX can retain a ‘familiarity’ across both types
3. Other than fetching the initial data / framework the app does not have to be online to run (a common misnomer) as content can be cached and we can use HTML₅’s offline mode
4. You don’t have to go through the App Store acceptance procedure and updates / enhancements can be released as and when required (see point one)
5. There is no reliance on someone else’s business model (eg Apple) to monetise your idea
6. You get to keep 100% of the revenue you generate
7. As you will see in the final paragraph, mobile web apps can be packaged as native apps for multiple platforms (eg iOS, Android, Symbian, Blackberry) using mobile frameworks such as PhoneGap and Appcelerator Titanium
8. Applications can be developed more rapidly (see all above)

Native is Still Best (sometimes)

That being said, there is no denying some advantages that native apps (particularly in the case of Apple) have:

1. End users currently better understand the concept (of the store – application – handset relationship)
2. Businesses currently better understand the business model because it is quite simple
3. People feel confident in the application vetting process and therefore have confidence they are not being scammed or having malware/viruses delivered to their handset via the app
4. You can access all the handset features and hardware (eg: the camera, geo locations, graphics acceleration, file system and so on)
5. Monetisation of the app itself – if your idea is to produce an app which makes money just because it sells 1 million copies at 59p then this is the only way you can go

There is a Third Way

Our mobile web application development uses the Sencha Touch framework (a HTML₅ Mobile Web App Framework for touch screen mobile devices). We can expose various methods of our content management system (for getting content or defining functionality) via webservices which take parameters and data and return data in json format (or XML if you desire) to the Sencha Touch application. The framework allows development of mobile web apps and provides a local storage proxy for saving data offline.

The Sencha Touch framework runs on Webkit which is shipped with all the major mobile devices these days (and Google Chrome) so when browsing the mobile web app via a web browser on the mobile handset the user experience is fairly consistent and as previously discussed can very much be like a native app.

However, if you want to deliver your mobile web app as a native app this is now possible using frameworks such as PhoneGap or Appcelerator. In our case we use PhoneGap which allows us to provide native functionality such as access to geo location, camera, storage, contacts and so on (list of PhoneGap supported features).

The steps are fairly easy (paraphrased here):

1. Develop your mobile web app in Sencha Touch (or other)
2. Add any native functionality your require (and is supported by your framework)
3. Package this up for your target device in PhoneGap (or other)
4. Send native app to appropriate store for acceptance testing
5. Sell / provide your app via the app store

See, sometimes you can have the best of both worlds!

Further reading:

http://www.phonegap.com
http://www.appcelerator.com
http://www.sencha.com
http://www.lukew.com/ff/entry.asp?1193
http://www.lukew.com/ff/entry.asp?1264
http://www.uxbooth.com/blog/its-about-people-not-devices

The old site was a passive audience experience: traditional article driven content read by the user but the aim of the new site is to encourage discussion and user contribution; discussions are started by a number of key individuals who open out their comments for other users to contribute. User’s contributions are given equal prominence to the article itself and form part of the overall site content.

One of the key features we have implemented enables users to register and subsequently log in with their LinkedIn account: instead of the traditional registration form and then double opt-in email verification process the registration is simply a matter of the user allowing ModernSelling.com permission to access their LinkedIn account, entering in their LinkedIn email and password and Bob’s your uncle we can then authenticate against the LinkedIn user account in the backend (using the OAuth protocol and the LinkedIn API). The beauty of this is four fold:

1. Users with a LinkedIn account don’t have to worry about managing subscriptions / profiles on 2 different sites
2. The registration process is vastly quicker and easier for those choosing to use it
3. We can maintain up-to-date profile information about a user as it is passed from LinkedIn each time a user logs in and don’t have to rely on users updating their profile through a traditional ‘My Account’ section
4. Although we are not currently using all the profile information LinkedIn provides and have only scratched the surface of the many different API’s available we can choose to leverage them at any point in the future without going back to our user base and asking them to fill in more information; we are essentially piggybacking the LinkedIn system

Warning: you might not get what you want

For those wishing to utilise the LinkedIn API for their own web applications / subscriptions sites / profile building there is one word of warning: unlike the Facebook method (‘The Graph API’, part of which was previously known as ‘Facebook Connect’) the LinkedIn profile doesn’t provide you with a user’s email address. This appears to be a strategic business decision by LinkedIn but poses some hurdles for those with existing databases which use the email address as a unique identifier: for obvious reasons, if the email address is the unique identifier then it is a prerequisite to have it in order to set up a user account. Furthermore, even if your database does not require an email address, your businesses sole form of direct communication with one of your users / profiles is likely to be via email – so not much use if you don’t have it!

Personally I think this is a major ‘faux pas’. Some might say it is a security issue but actually, if an individual is already giving a third party web application permission to access their user profile it is just another (important) part of personal data they are happy for the third party to use to enhance their experience.

Our solution to this issue was to create a ‘one off’ step on the first attempt to use our log on with LinkedIn process: this ‘intermediary’ page requests the email address  prior to us creating a user account for them in our database. Secondly, for those who already have a ModernSelling.com account but decided to start using the log in with LinkedIn feature we asked them to link their existing ModerSelling.com account with their LinkedIn account by providing their existing ModernSelling login details (email address and password). Both of these actions were very easy and not required on subsequent use of our log on with LinkedIn process.

Below is a screen shot of this ‘intermediary’ page which hopefully should explain it:

Post Script: I’m subscribed to the LinkedIn Developers network and they have released a few useful development libraries and plugins to make life a bit easier. You can find some useful plugins here and a useful OAuth JScript library has been released here (meaning front-end developers can now leverage the LinkedIn API. Note: as it stands – on 20/04/2011 –  there are some bugs in this library which LinkedIn are working to rectify)

We are pleased to announce that Rob has finally made it to the UV^d fold, unharmed from Christmas over-indulgence and raring to get cracking on several of our more pressing projects. Rob has come from IBM after successfully navigating their graduate programme and is fully versed in everything LAMP. Just for the record, he is the first of the UV^d crew to choose Ubuntu as his operating system of choice for his desktop (choice is good right?).

Rob has worked his way into the UV^d circle of trust this week and has earned himself a) Office keys and b) Black n’ Red hardback notebook. He almost shed tear at receiving the latter.

Patrick has been working on our most recent web design project and we’ve now had sign off on the new homepage so though we would share a sneak preview of the work. The project is for Felton Fleet, a mixed independent school near Cobham, Surrey. It is being designed in conjunction with a mobile friendly version utilising CSS3 Media Queries which Patrick also blogged in Going Mobile with CSS3 Media Queries.

Click the image above to see the preview.

We nearly didn’t write this post because our motivation was at a low point following the disappointment of this month’s cake experience: we look forward to our cake consumption with gusto and feel slightly let down by the latest sweet treat.  I’ll hasten to add that the picture in question is NOT the cake we consumed; we were not motivated to take a photo of said cake which was a “Tesco’s Finest” number which was neither “Fine” nor “Drizzly” but it was from Tesco’s, did have a hint of lemon and probably was a cake so they got some of the name right.

Out of obligation I have written this post as a warning to other would be consumers of the “Tesco’s Finest Lemon Drizzle Cake”; beware of frauds in your midst and avoid at all costs.