May 15

I am spending part of this weekend preparing for a presentation I’m delivering this coming week for the Boston/New England Windows Phone User and Developer Groups. My upcoming presentation software development-focused and, as is usually the case, I will be using demonstrations of programming techniques to enforce the learning. After close to 20 years of developing this type of content for training and presentations in many different programming languages and technologies, I still face the same dilemma regarding the approach I take to the application code I present.

In an ideal world, a teacher strives to make learning content as relevant to the “real world” as possible as a way of reinforcing the the concepts being presented. When learning mathematics, for example, the reinforcement of an equation is often demonstrated by placing it in a real-world scenario (presenting the dimensions of a room and asking for the square and/or cubic feet the room occupies, for example). By putting concepts to use in real world situations more often than not helps in the grasping of the concept and increases comprehension for the learner. In the ideal world, a learning content developer would normally strive to place everything into a real world context. However, the “ideal world” brings with it some distinct challenges and drawbacks.

When developing learning content, the developer is often constrained by any number of factors, including (but not limited to) -

  • Time to deliver the material. We all would love to have unlimited time to learn, but time is simply not that available. As a result, the content creator is often constrained by how much time can be allocated to teach a concept. The more complex the real world example is, the more time it takes to teach.
  • The pre-existing knowledge of the learner. For “advanced” learning content, prerequisite knowledge is usually assumed. As a result, the information used to build the real world scenario is often easily understood by the learner and can be delivered in a shorter timeframe. For “introductory” learning content, however, real world scenarios often will take more time to build than the concept they are trying to teach.
  • Complexity of the real world scenario in relation to the concept being taught. I find this constraint to often be the most dangerous when building learning content for software development as its impact is felt in multiple dimensions (more on this shortly).

As a learning content developer, the challenge becomes finding a successful balance between providing real world applicability without causing a “tipping point” due to constraints that diminishes the overall goal – to teach a concept that is both comprehendible and retainable to the learner.

When developing learning content for software development, the time and knowledge constraints are usually obvious to me and are relatively easy to manage. I know how much time I have to deliver the material, so I therefore control the scope of how much I can teach in the time allotted. I generally know the baseline knowledge of learners receiving the material (at least when I set the goals for learning and prerequisite knowledge; we’ve all had people in a room who don’t meet the prerequisites). The complexity constraint is the one battle for the content developer that is most difficult to manage. The best explanation of this can be made by example.

Suppose I want to teach the concepts of data access to a new programmer. I could simply provide the minimal amount of application code to demonstrate this concept. However, one could argue that I am not being “real world enough”. So, how do I make for a more realistic example? I could (and often do) provide a context for accessing the data. Perhaps a simple application with a user interface that, when the user provides some input or action, retrieves data and displays it. While this may still seem rather simple, the additional number of lines of application code to make this happen can be in the tens (or even hundreds, depending on the programming language). Depending on the example and the pre-existing knowledge of the learner, the complexity of this additional code can become a distracter to the more important concept being taught. I liken it asking someone to extract a single fact out of a chapter in a textbook; while you can eventually find that nugget of information, you also run the risk of being distracted by all the other information that the chapter provides (as an aside, this is why I have never liked any teacher who “teaches from the textbook”).  As an example of how this issue of complexity can apply to teaching programming, consider the following two code examples. Both attempt to teach the concept of retrieving application settings from Isolated Storage in Silverlight for Windows Phone  7 -

Example 1

IsolatedStorageSettings mySettings = 
IsolatedStorageSettings.ApplicationSettings; txtName.Text = (string)mySettings["Name"];

 

Example 2

private void getSettings()
{
    IsolatedStorageSettings mySettings = 
IsolatedStorageSettings.ApplicationSettings; if (mySettings.Contains("Name")) { txtName.Text = (string)mySettings["Name"]; } if (mySettings.Contains("Address")) { txtAddress.Text = (string)mySettings["Address"]; } if (mySettings.Contains("Zip")) { txtZip.Text = (string)mySettings["Zip"]; } }

The first example is quite literally the most basic of programming code demonstrating the steps of getting an instance of of the application’s settings and extracting a single piece of information from those settings. Useful syntax, but not a lot of real world context. The second example does the same, but comes from a very simple application that includes a user interface with three fields. The application logic also does a bit of checking to see if the setting even exists before exacting the setting for each field. Just this little bit of adding real world context has added complexity to the code sample. Note that I could have gone even more “real world” in the coding techniques used for error handling and “best practice” that would would have resulted in more distraction (questions like “why are you using a ‘using’ statement?” or “What is this generic collection syntax really about?”). In even the most simplistic of examples like the ones shown here, it becomes clear that “real world” leads to “complexity” in code, and complexity in code runs the risk of reducing the ability to comprehend and retain the primary learning objective; in this case, how to retrieve a setting from the application’s isolated store. As a content developer, this is an example of having to deal with one type of complexity – code complexity. However, this complexity runs the risk of being made exponentially more difficult to manage if another real world concept is introduced.

