---

Smooth transitions in Cordova / Knockout

---

15 January 2016, by James Griffiths

Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the third post in a four-part series about our experience and what we’ve learned. Watch this space for the next instalment, or follow us on twitter for updates!

We’ve chosen to build the app using Apache Cordova, so our code can easily run on both iOS and Android platforms. Take a look at the first post to read about what Cordova is or the second to see some of the other practices we use to make Cordova feel as app-like as possible.

One of the important requirements was for scrolling and transitions to be smooth and to avoid the screen juddering. Lack of polish and smoothness is one of the most common objections raised against Cordova; it’s an easy trap to fall into, but simpler than you might expect to solve once you’re aware of it.

Work with the phone

Modern phones have powerful graphics processors, so we want to offload as much of rendering onto the GPU as we can, to keep the CPU free and ensure our rendering goes at top speed.

Let’s say we’re using CSS to move an element ‘my-page’ off the right of the screen by applying the ‘off-right’ class.

We could write:

#my-page {
    left: 0;
    transition: left 1s;
}
#my-page.off-right {
    left: 100%;
}

This will work, but it’s not typically run on the GPU by most browsers, which means performance may take a hit if you have many or large elements moving like this across the page.

Fortunately we can replace this equivalent to get GPU acceleration, with:

#my-page {
    transition: transform 1s;
}
#my-page.off-right {
    transform: translateX(100%);
}

The ‘transform’ property here is designed to be easy to handle on the graphics processor, and so runs much more smoothly.

Don’t stop me now

We’re building our app as a single-page website, within Cordova. As part of this, we’re using Knockout.js to do data bindings. Knockout is a simple way of keeping your javascript object models in sync with the HTML (or ‘binding’ them together, in Knockout lexicon).

It’s important to understand how this works to improve performance though, with Knockout or other similar frameworks. When you change the value of a Knockout-observed variable, Knockout will immediately make the corresponding change to the HTML, and each of these changes in the HTML will cause the browser to re-render the relevant part of the page. If a large part of the page is moving when this re-render is trigger then it will appear to stop, re-render and then continue moving, causing a noticeable judder.

This is particularly noticeable if you update properties across an array of objects. Knockout interprets each of these as a separate change and causes the page to re-render multiple times, resulting in a very juddery transition! Doing this is generally bad for rendering performance, but it’s a very easy pattern to fall into with many modern single-page app frameworks.

To solve this, in our app we’ve been careful to make sure we never change knockout-bound values whilst we’re transitioning. When we move between pages, we’ve adopted a workflow like this:

• 0 ms
  Create new page, start loading data and binding each part to the page.
• 100 ms
  Pause data bindings. Put any data change requests in a queue.
  Start transition (transition lasts 500ms).
• 600 ms
  Resume data binding. Process any queued requests.

In our testing we’ve found that the first 100ms is typically long enough for data to be fetched from the cache and rendered, when it’s already cached, without being long enough for the user experience to suffer.

Nothing to see here

Generally, we’ve been very happy with the performance of Knockout, but it’s performance can degrade with increased load. Every data-bound value causes extra work for it, and slightly reduces performance. For best performance, we should minimise the amount of data that Knockout is binding.

For us, this means segmenting the app into different ‘journeys’ and ‘pages’ and ensuring Knockout is only data-binding the journey and page currently in use, and disposing of the data and DOM elements not relevant to the current page. Within some of our larger pages, we take this further, and change what data is bound as the user moves around the page. This requires some discipline for us to remember to destroy pages and journeys as soon as we’ve finished viewing them, but has been well worth it in performance benefits. If there’s “nothing to see here” then it’s best if Knockout doesn’t have to keep track of it.

All this has come together for us fantastically; despite being built with Cordova the app feels snappy and quick across a wide range of devices, and our customer is very happy with the result.

In the fourth and final post we’ll look at how we architected the app to ensure maintainability for the future. Keep an eye on our blog for the next edition, or follow us on twitter for updates.

What does it mean for an app to feel like an app?

