How to write for mobile, without writing for mobile

What do we do, as web developers? Do we write a web site? What about an iOS application? How about an Android app? Should we look at Windows Phone 7? Should we even consider writing a Blackberry app? Do we make a mobile version of our site?

Questions, questions

It’s a difficult proposition, what to write. On the one hand, Apple sold 37.5 million iPhones and 15.7 million iPads in three months. That metric alone says to write the iOS application. What about Android? It’s hard to pinpoint an exact number, but lets say the last quarter saw about 40 million Android phones get sold. Windows Phone 7, a bit of a rounding error. Blackberry?

One thing most of these platforms have in common is an advanced WebKit based browser. This means instead of writing one app many times, we can in theory write it once and the mobile browsers just do the right thing. This isn’t a new way of designing web applications. It’s been the de-facto way of writing web applications for last couple of years. Let’s just call it “standards first.”

Thing is, that does nothing to tailor the site to the device. A standards first web site will work on mobile WebKit every bit as good as desktop WebKit. The problem is it’s more than just the rendering engine, it’s about the experience the user encounters with your site.

Writing an app versus writing a mobile site

The next thought typically is to either design a native application or a separate mobile version of the standards first web site. Let’s take those one at a time:

Application

• Tailored to the specific device platform
• Fast
• Expensive to develop
• Separate effort to maintain

Mobile site

• Styled to look pseudo native
• Faster than the regular web site, slower than a native app
• Less expensive to develop than an app, more expensive than standard development
• Separate effort to maintain

Some may take issue with my assertion that a mobile site is a separate effort. Look at all the sites that redirect you to a m.* version of the web site when you visit with your phone. That’s separate development.

What about responsive design?

Yes. I’ve left that one out for now. In cases where you are totally green-field, a responsive design, where you write mobile-first and can tailor for each expected device orientation in the beginning is the best approach. However, like the application and mobile site approach, responsive design has it’s share of pros and cons:

• Optimized for device size and orientation
• Slower than native app
• More initial development than standard development, but not significantly more
• Difficult to pull off unless you are starting from scratch

Stop talking about things not jQuery Mobile!

A fourth option has come about somewhat recently that is very exciting. The jQuery Mobile team has attempted to provide the advantages of building an application without having to invest the resources. Having the cake and eating it, as it were.

View both examples on a phone if you can

Listing users

Listing users


  <% @users.each do |user| %>
  
  <% end %>
  

  

    

      
Name
      
Email
    
  
  

    
<%= user.name %>
    
<%= user.email %>
  

Same page, using jQuery Mobile

  

      
Users
  
  

    

    <% @users.each do |user| %>
      

        
          
<%= user.name %>
          

            <%= user.email %>
          
        
      
    <% end %>
    
  

That’s a lot of awesome for a very minor restructuring of the code. It makes things finger friendly as well as does a good approximation of what a native app looks and acts like. It’s clear that the developers of the framework used iOS as their model, however users of Android and Window Phone 7 devices will also benefit from the larger touch targets, even if the skin reminds them of an iPhone.

What gets really interesting is what happens when you start linking pages together. The framework makes client side requests for links instead of doing full server post backs. This gives the appearance of a more application like presentation, but without the application developer needing to do the ajax wire up themselves.

Like any framework there is a learning curve. Where in native development it’s sets of API’s and coding conventions, here it’s CSS styles and page structure. It’s up to you to decide which set of compromises is best for your environment.

Re-thinking the enterprise

Keynote presentations can be an odd duck. Depending on the presenter, they can either define the conference or defile the mood. I’ve been to both types and am still trying to figure out which group this presenter sits.

So far, I’ve noticed that the font on this keynote deck is about 50% too small. The law of keynote presentation is no font under 48pt. Either that or get the Kalahari to get some up to date projectors that handle something over 480p. Anyway, back to the content…

The thesis here is the educational world is too far detached from the real world. When was the last time you had a programming class, or tutorial that actually tackled a real world problem? Nothing frosts me as much as documentation that solves a problem nobody ever needed to solve. Conceptual problems get taught in class, but rarely find a need to be solved at a job. When was the last time you needed to get the Fibonacci sequence? What about write a quick sort? These problems have already been solved.

The problem and it’s solution are never far apart. Typically, the most recent bits of memory are the ones we usually suggest as the solution. Case in point, you go to a class to learn the “Spring” MVC framework. When you get back and need to write a web app, of course the first and only thing you recommend is what’s new in your mind. We either take the hardest or easiest 10%. Sometimes you just aren’t’ smart enough, which leads to…

