At this month's Londroid, Qi and I presented Wutson - an app we've been working on since the start of this year. We share our workflow describing how we worked together, which tools we find most valuable, and tips for improving the dev-design process.

Wutson is your own personal TV guide, an app to help you find what's on. We decided to make it because none of the existing options we found felt quite right: some had thoughtful features and UX but looked dated and carried ads, while others looked brilliant but had confusing UX and awkward user journeys.

Photo showing Wutson on the Discover shows screen

Development started around the time that Android TV was launching - Wutson would be a perfect app for the living room: very visual, really simple and of course, it's the right place for a TV guide.

This year, we've also been quite focused on exploring accessibility for Android in some of our newer projects; a lot of the considerations that would make an app usable for TV would also help make the app accessible, so this was an ideal case to experiment and learn.

We started by looking at existing apps - two of the most popular were SeriesAddict and SeriesGuide.

SeriesGuide is a great example of an app with a gorgeous UI; it's the one I currently use. Unfortunately some simple tasks are not intuitive (searching for a show) or not possible (looking for the episode description for a show you don't yet track).

SeriesAddict is a popular app in France backed by the BetaSeries API. It doesn't follow the most up-to-date UI patterns, but has some well designed features like the watchlist, a view which presents the oldest five episodes that you haven't marked as watched for every show you're tracking.

Photo showing collection of post-its representing screens in Wutson

Qi and I made a list of all the features from these apps (and more), then identified the ones we felt were most important to include in an initial release of Wutson, mapping them together as user journeys to form a rough information architecture.

After the initial project bootstrap tasks were complete, it's time to start working on features. We follow a process that's similar to the one we use at Novoda:

  1. Plan
  2. Scribbles/prototype
  3. Visual design and specs
  4. Implement visual refinements
  5. Review (then back to 1)

Screenshot of Wutson board on Trello

While we tend to use Atlassian JIRA at work, for our personal project, Qi and I chose to use Trello.

Our Trello board is made up of four columns:

  • a to-do list
  • Qi's current tasks
  • my current tasks
  • completed tasks

Our planning meetings would begin with a review of the previous week's work, running through the completed tasks column and either archiving the ticket, or moving it back into the to-do list, if it wasn't done-done.

Then we'd run through the remaining tasks, deleting the ones that weren't going to be worked on in the near-ish future, and selecting others to move to our respective columns with the intent to start these tasks next.

By planning and reviewing together (instead of separately) we're able to:

  • organise tasks so we don't block each other
  • give feedback to contribute to the direction the product is taking
  • receive praise and feedback after presenting the work we've spent time and effort on completing

We presented our workflow for the search feature:

Scribble version of search overlay and search results

Based on the user flow, Qi is able to produce quickly scribble out the basic structures page by page. The Search Overlay and Search Results screens are shown above.

For this stage, there's no need to worry about the details - it doesn't matter what text is displayed, what colour the app bar is, which images to use, and it doesn't even matter if you can't even draw straight lines; they're meant to be pen & paper scribbles.

While Qi is working on these, I'm keeping myself busy by setting up the data side. During the planning stage, we already discuss what the feature should include, so I know which APIs I'll need to hit. On Wutson, I used a combination of Retrofit and RxJava to work quickly.

I should have also started to write tests at this point - it's one of the things we do daily at Novoda but I regret not doing for Wutson. It's never too late though!

When Qi is ready with some scribbled screens, we'll meet again to discuss them:

Scribble for the search results screen

Now is the time we identify all the assets I'll need to implement the design, including overlays for focused and pressed states, icons in various sizes, image placeholders, and font files - that is, we make a list of all the things I need from Qi.

In terms of accessibility, we identify which components can fall under a single content description. To ensure we have keyboard/trackball/switch access (non-touch mode), we take decisions on which elements are core to the screen. For example, we might hide the star icon here if the user is in non-touch mode, because it'll make navigation through the list take two clicks per item instead of one. We must be careful not to remove functionality though - there is an affordance to track a show on a different screen (show details).

