Background

Wooden is an iPad app detailing the methods, materials and processes behind hand-building a wooden boat. Boat-building using traditional methods and materials is a topic that captures the imagination and carries with it a hint of romanticism – especially in an island nation such as Ireland, where the ability to shape vessels by hand from natural materials has been around as long as there have been people. The intention for this project was to create an immersive iPad app, with interactive presentation telling the story of how a boat is built.

The implementation of Wooden was an iterative, user-centred and test-driven process. My activities on the project revolved around the following topics:

• User needs analysis.
• Technology analysis.
• Front-end design and development.
• Testing.

The following section give an overview of the activitie undertaken for each of these topics.

What I Did

Needs Analysis

An understanding of user needs is the key driving factor of all design considerations when setting out on a project such as this. To this end research in the form of surveys with the results from the surveys then being distilled down into user personas and scenarios. This process helped to make aspects of the target user groups for the app more tangible – for this reason, strongly-represented characteristics from the respondent groups in terms of age, gender, background, etc. are reflected in the personas.

Two surveys were conducted, having a total of 62 Respondents over a three-day period - with 21 Subject Matter Expert (SME) respondents and 41 non-SME. The SME survey was aimed at gathering pointed feedback from individuals who likely already had domain expertise in wooden boat building. The intention was to gain understanding of their background demographic, use of technology and opinion on specific features, as well as suggestions for feature inclusion. The non-SME survey had a similar set of goals, this group however probably having a different and more varied set of drivers and interests, as well as a different view on what features should be included, etc.

The survey questions were grouped into two topic areas, both seeking to gather different types and "grains" of information. The first section was intended to gather general responses on user demographics, internet use and app use. A further section then proceeded to ask more topic- specific questions around the idea of a "Boat-Build App" – e.g. opinion on domain-related features, etc. Different question-types were posed in each area also – for example around feature type, Likert Scale items were employed in blocks in order to gather responses around the perceived usefulness of given features.

In order to present the results of survey analysis to stakeholders I created data vizualizations (example here). Based on these results, generalisations as to potential users could then be made. These generalisations, or initial user models, were manifested in user personas and scenarios that would serve as guides ongoing throughout production of the app.

Technology Analysis

Given use case context and Android OS/device fragmentation considerations, the target platform for Wooden was set as Apple iPad. Though native development was considered, the decision was ultimately made to go with PhoneGap due to skills.

With PhoneGap the app is composed of HTML, JS and CSS files, along with assets, images, and a configuration file. When the app is built, it is couched in a "web view" wrapper inside a native application container that can have bridges to native APIs, allowing interaction with hardware functionality – e.g. accelerometer, etc. PhoneGap’s primary strength is the fact that native APIs and native development languages are completely abstracted from the end developer. As the only development skills available to the developers working on Wooden were HTML, JS and CSS, PhoneGap allowed the requirement barrier for iOS app development to be lowered.

Front End Design and Dev

Initial wireframes detailing application layout, flow and interactions were explored using pen and paper. Conceptual diagrams for how the HTML mark-up would work for the main views were also assembled. A product of Wooden's user analysis and wireframing was a prioritised feature list that I compiled and analysed using the MoSCoW method. The next piece of work undertaken on Wooden was a proof of concept on the app’s key piece of functionality – the "magazine" content view.

This proof of concept was an important milestone in both the design and development processes – it verified that the design looked and worked well, and that it was technically viable. Further development work with this item at its core could begin in earnest. As Wooden was an iPad app, designing for touch and gestures was a key element to get right. The magazine elements were all to have movement at heart – from the flipping of the pages complete with shadows as the pages turn, to the opening and closing of a magazine article. The design for the individual magazines would be developed out further during the course of the project, but at this stage the key design elements were standardised – i.e. magazine layout, article format and most controls.

In order to capture design thinking around Wooden's planned look and feel, a moodboard was assembled containing a sample colour palette, typography and imagery. After that, it was back to graph paper to sketch out logo ideas that would reflect Wooden's background and meaning.

Finally, taking the firm set of wireframes that had been arrived at, along with a visual style and a working PoC, I could then move my efforts to designing and building in the browser using HTML/CSS/JS ina series of sprints.

Testing

I thoroughly user-tested Wooden throughout development, with a total of 42 individual tests completed over 5 rounds. Testing was conducted mostly remotely on end-user devices using TestFlight, though some observation and interviewing was undertaken. TestFlight testers submitted feedback via an online survey, with in-person results completed in a hard-copy version of the same. Once all results for a round were collated results were analysed and prioritised changes were introduced to subsequent sprints.