I have had both the fortune and misfortune to work on a number of projects over the years that attempt to create a “reference application” for learning. In these situations, the goal is well-intentioned. An application is created that is real world in nature and provides by code example the best practices for achieving the required business goals of the application. I have always liked the idea of a reference application, but only when used in a proper context for learning. Unfortunately, reference applications are misused.

In almost all of the cases where I have been involved in developing a reference application, a design goal is being able to repurpose the application code to teach every learning concept, regardless of context of the learning objective or knowledge of the learner. Translation – make the reference application code apply even to introductory learning objectives. This goal invariably fails miserably for introductory training for two reasons. The first reason is one I have already introduced in terms of code complexity. When a code sample from a reference application is used to teach a basic concept, there is typically an incredible amount of “distracting” code associated with it. As a result, the learner is either trying to wade through a lot of potentially unfamiliar application code to find the relevant learning material, or is being confused by code that they have yet to learn about. Even if an instructor or material can help to point the learner in the right direction, the collateral code can often lead to confusion or a desire to understand that which is not intended to be learned about at the moment. As an instructor, I cannot tell you how many times I have had students “wander from the path” when it comes to these situations, resulting in difficulty in learning the current learning objective and spending value time discussing/covering information not intending to be covered. If this level of complexity is not difficult enough to overcome, reference applications usually introduce a higher level of distraction for learning – the business process learning complexity.

Imagine that I were to hand to you a text book written in your native language. This book covered a business concept of which you had no prior knowledge or exposure (for arguments sake, let’s say quantum physics). Within this book lies a specific bit of knowledge I want you to learn. While you can read the words in the book, many of those words, sentences and paragraphs will relate to concepts totally foreign to you, and will require you to learn them in order to learn the true objective. In other words, I need you to learn about other secondary knowledge prior to learning the primary objective. This is the additional complexity that using a reference application often adds to learning about programming.

Because reference applications are designed to present application code in a real world context, they are fundamentally designed to solve a business (not technical) problem. They often take the form of solutions around order entry systems or customer relationship management. When I have been asked to teach from a reference application, many of the learners in my audience usually have no business experience in these areas. Even if I am teaching experienced application developers, I often find myself explaining the business rationale that makes up the code rather than the primary learning objective. For example, I cannot recall how many times I have found myself explaining in a programming class why an order entry system does not actually delete cancelled orders, instead marking them as “deleted” in a field in a record. This discussion did not come about because I was teaching order entry concepts; it occurred when I was teaching how to update a record in a database (the primary learning objective). Business learning, therefore, becomes a distracter to the true learning objective.

Reference applications do have a place in the bigger picture of education for application programmers. However, it is in the context of the first word of their definition – reference. I find reference applications to be most useful in the same way as other reference materials; when they are used after primary learning is achieved and the learner wants to learn more. Most importantly, reference applications are most useful when the learner is not constrained by time or business complexities that exist in a classroom or introductory learning. Reference applications are most useful in advanced and self-paced learning scenarios.

If you’ve managed to get this far in your reading, you’re likely wondering what the proverbial “moral to the story” is here. As I mentioned at the onset, I am once again tasked with the development of learning content for software developers. Over twenty years of developing and delivering content of this type, for structured multi-day classroom learning to 90-minute presentations, has taught me a very valuable lesson – there is a difference when presenting application code for learning purposes in comparison to developing actual applications. When I “code to teach”, I have one goal in mind – to present the code in a way that makes my audience understand and retain a learning objective. Anything that distracts from this objective does nothing to serve the audience. While getting more “real world” might help in achieving a learning objective, it can hurt it as well. It is also often very easy for the content creator to leverage existing application code to teach, be it from a formal reference application or even code “just lying around”. When you use code of this type, however, you should carefully consider the implications. Put yourself in the shoes of your intended audience and ask -

  • “What am I trying to learn here?”
  • “When I look at this code, do I see what it is I am trying to learn?”
  • “How much help do I need to find the relevant code?”
  • “Does looking at the code make me think of questions not related to what I am trying to learn?”

Only by finding a balance between learning objectives and the real world they reflect will your code help your audience to become good programmers.