By doing these now, the app is already TV ready - after spending around 8 months with a Nexus Player, I'm certain when I say I'd rather have a completely functional app with similar UI to the phone version than none at all.

Search Overlay and Search Results implemented in the app, with scribble-level UI

Qi will cut up the scribbles into slices and I'll put them in the app. Implementing it like this for now means:

  • Qi can work on visual design (mock ups) while I work on functionality
  • I can consider adding acceptance tests (Espresso) while everything is bare bones
  • I can ensure I've added focus and press states for all interactive elements, even if they're only temporary ones; I should be able to swap the assets later

Screenshot of app running on Genymotion in front of Genymotion virtual device list

To test focus states, you need a device with a dpad or trackball, a USB-OTG adapter to plug a keyboard in, or an emulator (you don't use 'focusable in touch mode'). The first doesn't really exist with recent versions of Android and the second is feasible but annoying. I tend to use Genymotion virtual devices:

  • I can use keyboard to enable non-touch mode, so I can check all focus/press states
  • it has a resizable window
  • screenshots/screen recording
  • very fast

I create a 360x640 px device with 160 pixel density (MDPI) to match Qi's output. Apart from Android's font rendering, this makes it easy to spot differences between the designs and the implementation.

I'll create a device at my minSdkVersion, and one at targetSdkVersion which is especially useful when you're theming or styling anything to do with AppCompat.

So while I'm working on implementing the scribbles, Qi's working on making the scribbles pretty:

Search overlay and Search results mockups

Qi explains that Sketch is currently her favourite tool for visual design, particularly loving the vast improvements on loading/running speed (over Photoshop/Illustrator). The Hover Guide allows you to see the distances from your selected element to other elements:

Sketch also uses symbols. You create a symbol (e.g. an icon) and use it in multiple places, but when you change the symbol, it updates all the other instances. A similar feature exists for styles, applying the same set of attributes (like text colour, font, etc.) to multiple text boxes:

Sketch itself is available for a 30 day free trial (Mac only) and there are plenty of design kits online to get you started.

Getting designs over to the development team in a format that's useful to them used to be a hassle. We'd have to produce, for each screen, a PDF showing the margins and paddings, colours, text styles and dimensions. Here's an example that Dave produced while we were working on the Sun Mobile app:

Spec sheet or redlines from the Sun Mobile project

It's not great. For designers, it's a waste of time, and it's easy to miss things. As a developer, the spec sheet is very noisy - and flipping between different projects meant having to get used to the spec sheets from different designers.

Zeplin is program which hopes to have the solution to redlines/spec sheets. It's available as a web app and for designers using Sketch, producing a Zeplin project is as simple as using "Cmd+E" to export their artboards.

Zeplin provides an interactive portal into what we used to get as static spec sheets - we can now query for the information we need, when we need it:

It does require care from designers though - Zeplin isn't clever enough to know what information we need - as developers, we know there's a difference between what the user can see on the screen and what views/view groups make up that screen. These look the same:

Designs with bounding boxes invisible

But in Sketch, Qi has to add an invisible bounding box around the numbers so Zeplin can pick it up:

Designs with bounding boxes visible

Once we have the designs exported to Zeplin, it's time to update the app from scribbles to match the design.

I bought this whiteboard from Amazon and it's glorious. You need to get the thin pens too, the fat ones are not useful.

whiteboard showing sketches of Search Result view

I draw the part I need to implement as a lo-fi sketch; even though Zeplin hides a lot of information by default, I still think it's a lot of noise, and by making a list, I find it easier to get from A to B.


Iteration of implementing the design

Next steps will include releasing a beta via Google+ communities and exploring a smart TV app.

Zeplin have generously offered a discount code for Londroid attendees! Use ZEPLINLOVESLONDROID to get 25% off for 3 months until 26th of August. Keep following this blog to stay updated!