HTML 5, along with new versions of CSS and JavaScript are the standard platform developers use to create rich Internet software. IE 9 is Microsoft’s first (mostly) HTML 5 compliant browser. The software giant had classically resisted, or at least been slow to adopt, general Internet standards and preferred to push their own technologies. However, IE 9 marks the first product launched to the general public showing their full support for the standard, which has pulled in an improbably large amount of press lately.

A few months ago the tech world was buzzing over the sharp exchange of words between Apple and Adobe. Apple’s Steve Jobs in no uncertain terms said that Adobe’s Flash product would never be available on any iOS device, which includes the iPhone, iPod and iPad. Apple had committed to HTML 5, in lieu of Flash, as the way to deliver rich web content on its hottest selling devices. Those sentiments were backed by a number of other large industry players, including Microsoft and Google.

Microsoft jumping on board with Apple to take a dig at Flash seemed obvious as it has a competing product, Silverlight. However, it’s clear there’s more to the story than was obvious at the time.

The two most interesting new technical elements of IE 9 are the hardware acceleration for HTML 5 graphics and how each tab runs in a separate application process. The hardware acceleration is interesting because it allows software based on HTML 5 and JavaScript to run at a performance level compatible to desktop applications. This is a big deal as application developers are moving towards web based solutions for even the most complex software and Microsoft needs Windows to be able to run this software well.

Which is why running each IE 9 tab in a separate process is important. Imagine you had a Microsoft Word and an Excel document open at the same time and for some reason while working with the Word document, it crashed. Pretty upsetting, however, you’d be even more upset if Excel crashed as well. Now imagine if all of your applications crashed simply because one of them did. Prior to IE 9 that’s how Internet Explorer worked. If one of the web sites you had open in a tab crashed, the entire program would shut down closing all of your tabs. This may be okay if you’re just surfing the web but increasingly people are running software applications in the browser, a trend that will only continue to increase.

Clearly Microsoft is committed to enabling the development of rich applications based on HTML 5; applications that in years past would have only been possible to develop using technologies like Adobe’s Flash or Microsoft’s Silverlight. In fact, full desktop quality applications are possible using these technologies, which forces questions about Microsoft’s other development platforms.

These questions are causing heated conversations within Microsoft. Lately, there’s been a rash of public conversations by current and former Microsoft employees about the shifting direction in Microsoft’s approach to the software development – particularly around their Silverlight and Windows Presentation Foundation (WPF) development platforms. Microsoft is known to have rivalry among its divisions, which often take parallel but competing paths. The profitable Windows division usually wins these fights and it seems that the Windows division is backing HTML 5. This raises doubts about the viability of both Silverlight and WPF going forward.

With WebOS Palm proved that it’s possible to create an excellent operating system where applications are primarily based on HTML 5 and JavaScript. Google’s Chrome OS hopes to continue that trend when it’s released later this year. Even with the very successful launch of Windows 7, Microsoft is facing the toughest competition in the OS space that it’s ever had and it is paying close attention to this trend in order to keep from being caught behind the times with their primary money maker.

Internet Explorer is the last major browser to make the move to HTML 5, but the technology in version 9 and the conversations coming from within Microsoft are good indications about the platform Microsoft will use to wage not only its browser battle, but also its broader operating system war.

Why should you care about IE 9? It appears Microsoft’s preferred development platform could very well be HTML 5 and its continued success in the OS space could rely on how well they implement it in Windows. IE 9 is Microsoft’s first major move in that direction making version 9’s success very important to Microsoft’s market position.

Shane Kempton is Phase 2’s Director of Consulting and Chief Software Architect. You can learn more about his vision and insight regarding web and mobile technology by following him on Twitter @shanekempton.

Colbey Chittenden led the development on the project with game play ideas from Chad Scott and graphic design by Jacob Eck.   The team cranked through the app in about a month, learning the iPhone SDK (Software Development Kit) quickly then building the game in just a few weeks.