Mar 12

Last week, I wrote a bit about how HMTL 5.0 holds some promise for some mobile application developers. A critical part of the HTML 5.0 specification relates to it’s ability to work offline when an Internet connection isn’t available. Recently, I’m seeing more and more marketing aimed at cloud computing. When combined with 3G and 4G networks, it appears that the message often being portrayed is that new technologies have become a sort of “magic bullet” for all mobile applications. With that in mind, I felt a little “refresher” on the foundation of many mobile applications is in order.

I remember attending a keynote speech at a Pocket PC Summit event in Philadelphia (which should date how long ago it was; I can’t even remember the year off the top of my head) given by John Landry, whose focus at the time was on Adesso Systems, a company who (again at the time) had a multi-device development platform that was ahead of its time. Mr. Landry talked about mobile devices and application development in his keynote, and talked about what he considered an oxymoron - “ubiquitous wireless access”. The point made in the keynote was that no such thing exists. No one can guarantee with 100% certainty that, when you need it, you will have access to the Internet from any computing device. That oxymoron, along with a term Landry used to describe a paradigm for building applications that can meet user needs while withstanding a lack of network connectivity - “Occasionally-Connected Computing” – have stuck with me ever since.

Let’s turn to the present day. We’ve seen great advances in technology with regards to networking. When John Landry gave his keynote, GPRS speeds of 40-50 kbps were considered “fast”. You were lucky to have a cellular data connection at all when you were indoors, and even being outdoors was a bit dicey. Today, we have multi-megabit transmissions speeds and far greater coverage, but ask yourself a simple question – can you remember a recent time when you either couldn’t place a phone call or connect to the Internet on your device when you wanted to? For most people, they will likely answer with the date, time and specific problem ;-) My point here – things are better but not perfect when it comes to wireless data networks. It is this fact that still makes the premise of occasionally connected computing as relevant today as it was almost a decade ago.

When developing mobile applications, the common goal is to allow users to complete a task or tasks in an effective manner. This basic principle of course applies to software in general. When network access plays a part in completing the task, the goal has to account in some way for what happens when that access is not available. This has been the primary constraining factor for most mission-critical mobile web applications; no network access means no application access. HTML 5.0’s inclusion of offline data storage of potentially large and complex data makes mobile web-based applications a far more viable option. Aside from that fact, though, the more important application principle is designing an occasionally-connected application for mobile devices that is data-dependent requires the ability to efficiently store essential data on the device for non-connected periods, allowing the user to still perform some aspect of the task at hand until the network is again available.

How much work is required to design and develop a good occasionally-connected application is of course contingent specific requirements. A sales force automation application may, for example, require the offline storage of data in order to meet business requirements than a simple contact application. Nonetheless, there is usually the need at either a business or user expectation level that some form of functionality be present in order to at least partially complete the task when offline. In the sales force automation example, it may include the ability to look up customer and product information, and to place an order on the device that is transmitted to the home office once connectivity is attained. For my many years in developing mobile applications for both the desktop (laptop/notebook) and phones, these types of requirements are the norm (if not always the case). New technologies, including faster and better cellular networks and cloud computing have not changes this need one bit.

I guess that the moral of this story that I am trying to convey here is that while advances in technology are opening up a world of new possibilities for mobile applications, fundamental principles still apply. When messages such as “cloud computing is the answer” and “access everywhere” are spreading like wildfire, it’s important to keep them in context. I really believe that cloud computing and better cellular networks are incredible enablers; they are, more often than not, a partial solution to mobile application needs and not the solution itself. When deciding upon the development  platforms and technologies for mobile solutions, the true needs of the application must be factored in. If the solution requires resilience to the still-prevalent issue of occasional connectivity, an extra look at how those platforms can meet your requirements is essential. The answer “just store it in the cloud” is not the answer. The answer “you’ll always have access to the Internet” is not the answer. The answer “I need to consider how my application will function until i have access to the cloud” is the answer (or at least the starting point). The principles behind occasionally-connected computing complete the answer.    

Mar 05

Microsoft’s recent announcements around Windows Phone 7 Series and first details regarding application development for the platform have made me take pause to think about those of us out in the world of mobile device application development. More specifically, I’ve been thinking about things from the perspective of a developer who supports mobile device platforms in general, not just one in particular. I know I am anything but alone in this situation. An increasing number of independent developers and commercial development companies are in this situation. Additionally, the number of enterprises supporting Line of Business applications to an increasing variety of users and phones fall into this same group. For everyone involved, the dizzying array of hardware types, operating systems, development platforms and programming languages are a challenge, to say the least. That is why I am becoming increasing convinced that for many, the only real hope in being able to support all mobile device platforms is HTML 5.0.

