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.

Apr 22

For you Facebook users out there… BostonPocketPC.com now has a Facebook page! In addition to the content you would find here, our Facebook page also includes an event calendar for upcoming Boston/New England Windows Phone User and Developer group events as well as Windows Phone events in the Greater Boston area. The BostonPocketPC Facebook page also hosts Discussion Threads for members.

If you are a Facebook user, be sure to head on over and “like” us today (in case you were unaware – Facebook has replaced “Being a Fan” with “Like” for joining a page).

Apr 22

NOTE: Cross-posted from BostonPocketPC.com.

During last night’s monthly Boston/New England Windows Mobile User and Developer Group meeting, we covered a number of items. Steve Hughes’ KIN presentation was great in providing lots of info. We also covered an overview of Windows Phone 7 development (SIDE NOTE: We are planning a number of focused developer presentations in the coming months on various aspects of Windows Phone 7 development. Stay tuned for more details…).

During the meeting, a recurring theme emerged. It spanned both the KIN and Windows Phone 7, and it is an area that is essential for both platforms’ success. It is also an area that has been a sore point for Microsoft and it’s partners throughout the life of the Pocket PC, Smartphone, Windows Mobile and now Windows Phone – price competitiveness. It is an area that if not addressed will potentially cause history to repeat itself and risk the failure of the platforms regardless of the the values they provide.

The cellular industry has a long history of product pricing through subsidies that reduce the cost of a phone for the consumer. While we all know that the physical phone is but one “cost” when combined with voice, data and additional services, the general consumer expectation has been that the cost of hardware should not be an obstacle in making a purchase. This has become a sort of “immutable law” for the average consumer when it comes to cell phones. For many of you reading this piece, this line of reasoning does not apply (and rightly so). Your love of “gadgetry” supersedes cost. But remember – you are the exception, not the rule. Just think about significant others, family and friends who have questioned your sanity about the amount of money spent on such technology :-) All this brings us back to the history of Windows Mobile in the cellular market space.

Traditionally, device manufacturers using the Windows Mobile operating system and mobile operators (the AT&Ts, Verizons, etc of the world) have chosen to brand these devices as “high-end” and often priced them closer to traditional computers than phones. At the same time, the industry still treats them as “disposable devices” in terms of shelf-life (translation – you, the consumer, are willing to upgrade to new hardware on a frequent basis at “discounted” prices in return for renewing service agreements). At prices that are often still $100 - $200 USD over other phones (even after subsidies and discounts), the perception to the average consumer is often “that’s an awful lot of money for something that I won’t keep forever.”

I will grant you that Microsoft is working hard with Windows Phone 7 to attempt to add long term value to Windows Phone 7 devices. But they are not the device manufacturer nor are they the mobile operator, both who see value in you not keeping a single device for long periods of time. That being said, what else will drive sales of new Windows Phone 7 devices. Ironically, the answer lies with Apple, AT&T and (of course) the iPhone.

While initial sales of the original iPhone were good, it was not until the iPhone price drop (remember the event that had many early iPhone adopters feeling foolish for paying so much?) that truly drove sales. Since then, there has been a continuous and very conscientious effort of Apple and AT&T’s parts to bring new devices to market at lower prices. The most recent example – the entry price for the iPad coming in at under $500 and resulting amazing sales numbers – shows that competitive pricing in this segment matters. Price matters. The iPhone and iPad have, in essence, revolutionized another aspect of technology (at least in the cellular space) – powerful devices at affordable prices (at least that is what the numbers show).

For both KIN and Windows Phone 7, price will matter. IN the case of KIN, which Microsoft themselves brand as a “feature phone with great features”, but not a smartphone, pricing this device significantly above other feature phones will likely be disastrous – history and the numbers simply don’t lie. Interestingly enough for Microsoft, this is the first phone for them in which they are actually closer to being the manufacturer than ever before (while Sharp was their hardware partner here, Microsoft really ran the design part of things). Such is not the case with Windows Mobile, nor will it be the case with Windows Phone 7; Microsoft is simply the operating system licenser. However, Microsoft has the most to lose or gain with it’s investment in Windows Phone 7 (keep in mind that most of the device manufacturers are currently hedging their bets on the operating system front with Android as well).

So, how does Microsoft ensure price competitiveness with Windows Phone 7 devices? I don’t know the final answer here. Some common sense possibilities include putting pressure on the device manufacturers and mobile operators to ensure cost competitiveness (although that really hasn’t worked out in the past). Perhaps Microsoft themselves stepping up (at least initially) to cover some of the subsidy cost in order to improve chances of success. Regardless – something has to be done here to make certain that Windows Phone 7 devices do not show up on mobile operators shelves with prices that induce consumer “sticker shock”.