For more information about Quadrangle and how to get it on your iPhone or iPod touch click here.

1. Clients have the right to working software, at regular intervals, throughout the implementation life cycle.
2. Clients have the right to usable software.
3. Clients have the right to clear, non-technical communication about the software being developed and the development process.
4. Clients have the right to the best solution available.
5. Clients have the right to be regularly involved in the software development process.

Good software should work well, but you’ll notice it doesn’t say clients have the right to working software. “Working” software means different things depending on who you’re talking to at the moment. To some “working” can mean the software works if you do things just right, if you enter all the correct information, you remember the correct order of operation or you’ve read the instruction manual ten times through. To others “working” means a piece of software should do everything they can think a user will ever want, everything they can dream up or everything a competitor is doing.

“Usable” means something different and gives us the right foundation. It implies a balance between over-engineering vs. under-engineering and feature creep vs. under-development. Usable means the software does everything that it needs to do, nothing more and does so elegantly.

The key to “Usable” is that it puts the focus where it should be, the end user. While most of the time the client and the developer have great ideas and intentions, neither can be the objective third party necessary to create great software. By focusing on exactly what end users need inorder to accomplish their tasks we get an unbiased judgement about that button placement, this workflow order or the proper number of navigation elements.

Without fighting for this Right, a project will only be a success for the end user through pure luck. Watch this video for a hilarious but oh so true example of what happens when you don’t value “Usable”: Watch Video

In my previous posts I discussed the way Phase 2 develops a deep understanding of our clients’ needs. Once we discover the needs and can fluently speak in the language of measures of success, we create a technology implementation plan. In the next series of posts I’ll cover my philosophies around the process of implementing a custom software project, we call it a Software Bill of Rights, credit to Jeff Palermo for articulating it as such. It’s what every client should expect from us, or any software partner.

There are 5 Rights our clients can expect during the implementation cycle of a project with P2.  While the details of an implementation will change depending on the project and the team, these are the guiding principals.

1.  Clients have the right to working software, at regular intervals, throughout the implementation life cycle.

2.  Clients have the right to usable software.

3.  Clients have the right to clear, non-technical communication about the software being developed and the development process.

4.  Clients have the right to the best solution available.

5.  Clients have the right to be regularly involved in the software development process.

Let’s talk about Right #1: “Clients have the right to working software, at regular intervals, throughout the implementation life cycle.”  I’ll make this bold statement, it is impossible to create an effective, well designed piece of software on the first pass.  Iterations are necessary and great software can only be created through iterations of actually working code and interfaces.  To meet the ultimate vision, a development project requires that the end user get their hands on the software as early and as often as possible.

There are no practical amounts of upfront specifications that will allow a development team to get a software compenent correct the first time.  Clients will forget things they needed, developers will botch routings they shouldn’t have, etc.  This first Right in the Software Bill of Rights defines the essential need for the end user to have access to working components of a piece of software throughout the develoment process.  This creates a fundamental feedback loop between the client and the developer.  Feedback is absolutely necessary for both the client, as they will gain confidence in code they cannot see, and the developers, as they will be able to craft the solution based on user interaction.  It is always a bad idea to take a software spec, have developers go build from it for a month or two, then show the results to the client.

Feedback should happen at least once a week with real working components that the client can touch.  This means developers must be mindful of error handling, bugs and UI issues at all stages of development.  Usable software early in the cycle helps keep the software on the right track, meeting the client’s needs and expectations, as well as allowing a developer to implement creative concepts which are difficult to justify without the client seeing them actually work.

As with all rights, these involve a high level of responsibility; great software implementations require a commitment to this feedback loop from both the client and the developers.  Clients must be committed to the, often substantial, time to use and test the ever changing prototype, giving valuable feedback to the development team.  Developers must be committed to the process of creating incremental, usable pieces of software, which requires a constant committment to working components at all stages, consistent focus and a willingness make user feedback a primary value.

In the end this Right facilitates great, usable software and happy clients.

