Ezo

Specialising in Mobile Hacking & drinking Aeropresses - Sharing Tips Along the Way

Can you easily deploy your Cordova/PhoneGap apps?

99 problems

Houston, we have a problem! It’s failing, our app is constantly breaking UAT - but nothing has changed. Apart from we now build from JS and generate our iOS platform project on the fly. Could that be it? Why would that be it???

Damn Cordova, we should’ve just gone native. At least we could’ve relied on more solid documentation!!

After a day of frustration and digging it turns out the culprit is our base SDK set up. Previously, we were configured to run on iOS7+. This gave us the latest and greatest from Safari. Bizarrely, we’re now on a base of iOS5+.

Wat! and with dynamic builds how in the name of Steve Jobs can we make sure we’re always configured correctly!

The leaky abstraction

This scenario happens all the time. With Cordova and PhoneGap apps your constantly tweaking something or other in the underlying native platform. Its a very leaky abstraction. Some settings you actually understand while others are pure copy and paste. No idea why they’re there.

The problem quadruples when you start adding more native platforms. Each one is evolving allowing for newer config/functionality and deprecating older setups. Not to mention the ever so important issue of testing on an actual device.

There are no hybrid bullets

You just have to understand what you’re building for. Yes, in hybrid land you’re mostly drinking the Html5/JS Kool Aid but at some point you have to get down and dirty with iOS/Android/Blackberry etc…

It really isn’t that hard especially with a few fundamentals to get us going. Also, the new Cordova CLI has some awesome tooling to help!

A book of recipes for iOS & Android

Since a book doesn’t yet exist, I’ve decided to bite the proverbial bullet and write it. A simple guide with recipes to help Cordova/PhoneGap devs around topics like,

  • Provisioning
  • Project set up
  • Device testing
  • Automated builds/deployments/CI
  • How to deploy to an app store

In the first iteration my main focus will be iOS and Android but I might look to add recipes for more native platforms in the future.

Sign up here

That is, if you want to get better at understanding your app’s setup, its provisioning, building/deploying as a team and what to automate.

No spam ever just book announcements, general deployment tips and sneak peeks.

How can I test my responsive (hybrid) mobile app - Part 3

In this series I’ll be uncovering the various techniques and tools that can help you get started to manually test a mobile web or hybrid app. Manual testing is a great way for verifying layouts and basic functionality. Automated tests afford us more verification but require a different set of tools and deeper understanding that’s not part of this series.

In part 1, we tested with online and browser plug-ins to capture bugs.

In part 2, we focused on emulators and mobile web apps.

Part 3, we shift our focus to hybrid mobile apps covering,

  • Setting up a Cordova based app.
  • Testing with a local iOS simulator.
  • Testing with a local iOS simulator minus Xcode.
  • Testing with a local Android emulator minus Eclipse.
  • Workarounds for testing with cloud based emulators.

This post is great for anyone looking to get a flavour of how to test an app in a hybrid environment or if you’re a newbie hybrider who wants to expand their testing knowledge.

What is a hybrid app?

In essence, its a web app that can access special device features if it needs to in an agnostic manner. It’s installed directly from an app store. This gives it the power to be cross platform by default.

Aforementioned device features may include filesystem or camera access. Increasingly, HTML5 is closing the gap but as new mobile operating systems are constantly being released there’s always some catching up to do.

Tools such as Cordova/PhoneGap, Trigger.IO & Sencha Touch make this easy. In this post I’ll be working exclusively with Cordova version 3.3.0.

If you’re new to using Cordova I’ll help you setup and get started as getting Android up and running is slightly a bit involved. If you’re familiar with Cordova you can skip the setup and get straight to the testing!

Up and running

I’m still using Up App for this. We need to install the Cordova CLI toolkit while ensuring both iOS and Android build dependencies are configured correctly.

Again, I’m running  this on a Mac OSX machine with Xcode installed. You can follow instructions from part 2 on installing the iOS simulator to help. Provided we’re ready to go let’s get started.