Ignorance has never stopped an architect from a solution. We look for shortcuts to end around our deficiencies. This is why we go to conferences, to find the definitive “why” to do something – and sometimes even “how”.

We are now in the era that has problems that don’t fit into the “box->box->box->cylinder” model. We keep trying to fit our problems into a domain that won’t solve it. Reject reuse – big gasp from the crowd – you don’t know what can be reused until you’ve built it. Where will it fail? These are the questions we should be asking, not how awesome product x is, but where will product x not work? Everything has costs, what is being hidden?

A best practice is an attempt to keep you from thinking

This is the suck/rock dichotomy. How great this product rocks versus how terribly this piece of garbage sucks. A best practice really isn’t close to being best. In reality, it’s the average. If everyone follows the practice, it’s the definition of average. Don’t code to the least common denominator. Every once in a while you need to stomp around and smash things.

Yesterdays awesome is todays suck

You will have to learn new stuff. If you choose not to learn, you will be selected out. Law of the jungle put in the cubicle. Choosing to stay put is choosing to stagnate. If you never venture out of your comfort zone, you won’t have a comfort zone very long. Ideas that were once good will not always be.

• Define the goals
• Features are goals, but goals are not features
• Revisit the rules once and a while
• Remember the customers

There is no spoon

There is no answer to rethinking the enterprise. You have to make your own choices and think for yourself. Be your own driver. Grow. Change is the driver that moves us.

One of the misconceptions about HTML5 is that it begins and ends with not needing to use Adobe Flash to play videos from YouTube. Sure, that’s one part of it, but there is a whole lot more that makes up the entirety of HTML5. This pre-compiler session will attempt to fill in the blanks. This is the second pre-compiler of the day and the last session of day #1 @codemash. The first session was a nice refresher into what iOS development can be.

Not six months ago I was at An Event Apart in Minneapolis that had an entire half day workshop dedicated to answering the question: “What is HTML5″? It should be an interesting compare and contrast.

What is HTML5?

HTML5 is not just the markup, but a collection of technologies that when taken together, is the next evolution of the technologies that build our web. These include:

• HTML5 markup changes
• CSS3 styling enhancements
• JavaScript behavior augmentations

HTML5 markup changes

Browser technology has made tremendous progress since the days of IE6 and Netscape Navigator, yet we largely still use the same set of elements to define our content. Years ago, we used tables to lay out our pages, but not describe the content. Later on, we started to structure our markup based on the definition of the content. Lacking a better element, div’s were our semantic weapon of choice.

Based on looking at what designers had been doing over the past decade, the following sets of elements were added to the spec: (I’m including the ones that matter the most to me!)

• Section
• Article
• Header
• Footer
• Aside
• Nav

Note, I didn’t pick audio or video. For better or worse, I don’t find myself supplanting YouTube anytime soon. While I occasionally will have the need to embed a video clip, I’m much more likely to need to structure a set of articles or provide a navigation structure.

Section

A section is very similar to a div, in fact when many people make their site “HTML5″ all they do is replace the div’s with sections. This is not smart. A section is a group of content that is somewhat related. Divs are still very much alive and should be used along side the new elements – they are not a replacement. Of particular importance is the fact that headings are now totally self contained. You no longer have to worry about which level of heading you have in other places in the document, any time you’re in a section (or one of it’s specialized types) the outline starts back at zero.

Article

An article is a specialized type of section. Specifically an article is something that can be syndicated. This doesn’t have to mean via an RSS feed, it can be something like a JSON call, essentially any bit of content that can be consumed multiple ways is a candidate for being represented as an article. It’s one of the more contentious elements in the spec.

Header

Where we once used to class our div’s with “class=header” we can now use the specialized section “header”. You can have one header per page, or multiple headers per element. Header doesn’t refer to the position on the page, but the meaning of the content being expressed. You might have an article that has a header which contains the title, the byline and perhaps the date published.

Footer

Like the header, this is a specialized type of section. The same rules apply to the footer as the header, multiple can exist. Traditional example of a footer are the one you see at the bottom of pages, with the copyright notice, etc. However, like the header, it’s an element that might warrant inclusion depending on what you’re trying to represent. As an example, you could use a footer to include items such as footnotes to an article.