In order to understand the true scope of the current dilemma for so many people, you simply have to break down the potential target phones from a development perspective. You get something like this…

  • Windows Phone – Currently, you have native development with C++ or managed development with the .NET Compact Framework. Moving forward, you will have Silverlight or XNA. The development platform – Visual Studio (running on the Windows operating system).
  • iPhone – Objective-C is the language, with XCode as the development platform (running on the Apple OSX operating system).
  • RIM – A device-specific subset of the Java language, with different development platform options.
  • Android – A device-specific subset of the Java language, with different development platform options.
  • WebOS – A device-specific subset of HTML standards, with different development platform options.

OK – so what does this mean for a developer trying to build a single application that supports multiple phones using native development tools? Well, for starters…

  • From a development computer, the best-case scenario requires an OSX-based desktop or notebook (think iMac or MacBook) with both the OSX and Windows operating systems installed. I have set up such a computer in the past, and it’s not very pretty (or inexpensive).
  • Again from a best-case perspective, I need to know at least the fundamental aspects of -
    • .NET (then the derivatives for the Compact Framework, Silverlight and XNA)
    • Objective-C (C or C++ for starters, but a whole lot of differences)
    • Java (then the SDK-specific derivatives for each device)
    • HTML (and then the specifics for WebOS)

Folks – that’s one specific computer and FOUR programming languages (with a lot of additional knowledge on top of the language basics) just to get my single application to all the major phone platforms. And remember – these are “best-case” scenarios. I didn’t include those applications that are very hardware-dependent (physical buttons versus  touch screens, screen resolution, etc) or graphics-intensive (using GDI versus OpenGLES versus native, etc). Of course, I left out the biggest challenge of them all regarding development – having to re-create one application many times. Even under the best of circumstances (an application where the bulk of application logic resides in a centralized location accessible via the Internet), there is all the work on the client/device of the application to perform. Even under the best of circumstances (Java to Java, for example), there is still lots of platform-specific work to do).  

With all these challenges in mind, what’s a developer to do? Well, there are several options -

  1. Pick your platform(s) is stick to it/them. For many independent developers, this is the only viable alternative. The time and effort for a single person to develop one application for multiple devices without a guarantee of return on investment makes for a simple decision – choose the platform or platforms I can reasonably manage from a time and cost perspective. For larger development groups, there is still the challenges of identifying and allocating the proper resources (developers) to the development efforts, never mind the challenges of keeping everything in sync to assure that work on Platform X doesn’t break or supersede Platform Y. For enterprises, there’s the cost of development, hiring and training the resources required. 
  2. Leverage multi-platform development platforms. This is primarily an enterprise-focused option that is becoming more popular. There are solutions that allow you to ‘write once, deploy everywhere” when it comes to phones. However, these platforms often come with new challenges. In addition to the sheer cost of such solutions (limiting their consideration to larger enterprises with IT budgets capable of purchase), there are infrastructure and capabilities (think “Jack of all trades, master of none” when it comes to these platforms when compared to native development) to consider.
  3. Develop mobile web application development. As any developer knows, the current state of mobile web application development comes with a number of limitations. First and foremost is the issue of being offline from the Internet and the “red flag” this poses for many applications. Despite all the marketing hype, guaranteed mobile device access to the Internet is still a myth (just think about all the times you’ve had dropped calls on your cell phone). Heck – guaranteed wired Internet access is a myth; just think about your home computer and your ISP. Many application rely on being able to work when no Internet connection exists. These applications not only need to function from a user interface perspective; they also need to be able to safely store enough of a cache of data locally when the the connection is lost to be able to allow the user to perform their work. For the most part, most mobile phones do not implement the capabilities within their respective web browsers to make this a reality.
    The current state of mobile device web browsers also makes for a present-day situation I like to refer to as the “Microsoft/Netscape Syndrome”. Anyone who has been developing web applications can remember the days when the differences between the two most popular web browsers at the time (Internet Explorer 3.x and Netscape Navigator 3.x) were so different in what HTML standards they supported that as a developer you were required to essentially build two versions of a web application if you wanted the widest usage. NOTE:  Yes, I acknowledge that this is STILL going on today in the desktop browser world – I just like to refer to the first time that this became an issue that truly affected the development world in a broader scale ;-) Today’s mobile web browsers mostly suffer this same fate. Their capabilities vary by platform, making even the simplest of application development tasks difficult and requiring a lot of conditional coding and rendering logic based upon browser detection (the term “browser sniffing” is has relevance more than a decade after it’s creation).