Install Node.js

  • Open Terminal.
  • Run this command: brew -v
  • If you can’t see something similar to: Homebrew [version no.] then install it.
  • Run this command to install brew: ruby -e “$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)”
  • Run this command to install Node.js: brew install node

Configure Android

If you haven’t already, follow the steps from part 2 to get Android with Genymotion setup. Then,

  • Navigate to the (android-sdk-macosx) folder.
  • In the tools folder right click the android Unix executable file and select open.
  • The Android SDK Manager should appear.
  • Select the Android 4.4 SDK Components (it powers the cordova build command)
  • Click install packages.
  • Follow the Mac OSX instructions to ensure Cordova can execute Android commands.
  • Open Terminal.
  • Run this command to install Ant: brew install ant

Install Cordova

Finally, we’re ready for Cordova,

  • Open Terminal unless its already open.
  • Run this command to install Cordova: npm install -g cordova
  • You can create a new cordova project using these instructions

For Up App, here’s what I did (on the same Terminal window),

  • I navigated to my Documents directory then typed these commands
  • cordova create UpAppHybrid com.ezosaleh.UpAppHybrid UpAppHybrid
  • cd UpAppHybrid
  • cordova platform add ios
  • cordova platform add android

This gets a very basic shell app configured with both iOS & Android build capabilities.

To truely get up and running you need to setup your own web app within the Cordova project. Have a look at this for a basic demo. Further getting started notes are found here for iOS & Android.

Build & run the local iOS simulator

This is where we arrive at the meat of this post. Traditionally, you can interact with a Cordova project using Xcode directly,

  • Open Terminal unless its already open.
  • Ensure you’re in the project’s directory, eg: cd path/to/UpAppHybrid.
  • Run this command: cordova prepare ios
  • Run this command: open .
  • Using Finder open platforms/ios
  • Double click on the file with an extension of .xcodeproj, eg: UpAppHybrid.xcodeproj
  • Follow these instructions to deploy to the simulator.

Build and run sans Xcode

If you’re a command line junkie, Cordova has a mature toolbelt that allows us to stop the constant dance of opening and closing Xcode. This is the last time we install anything I promise,

  • Open Terminal unless its already open.
  • Run this command: brew install ios-sim

Now navigate back to your project directory,

  • Run this command: cordova build ios
  • Run this command: cordova emulate ios

This will bring up the emulator and load the app for you all in a oner. No Xcode in sight!

Build & run the local Android emulator sans Eclipse

So, here’s a twist. Most posts out there will urge you to install the Eclipse IDE to be able to run emulators locally. This is a bit of hassle considering that unlike Xcode, which provides us with build tools, running Eclipse is a bit of a personal preference. Hence, we don’t really need it.

Luckily, we can utilise our Android setup from part 2 using Genymotion quite easily,

  • Open Terminal unless its already open.
  • Ensure you’re in the project’s directory, eg: cd path/to/UpAppHybrid.
  • Run this command: cordova prepare android
  • Start Genymotion and play your device - mine is Nexus 4 running Kitkat.
  • Wait for the emulator to load.
  • Go back to your Terminal.
  • Run this command: cordova run android

Android adb recognises the Genymotion VM as a physical device. That’s why the last instruction works.

Genymotion with Nexus 4 running Kitkat

image

Hybrid apps and cloud testing

I’ve saved this for last as you need a bit of imagination to get this up and running.

Cloud based testing is great because it removes the need to install numerous emulator environments on you’re machine - its all taken care of by someone else. This is ideal for Android as the explosion of devices, OS versions and screen sizes is mind boggling.

iOS is different, for now there’s only a handful of devices and OSes to test on. So, if push came to shove you can use Xcode to install more simulators.

Mobile web apps, unlike hybrid apps, are simple to test. You point to a web url from a cloud hosted emulator and get going. Hybrid apps are more complex because you’re essentially installing an application on an emulator. I haven’t found any services that allow you to perform this manually. Any services that do are primarily powered by automated testing using tools such as Appium.