Those who cannot remember the past are condemned to repeat it.” - George Santayana

For Microsoft and it’s partners in the cellular space, these words have never rung more true. Regardless of capabilities or of “sex and sizzle”, KIN and Windows Phone 7 devices risk being relegated to inventory shelves if they cannot entice average consumers with effective competitive pricing.      

Apr 16

The next meeting of the Boston/New England Windows Phone User and Developer Groups will occur on Wednesday, April 21st starting at 6:30pmat the Microsoft offices in Waltham, MA (201 Jones Road, 6th Floor).

Map picture

There are lots of exciting things going on around Microsoft and phones, and this month’s agenda reflects it! -

Introducing Your Next of KIN: Microsoft’s New Feature Phone Platform
If you haven’t already heard, Microsoft has announced a new feature phone platform in KIN. In this presentation, we will discuss what KIN is (and isn’t) and talk about the first two KIN devices announced – the KIN 1 and KIN 2.

Introduction to Windows Phone 7 Development
The Windows Phone 7 platform introduces an exciting new platform for smartphones – not only for users, but developers as well. In this presentation/demonstration, you will learn about the basics of Windows Phone 7 application development using Visual Studio 2010, Silverlight and Expression Blend.

I look forward to seeing you all there!

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

Back in the “good ol’ days” of late 2000, I started writing regularly on the Internet. Back in those days, I was mostly writing software reviews for a relatively new gadget – the Pocket PC. There were a few web sites around that focused on the technology, but not a ton. In January 2002, I launched BostonPocketPC.com. The idea was to use the Internet to communicate about Pocket PC, then Smartphone, then Windows Mobile and now Windows Phone technologies. News and reviews was the name of the game.

BostonPocketPC.com has always been an enjoyable experience for me. It has given me the chance to meet new people and write about technology I love. A lot has changed in the last 8 years, but it is what has occurred in the last year that has really changed by interaction with the Internet – the emergence of social media.

I’ve always enjoyed writing. I’ve also enjoyed interacting. While traditional “blogging” on the Internet is a great way to speak to an audience, it’s never been a great way to “communicate”. Even longer than my Internet writing career, my professional career has been focused on dialog rather than monologue. Blogging does have it’s ability to invoke conversation, but it is not it’s default nature. The advent of technologies like RSS have moved traditional Internet writing even more towards a more uni-directional nature. That’s never really been my “cup of tea”. The emergence and acceptance of social media technologies has proven to be the media I truly crave.

Whether it be Twitter or Facebook, Yelp or FourSquare, social media is all about interaction. Tweets are replied to, either in replies, retweets or direct messages. Facebook posts result in comments or “likes'”. All very much and very easily in real time. Sure, we’ve had email, forums and newsgroups. None, though, have encouraged the widespread and rapid response to thoughts, opinions and statements than these social media tools do. For me, the result has been quite obvious – I’ve found myself spending far more time in the social media world. This has come at the expense of the traditional Internet mediums. I’ve been thinking a lot about this recently, and I’ve come to some conclusions.

I’ve come to realize that there still is a place for both the traditional and “new” ways of communicating on the ‘Net. I have come to realize I still find enjoyment in blogging. I’ve also come to realize that it is most enjoyable when I want to communicate a message that can’t be conveyed in 140 characters or a “quickie” paragraph. While social media has some strengths (as I described above), it does has it drawbacks. I also realized that by being a little too immersed in social media, I sort of rationalized myself  out of writing more. You have to admit it; Twitter and Facebook do make us a bit lazy when it comes to writing. That is going to change.

My plan moving forward is to try to start doing a healthier mixture of both social media and blogging. I really don’t need to change my social media habits to accomplish this; social media only takes a matter of seconds at a time to communicate. I will start to take the time to identify those things worthy of more complex communication (read - “more words”) and bring them to my blogs/sites. While I might not get the interaction I would like, I still hope that they can either inform or invoke thought. In the end, that is why I have always really enjoyed my writing on the Internet, and what I had somewhat lost sight of – until now.

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.

Jan 19

We will be having the next Boston/New England Windows Mobile User and Developer Groups on Wednesday, January 20th beginning at 6:30 PM at the Microsoft offices (201 Jones Road, 6th Floor) in Waltham, MA.

Map picture

Among the topics discussed -

  • A wrap-up of CES 2010. Lots of interesting things going on.
  • Hands-on with the LG eXpo. If you haven’t seen this Windows Phone device in action, you are in for a treat!

See you all there!

Jan 09

I happened to come across a news article out of the Consumer Electronics Show (“CES”) this week. The article from CNN was entitled “What is a tablet, anyway?” and discussed the introduction of several new computers from different manufacturers. The focus of the article was not on the new hardware itself, but the “labeling” of the hardware -