Now after saying all of this (including the current challenges around mobile web development), you may be wondering why I think that yet another HTML specification may provide some relief for multi-platform mobile device developers. Well, there are a couple of things around HTML 5.0 that can address these issues -

  1. Reducing fragmentation that has occurred in the years since HTML 4.0 was ratified. A lot of time has past in the years since HTML 4.0. During this time, a lot has changed with regards to the Internet and how we use web applications. We’ve seen fragmentation in addressing these issues as a result. Don’t get me wrong here; I’m not saying that HTML 5.0 will solve all the issues. However, we are already seeing some vendors in the mobile space betting in some way, shape or form on HTML 5.0 and moving away from their own individualized solutions to problems, instead building in HTML 5.0 support in their own mobile web browsers. Heck – Palm has practically bet everything on HTML 5.0 with development for WebOS. As I mentioned earlier, WebOS application development is grounded in HTML standards – HTML, JavaScript, CSS, etc. If that makes you wonder how you could possibly develop applications that work offline, then you need to consider…
  2. The HTML 5.0 Database specification. I will leave the details to this specification to the W3C. However, if you care to look at the HTML 5.0 specification, you will find a great deal of changes dealing with application caches, application sandboxing and databases. All of these changes account for offline HTML applications as well as traditional online access. In essence, the W3C is, with the HTML 5.0 specification, finally officially addressing the use of native HTML as an application language, rather than simply a connected web application language.
    Palm is not alone in moving toward HTML 5.0 for mobile technology. Google (via Android’s browser) and Apple (starting with the iPhone 3.0 and Safari) have started implementing HTML 5.0 standards. One example is with the HTML 5.0 support for location. If you’d like to see this in action and have either an Android or iPhone handy, check out Microsoft Device Application Development MVP Richard Jones’ example (complete with source listing). Bottom line – if the HTML 5.0 as currently written is ratified and if the mobile device platform players implement the standard, it will be much more possible to develop cross-platform applications that meet offline requirements than ever before. While I am certain there will always be platform-specific APIs (likely exposed via JavaScript) to deal with, I think that learning one base language and device-specific extensions is certainly more manageable than four languages that exist today.

Of course, HTML 5.0 cannot solve all multi-platform development problems. There will almost always be application scenarios that require using a development model and language that is “closer” to the device. Gaming applications, for example, commonly require complex graphics processing. While HTML 5.0 is making strides even in this arena, it is likely that it will not supplant the need for more native development solutions that are optimized for and tailored to a specific device. For many other applications, however, HTML 5.0 provides the potential to enable development of applications that can meet the challenges of modern mobile applications, and all under a single development language umbrella.

I applaud those device and mobile operating system manufacturers that are embracing HTML 5.0 as “early adopters”. To those that are not, I strongly urge them to consider not embracing this standard might mean. Early on, I mentioned the “pick your platforms approach”. If HTML 5.0 is adopted by everyone but you, it is more likely that you will be the “odd man out” for a potential audience of thousands of developers. Here’s to hoping that is not the case for any one manufacturer. Here’s also to looking forward to HTML 5.0 final ratification. And finally – here’s to hoping that HTML 5.0 really can live up to addressing one of the greatest challenges posed to mobile device developers today.    

Jan 30

I’ve decided to capture some thoughts and observations around this past week’s announcement and subsequent hoopla over Apple’s newest product – the iPad

iPad .

I write this for 2 reasons -

  1. I would feel left out if I was not one of the BAZILLION bloggers on the Internet who had not posted thoughts on the iPad. If you were following me on Twitter, however, you might have picked up some of my thoughts.
  2. Ever since the announcement, I have been asked by any number of people what I thought about it. Easier to write once and point than to write over and over again, I always say.

Now before I go on, a few “ground rules” -

  1. Anything that I say that appears to be a criticism of the iPad should not result in the instantaneous response of “you’re just a Microsoft fanboi” (the tech intellectual equivalent of “I know you are, but what am i?”) Remember that I regularly use a MacBook (BootCamp’ed with both Snow Leopard and Windows 7) and have an iPhone in my fleet of mobile devices (the MacBook allows for iPhone development). I see and know from my personal perspective both the pros and cons of these products, and objectively understand them.
  2. Anything that I say that appears to be a positive of the iPad should not result in the instantaneous response of “Ha! Your abandoning Microsoft! How could you!” or the likes. For rationale, see #1 above.