For the next section I’ll be concentrating on Android as its more open. I’m ignoring iOS, because of the reasons I mentioned earlier as well as constraints imposed by app signing requirements.

So, how do we get this cloud thing going? Luckily, I found a couple of workarounds - feel free to get in touch with more :)

Cordova serve

The simplest route. It utilises the fact that you can serve your cordova app just like a normal web app locally from your machine.

However, there is a huge catch: this approach is useless if you’re using any native extensions!

If you’re not,

  • Open Terminal unless its already open.
  • Ensure you’re in the project’s directory, eg: cd path/to/UpAppHybrid.
  • Run this command: cordova serve 3000
  • Open a web browser and point the URL to: http://localhost:3000

image

We can now use a service like BrowserStack and point it to our local running web app the same way you would do with any web app.

image

Let’s do a quick run using BrowserStack running on Chrome. BrowserStack will detect Chrome and install a proxying plugin to simplify config,

  • Open Chrome.
  • Sign in to BrowserStack
  • On the main dashboard select ‘Test an internal URL’ tab.
  • Configure host: localhost
  • Configure port: 3000
  • Click finish

For me, this started the app on an Android Google Nexus 7. I then clicked on Android from the platforms list which then navigates to the Android version of the app served locally from my machine!

image

Note: A few alerts pop up when selecting Android from the platforms list, just click cancel and you’ll be fine.

Self hosting Android apps

Unlike iOS, Android allows developers to install apps from anywhere on any device. That is, we can point a web browser to a url hosting the app archive which will both download and install the app on a cloud based emulator.

Dropbox to the rescue! Let’s add our .apk file to Dropbox and ensure we obtain a publicly shareable link for it. The same can be done with any cloud based storage service. But first, let’s locate the app’s .apk file,

  • Open Terminal unless its already open.
  • Ensure you’re in the project’s directory, eg: cd path/to/UpAppHybrid.
  • Run this command: open .
  • Using Finder open platforms/android/bin
  • You should find a file ending with *-debug.apk - in my case its UpAppHybrid-debug.apk.
  • Add the file to your Dropbox folder and ensure that its publicly accessible.

Now we can run the cloud emulator and install the app.

  • Sign in to BrowserStack
  • On the main dashboard select an Android VM combination.
  • Start testing without a URL.
  • Point the web browser to the *-debug.apk shareable link from Dropbox.

This will download the app and ask if you want to install it. After installation the app should be open on the emulator for you test. You can do the same on various cloud based emulators combinations to replicate a multitude of environments.

The end

We made it! We’ve reached the end of the manual testing series. You can now test a mobile app whether online or hybrid using a plethora of techniques. From browser plugins to cloud and command line wizardry including an understanding of the ways of the hybrid mobile app.

Use this power for good and enjoy ;-)

P.S. Learn faster about mobile development directly from your inbox!

Links:

Beyond the basics with my first Aeropress

image
home setup (Aeropress, scales, thermometer & cheap grinder)

I love coffee, a lot. Luckily, I live in London town where the current crop of brilliant cafe’s and roasters has left me spoilt for choice. I’ve sampled the basics from the likes of Monmouth all the way to the ultra refined from Prufrock, Dunne Frankowski and Ozone to name a few.

I’ve nurtured a taste for the humble filter coffee. Actually, humble is a major understatement as the flavours are as complex as vintage wine. Brewing a filter is a delicate business something that a Hario V60, Kalita Wave and the awesome Chemex do really well. Not to mention the clean finish that you get from Siphon brews.

Aeropressed

However, when it comes to taste the only device that has genuinely captured my imagination is the clever, simple and durable Aeropress!

I have been procrastinating about buying one for well over a year now. Last Friday (8th of Nov 2013), it finally arrived. 10 mins later I was off making my first brew.

This started with a quick google, leading to The Brew Methods site, then viewing a ‘how to’ Video from Verve Coffee Roasters. I’m sad to report that the first brew just didn’t make it. Yes, I was still familiarising myself with the equipment but I’ve tasted what’s possible and had brilliant beans that could deliver way more on flavour.