For all the buzz about "tablet computers" in recent weeks, one fundamental question about this supposedly break-through computer category remains unanswered:

What exactly is a tablet?

Computer industry representatives here at the massive and hype-heavy Consumer Electronics Show can't seem to agree.

Some say a computer just needs a touch-sensitive screen to be a tablet. Others say a person should be able to write on it with a pen. Still others say it's screen size that's important -- tablets must fit somewhere between phones and laptops. For Philip McKinney, vice president and chief technology officer at Hewlett-Packard, it's partly the keyboard -- a tablet should have one of those.

Break off the keyboard, leaving only a touch-screen device, he said, and the gadget falls into another buzz-worthy category: the slate.

Others say the terms slate and tablet are synonymous.

The sad part of this is that the creation of buzzwords in the technology industry is nothing new and only seems to get worse as time marches on. Even sadder is the fact that the industry amazingly considers being the first to label an existing technology with a new term outweighs the confusion this causes to consumers.

Another example of this industry fetish with attempting to make something new by labeling occurred when Google announced their new phone, the Nexus One. As someone who has been immersed in the mobile phone space and makes his living off of it, I can tell you the following -

  1. The Nexus One is a very nice phone with advanced capabilities for messaging and application support. Nice hardware and nice “bells and whistles”.
  2. The Nexus One may be better than other similar devices, but it is not a new category of device. Based upon what the industry has come to understand and accept, it is a smartphone; a phone with powerful computing capabilities.
  3. In spite of #’s 1 and 2, Google proudly proclaimed the Nexus One to be a new category of phone – the superphone.

Now, if Google were to only make a passing reference to this label, as in “This is really a great smartphone; in fact, it’s a superphone” and left it at that, things would be OK. However, much like the computer industry that throws out terms like “tablet” and “slate” and all with differing definitions, the average consumer is usually left with the deep thought “Huh?”. By creating brand confusion (with a type of technology being the “brand”), consumers are left to sift through the deeper technical aspects of each company’s offerings in order to make any sense. This is something the average consumer doesn’t want to be bothered with. I can’t tell you how many times I have had to spend time with friends and customers who, after several minutes of explanation, say things like “I just want a phone” or “Why should I have to figure out what type of tablet computer fits my needs”.

I can’t say for certain if the technology industry has become so focused on trying to differentiate via buzzword rather than value. If you’ve been around the computer industry long enough, you know we get a huge endorphin rush from creating acronyms and buzzwords. But they are usually attached to more abstract concepts. For some reason, this need to create new words to describe things has now reached a fevered pitch, and the hubris associated with such branding has killed off the last brain cells associated with good marketing sense. Hasn’t the industry learned from past mistakes of this type? The “Notebook/laptop/portable” naming craze? More recently, the “notebook/netbook” debate? Heck – even this branding confusion around tablet computers is a new and even more confusing version of the “tablet vs. slate” marketing confusion just a few years back. And please – do NOT get me going on the PDA/phone/smartphone confusion that surrounded the mobile industry in the last decade.

While the creation of new terms for existing technologies may please self-indulgent marketing executives and a small segment of the consumer population obsessed with having the “latest and greatest” (even if it is not), all of this naming simply leads to the perception of fragmentation of what is logically a single segment of the industry in the eyes of the consumer.  Fragmentation leads to confusion, and confusion leads to a lack of sales to the very audience that is often the target.

I would suggest that the technology sector take a moment to step back and remember why they exist – to make money. When you are trying to sell a product in a competitive market space, clarity is key. Telling people why your product is good and how it benefits them is what makes the sale. Re-segmenting existing and accepted categories of products does not provide clarity unless everyone agrees to the new segmentation and communicates in the same way. Yes you differentiate yourself, but only by alienating potential customers who look at you and your competitors providing mixed messages. In the end, they will likely not trust either of you. By the way – if your goal with this strategy is to confuse or distract the consumer, I suggest a career with a much greater chance of overall success. Political bodies are always looking for “fresh blood” :-)

I’d like to think that this trend in creating new technology segments and confusion will end, but history shows that just the opposite will happen. For you, the consumer, all I can say is caveat emptor. Don’t take the labeling of a technology to something new as automatically equating to something better. Stick with the tried and true methods of purchasing – determine what you need, what you want and then find the product that meets those needs regardless of the marketing category. Tablet or slate, smartphone or superphone – in the end, they are just products with features and capabilities. When you do make your choice, let your salesperson know that you made your choice by thinking and not by catchphrases and buzzwords. Maybe someday the message will make it back to the appropriate people. Wait – they’re all locked in a room trying to come up with the new hot buzzword ;-)