moebius recursive

It feels like the tech industry is still trying to work out what the optimal mobile user experience should be. And it also feels like we have been down this road before. Like when we went from a comfortable desktop (client server) design/development paradigm to a browser-based one it took a while to figure out that they weren’t the same and how to exploit the differences.

Think about it. At the time of the browser shift the desktop development mentality was around using Visual Basic and a huge palette of visual components (most of which were just fluffy eye candy). So the first impulse of the industry was to try to replicate that (admittedly hideous) component heavy user experience/development model inside of the relatively austere HTML model. This gave birth to the loathsome Java Applet and the even more vile ActiveX control. The industry had completely missed the boat by treating the browser as a heavy desktop application delivery mechanism rather than exploiting the lightweight, largely device independent model that HTTP/HTML provided.

It took about ten years time before HTML/CSS/Javascript and related standards support in browsers made it possible to have truly rich interactions within the browser without having to assume a pretty heavyweight underlying infrastructure for most in the industry. It is worth noting that both Microsoft (.net) and Adobe (AIR) continue to flog this decade-old failed development/delivery model. Any technology that assumes that there is several gigabytes of code on the (lightweight) client is not a proper technology for developing browser-based applications (nor mobile ones for that matter).

Now it feels like we are in the same place with mobile development and user experience — far too many people look at mobile devices as if they are just a desktop browser/computer with a smaller monitor attached to it. But for the mobile experience to be successful, applications need to be designed to address the constrains that are on most mobile devices not try to force them to be mini-desktops. This includes not forcing mobile users to endure your useless Flash-only sites, popups, gratuitous CSS layers, plugins, requiring too much typing and browser specific markup.

To some extent, Apple is leading the way with changing ideas about mobile development with the iPhone SDK (and all of its constraints and limitations). The difficultly with this is that what Apple defines is okay for Apple, not necessarily for the rest of the mobile industry. This can lead to something else we have seen in the past — a ghettoization of the mobile experience between sites ‘optimized for iPhone’ (eg IE) and what everyone else gets.

I am no expert, but it feels like we have the basis for a successful, flexible implementation on mobile devices in the guise of XHTML/CSS/Javascript. Flash and other desktop legacy apps just won’t cut it. Combine that with microformats to facilitate data sharing (and potentially reduce keying) and ‘designed for mobile’ interfaces and we have a fighting chance.

Note: I subsequently found this posting on The Web Beyond The Desktop that does and excellent job of both reinforcing and expanding some of the points that I was making.

Technorati Tags:
adobe, browser, design, development, flash, innovation, iphone, javascript, microformats, mobile, technology, ubiquitousdata, webdev

 

The source of the title of this posting comes from a document that I was reviewing recently. The author was going on and on with buzzword-laden run-on sentences in which he proudly proclaimed how he had revolutionized development at a company through the application of ‘agile mythodology’. I laughed out loud and decided that typo was a keeper because it expresses some of my feelings about and experiences with agile.

Don’t get me wrong, I have seen agile work very, very well when it is used to structure the execution of the development phase and/or when agile design and modeling approaches are well understood and applied. Where agile absolutely falls apart is when it is twisted into the ‘I don’t have to design or document anything — I just make it up as I go along’ approach that many proponents advocate. Agile delivery is not a substitute for proper design and documentation. This is the mythology part: that you can create quality software by fiat. It is easy to pick out the agile mythologists; listen for their disdain for ‘architecture’ and ‘documentation’ and ‘standards’ while all the while no producing any acceptable code.

I recall being asked to do an architectural review of an ‘agile’ project. When I asked for the standard project documentation I got the asinine response: ‘The code is the most accurate documentation for the system’. Really. So show me in the code what the security requirements are and how they were approved by corporate security or where the scope and objectives are (and on and on). I wasn’t about to accept the ‘trust me I coded what the customer wanted; oh and by the way, you have no way of verifying that’ BS.

Agile-boy eventually came back with a link to a wiki (cus’ wikis’ is agile-cool) that had a handful of paragraphs on it and some links to a few UML diagrams (several of which had nothing to do with the project at hand — but I wasn’t supposed to be smart enough to figure that out). Needless to say the project was shaping up to be a disaster and was saved only when a proper design and more ‘traditional’ development approaches were hastily put into place.

Technorati Tags:
agile, architecture, development, dubious, ideas, , mythodologysoftware