Moar tips

I needed to practice and I needed tips that went above the basics of how to operate an Aeropress. After a bit of research I found the World Aeropress Championships site. A brilliant find indeed. This is a competition that’s been running for a few years now. The site contains great interviews and brewing recipes from previous winners.

Armed with this knowledge, my trusty scales, a thermometer and a recipe from Jeff Verellen I started testing and tasting.

Everthing changed,

  • I can now taste what I smell before brewing or grinding the coffee.
  • The process is simple yet highly concise.
  • A thermometer is mandatory - water temperature has a huge impact on which solubles are extracted.
  • A timer is a must.
  • Blooming the grounds for a small amount of time before pouring all the water really matters.

I have to master a lot but one thing I didn’t appreciate was how hard it is push down an Aeropress in 30 seconds - I average around 50 - 60.

Go Kaizen

Jeff has a good tip on how to improve: go Kaizen and make 1 best method as a standard and 1 challenging method every day. Use the challenging method to experiment. If it proves to be better than the standard make the challenging method the standard and find a new challenging method.

I would add that for a beginner it probably makes more sense to practice one standard for a couple of weeks until you get comfortable with the brewing techniques. I personally will be practicing a handful of recipes for a few months before emabarking on my own experimentation.

I’ll be sharing everything I learn as I do so.

How can I test my responsive mobile app - Part 2

The manual testing series

In this series I’ll be uncovering the various techniques and tools that can help you get started to manually test a mobile web or hybrid app. Manual testing is a great way for verifying layouts and basic functionality. Automated tests afford us more verification but require a different set of tools and deeper understanding that’s not part of this series.

In part 1, we tested with online and browser plug-ins to capture bugs.

Part 2, delves into testing on emulators specifically for mobile web apps running from the web. We’ll cover,

  • Screenshot based tests.
  • Testing with cloud based emulators.
  • Testing with a local iOS based emulator aka simulator.
  • Testing with a local Android emulator

Embracing devices

The layout of a page is influenced by more than just the width settings assigned to a media query. Testing on an emulator or on a physical device can highlight hiccups caused by how a specific version of a mobile browser renders an element before applying a media query. When you stick to basic tests you can never be sure how your app will truly render and function. More often than not, it will definitely be broken.

Also, there’s a breed of mobile apps like Forecast.io that render different layouts by detecting whether a user is visiting from a mobile browser. For these, emulators or devices are the only testing solution.

Hybrid mobile apps add their own complication, some have device dependencies that stop us dead in our tracks when testing on a desktop browser.

Emulators versus physical devices

Emulators are great for sanity checks. They’re brilliant for quick feedback loops that can optimise your work-flow. Moreover, they give you access to a browser environment that is a one to one match with your target device. Bugs encountered here are not an approximation - these are real issues.

But, watch out! An emulator will mostly be running on either a server or a desktop machine. This gives it far more resources than you’ll ever get on the physical device. It allows emulators to be more forgiving. I have caught many a bugs on a physical device that were never obvious on emulator tests.

I want emulators

If you’re working on a mobile web app, you might not have any emulators set up at all. It all depends on your development environment and the resources available. But its easy to get set up. Although, your access might be restricted to a smaller range.

Cloud based testing sites offer a wider range of emulators. Its very quick to get going and legacy emulators will always be available - something very hard on a personal development machine.

Let’s start by looking at cloud based emulators and then plunge into running our own.

Emulators on the cloud

Some of the services include BrowserStack, Sauce Labs and Cross Browser Testing to name a few. They’re essentially the same, but provide different UI testing interfaces. My personal preference is BrowserStack but feel free to use any solution you (or your pocket) prefers.

Starting With Screen-shots

You can start things off quick and dirty. Just take a screen-shot of a single screen across all available devices.

BrowserStack offers this,