(It’s not like I haven’t been in this position before, mind you. Long before the Microsoft/Apple thing, I dealt with the Windows/Unix thing. When you try to be objective, someone always gets pissed off. Simple fact of life.)

Finally – What is contained here are my personal thoughts and speculation on the subject. Nothing “etched in stone”…

With all this now “on the table”, here are my random thoughts, in no particular order…

  • For aesthetic industrial design, the iPad is a winner. Then again, when isn’t Apple a winner in this category? As a matter of fact, the day Apple releases a hardware product that isn’t aesthetically pleasing is the day they should shutter their doors (and you should beware of it raining frogs). I like the size and weight. I’ve heard complaints about the size of the bezel, but folks – you have to have some area to hold the device without interfering with both the touch screen and the viewing area.
  • I get the hardware specs for processor, memory and storage. Apple sees this as being in the “netbook” segment (more on that later), and for the use cases they associate with this segment, a more energy-efficient processor with longer battery life is a good move.
  • First criticism – choosing the iPhone OS for this device. While I know this opens the door instantly to hundreds of thousands of Apple AppStore applications, it brings with it some limitations. I really thought that the iPad could have solved a major and long-standing problem for Apple if this was one differently. Follow along with me on this one…

    Since I can remember, OSX has always been held back by the lack or quality of applications in a lot of market spaces. The iPhone was the first time Apple truly had widespread developer adoption of their tools and development platform. However, this jump to the Apple development platform hasn’t really equated to developing for ALL Apple hardware. Now, if Apple had chosen OSX for the iPad, they might have had a compelling OSX story. Something like “iPhone developers – here’s a device that is similar in many ways to what you are familiar with in the iPhone. With some work, you can now bring your applications to the next level, and not just with the iPad!” If the rumors of touch screen enablement in other Apple hardware is true, all the more for a compelling case to lure an army of iPhone developers to the OSX world, bringing scores of applications with them. Apple, I really think you missed the boat here.
  • Still on the iPhone OS choice – this time, it’s the lack of multitasking. Apple really needs to bring something, even in limited form, in the way of multitasking to the iPad. While I might not agree with it, I can see some of Apple’s arguments against multitasking in the iPhone. However, Apple made a point to position the iPad in the segment of a netbook replacement. I believe that either Apple is WAY off here or simply isn’t serious about that representation. It all comes down to use cases here, folks.

    A netbook is a more traditional computing platform in the way of use cases (unlike a mobile phone). Even under the most restrictive of situations, people expect some ability to move between applications, or to leave one application open while working on another. Even the most basic of end-users will find themselves working with or using an application downloaded from the AppStore and expect to be able to leave it for a minute when a new email arrives. This is what any computer user has come to expect these days. While users may initially be willing to accept this limitation, I will expect it to become an annoyance over time.
  • iPad and eBooks – I strongly suspect that THIS (not a netbook competitor) is the real motivation for the creation of the iPad. Just look at Apple’s recent history in consumer devices. iPod, iPhone – it’s all really about creating and controlling a media-based ecosystem (read iTunes and the AppStore). I suspect that if Apple were really going after the netbook market, they would have gone a different way. Create an “eReader+” with all the apps and additional capabilities and a closed delivery system like iTunes and you have the potential to control a rapidly-expanding market segment.

    I think Amazon should be in a state of “heightened awareness”, but not alarm (at least for the moment). They have an incredibly established base in the Kindle today. They shouldn’t rest on their laurels, though. As for Barnes & Nobile (Nook), Sony (eReader) and the others that haven’t really established a foothold in the eBook Reader market – things aren’t looking so good for you. Apple has already proven a closed system can be successful, so the “indy” eReader hardware makers have to worry. As for the Nook; I’m not so sure there’s room for 3 closed systems in this market.
  • The '”iPad” naming – this is incredibly uncharacteristic of Apple. Not so much the “open to feminine hygiene jokes” thing, but the fact that the name “iPad” was trademarked years ago. This leads me to believe things were a little rushed here, especially when combined with…
  • No immediate availability? If there’s one thing Apple is great at, it’s generating interest, generating demand and then launching with immediate (or near-immediate, i.e. – a few days) availability. This time – 60 days? 90 days? When you combine this with the naming, I can’t help but believe something more was in play here.

    Was Apple afraid of  too many product leaks? Probably not. There were far more “guesses” relating to the iPad than anything else. I do think Apple might have been concerned about losing even more ground in the “eBook Wars”, though. Consider CES early in the month, were literally hundreds of eBook readers were on display. Combine that with continuing growth in sales of the “big guys” (Amazon, B&N and Sony) and you had the potential of losing a lot of potential customers in 3 months time. How many people would be willing to spend $500 for an iPad  after just plunking down $250+ for a Kindle? By at least announcing a “coming soon” to the iPad, I think Apple was hoping for a pre-emptive strike that will get people to hold off  on another eBook reader purchase. Of course, all of this also goes to reinforcing my thoughts that the real market Apple is targeting is not a traditional computing platform (netbook), but a consumer market segment (eBooks).
  • The whole “closed ecosystem” thing. While you may not like it, you can’t argue that it works for Apple. They’re still making boatloads of cash with iTunes and the AppStore, aren’t they? I don’t see people casting their iPods and iPhone in the trash en masse screaming “I want freedom!”. While I have always had an issue with this, I’m not foolish or egotistical enough to believe that this is wrong for everyone; the numbers don’t lie. Apple obviously believes the same formula applied to the eBook space will work as well.
  • The iPad / Tablet PC debate. Lots of “stuff” being flung back and forth here. My take – it’s all about use cases and usability. It’s a variation of the iPad/netbook discussion. Listen, if Apple’s intent to focus on eBook reading and basic applications, the UI they’ve created for this is hard to beat. No one (STILL after all this time) does user experience (UX) like Apple. Just watch the demos from Apple’s press conference. If, however, you are looking for the ability to multitask and have more robust applications, the Tablet PC wins.
    NOTE: A bit of advice to those in the fervent Tablet PC and iPad camps – you’re not going to convince those that simply don’t need what your selling that your side is right. Tablet PC folks – a Tablet PC isn’t better to an iPad for someone that doesn’t need office suites and powerful applications all running side-by-side. iPad folks – an iPad isn’t going to work for someone who needs the things mentioned above. I suggest this debate end and folks move along :-)
  • Finally – how do I think the iPad will do? That’s a really good question. Overall, I think it will do just fine… initially. One caveat here – I think the long delay between announcement and availability might actually hurt Apple in some target audiences. When you lose the “impulse buy”, it gives people the opportunity to research and think a bit more. I have already talked to a lot of folks who typically buy “the next big thing” from Apple the day it arrives. For those that already own a MacBook and an iPhone, I’m hearing more “no’s” than “yes’”. Just nothing compelling enough. I do think, however, that Apple can once again find a consumer “sweet spot” with users, similar to how they did with the iPhone. Long term success, however, will likely rely on how satisfied those consumers will be with just a powerful but narrowly-defined device versus a full-blown computer. Of course, Apple has lots of room to work with here, and lots of time to evolve (something else Apple is very good at historically). We’ll just wait and see…

