Always Learning

Posted by admin_pnp | about 7 years ago

The TigerSpike development process


App overview


The Pearson Plug & Play application was envisioned as a showcase to show off the newly available FT Press APIs by means of new and upcoming technologies.


Instead of choosing to write a native app (iOS, Android), our plan from the start of the project was to create an App that would be compatible with as many mobile devices as possible. This led us to choose a HTML5 implementation using a cross platform development framework.


One of the major highlights for this project was the idea of making the dataset available for reading whilst also adding a social element to it making the reading experience more interactive.


Initially the device was intended for the Blackberry Playbook due to it being so new in the market and having very good HTML5 support. Subsequently we instead chose to target Android Honeycomb devices because of the recent push of Android into the tablet market with Honeycomb OS and the superior quality of devices that will be emerging in the market in the near future. Larger tablets also give the designers of the App more screen space which allows a more natural reading experience.


Brainstorming the App


It was decided during our initial brainstorm for the Plug & Play App that our focus should lie in deciding how to present the Data Set so that the reading experience is as intuitive and natural as possible.


Instead of creating another standard, static PDF-style e-Reader our vision was to employ the absolute latest tools within web development in order to create a ground-breaking, innovative e-Reading experience that allows users to interact with the data, easily navigating and browsing through topics and authors relevant to their interests and subsequently displaying the chosen article in a neat, uncluttered way.




Facebook was chosen as our social element for the project, partly due to its popularity and power as a promotional tool, but mainly due to the recently established OpenGraph API which allows us to integrate a social web of content that users can navigate through, using ‘Likes’ as a popularity score for each book.  




After contemplating around the concept of employing Facebook ‘Like’s and the need for a clear, navigational user interface we decided on using “weight” to determine which articles should be presented to the user first. It was equally decided that topics and authors should include “weight” in order for content to be displayed according to topic/author preferences.





Developer Investigations


The next step in our process was for the development team to conduct some research on new available technologies, and subsequently determining if/how we could integrate relevant features of those technologies in the app-build.


The first thing we did was look into using HTML5 and CSS3 (an excellent set of guides and tutorials for beginners can be found at Dive Into HTML5). We also found a few examples of fun things you can do with HTML5 such as an interactive twitter cloudand an interactive map to our solar system.


We quickly realised that we would need a solid wrapper app to hold all of our HTML5 and CSS3 development, and subsequently progressed to look at ways of migrating onto Android devices.


We came across several alternatives as to how to deploy our app. There was the alternative of making a wrapper app ourselves with custom methods to reach the native elements we wanted to take advantage of. However we decided that this would defeat our goal towards making a flexible app that could potentially be deployed to other devices with ease. Also this would be re-inventing the wheel in many ways, as there are already several very effective open source alternatives to creating a wrapper app.


Two of the main options for creating a cross platform mobile application from one code base are PhoneGap and Appcelerator Titanium. We chose PhoneGap due to its open source nature and its lightweight implementation.


Wire framing


Wire frames for the project were then drawn up to plan out the app and all its features. During this process the technical implementation was planned out and the weighting system finalised.




Each article will be connected by the keyword metadata associated with it and the umbrella topic that contains it. When a user reads an article a weight is given to each if its keywords. The weighting of these keywords then add weight to all other articles associated with them.

The app will also regularly ‘scrape’ Facebook for information on each article to find out if any new users have “Liked” them, which consequently improves the “weight” of each book.

This significantly means that books that are more relevant to their associated Topic/Author will bubble to the top, so that over time the App automatically learns what the user enjoys to read. It also means that more popular articles will end up closer to the top of the list and are hence more likely to be read.

It is through this ground-breaking new concept of semantic filtering that we hope to provide the App users with a more customised, personalised and enjoyable reading experience.








The next stage of the process involved creation of design based on signed off wireframes. We also created App’s visual identity and branding with contemporary look and feel and visually simple yet strong App’s logo


See the app designs here 




The development process for this App threw up a few unexpected hurdles due to the relatively new concept of using HTML5 and CSS3 on mobile devices. Hopefully we can give you a few hints and tips to get around the issues we faced during our development process. We’ll also go over how to use and access the FT Press API to access their content. 


Our most obvious first problems were the performance-related issues associated with employing HTML5 on Androids implementation of a webkit browser. Initially we aimed to use the Canvas element in HTML5 for the majority of our animations and the visuals for our app. However the support of the Canvas element on Android is not optimised for this and lead to the animations being extremely jerky.  This was solved by using CSS3 animations wherever applicable but even this turned out to be jerky on mobile browsers.


Our solution to this residual performance issue turned out to be a very simple one, we forced the CSS animations onto the device’s graphics processor by using:


            -webkit-transform: translate3d(0, 0, 0);


Secondly we found that using Facebook as you would in a native app is quite difficult from an App based in a web-view. A Native mobile app has an application ID to fire off requests with, however in a web based application the calls to Facebook to “Like” and Share articles require a static URL to call back to.

In our case we didn’t have a static URL and we didn’t have access directly to the native Facebook framework so we ended up making a lot of out-calls to the Facebook OpenGraph in raw HTTP.


Through our development time we found that these were the only two really big hurdles that we faced. The major problem with current HTML5 mobile development is that there isn’t as much documentation available as there is for native applications.


One of the most useful tools we discovered for a mobile web environment was iScroll. Although originally optimized for iOS devices we used this in all instances where we needed to scroll through information smoothly. The process of applying it was as easy as adding a new iScroll variable, giving it the name of the element to scroll and adding <lu> tags to the <div>


var articleScroller = new iScroll('wrapper', { snap: 'li', momentum:true, hScrollbar:false, vScrollbar:false });


In this case the iScroll snaps to the <li> elements that it can find. We used this to snap to the articles at the top of our list and to the top of our topics stack.


$('#articles').append('<div id="wrapper"><ul>');


<li><div class


Although the Pearson documentation for the API covers all bases, we particularly found the search functionality useful.  Although this isn’t frequently used as a simple way to find topics and articles, we preferred cutting our overheads down by using the processing power of the servers instead of implementing it on the Device’s search functionality.


One of our major concerns towards the end of the project was load times, due to the fact that we were trying to scrape as much information from Facebook as possible. Unfortunately you can only make 600 calls every 10 minutes to Facebook, which we nearly over-exceeded whilst trying to collate all the “Likes” associated with FT Press articles.


Blog Categories: 

Average: 2.3 (4 votes)

16602 reads
Always Learning