---

21 December 2015, by James Griffiths

Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the second post in a four-part series about our experience and what we’ve learned. Watch this space for the next instalment, or follow us on twitter for updates!

We’ve chosen to build the app using Apache Cordova, so our code can easily run on both iOS and Android platforms.

As a quick recap: Cordova is cross-platform way of building mobile apps using web technologies. As a developer, you write a regular website using HTML, CSS and javascript, and Cordova takes this website and creates an app that is a wrapper around the website.

For the iOS app to be available on the App Store it needs to be approved by Apple. One of Apple’s requirements that is particularly relevant for Cordova apps is that the app “feels like an app, not like a website”.

What does this mean for us? There are a lot of components to this, but in this post I want to look at how it’s affected our approach to client-server interaction.

No 404s

We’re lucky to have some really nice designs for the app, and we wanted the entire UI to live up to these.

To keep this user experience really smooth one thing we really have to ensure is that we don’t ever show the user an ugly 404 page.

On a regular website, a user moves from one page to another. Each page is loaded individually from the server and contains the data they have asked for, as well as the code needed to take them to other pages.

This wasn’t an option for us. Our app users might be on the move, underground or have a slow data connection. If we built the application extremely minimally as a wrapper around a traditional server-hosted application then we’d be making these page requests in an environment where they might fail. We can’t risk showing them an half-loaded page or, even worse, a 404.

Load data, not code

To solve this, we’ve built the application as a single-page website. All the code is bundled into the initial download – that way, all our pages load instantly, without having to wait for any code to be downloaded. This approach is an important part of good Cordova development, and helps solve the error handling issue above and reduce latency for users to keep the app feeling snappy.

The only communication we have with our servers is to send and receive data (rather than code). We have a RESTful API that manages all our operations, like loading class timetables, making bookings and getting club opening hours.

If any of these API requests fail we can show the user a pretty error message, and allow them to retry, without the app looking broken.

Smooth transitions

The app looks beautiful so we want it all to perform well on the phone. That includes loading pages, but we also want scrolling, swiping and transitions to all be smooth, and to avoid the screen juddering.

In the next post we’ll look at how we achieved this. Keep an eye on our blog for the next edition, or follow us on twitter for updates.

Design & Deliver – Our Most Recent Event

---

20 November 2015, by Amy Wood

Last week we held our third tech workshop of the year at Shoreditch House. Our most recent area of exploration was the concept of design as part of the software delivery process. During the afternoon event our speakers and guests delved into what it means to design great software and looked at the risks of not designing software properly.

It was our busiest event yet and all of our speakers were well received. We were joined – as is now tradition- by the wonderful Bill Thompson as well as George and Liam from Maido and Jim and Luke from Sketch, both very talented design agencies. Sketch offered the audience a lot of practical design advice whilst Maido spoke about what makes a design good. Tim, Head of Design and UX at Softwire spoke about the cost of bad design and why it’s so important to get user experience just right from the start of every project.

We followed our talks with an open and engaging panel discussion, in which the audience were able to share their views and ask questions. In true Softwire style we welcomed our guests to join us for a drink and more conversation on the topic once the panel discussion was over. The room was a buzz with ideas about design and how we can improve software processes. We’re now looking forward to our next event in March 2016.

How I made my own photobooth

---

5 October 2015, by Peter Harley

I was lucky enough to get married last year and decided that my contribution to the wedding planning would be to make a photobooth. This saved on the cost of hiring one and was also a really fun project. Since then the booth has been used at a friend’s wedding and had an outing at the recent Softwire birthday party.

Electronic Components

The main guts of the photo booth are:

• A laptop, to control it
• A camera (I used my Canon 450D)
• A screen to show the images on
• A printer

Various other bits and pieces were required too:

• A big push button, to activate it
• A USB to serial port converter, to attach the button to the laptop
• A flash for the camera
• Some lamps, to provide always on lighting
• A big box full of silly props!