Of course, my musings would not be complete without answering two questions -

  • Don, will YOU buy an iPad for yourself?  Personally, no. For me, adding an iPad would not result in me dropping another device. I need the functionality and size of a netbook when I want to travel light. The iPad just wouldn’t be able to do all that I need it to do. It’s also not a phone, either in functionality or size, so I can’t drop that device.
  • Don, would you recommend an iPad to someone? To the right person, sure. Who might that be? Well, my target demographic includes…
    • Likely not already owning a notebook computer, and definitely not owning a netbook computer.
    • Maybe already owning a smartphone (iPhone or otherwise) and liking the ability “to do more”.
    • Looking at purchasing an eBook reader.
    • Wanting something a bit more in an eBook reader, like surfing the web and checking email.
    • NOT wanting a “small computer”.

I’ll be keenly interested in watching this all play out over the coming months. I’m sure I’ll have more to say over time.

Aug 21

During our Boston/New England Windows Mobile User/Developer Group meeting this past Wednesday, we had a wonderfully interactive discussion during my presentation “State of The Union: Mobile Device Application Development”. A common theme/concern during the presentation revolved around the effort involved in creating a single logical application that runs on multiple devices across platforms like Windows Mobile, iPhone, Android, WebOS… and on and on. We talked in great length about development tools, programming languages, learning curves and the like. During the presentation, one consistent message I tried to impart the audience with was simple…

Don’t dismiss the possibility of leveraging the mobile web for your application.

I think the greatest example of this came from one of our attendees, Jim Travis (thanks, Jim!). He gave an example of an iPhone application currently available in the iTunes App Store (and a quite popular app as well). This application, focused on mobile banking, is quite nice and has the visual appeal expected when using iPhone applications. Jim then pointed out that by using this bank’s mobile web application, you received a similar visual appeal with similar functionality. No application download required. It is this very example that brought me to writing on this subject.

