Last week I participated in a Workshop on Mobile Software Engineering as part of the MobiCASE conference.  I had agreed to be an organizer last summer upon the request Martin Griss.  I was intrigued by the topic, but didn’t have a clear vision of what might come of the workshop.  I applaud Martin’s facilitating an engaging discussion.

What is different about mobile? and what does it mean for software engineering in general and education specifically?

I appreciated Tony Wasserman proposing his list of what was unique to mobile. After a lively discussion, there seemed agreement that mobile had just a few unique aspects, but the rest were significant due to the degree of constraint or opportunity offered by mobile platforms.  Aspects below are quoted from the Wasserman paper which summarizes results from his survey of mobile developers, with additional comments from me and the addition of privacy, personal and “always on” which were raised at the workshop.

Unique aspects:

• Real World Interaction. “Sensor handling – most modern mobile devices, e.g., “smartphones”, include an accelerometer that responds to device movement, a touch screen that responds to numerous gestures, along with real and/or virtual keyboards, a global positioning system, a microphone usable by applications other than voice calls, one or more cameras, and multiple networking protocols.”
• Always On. One participant remarked “I’m interacting with my phone right now” — with the device out of sight, tucked away in his pocket, he noted that the vibrate option and connectedness of the phone were a key part of the interface which provide phones with unique capabilities.
• Personal. Mobile devices are true personal computers.  People rarely, if ever, share mobile phones.  Unlike so-called personal computers which may sit in a living room, lab or café to be used by various individuals, the cell phone is typically tied to an individual who has a phone number, contacts and other very personal, private information stored on their device. The device can also act as an agent, taking messages or notifying the individual upon significant events, such as a phone call or that crops are ready to be harvested in an online game.

Significant Aspects:

• User interface.  Tony contrasts “that with a custom-built embedded application, the developer can control all aspects of the user experience, but a mobile application must share common elements of the user interface with other applications and must adhere to externally developed user interface guidelines.” However, this is is a similar constraint to desktop applications.  I believe that the small form factor combined with very high resolution screens that we see in today’s devices actually presents opportunity for innovation around visualization and task-oriented user experiences.
• Privacy. The constraints and abilities differ a little between mobile platforms in terms of access to information; however, the models are starkly different from the allow-everything model of the desktop and rigidly sandboxed web applications.  Mobile applications, like web applications, have free access to the network but can contact any host and exchange any information with no requirement for user notification.  Access to certain sensors like geolocation and private data like contacts do typically require approval, but once given we have no additional control and must simply trust the application to do the right thing.  There are not yet clear guidelines around what is and is not appropriate in terms of data collection and tracking.  There is also room for user interface innovation of how we might let people know what information is shared and what is private.
• Complexity of testing. “while native applications can be tested in a traditional manner or via a PC-based emulator, mobile web applications are particularly challenging to test. Not only do they have many of the same issues found in testing web applications, but they have the added issues associated with transmission through gateways and the telephone network.”
• Power consumption. “many aspects of an application affect its use of the device’s power and thus the battery life of the device. Dedicated devices can be optimized for maximum battery life, but mobile applications may inadvertently make extensive use of battery-draining resources.”  A workshop participant noted that with the popularity of laptops, some desktop applications and certainly desktop operating systems have started to take into this into account in software design; however, this is clearly a more significant factor influencing mobile application design.
• Interaction with other applications “most embedded devices only have factory-installed software, but mobile devices may have numerous applications from varied sources, with the possibility of interactions among them;” however, desktop and web applications more routinely interact.
• Native and hybrid (mobile web) applications “most embedded devices use only software installed directly on the device, but mobile devices often include applications that invoke services over the telephone network or the Internet via a web browser and affect data and displays on the device.”  We saw this in hybrid CD-ROMs and many desktop applications today; however, the prevalence of connectedness and web integration in mobile applications is unrivaled.
• Families of hardware and software platforms. “most embedded devices execute code that is custom-built for the properties of that device, but mobile devices may have to support applications that were written for all of the varied devices supporting the operating system, and also for different versions of the operating system. An Android developer, for example, must decide whether to build a single application or multiple versions to run on the broad range of Android devices and operating system releases.”  While analogous to variety of desktop hardware and software platforms, the diversity of mobile devices and operating systems is much more significant.
• Security. “most embedded devices are ‘closed,’ in the sense that there is no straightforward way to attack the embedded software and affect its operation, but mobile platforms are open, allowing the installation of new ‘malware’ applications that can affect the overall operation of the device, including the surreptitious transmission of local data by such an application.”

So, mobile is different, but what does that mean for software engineering?

I enjoyed Martin’s analogy to the advent of object-oriented software development which was necessitated by the complexities of applications with a graphic user interface.  The preceding work in command line programs just did not need that level of abstraction; however, once invented, object-oriented programming patterns are effectively used for every type of programming challenge. Perhaps the constraints of mobile development will offer similar innovation.  I think we are seeing a glimpse of that with web development patterns being applied to mobile user interface development with native mobile apps using HTML, CSS and the web pattern of model-view-controllers with screens addressed by internal URLs.  I wonder if there are other emerging patterns as well.

At the end of the workshop, I voiced the opinion that while the conversation was interesting, there was no urgent question raised.  Upon reflection, I have changed my mind.  There is an urgent need for research into how to take advantage of emergent capabilities which will not be mainstream for many years.  While industry implements obvious ideas taking advantage of now prevalent infrastructure and popular devices, many challenges and opportunities are ignored.  Just as Doug Engelbart’s Augment system and Ivan Sutherland’s Sketchpad leveraged what was then enormous compute power to lay the foundation for what became ubiquitous patterns in modern desktop GUI, there is an opportunity for universities and research labs to create applications and patterns of user experience and software component design that could revolutionize how people use mobile devices in ten or twenty years.