As we consider the future of our native mobile applications, it is worth considering what features we want to add and support as the capabilities of devices grow. Recently, the Apple Watch has extended the utility of the iPhone. I have had the opportunity to use an Apple Watch for some time and have tried a number of different news and audio listening apps. These are some rough notes on how various applications work and what they provide.

NPR One

This is one of the more polished and apps on the watch and it is a great companion/extension of the iOS app. Almost all the functionality of the iOS app is here, except the ability to sign in (you have to do that on your phone). If I have any gripe of this app, it’s that finding the menu with a force touch is not terribly intuitive, but that is more a condemnation of the Watch’s UX pattern than the NPR app.

Launching Local intro playing After the intro Story playing Story details Force touch menu Search Suggested

BBC News

This app has several basic groupings of news that you can choose from: Top Stories, My News, and Most Read. The interface is a simple watch-like tree, using the default watch typefaces. Each story detail consists of a small image and short summary. A force touch brings up a menu that lets you jump to an extended version of each of these sections, even if you’re already in one. Strangely, it does not let you add a story to “My News”.

Home Story detail Force touch menu

Flipboard

Flipboard feels like a natural and smaller-weight extension of the iOS app. It doesn’t feature the compelling visual transitions, but it does retain most of the important functionality, in an albeit stripped down manner. You only have a selection of the most important 10 or so stories to choose from, not the depth that you can explore on your phone.

Sign up Story details Read on phone Force touch menu Send to magazine

New York Times

Upon launching, this app gives you a very simple walk-through of what it does. Perhaps because I am a new Apple Watch user, I did not find this as tedious as similar experiences on the phone. Like most watch apps, this one is basic and focused; there is a limited selection of important stories and your only force-touch option is to save them for later. The app tells you when you’ve seen everything that there is to see. Unlike the other apps, the NYT app is more richly styled with their signature typefaces.

Launching Story Story detail Force touch save It all fit

Overcast

Overcast is the popular alternative podcast player and its designer, Marco Arment, has written extensively about the iterations of the watch app. You should go read his piece rather than mine, but it’s a gem of an app. As you might expect, controls are up front and easy to use, and the power-user features of voice boost and smart speed are hidden behind a force touch menu. Since Apple doesn’t have a watch version of their own Podcast app, this app is useful for prolific podcast listeners.

Initial now playing Playing details Available items Force touch menu Speed and effects

Tune in Radio

Like Flipboard, you cannot start your experience in this app, but have to set up stations and an account in the iOS app. Once you’ve set up stations, the watch app gives a basic view of your stations and what’s playing. The artwork is inconsistent, but that might be a problem of metadata from providers (like us!). Also, the app does work with the now playing glance, and shows fast forward / rewind controls, which is not correct for an audio stream.

Now playing Stations menu Force touch menu Media player glance

SoundCloud

This app is very simple. It offers you play/pause and prev/next functionality for whatever list of content you’re looking at in the iOS app. There is no ability to find other content. The only other option that it offers is the ability to like a track via the force touch menu.

Playing Paused

Pacemaker

This is a strange but potentially fun media player app. You can play songs from your media library, either on the watch itself or via the connected iPhone. The play/pause/next track controls are straight forward. The real differentiator in this app are the four effects that it offers: ChopChop, Whitenoise, 8-Bit, and Hi-Lo. They’re useful just in case you ever wanted to DJ a party with cheesy effects from your watch. There are no force touch menus in this app.

Playing Choose tracks Effects
The new mprnews.org on a tablet.

Earlier this week, we made public the new homepage for MPR News. This is the final big piece of our ongoing responsive re-design of the site. Technology-wise, there aren’t any new systems or components on the homepage that haven’t been put in use in the topic pages or story pages. But, the homepage is a very visible and important design change.

Old and tired.

The biggest problem we were trying to solve is that our old page didn’t work well on a mobile device. Today, about 40% of our total traffic comes from mobile devices. That’s a lot, and to remain relevant to that growing percentage, we need to not be a bad experience, and maybe even a good one.

