Around 8 months ago I was asked to start thinking about the now emerging (particularly from a Flash Platform perspective) world of multi-screen application development. What are issues to consider? What guidance should we offer?
It turns out that my thinking on that topic isn’t going to become anything in the Adobe documentation. So I’ve sort of just been sitting on my ideas with the idea that someday I’ll probably share them.
Which brings me to this post.
Aside: upcoming presentations on multi-screen development
This is really a side note to the main ideas here, but I thought I’d mention it since it’s the reason I actually stopped to write this. In one of my mind-wandering moments this morning, I realized that at the upcoming 360|Flex conference (San Jose, March 7-10) I’ll be involved in two presentations that are directly related to practical aspects of building multi-screen apps:
As part of the pre-conference free training, Joel Hooks and I are doing a four-hour training on using the Robotlegs micro-architecture. (Joel is the main speaker, fortunately, because he’s one of the core Robotlegs developers and the main “evangelist.” I’ll be helping out, to try and help save his voice and maybe to help find typos. =)
If you’re wondering what a Robotlegs session has to do with multi-screen apps…keep reading, it’s explained below.
- On Tuesday and Wednesday, Renaun Erickson and I are giving (two separate) presentations about building iPhone apps using Flash Platform tools. My session is more of an intro into the workflow, how it’s similar to other app building, and how it’s different. (Plenty of code to look at – don’t worry!) Renaun is going to get more into specifics of building a game, as well as some more intermediate/advanced topics like performance.
Funny that I never really made that connection until this morning. I guess subconsciously I knew this is a direction I want to move in, and that’s why I’ve been focusing my learning (and hence my presenting) on these topics =)
Background
While I was partially trying to keep my thinking abstract, from a practical perspective I centered my thoughts around developing using the Flash Platform. So conceptually, what I was thinking about was the idea of making a single “app” for multiple screens, which would mean that (in the technology of the next year or so) it could be potentially take several forms:
- a browser/computer app (Flash Player)
- a browser/mobile app (Flash Player)
- a desktop app (AIR)
- a mobile (iPhone) app (Publisher for iPhone, similar to AIR)
- a mobile app for other devices (AIR)
- a TV app or widget (Flash for the digital home)
(Obviously many of these are only out in public beta, some have only been vaguely publicly acknowledged, and others may or may not ever exist as actual Adobe products =)
One app, or many?
Back when I started thinking about this, there seemed to be two main camps. One group was a strong advocate for the “single source” idea: you would build one SWF or one AIR app and distribute that same app on any platforms (desktop/mobile/TV). Obviously a key element to that, especially for desktop/mobile apps rather than browser apps, would be having code that detects screen size and device capabilities and adapts the UI to the device.
The second group felt that it was more likely that developers who are creating an app for multiple screens would actually create multiple apps (from the perspective of the IDE). The apps would obviously share some code, visual assets, etc., but would be different enough that they’d be created separately and distributed as separate file types. (In the case of apps created for the iPhone, of necessity this has to be true, at least in terms of the publishing part.)
Since I try to be pragmatic about things unless I have a really good reason, I favored the second viewpoint. However, I acknowledge that in some circumstances the first approach might be used. As always, I think that developers are going to use a mix of approaches.
For example, suppose I’m building an app and I want to create a version for desktop computers, a version for the iPhone, and a version for other mobile devices. Personally I see this not just as an issue of “porting” the app from one platform to another. I think that each device has its strengths, and more importantly, each device is used for different purposes and in different contexts. If I’m building an app for a device, I should definitely be taking that notion of context into account as I’m designing the app. That pretty much rules out the possibility of using the exact same app (UI and everything) for both computers and mobile devices, unless I want it to run as a widget-type app on the desktop.
Also see: Adobe Flash Platform contextual applications developer center
Adaptable code to the rescue
On the other hand, that doesn’t mean that developers will always create completely separate projects. For example, suppose I’m creating an app for iPhone, and another for another mobile device. Or perhaps I’m using the Publisher for iPhone to create an iPhone version of my app and an iPad version. If my app is a game where I can more freely discard the conventions of the platforms, perhaps the only platform difference I need to consider is the difference in screen dimensions and pixel density. In that case, it’s quite possible that I canuse the same source code and have it adapt to the different screen sizes.
Frameworks to the rescue
Even for a more line-of-business or productivity app, one of the key ideas in Slider, the future Flex mobile framework, is to (as much as possible) abstract away platform convention differences. For example, if iPhone usually puts the back button on the top, and another platform puts it on the bottom, and another platform puts it in a menu, and another platform has it assigned to a physical button on the device, then Slider might have a “back” event that you can hook into, and you can make your app perform the necessary “back” tasks regardless of platform.
Design patterns to the rescue
And, of course, in some situations you’ll almost surely need to create different versions of apps for different screens. For example, suppose you’re building a desktop Twitter client and a mobile Twitter client. Chances are good you’ll put some functionality into the desktop version that doesn’t go into the mobile one – such as previewing images, or maybe Facebook integration. On the other hand, adding a feature like automatic location tagging would make lots of sense in the mobile version, but not so much in the desktop one.
As I was thinking, many months ago, about the idea of efficiently creating different versions of the same app for different devices, a thought hit me like a ton of bricks. This is exactly the use case that the oft-mentioned “separation of concerns” is designed for:
Over several years, various “micro architectures” and “application frameworks” have emerged and waxed and waned in popularity. Many of these architectures are modeled around the ”Model-View-Controller” design pattern (or its many variations).
One of the key benefits that these architectures claim is that it helps you keep the pieces of your application separate, without explicit links and dependencies between them. I’ve looked into and even tried out several of these over the years. One example that is frequently used to describe the notion of separation of concerns, which I always struggled with, goes something like this:
Suppose you’re creating an app, and you build the user interface and the other logic like server communication and data processing. If you use MVC/separation of concerns, then it’s really easy to just rip out your whole user interface layer and replace it with a new one.
They usually lost me with that one. As much as I tried, I couldn’t imagine a situation in which I’d want to build my app and then just rip out the UI and replace it with a different one note 1.
Until now.
Suddenly I had discovered, for myself at least, a real-world use case for the separation-of-concerns-so-you-can-swap-out-the-UI argument. If I’m building an app for the desktop and mobile, I’d like to be able to reuse my code where I can. At the same time, some functionality is only going to apply to one app or the other, so it’d be nice to be able to plug it in cleanly. Oh and by the way, the user interfaces are going to be different, so being able to swap those out is an absolute must.
I’d always liked micro-architectures in general, if only because I like knowing that I’m building my app using some pattern or structure that is based on developers’ real-world experience. It’s much nicer than trying to invent it myself and having to deal with all the pain points they’ve already gotten over. Now that I am imagining a world where I create multiple versions of the same app, with similar functionality but different user interfaces, suddenly micro-architecture patterns have become indispensable in my mind.
Conclusion
These are only just a few of my thoughts about the future world of multi-screen, contextual applications. Like Lee Brimelow, I believe that going forward building multi-screen, multi-context apps is going to be a much more common scenario. From my perspective as someone who thinks a lot about user experience design, and trying to optimize tools for the task and context, I think this is one of the most exciting aspects of the current technology revolution. I’ll definitely continue to share my thoughts and ideas in the future (hopefully more practical ones, too, not just abstract ones like this =)
Notes
Note 1: Just to be clear, I’m not trying to sound negative about MVC or micro-architectures/frameworks. Most of them provide many benefits, many of which are also related to the idea of separation of concerns, such as making code easier to test, making code cleaner, reducing boilerplate code, providing structure so that teams or developers who inherit a project can get going more quickly, etc. Swapping out the view layer is just one little benefit they mention. (back)