Any seasoned application developer will tell you that there are times when a web-based application simply will not work. Usually, it is business-critical requirements like offline access to the application, detailed interaction with hardware and/or system resources or local storage of information that becomes a “show-stopper”. I understand this entirely, having experienced this far too many times myself over the years. I believe, however, that when it comes to mobile application development, we have become conditioned in an almost Pavlovian way to assume mobile application equates to native application.

Part of our conditioning when it comes to mobile application development comes from the evolution of mobile devices themselves. For so many years, mobile web browsers were well behind there desktop counterparts in capabilities. In fact, it was not that long ago that the only “safe bet” when developing for mobile browsers was to keep it as simple as possible, falling back to WAP standards to guarantee that the application would work. Times have changed in this regard; today’s mobile browsers are quickly gaining the ability to render desktop web sites with near-desktop fidelity. Unfortunately, these capabilities have led to yet another aspect of our turning away from mobile web application development.

With today’s mobile browsers supporting near-desktop browser capabilities, many have come to assume that there simply is not a need to mobile web equivalents. I frequently hear people say “let the user go to the ‘regular’ web site if they want <fill in the blank>.” Sadly, simplistic statements like this forget an oh-so important principle of software design – accessibility and/or readability do not equate to usability. While I can see my bank’s web site on my mobile browser, the process of using my bank’s web site to manage my finances is fraught with challenges zooming in and zooming out of a page, panning, scrolling, doing data entry, etc. All this typically leads to frustration and (inevitably) abandonment. If the banking site is optimized for my mobile browser, however, I can perform the tasks I require with improved readability, navigation and data entry. Result – a workable application that, when crafted correctly, can support a user base using different devices.

The techniques for supporting mobile mobile web browsers have existed for a long time. In fact, those who have developed web applications long enough can recall having to use the same techniques for desktop browsers (remember the first “Browser Wars”, with IE 4 and Netscape 4?). Interestingly enough, desktop web application developers are finding themselves in a similar situation today with IE 8, Firefox, Safari and Opera. To best provide rich web application functionality using “browser sniffing” (the web application determining the browser being used) and appropriate rendering of the web page, one can leverage a single base of common business application logic and customization only for the user interface. If you are developing using this technique today for your desktop experience, why not simply extend it for your mobile experience? While this approach requires a greater development effort, I think it is safe to say that it is usually far less effort than the alternative of learning multiple programming languages, investing in multiple toolsets and trying to keep everything “in sync” from a feature/functionality standpoint.

Another major challenge with native mobile applications lies in the process of distribution. How do you get your application to your users? Every mobile platform currently has one or more ways to deal with software distribution, but managing this when complicated by one logical application having multiple device-specific implementations is complex, to say the least. One compelling reason for the explosion of web applications in the past decade has been around this challenge. Simply put, web applications have no distribution issues to address, at least from a mechanical standpoint. New features? No problem. Bug fixes? No problem. Simply update the web site and voila! Bottom line – distribution of software is almost always a major complication for any type of application; web applications practically trivialize this issue.

All of this may sound like I am minimizing the importance of native device applications. I most certainly am not. I recognize their importance as well as scenarios where they are the only option. What I want to make clear, however, is that they are far from the only alternative for building solutions that support disparate multiple device platforms. When the idea for developing a mobile application first arises, you should be asking yourself some simple questions…

  1. Is there a compelling business and/or technical reason why I cannot design the application for the mobile web? Sometimes, a legitimate business reason may trump technical reasons. An example – the exposure of a native application to the public through a distribution channel provides more marketing ROI than a web application would. I think the mobile banking example mentioned previously could support this scenario.
  2. Can I provide the functionality for the user that meets the business and/or technical requirements with a mobile web application? While this used to be a blocking factor for the mobile web, it is increasingly becoming less so. Remember – the same mobile browser functionality that allows for the rendering and interaction with desktop web sites can be leveraged with a mobile web site; it is the design for usability on mobile devices that makes the extra development effort worth while.
  3. Is the extra cost associated with multiple versions of the same application for different devices worth it? Back to the ROI discussion. If there are no blocking factors for a mobile web application, it is crucial to address the costs and benefits of going the native application route to make sure that there is a very real reason to “go native” (held off using that phrase up until now ;-) ).

As a presenter, I love discussions that make me think in the same way that I hope to get my audience to think. This past Wednesday’s meeting/presentation was one such discussion. I really believe that the diversity of mobile devices and associated platforms may in fact be a greater driver to mobile web application adoption than anything else prior. By simply being open to the idea of cross-platform mobile web applications, we can potentially see a new world of opportunities for all mobile device users.