The last redesign of MPR News was done in 2008, before responsive websites were really a thing, and mobile websites were only just starting to pop up. In addition to not being mobile-friendly, there were numerous other substantial problems with our old homepage:  The type was too small and without hierarchy. There were too many topical sections that all looked alike. Some testing showed that few visitors (under 25%) scrolled past the “blog box”. And there were so many different links and elements on the page that it was too much to practically take in and decipher.

To design the new homepage, we formed a small group of invested parties, the core group of which was Digital News Director Jon Gordon, Product Director Peter Rasmussen, and myself. We started by making a list of the things that we wanted to be on the new homepage. Designing a page to work well on a mobile device means you need to focus on the things that are relevant to someone with a limited screen size. We settled on the following things, which neatly explain our final design:

  • News stories that editors can adjust in order and prominence
  • NewsCut, updraft, and the weather forecast are important and well loved by our audiences
  • Today’s Question needed to make an appearance when relevant, as decided by editors
  • We do news related events, and those needed to show up, and not as ads
  • Links to the major sections of the site for more focused news
  • Most viewed is very popular, and we wanted that to stand out more
  • We do excellent photos and video, and wanted that to stay omnipresent, but not huge
  • The radio schedule should be present, since we are, after all, a radio service
  • More links to find us in other places: social media, our apps, podcasts, and email
  • Audio everywhere, because we create great audio

Much like our section fronts, we settled on a three column layout. Unlike the section fronts, the persistent column moves depending on screen size. On desktops & larger screens, it is on the left, on tablets and medium screens, it moves to the right. We debated this, but ultimately liked it a lot on tablets because it puts the latest news furthest to the left and felt that was most appropriate. On phones, this all shifts to one column, and puts the news stories first.

When we display the news stories, we default to reverse chronological of our latest stories, but editors can and do override that to put the more important and noteworthy stories at the top of the heap. This listing of stories integrates content from our internal CMS, itasca, our blogs, and the PMP, through our internal search normalizer, The Barn. In addition to ordering, there are five different levels of prominence a story can be given. They are:

  • Level 0: Just the headline
  • Level 1: Headline slightly larger, thumbnail image, and a short description. This is a “described story”
  • Level 2: Headline larger yet, larger image, and the short description. This is a “promoted story”
  • Level 3: Much bigger headline, short description, no image, goes across both columns on tablet and desktop screens. We probably won’t use this very often. This is a “blowout story”
  • Level 4: Just like the blowout story, but with an even bigger headline. Think “Dewey Defeats Truman”. This a “super blowout”.

In addition to these levels, editors can turn on or off the date stamps and add labels, e.g. “BREAKING NEWS”, above headlines.

news_levels

We’ve also fully switched to using Franklin Gothic Demi Condensed as our headline typeface, and use Franklin Gothic Medium in some places as well. As any newspaper designer knows, using a condensed font allows more characters to fit into a line, a consideration that is particularly important on smaller phone-sized screens. The MPR News logotype is Akzidenz Grotesk, but Akzidenz is not easy to license as a webfont. Franklin is easier to license and is a close relative of Akzidenz, so it suits our needs. This change to Franklin Gothic now propagates to all the pages on the site, including the stories, topics, and section fronts.

One element I particularly like is the new schedule. We are a radio station, and the schedule serves a very utilitarian and necessary function of informing the audience when shows are going to be on. It was surprisingly difficult to find on our old site. With the new homepage, the schedule will move to the top of the page on the weekends, when the news slows down somewhat and the programs are different from the week. It is a carousel, which is somewhat taboo for mobile, but slick works fairly well for our limited and text-based implementation.

We still have some work left to do on the homepage and mprnews.org: Our show pages aren’t fully migrated to the new layout; Our media player & playlist system needs to be re-worked to use websockets; There is an election coming up… The list goes on and a website is never truly finished (well, maybe). But, we are in a better place for more of our visitors than we were a year ago when we started this project.

We know everyone won’t agree with all the choices that we’ve made, and we know we’re not perfect. Please feel free to share your thoughts on our design here in the comments, or use the feedback forum we’ve set up.

As requested by my colleague, here are some nerdy details about the flow of data driving mprnews.org and other MPR|APM websites.

Origins

The Barn is a the central internal search engine and content aggregator within MPR|APM. Here’s how it came to be.

A few years ago I went through a period of reading and re-reading Charlotte’s Web to my kids. I loved the metaphor of the barn as a place for everything and everything in its place.