It can take a few seconds. BrowserStack loads Up App’s homepage on a super huge range of mobile browsers, all processing screenshots and then displaying them.

Since I haven’t fixed the issues from part 1, you can see these cropping up again with the iPad 3 on portrait mode.

But there are other peculiarities, the animated sun illustration is broken on all Android devices from the 2.1 Droid Razr (320x640) to the 4.1 Nexus 7 (603x966). The layout renders well while the illustration positioning is slightly off or in case of the Droid Razr the illustration is bigger than it needs to be.

2.1 Droid Razr (320x640)

image

4.1 Nexus 7 (603x966)

image

There’s great value in this exercise. Very quickly, we’ve realised bugs that were in no away apparent from simple plug-in or online testing.

In fact, here’s a screen-shot using the Droid Razr dimensions as rendered by the Viewport-Resizer browser plug-in. According to the plug-in, there are no issues whatsoever (but we know better).

image

Probing further with live testing

Now that we have a bug benchmark for faulty OS and screen sizes, we don’t have to waste our time testing things that already work. Instead, we can hone in on those problems that need fixing straight away.

Most cloud based testing tools have a live environment where you can select an emulator and use it just as if it was running on your machine. We know that we’re having some serious problems running on Android.

To start testing on BrowserStack you need to be signed up and logged in (there’s a trial subscription).

Then, navigate to the Live testing section.

  • Enter the URL of the page you’d like to test, I’m entering http://aishy.github.io/UpApp/
  • Select Android as the OS.
  • Select Google Nexus 7 as the device.
  • Click (or tap) the Start Testing button.

A few seconds go by while the environment is starting. Once complete, you’ll be connected to a server running a browser on a Google Nexus 7 emulator with your target URL loaded up.

Note: Your environment may never load if you’re browser does not have a recent version of the flash plugin installed - I found that the hard way.

image

Using the app, I can see the sun illustration dimensions are completely wrong. However, the layout is correct and the css3 animation works. This suggests that only a few simple css tweaks are necessary to support the Google Nexus 7 default browser for Android 4.1 - Yay!

Cloud emulator 4.1 Nexus 7 (603x966)

image

Browser, browser, browser

All this testing highlights that the peculiarities are browser centric. In the Android world there’s a high spread of browsers all supporting variations of CSS and the latest HTML5 capabilities. The Cross Browser Testing site has a good list of the different browser configurations for mobile devices. I particularly like their detailed listings for Android.

Coupling this knowledge with tools like Modernizr allow us to smooth out the discrepancies and build a unified set of instructions that can be applied to more browsers. Basically, less frustration, more fun and speedier development!

Running your own emulators

We’ll attack iOS and Android emulators separately. Each platform requires some software installation before you can start. Once you’re up and running you can use the same setup over and over again with no hassle!

Bear in mind that iOS emulators are only available for Mac OSX operating systems. This pretty much means that you have to be running on a Mac. Android is more widespread and you can run the emulator on multiple operating systems.

Local iOS emulators

To avoid confusion, I’ve been constantly talking about emulators but in iOS world they’re referred to as simulators. So, on a mac desktop if you’d like to access an iPhone simulator then you need to,

  • Ensure you have Xcode installed or install it - I’m using Xcode 5 installed from the App Store.
  • Launch Xcode.
  • Choose Xcode > Open Developer Tool > iOS Simulator.

This gives you access to the latest iOS7 simulator. You can also access older simulators which would simulate an older browser environment. Here are more details.

To test an app on Safari,

Here’s the Up App running on the iOS7 simulator on my machine.

image

Local Android emulators

For Android, the installation is slightly more cumbersome but definitely doable with speed improvements here. Also, a few vendors have popped up to help get you get up and running in no time.

I like Genymotion simulator. Although slightly long-winded because of the dependencies, it is simple to set-up and they have a free personal licence.

Genymotion relies on having a Virtual Box VM installed to run the different configurations for an Android Simulator. Its very similar to the emulator configurations seen on cloud based services.