The camera and printer just plug into the laptop by USB. The button was wired over two pins of the serial converter, which then plugs into a USB port. The button presses can then be detected by watching for when the pin goes high.

Construction

I decided to make an all in one case for all the components based loosely around a combination of various designs I found online. Sadly I didn’t take any photos as I went along, and as you can see from the finished product my carpentry skills are beginner at best! My main regret was going with the curved corners – they were far more trouble than they were worth!

This main box then sits on top of a speaker stand. The whole thing is a little wobbly but not too bad!

For our wedding we just hung sheets from some beams to create a booth around it, but for our annual Softwire birthday party I decided to create a full photobooth experience by constructing one from plastic pipes and covering with sheets.

Software

The camera is controlled using libgphoto2, specifically using a python wrapper called piggyphoto. For the graphical display I used pygame – whilst it is a little out of date now, its fine for something simple like this, and piggyphoto includes examples using it so it was easy to get started.

The most challenging aspect of the software was the interaction with the camera. The protocol is reverse engineered and sometimes unpredictable, and getting reliable results was only achieved with trial and error. If you try to use it with a different camera you’ll probably find it needs its own, slightly different tweaks.

You can get the full code yourself from github: https://github.com/pjrharley/boothy

Results

We had a lot of fun using the booth every time we’ve set it up! The photos have come out brilliantly. The main problem I’ve found is that using an inkjet printer is a bit slow. We also tried a laser printer, but the results were pretty poor quality. Ideally you need a proper dye sublimation printer, but they’re quite pricey.

Lightning Talks – The UX Factor

---

15 December 2014, by David Simons

In October 2014 we ran our fourth Lightning Talks competition. The number of speakers this year was sufficient that we ran two sets of talks where eight employees each had five minutes to tell us something interesting about software development. We voted on our favourite talks and the top two from each event won Amazon vouchers.

Here is David Simons’ winning talk from the first round, about what The X Factor can teach us when designing our applications.

Training Tracks: How to become amazing at User Experience

---

25 February 2013, by Chris Harris

At Softwire we select employees on the basis of technical ability and potential as well as technical knowledge, and provide all the training that our new recruits need in-house. It goes without saying, then, that training is  something we devote a lot of time to getting right, and it takes many different forms.

We thought we’d share one of those forms with you: our set of recommended reading lists or “Training Tracks”. We get a top developer to compile a list of books, tutorials and other on-line resources for a specific technology or area of development, and categorise them into different levels, all the way from beginner (Level 1) to ninja (Level 5 and beyond). Below is Tej’s UX Training Track to start the series: we hope you find it useful!

(more…)

Clicking to download hundreds of files

---

30 November 2012, by Rupert Wood

As part of testing some changes I made recently, I needed to check that a page of report spreadsheet downloads still worked, which meant clicking and download all of the 300+ reports in the system.

Of course I considered automating this process, but in the end I decided it would be simplest and quickest to just click down the list of links by hand (you can see my reasoning at the end of this post). Still, the manual route was not exactly straightforward – and I thought I’d share with you the best approach I found in case you’re unlucky enough to find yourself in the same situation!

(more…)

TeenTech – designing a mobile app

---

25 September 2012, by Zoe Cunningham

When I attended TeenTech back in May, I was asked to judge the “ideas of the future” competition. The children had to think of a possible invention that might exist in 2050 and write it on to a Post-it note. These notes then formed an “ideas wall”. There were two iPods up for grabs so this was a serious competition.

Certain ideas were quite prevalent with several different but similar submissions on the same topic. Machines to record your memories, or your dreams, space age buildings and cities and clothing related apps abounded. One of the more unusual ideas was a set of “power gloves” that allow you to lift heavy objects with ease after you put them on.

(more…)

Web Development in 2012

---

31 January 2012, by Tajinder Birdi

It’s 2012 and we’ve seen a lot of new changes in web development in the last year or two. So here’s my quick overview of some of the highlights and some examples from the best of the web, along with lots of links!

(more…)

User Experience: Flow

---

28 July 2011, by Tajinder Birdi