Around the same time I had grown dissatisfied with the state of search within the company. There was no single place where I could go and find everything that the company had ever produced. Google knew more about our content than we did. That seemed wrong to me.

I also knew that we would soon be faced with a big project called the Public Media Platform, which would involve standardizing the metadata and structure of our content for publishing to the central PMP repository. That meant I needed to learn about all the different CMS systems at work within the company, a non-trivial task since we have at least these:

  • Itasca (homegrown, powers mprnews.org)
  • Drupal (powers marketplace.org, splendidtable.org)
  • WordPress (powers MPR blogs (including this one), witsradio.org, dinnerpartydownload.org and others)
  • Teamsite (static files with SSI (!))
  • Eddy (our digital archive)
  • SCPRv4 (powers scpr.org)

In Barn parlance, each of those CMS data silos is an “origin”.

I had spent the three years prior working on the Public Insight Network, particularly in building a robust search feature for the PIN’s main tool. Out of that work came Dezi, a search platform similar to Elasticsearch but based on Apache Lucy rather than (like Elasticsearch and Solr) Apache Lucene. So I knew what tool I wanted to use to search the content.

Aggregation

Before I could use Dezi, though, I needed to tackle a much harder problem: aggregating all those origins into a single location. I cobbled together a system based on the following criteria:

  • If I had direct access to the backend storage of the origin (usually MySQL) I would talk directly to the backend.
  • If I had access only to the public-facing website, I would crawl the site periodically based on a feed or sitemap.
  • If I had no feed or sitemap, I would make a best effort based on a traditional web crawler approach.

Since my go-to language is Perl, I ended up using the following CPAN modules:

Rose::DB::Object
High-performance ORM that can interrogate a database and derive its schema automatically
Rose::DBx::Garden::Catalyst, CatalystX::CRUD::Controller::REST and Catalyst
MVC web framework for managing the Barn database, scheduler and logs
LWP::UserAgent
and WWW::Sitemap::XML
Web crawling tools
Search::Tools
My own module, essential for massaging things like character encodings, XML/HTML/JSON transformations, and the like.

Throughout the day, cron jobs keep the aggregated content in sync with the various origins and marshals it all into XML documents on local disk. An indexer sweeps through, finds any new XML documents and incrementally updates the Dezi indexes.

I create a single index for each origin+content-type, so there’s a separate index for Itasca-Features and Itasca-Audio and Itasca-Images. Maintaining separate indexes makes it much easier to create distinct endpoints within Dezi for limiting search to particular content subsets, whether by origin or type. It also helps with scaling, by sharding the search across multiple filesystems and machines.

Creative re-purposing

Once the Barn system was up and humming along its automated path, we started to see other uses for it besides just search. Since all our content is now normalized into a standard format and metadata schema, we can create ad hoc collections of content across multiple origins. Since the Barn knows how to talk to the origin backend databases, in real-time, we can de-normalize and cache assets (like MPR News stories) that do not change very often but which can be expensive (in terms of SQL queries) to generate. And since we now have all our content in one place, we can re-distribute it wherever we want, automatically.

Here, for example, is an example command for exporting Barn content to the PMP:

  % perl bin/barn-export -e PMP 'origin:marketplace date:today'  

That pushes all of today’s Marketplace content to the PMP. It runs on a cron job via the Barn’s scheduler system. An export is just a search query, so we could also do something like:

   % perl bin/barn-export -e PMP 'sausage politics origin:feature'  

That pushes every story mentioning the keywords ‘sausage’ and ‘politics’ to the PMP. Pretty handy.

Future

The Barn has proven very helpful to our internal infrastructure and content delivery. That improves our audience experience in some direct ways (faster page load times, automating some tasks our content creators used to do manually). We’d also like to open up a subset of the Barn’s search functionality to our audiences as well, so that they can search across all our content at once, and preview audio and images inline within results, just like our reporters and editors can do today.

Every day APM|MPR generates several hours of audio content for its radio and digital broadcasts. Over time that adds up to many terabytes of audio, most of which has no written transcripts available, because transcripts are expensive and slow to create. Imagine listening to the news and writing down everything you hear, word for word, Read more