Aside

This element is a bit of a mystery. Like a section, it represents a set of related content. It is however content that is not the primary content. It’s typically seen inside one of the other HTMl5 elements as a place to put content that’s ancillary. This might be a good element to use for a picture that adds some context to an article, or a product photo. The content should be such that if it weren’t there, it wouldn’t affect the rest of the element (whose content remains.)

Nav

Unlike aside, this one has a set mission in life, to contain elements that allow you to move about the web page, site or application. Like the other elements, this is a specialized section and includes the same rules regarding the document outline (independent header levels). It’s not uncommon to have multiple nav elements in a page – you might include a “site-nav” and a “page-nav” depending on the type of navigation you’re representing.

CSS3 styling enhancements

Animations, transforms and columns are the big takeaways. Use an iPhone and notice the animations, or rather imagine how the device would feel if you didn’t have them. The animations on iOS give an app a more realistic feel, CSS3 animations hope to do the same. Hover over a button and you can slightly enlarge the button and perhaps cycle the colors to give the user some feedback that they didn’t have before. Nothing huge, though there are many examples online that showcase what can be done in this very early stage of development.

Columns for layout. This is huge. Right now we have to lay out a collection of sections and float them to have the appearance of columns. This mostly works, but does not handle flowing content from one column to another, and there’s always the problem of dealing with columns of unequal heights and how to style them. Modern browsers such as Chrome and Safari can already use columns for layout, though it will be a little while before other browsers won’t need the javascript hooks we use now.

JavaScript behavior augmentations

Web Sockets

This is the one that really interests me. Right now, in order to feign a persistent connection, we have to poll on a timer. This works, but doesn’t have the fluidity and responsiveness of a persistent connection. This is because the web was designed to be stateless: little bursts of activity. This made a lot of sense fifteen years ago. With applications that start to mimic what can be done with a native app beginning to appear, the need to have a full time connection to the server is becoming harder to ignore.

There’s a nice piece of code developed by one of the ASP.NET principles called “SignalR” that works with web sockets if they’re available. Very good stuff.

Data-Dash

This isn’t necessarily a JavaScript behavior, as it’s markup. However, the usage of such is in the scripting realm – so here we are. If you look at many web applications, you will see attributes added to elements that do not so much as describe the content but rather context (say a record ID.) This works and browsers happily don’t render attributes they don’t understand. It’s not valid markup though. Use ‘data-recordid=98′ instead of ‘recordid=98′.

Conclusion

Not a lot that differentiates this from the workshop at “An Event Apart” though it’s nice to see reinforcement from a set of Microsoft presenters.

So, CodeMash happened last week. Following up my busy conference schedule of 2011 I start the New Year off with a three-day blitz of immersive code, bacon and beer. It’s not my first developer conference, but it was my first CodeMash.

The idea behind CodeMash is an interesting one. You get twelve hundred developers of all stripes and mix and match the sessions to the stripes. It’s totally different from say WWDC (world wide developer conference) where there is a singular focus. At CodeMash, it’s every technology for itself. Every viewpoint is considered, every opinion a valued voice. It is definitely a change from both the fire hose crazy of WWDC and the structured blitz of AEA (an event apart.)

The first order of business is figuring out which sessions to hit. The easy path is to find buzzwords you recognize and fall in line with the comfortable things you already know. I didn’t do that (mostly anyway.) Here’s the tale of the tape:

• iOS 5 Development : Precompiler
• HTML5 Workshop : Precompiler
• Microsoft Web Stack of Love
• Async with C
  * iOS Networking
• Organizing JavaScript* Signal R
• Information Overload* Beautiful Front End Code
• Bacon

Yes, I know that I just spent a whole sentence decrying the natural tendency to stick with what you know and using this as an opportunity to branch out. Frankly, there were some wacky sessions that I couldn’t justify attending and some that I could clashed with a few I really wanted (the Hansleman sessions especially).

The high level view of CodeMash is an odd one. On one hand there was quite the variety of sessions to attend. The flip side is the quality of the speakers varied wildly. Some were very sharp and others seemed to be filling time awaiting the bacon bar.

Then. The keynote. Never in my life have I sat in a hall and been bombarded by more f bombs, outside of a George Carlin event. The speaker had a very good riff, I felt he hid a bit behind the vulgarities. Too bad, it diminished my thoughts toward his thesis.Tomorrow, the code.