Lately, we are beginning to think about Javascript MV* frameworks. While we are not yet comfortable using these frameworks for public facing sites, we do think they make a lot of sense behind a login where the user is creating and updating content.

Our Audio Backpack application allows users to create their own classical music playlists. We built it in Ember.

I spent some time recently reviewing a few frameworks and came up with these bullet points in trying to decide which one to bet on internally long term. This is what I found:

Angular

– digest for 2 way binding can be inefficient as it uses dirty checking in a loop – computationally expensive
– Uses Plain old Javascript objects (POTS)
– More of an open ended tool set than a framework
– Directives let you bind behavior to DOM elements
– A few more edge case bugs
– Can filter expressions easily (ie an html table filter results for results that have a coomon value in a filed like show me all the results with city is St. Paul – not sql filters the markup)
– Custom services
– We have someone coming in new to our team with Angular experience
– Angular 2.0 coming out may not be backwards compatible

Ember

– A more opinionated framework that almost make you do things “the right way”
– Very Rails-like lots of similar concepts
– 2 way binding more efficient because you have to call accessors – getter and setter methods explicitly
– CRUD field generation based on models a la Rails allows for rapid development
– Powerful router that works just like the Rails router
– Better documentation
– Computed properties very powerful ie a circle object that has a user entered radius field can have a diameter filed that is calculated automatically
– is only just getting to stable APIs

Backbone
– even less than a framework than Angular. A tool set where you do most of the work but is more light weight

React
– Really just concerned with the V in MVC but is very efficient with its use of a virtual DOM to shadow the Real DOM. Can be used as the V in Backbone.

At this point I am still leaning toward Ember for a few reasons. First we do a fair amount of Rails already and Ember is conceptually very similar to Rails. Additionally, an opinionated framework can be really helpful in a team setting where some of the team is new to the framework as it almost enforces good practice.

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 Read more

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