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.    

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.