Let’s install this first,

  • Download an installation for your OS from here.
  • Install Virtual Box on your machine.

You also need to ensure that you have Android SDK for your OS installed including the platform-tools directory. On Mac OSX,

  • Navigate to the Android downloads page.
  • Select Use an Existing IDE section.
  • Click Download the SDK tools for Mac.
  • After the SDK is downloaded, move the folder (android-sdk-macosx) to your home folder using Finder.
  • In the (android-sdk-macosx) folder, open the tools folder.
  • In the tools folder right click the android Unix executable file and select open.
  • The Android SDK Manager should appear.
  • Under the Tools listing, select the Android SDK Tools + Android SDK Platform-tools and Android SDK Build-tools.
  • Click Install … Packages.
  • Your done once you can now see a new folder called ‘platform-tools’ in the (android-sdk-macosx) folder.

To get Genymotion up and running,

  • Start using instructions here.
  • Run Genymotion and click on Settings.
  • In Settings, select the ADB tab and ensure that Path to Android SDK points to the (android-sdk-macosx) folder.
  • Add a device using instructions here - I added a Nexus 4 - 4.3 768x1280.
  • Play your device.

After the device is up and running,

  • Navigate to the Built in browser by clicking Browser icon on the homepage.
  • In the address field type the address of your app, in my case http://aishy.github.io/UpApp/

4.3 Nexus 4 768x1280

image

Finally

There you have it, all the emulator love we can handle!

Part 3 will showcase how to manually test hybrid mobile apps using both cloud services and local emulators mainly for the Cordova ecosystem.

P.S. Learn faster about mobile development directly from your inbox!

Links:

How can I test my responsive mobile app - Part 1

The manual testing series

In this series I’ll be uncovering the various techniques and tools that can help you get started to manually test a mobile web or hybrid app. Manual testing is a great way for verifying layouts and basic functionality. Automated tests afford us more verification but require a different set of tools and deeper understanding that’s not part of this series.

Part 1, starts with examining responsive design and the simplest tests that can help us ensure all is well. Specifically,

  • Testing online using viewport resizing sites.
  • Testing with viewport resizing browser plug-ins.

How responsive?

Media queries afford us the capability to adapt our layout using a variety of parameters. The most commonly used parameter is width, specifically playing around with width ranges. You see this in the wild a lot especially as implemented by a multitude of css frameworks like Skeleton, Foundation and Frameless. These are grid frameworks that can react to the different width ranges presented by browser viewports - a viewport is the viewable part of the screen configurable by setting the ‘viewport’ meta tag. Browsers can be running on anything from a desktop screen to the excitingly and drastically differently sized mobile screens!

Iterating with visual tests

So, the challenge becomes to create an efficient simple design that showcases and hides features that are relevant or irrelevant depending on how a user views a mobile app. This can be mitigated by how we approach features and layouts. That’s a great first step but the true panacea is to constantly test and re-iterate.

Testing can be varied, it depends on what it is that we’re building. Specifically, if our mobile app will always be run from the web ala Forecast.io or if it will be embedded in a hybrid mobile app with native extensions. In this series of articles, I’ll be showcasing some of the approaches I tend to use including online/plugin, emulator and device based testing explaining the nuances and the why of each.

To make it easy for you to follow along, I’ll be using the home screen of (1) Up App which is a simple but functional page. FYI Up App uses the Skeleton responsive grid.

So, for part 1 let’s dive in by utilising both a testing site and a browser plugin. This works best for apps running on the web.

Testing online

There are a variety of online sites and tools that use iFrames to mimic different viewports. All you have to do is enter a url and start testing. The Responsinator is such a tool. I like to start by picking a browser such as Safari as it represents a substantial number of potential mobile users. However, this just a basic approximation as I’m running on a MacBook so the versions will be different.

  1. Go to http://www.responsinator.com/
  2. Enter the url for your app, I’m entering http://aishy.github.io/UpApp/

After the screen loads you’ll see how your mobile app renders on different viewports ranging from the iPhone 3/4 to the Kindle.