As I discussed in my previous post, when we start a project at Phase 2, we always start by looking at the people involved. We look at the different constituents, both internal and external to the organization, what each wants and needs as well as the current problems each face. After we understand what particular groups of people are looking for, we ask the tough but essential business question: If the goals are met and the problems are solved, how does it positively affect the organization’s bottom line and/or mission? What is the measurable success the business will see upon the successful implementation of the software system? This question is so essential to a successful software project it sends my stomach in knots when I think about how often it doesn’t even get discussed. It’s easy, especially for technologists, to fall to the temptation of justifying software just because it’s cool, it seems needed or someone else is using it. It is equally tempting for businesses to reject software recommendations because it seems too expensive, too new or because the benefits aren’t clear. Technologically impressive but ineffective software doesn’t make for good business partnerships but, neither does unimaginative software that misses opportunities for real innovation. In our information age, businesses large and small need great software partners to survive.

The only way to manage a great partnership is to create win/win situations, which is patently impossible if there is not a deep understanding of how each component in a software project will impact the bottom line success of an organization. Clear measures of success, or MOS, provide a common language between a business and their software development partner, help to justify innovation and facilitate long-term relationships by providing quantifiable return on investment.

Creating common language is often difficult between business partners, but is particularly challenging between businesses and their software partners. The intangible nature of software and the obscurity about how it’s created adds tremendous difficulty to the communication. Here’s a real life example: We developed an application for a directional drilling company that helps them manage their drilling process. During the life cycle of the project we discovered that a single job could have multiple drilling paths or tracks instead of just one. This seems like and easy fix, just add another track, but to make the change required substantial revisions to the software. Conversely, things that seem difficult are often easy. On a different project we were asked to add a seemingly complex calculation to a list of items. While this seemed complex to the client it was actually rather easy to implement. Similar situations happen on nearly every software project. In most cases the obscurity of how software works creates a large communication and understanding barrier between a business and its software partner. The common language of Measures Of Success is the key to overcoming this barrier. If we frame our above examples in the language of MOS it will look more like this: obscure software situation A will cost X dollars and benefit the organization in Y ways. That’s an easy decision of any businessperson to make.

The MOS language also allows software developers to justify key, high impact innovations. Smarter, faster, more usable, more elegant, etc. are usually expensive, often prohibitively so for many businesses. Software that is 85% of the way to what a business is looking for but 200% cheaper is normally good enough to go with. The problem is that most software developers are artists at heart; we are in the business to add new and innovative solutions to the world. Getting 85% of the way to an elegant solution is disheartening and all to often we are right to feel discouraged. While an 85% solution based on a budget may run the business just fine, that budget is more often then not, built without a technology imagination that envisions the impact of innovation. Great software partners live in a world shaped by the results of innovations, we are often first movers and adopters of technology that actually changes how we play, work, communicate and even think. 85% doesn’t change the world and we understand this intimately. Fluently speaking the language of MOS allows a developer to help a business owner imagine and then calculate the impact real, but perhaps seemingly expensive, innovations will have on his/her business. This gives software developers the opportunity to create real innovation for their clients.

Finally, speaking MOS brings the opportunity to strengthen the partnership by creating a structure which creates a clear picture of the return on investment of a software project or component. The quickest way for a relationship to turn sour is when one partner or the other perceives real or imagined inequity. A partnership with a software company deteriorates quickly when a project is near to or over budget and there was no clear expectation of the ROI for the project or the components. While 20% over budget on a highly valuable component of a project isn’t critical, that same 20% over budget on a feature that will have little impact on the business becomes a big problem. Without a clear statement about the return on investment of each component in a project it is impossible to make these critical decisions until it’s too late and the relationship is in trouble. Measurable success allows ROI to easily be defined before a line of code is written, making it clear how to prioritize a project.

Defining and fluently speaking the language of MOS is critical to a successful software project and in developing long-term partnerships between a business and a software development partner. It’s one of our required steps and has been a key to our success in the very difficult business of improving our clients’ businesses.