For Up App, our initial test reveals that both the text and the animated sun illustration render well, but the illustration looks slightly blown up out of proportion on Landscape view ports.

image

I generally tend to find that Android device layouts are usually unpredictable. Here Up App is completely broken on the portrait viewport but works well on landscape.

image

image

Skeleton, our grid, doesn’t support widths lower than 300px for portrait viewports very well out of the box. This could be the root cause.

Using a plug-in

Similarly, there are plugins that allow you to navigate to the app on most browsers. Once the page renders, you can then start testing by manipulating the viewport.

Viewport Resizer fits that bill. Its a plugin that works cross browser by default. Just bookmark a link to the site on the browser of your choice and start testing. The results should be comparable to what we saw with our online tests.

Test Results

After testing, I make a note of the issues and usually re-iterate on the design and functionality.

For Up App it looks like I might need to,

  • Add custom media queries to resize the sun illustration specifically for landscape & tablet portrait viewports.
  • Augment the grid with media queries to support viewports smaller than 300 px.

You can keep using the aforementioned tools to refine and retest.

Part two, discusses more thorough testing techniques by using device emulators both on the cloud and your own machine.

P.S. Learn faster about mobile development directly from your inbox!

Links

(1) Up App is developed by Aisha Yusaf aka Pakora Butty and was used by her permission.

From Airwaves to Online Radio to Podcasting: What’s Next?

By laura musselman duffy

Photo By laura musselman duffy

At The Super Times, our mobile audio start up, we really believe in the power of the internet and the current podcast revolution. We’re audio story geeks and love how stories can transform thinking, illuminate minds and bring people together. From lectures, to interviews, documentaries, dramas and fiction there’s so much out there.

Internet Radio 1.0

I believe that the recent paradigm of subscribing to podcasts was internet radio 1.0. It actually hurts listener discovery and does not help many podcasters create more of what they love and maybe make a sustainable living. I think we’ve barely scratched the surface of what can be done online

A Brief History

Here’s a brief history of audio story telling. Back in the day, stories were broadcasted solely on Radio. Listeners tuned in to a scheduled broadcast where the quality was determined by the channel. Radio channels could only broadcast a finite number of programmes per year - so listeners actually missed some awesome programming that never saw the light of day due to bandwidth constraints. Stations included BBC Radio 3 and 4 in the UK, NPR in the US, CBC in Canada and even RTÉ Radio 1 in Ireland.

Today, we’re online. That’s infinite bandwidth. Not only can you hear stories from the same old broadcasters but a new breed of storytellers have emerged. They have an awesome ear, a freedom to follow their heart with cheap tools and razor sharp production skills that rival the old broadcasters. On the internet they can podcast: the shows can either be listened to as they are broadcasted online, but mostly downloaded for offline listening. Even traditional Newspapers like the Guardian and magazine publishers like Wired have got in on the action producing brilliant audio content at low costs. A new listenership is now addicted, downloading all they can and listening when they can.

But somehow they’re voices are getting lost. Bar a few, the same distribution network that empowers them holds them back. It’s not just a question of quality, I’m sure there are tons of crap shows out there but the opposite is equally true. There are tons of great quality shows and stories with almost no listenership. I guess you can equate this with the Self Publishing revolution that has been taking off in the pushlishing industry over the last few years.

Aggregators - They Suck 

A quick answer to this problem was the ubiquitous RSS Feed, after all its what podcasts were all about. As long as a show had a feed, any listener can point a podcast catcher at the feed and start downloading content directly to their desktop or mobile device. Podcast directories started popping up everywhere.

For a podcast producer you had to get your feeds in as many catalogues as possible. As a listener you had traverse these catalogues and figure out what to listen to. Even with charts, evaluating content became a tremendous chore. Listeners thirsty for content subscribed to popular shows and when they got bored they either gave up or started asking for recommendations to no avail.

This is the problem inherent in podcast aggregators. Listeners have to find and pull in content, otherwise the software is useless. These days, podcast aggregators bundle some form of catalogue becoming a sole source for finding and listening to content. If you succeed and subscribe to the right content, you are now in catch up hell. The efficiency becomes you’re worst nightmare, suddenly you have so much audio that you need to listen to that you’re simply overwhelmed!

Getting Found on Radio

Podcast aggregators, when and if they work are a great tool for listeners. However, podcast producers including popular ones still have to figure out how to make a living. A recent phenemonen has started happening. With the help of organisations like PRX, some podcasts like The Moth have crossed over to traditional radio.

Meaning, they get paid for every show that is broadcast with exposure to a new audience. This is really awesome, the rebels have taken over. But this is not a scalable solution. Radio bandwidth is finite, a small number of shows can only be aired at a certain time.

Although, for listeners the convenience works. They tune into a trusted channel and experience a new kind of programming. They can even download more of the same if they wish. A subdued win-win.

The Offline Internet Channel

Funnily, I think there’s a weird happy medium. Specialist channels that can broadcast high quality internet content. Bonus points if the content can be offlined and consumed whenever and whereever. This may include programmes from traditional brodacasters as they’re content is also found online.

Basically, we can harness the power of podcasts with the simplicity of traditional radio and its push model. This is nothing less than a revolution for a new listener landscape.

Even though the idea may sound grand, the implementation could be as simple as publishing a brilliant list of podcasts for recommended listening on a regular basis.

Twas an Accident

We stumbled onto this when building the 1st iteration of The Super Times. Back then we had a website called Said.fm (as in I said, you said), we thought there was a gap in the market for a Spotify of audio stories. Listeners would use the app to find content by mood or topic (we built expensive algorithms that categorised and linked programmes).

We then employed curators to pick small recommendation lists that can be easily offlined to help make the content accessible and give listeners a good starting point. The content in Said.fm was constantly montiored for quality and we had a niche.

To our great suprise, the only feature that really mattered were those recommendation lists. Simply, they were convenient and more than good enough. Listeners visited the site, found the latest recommendation and synced ignoring everything else!!

They trusted us and that was enough :)

Others, have also picked up on this. PRX has Public Radio Remix which is “programmed with the best work from the hundreds of independent producers and stations on PRX and beyond, featuring  great storytelling, edgy podcasts, cutting edge lectures, interviews and more.” - the content is nothing less than awesome.

New Tooling

To make this work, the current crop of podcast aggregators and catchers just don’t cut the mustard. Its not about alarm clocks and double speed listening. I just want interesting stuff at the click of a button. I may spend a small amount of time performing minor configuration but that’s it.

This is the new challenge - its about filtering, discovery and distribution. You could argue this is more than tooling and you’re probably right. I’m also talking about new channels that can harness the web for a specialist theme and perform the broadcasting. Whether the channel and consumption end point are one and the same could be debated.

In fact, this is what we’re truely striving for at The Super Times: a specialist channel for amazing thought provoking audio conversations delivered as podcasts for offline consumption. We control filtering, discovery and distribution.

We could branch out with more channels like the best tech talks or even the best sports programming. The more I think about it, the more I see the similarities with Apple’s Newsstand.

Possibly Getting Paid

Like Apple’s Newsstand, this creates a simple market place for podcast producers to get paid. With enough listeners, even if a programme is played once that producer could see a one off distribution to millions of listeners.

If those listeners are paid subscribers, the producer can receive a paycheck to see them complete at least a single series. With simple segmentation and a good UI, listeners can fine tune their listening making them great supporters for the content they love!

If you’re in the US, how would this change Public Radio and all that pledging? There’s a new generation of listeners that is becoming accustomed to internet level choice and they’re hungry for awesome audio - we need to help them out!

The End

In closing, I’m really excited about this: The possibility of creating a self sustaining and accelerating ecosystem that serves both listeners and producers with internet level bandwidth!

Now, let’s get on with it.

P.S. I’d be really happy to meet you on Twitter: here