Category Archives: tech

HTML5 App Stores don’t go too far enough

tl;dr - HTML5 app stores don't leverage the web as much as we should.

Futurama Political Debate

 I'm convinced that packaging HTML5 apps for stores is emulating failure. There are lots of reactions. Among the comments here, Les made the opposite assertion of mine - "where app stores win over plain old URLs is discoverability. ... URLs are precise, but they’re sharp and pokey for most people to handle."

HTML5 App search engine > Pokey URLs

Les made his own counter-point that we fixed pokey URL's with search engines. So, do we need "a special case search engine where the results are constrained [to HTML5 apps]"?

Maybe.

The "webby" approach is to crawl the web to build an index of all app manifests. But how can we discover the manifests? None of the HTML5 app stores document a way to hyperlink manifests.

But maybe we can use schema.org SoftwareApplication type, with its convenient installUrl property. We can even use the WebApplication sub-type's 'browserRequirements' property to designate a Firefox, Chrome, or W3C manifest. So Incredible Pizza could expose their HTML5 app like so:

<div itemscope itemtype="http://schema.org/WebApplication">
  <a itemprop="installUrl" href="http://app.incrediblepizza.com/incrediblepizza.webapp"><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Firefox</span></a>
  <a itemprop="installUrl" href="http://app.incrediblepizza.com/incrediblepizza.crx"><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Chrome</span></a>
  <a itemprop="installUrl" href="http://app.incrediblepizza.com/incrediblepizza.wgt"><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Opera, Windows Phone</span></a>
</div>

Voilà. We have web technology to make an HTML5 App search engine. But why are HTML5 app stores making developers manually submit manifest URLs to directories when we could leverage hyperlinks - the central nervous system of the web? As a bonus, a hyperlink-fueled HTML5 app search engine is complimentary to existing mobile platforms. This could be nice:

iOS App Search mockup

Apps contextualize content

Still, an HTML5 app search engine doesn't leverage the web as much as we could. Ambrose Little suggests "discoverability is worse [on the web] because it’s not just apps, it is all kinds of content, much of which is not pertinent nor optimized for your device." This gets to the crux of the issue: outside of pure experience apps like games, when we say we want apps, what we really want is relevant, contextual, optimized content on our mobile devices. Can we deliver relevant, contextual, optimized content to mobile devices without apps?

In Programming the Mobile Web, Maximiliano Firtman touches on this in his chapter about geolocation:

One of the great features of mobile devices is that they can go everywhere with us. That is why the where is very important context to be considered by our websites. Knowing the user's location can help us to show useful contextual information -Firtman

Geolocation is a great place to start, since it's so widely supported on existing mobile browsers. I suggested that incrediblepizza.com could return location-specific content using a captive wifi portal or geolocation. But fuzzy search can also deliver location-specific content, as Google Maps does; though it could be improved to deep-link into a domains' pages with something like GeoURL or a geofenced sitemap.

I.e., if incrediblepizza.com added:

<meta name="geo.position" content="36.05877;-95.8831" />
<meta name="ICBM" content="36.05877, -95.8831" />

to their Tulsa store location page, and maybe add a geo point and radius to their sitemap:

<url xmlns:geo="http://geositemaps.org">
   <loc>http://www.incrediblepizza.com/locations/tulsa</loc>
   <lastmod>2013-01-01</lastmod>
   <changefreq>daily</changefreq>
   <priority>0.8</priority>
   <geo-radius>36.05877;-95.8831;30</geo-radius>
</url>

mobile search could do something like this:

iOS Search for Pizza

Search already works

We can search for a pizza place nearby. So what? Foursquare already does that.

But do we have to search for it? As predicted by Mike Masnick back during Yahoo's misguided deal with Microsoft in 2009, "People are discovering that information finds them, rather than them going in search of information. Search already works. The next interesting challenge is in improving the way information finds you, rather than the way you find information."

Improving the way information finds you is how social competes with search, and it's the way mobile web should compete with app stores. Location, time, personal information, preferences, friends, actions - all of these create the context in which information should find us. Chris Cox from Facebook summed it up:

[Mobile phones] should be contextually aware. Check-in to flights, find deals at grocery stores, etc. These things take a bunch of clicks now — it’s all wasting time. The phone should know what we want.

My phone should know:

  1. I have 2 kids under the age of 4
  2. We're near south Tulsa
  3. We typically eat out on Tuesday nights
  4. It's almost dinner-time

It should query the web. To which incrediblepizza.com replies:

  1. Kids 3 and under eat free
  2. We're located in south Tulsa
  3. We have double-play-points specials on Tuesdays

incrediblepizza.com and my phone inform me automatically. This touches semantic web stuff; and maybe that's something we mobile web developers should be touching. Because ...

The only group who can contextualize everything is everyone

The web will obsolete app stores ... again. In Scott Jenson's "Why Mobile Apps Must Die" talk at BDConf 2011, he longs for a web-based phone, and a discovery service that helps us find the right needles in the needle-stack of connected things. He calls it "a baby step towards this idea of doing just-in-time interaction" and says "I can guarantee you this will not happen thru apps."

Why not?

Christian reminds us of Yahoo's first (failed) attempt at re-creating a categorized directory of the web. If you don't have time to read Clay Shirky's classic perspective on ontology at least watch this great related 5-minute video:

Even if you skipped both, here's the crux of the matter (emphasis mine):

Yahoo ... added the shelf back. ... The charitable explanation for this is that they thought of this ... as their job, and as something their users would value. The uncharitable explanation is that they thought there was business value in determining the view the user would have to adopt to use the system. Both of those explanations may have been true at different times and in different measures, but the effect was to override the users' sense of where things ought to be, and to insist on the Yahoo view instead.

You can replace "Yahoo" with "Apple" in the preceding statement and it mirrors the current situation of Apps. The web out-grew Yahoo's shelf; it will out-grow Apple's, Google's, Microsoft's, and Mozilla's shelves. Our sense of where things ought to be and how things ought to find us is better than any vendor's. "The web is going to win again. The web always wins." as Johnath says.

The web will win sooner if we spend less time on the shelves and more time delivering relevant, contextual, optimized content to mobile devices.

Packaged HTML5 Apps: Are we emulating failure?

tl;dr - URLs delivered a better experience than native desktop apps; they can do the same for mobile apps.

update: see my follow-up post - HTML5 App Stores don't go too far enough.

HTML5 in a box

When we discussed Sencha's Fastbook app on the mozilla.engagement.developers list Robert pointed out that Sencha compared their HTML5 app running in mobile web browser to Facebook's HTML5 app running in an iOS WebView - the way Sencha & PhoneGap packaged HTML5 apps actually run. It's widely discussed, as we did with Fastbook, that HTML5 apps perform worse in iOS UIWebView than iOS Safari. There are similar stories about Android WebView performance, and Tulsa Web Dev and HTML5 PhoneGap developer Rod just posted a similar performance-related anecdote about BlackBerry WebWorks.

That made me think, "PhoneGap is just that - a stop-gap." ... "we should drop this whole PhoneGap App nonsense and go (back) to mobile web at simple URL's" since:

  1. App discover-ability & installation sucks
  2. App content discover-ability sucks

App discover-ability & installation sucks

A couple months ago, my wife and I took our daughters to Incredible Pizza. When we sat down, I saw this table-tent:

Incredible Pizza Table-Tent

I spent a couple minutes trying to make this "check-in" UX work on my wife's phone. The table-tent literally reads: "TIP: A QR-Reader App is necessary to scan QR codes. There are several free ones available. Check your app store." So, here's what I did to find an app:

  1. Connect to Incredible Pizza wifi
  2. Tap "All apps"
  3. Swipe down to "Play Store"
  4. Tap "Play Store"
  5. Tap "Search"
  6. Type "qr reader"
  7. Swipe thru a huge list of apps
  8. Pick one at random (*)
  9. Tap "Install"
  10. Tap "Accept & Download"
  11. Wait for download & install

Android prompts me with a wall of permissions that I have to accept in order to install the app. And because app updates with new permissions can't be automatically downloaded & installed, many app developers just make their app request all permissions.

* Especially interesting to developers - I picked a free qr reader app at random, verifying that App Stores are more like casinos than gold-mines.

Content discover-ability sucks

Once I had the QR reader app, I started to use it to check-in to Incredible Pizza on Facebook:

  1. Hold the phone in front of the card
  2. Tap "Visit Link"
  3. Tap "Browser"
  4. Go thru 5 redirects to a prompt to open native Facebook app
  5. Facebook opens
  6. Wonder: "Why am I trying to do this in the first place?"

There was no human-readable URL on the card. I had to choose between "Browser" and "VZ Navigator" that came with the phone from Verizon. The redirects took about 20 seconds. Finally, since they don't deep link into the native app, I ultimately end up just staring at the Facebook app as if I'd opened it myself - nothing there at all about Incredible Pizza.

This totally obscures the app's content, and value, from the user. If I package my HTML5 app with PhoneGap I have to also register a custom URL scheme to link to a specific part of it - something PhoneGap doesn't help you to do(?). And even when you do it, you will need to make and deploy an update to the app anytime you want to add new URL-driven logic to it, invoking another round of app review.

The Plain Old URL approach

Contrast the above experience with a more traditional web approach:

  1. Connect to Incredible Pizza wifi
  2. Tap Browser
  3. (Maybe) Type "incrediblepizza.com"
  4. (Maybe) Tap "Yes" at a geolocation prompt

Incredible Pizza could immediately give me the store-specific web page via captive wifi portal with big buttons for location-and-date-specific coupons, facebook check-in, etc. Or, if I'm not on their wifi, I type "incrediblepizza.com" to get the same thing via geolocation. In addition to a simpler experience, deploying new or updated content is as simple as updating the website.

So why package HTML5 apps?

Considering all the above, I usually ask web devs using PhoneGap: "Why are you using PhoneGap instead of just putting an HTML5 app at a URL?" and they often reply "everyone wants an app." This "everyone wants an app" situation is a problem we developers and designers should address - but not just technically. We should work with our clients and customers to consider the full user experience of native vs. web - especially app installation & content discover-ability.

... although many brands and creative agencies believe that they need to develop iPhone apps, what they need in reality is a good mobile site. It costs less to develop, manage and work across all handsets.

- HTML5 - The End of Apps | Mobile Europe

If you're making an HTML5 app, consider - do you want to make a native desktop application? Why or why not? Then consider if the same reasoning is true for the native mobile application. Consider the URL experience for your customers. Walk your clients thru both native app and URL experiences on mobile devices. We used web URLs to deliver a better experience than native desktop apps - we should do the same with mobile apps.

Good HTML5 Packaging - URL Bookmarks

Vendors like Mozilla (disclaimer: my employer) and Google are also working on manifests to install HTML5 apps on Firefox (OS) and Chrome (OS). Opera and previously(?) Microsoft (via Silverlight) use the W3C Packaged Web Apps (Widgets) standard. I like these efforts if they contribute towards a consistent "installation" experience that works more like an enhanced bookmark. I.e., turn this:

  1. Visit URL
  2. Tap "Add to ..."
  3. Tap "Add to Home Screen"
  4. Tap "Add"

into this:

  1. Visit URL
  2. Tap "Add to Home Screen."

But next time you make an app, consider the tried-and-true web experience:

  1. Tap Browser
  2. Type URL

mac raspberry pi dd permission denied

Raspberry Pi Grayscale Logotl;dr - If you get "permission denied" errors while trying to dd a raspberry pi disk image on your macbook pro, try blowing out your sd card slot to unset its "disk lock" switch. Seriously.

I love Mac's for the almost-linux environment coupled with a nice, rich, high-performance GUI. But every once in a while we Mac users have to search a couple extra error messages when we try to do more "linuxy" stuff - e.g., preparing a raspberry pi sd card.

This morning I got my HDMI cord for my pi, so I went thru the raspberry pi quick start guide including the easy sd card setup. But, even though I unmounted the disk and ran `dd` with `sudo` I still got "Permission denied"

I googled for this blog post title and found a topic on the Raspberry Pi forums, but the answer that seemed to work for most people was down at the bottom of the thread. So I'm re-posting it here, because it's funny, and so someone else having the same problem might fix it faster.

Apparently, 15" 2010 MacBook Pro's built-in SD card reader's get stuck in the write-locked position. So bust out your old Nintendo skills and give it a blow to clear it out. If you never had an NES, your weak under-trained lungs might need you to use a compressed air can instead. Pansy.

Facebook never bet on HTML5

I'm going to jump into the mix, but my post is short and sweet. In fact, I wrote it while waiting for tests to run.

Facebook never bet on HTML5. Anyone remember the convoluted rambling of Dave Fetterman at f8 developer conference last year? I remember being both dumbfounded and confounded by it.

So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebook in the iPhone. So, you build much smaller native goop instead of having to build over and over again.

...

HTML5 is probably the way that we should have done it.

Near as I can tell, Facebook invented their own PhoneGap (i.e., FaceWeb) and sent m.facebook.com to it, then FaceWeb changed webkit's rendering logic* to match m.facebook.com instead of changing m.facebook.com to a mobile HTML5 site? That's not HTML5 - that's just stupid.

* UPDATE: as pointed out in comments, this isn't exactly accurate. Faceweb does some funky stuff though, and their engineering manager in charge of the project couldn't even articulate what it is. So it still sounds like bad engineering unrelated to HTML5.

* UPDATE 2: You should read Matt Asay's analysis of Facebook's HTML5 fiasco. In fact, you should read everything Matt Asay writes.

Please Learn to Eat the World

TL;DR Code is eating the world the same way writing ate the world. We don't all have to be expert writers - of language or code - but we should all be literate in both.

Jett Atwood's "Please Don't Learn to Code" post shocked me a bit, because I agree with almost everything else he posts. I agree with much of it, but the "everyone should learn programming" meme is not the straw man he criticizes, it's a young nebulous movement. E.g., the Mozilla Webmakers initiative is just a series of blog posts and some communication channels organized on a wiki page. So Jeff's input could and should be formative somewhere like the next Webmakers community call.

Writing ate the worldWriting Technology - art from Civilization 5, according to Sid Meier

My MDN colleague and technical, sci-fi, and beer menu adviser Les makes a good "Please Do Learn To Code" counter-argument. I want to elaborate on his analogy to writing:

Consider writing: there's a lot to learn and it used to be a thing done only by a few scribes. But, people today get a lot of mileage out of just sticky notes and email. Sure, improving your grammar and learning how to structure an essay can help in many, many ways. But, you don't need to be a professional writer to be a professional who uses written language.

Consider the state of the world at the time writing was invented/discovered. In Civilization 5 (which is my definitive guide to history), Writing can be preceded by Pottery, Sailing, Trapping, Archery, Horseback Riding, The Wheel, Masonry, and Metal Casting. In a world of subsistence-level agricultural society, writing was a luxury knowledge skill. Maybe there's an ancient "Writing Horror: archiving and human factors" scroll telling potters, sailors, and animal trappers "Please Don't Learn to Write" - suggesting that the general populace only needs to memorize the laws of the land and sign their own name to it.

In Civ 5 - Writing enables Philosophy, which combines with Trapping to enable Civil Service, and also combines with Calendar to enable Theology, which combines with Civil Service to enable Education. Education combines with Compass to enable Astronomy & Navigation, and with Chivalry to enable Acoustics, Banking, Economics. These disciplines combine together in Scientific Theory which enables the Industrial and Modern Eras of advancement - Electricity, Telegraph, Radio, Electronics, Mass Media, Computers, Robotics, Particle Physics, Nanotechnology.

Yes, this is a simplified and gamified perspective, but the truth is, while writing is only of ultimate importance "... in the right context, for some people." the incorporation of writing into other disciplines has been the foundation of the modern world. Reading and writing are the fundamental knowledge skills for every person in every modern occupation.

Code is eating the world, according to Mark AndreessenComputers - Civ 5 Art

Writing is a technology that allows someone to externalize thoughts into a medium that can be communicated to others who parse, interpret, and process those thoughts. Code is a technology that allows someone to externalize instructions into a medium that can be communicated to computers that parse, interpret, and process those instructions. We call that externalization of code, software.

Marc Andreessen always seems to know what's going down and what's coming up. And back in December he wrote a great WSJ essay on Why Software is Eating the World - a survey of industries all across society that are being consumed by software-driven activity and operations. Code combines with book-selling to enable cloud computing. Code combines with telecom operators to enable world-wide video chat (like we were promised would happen in the 23rd or 24th century). Code combines with aviators and aerospace to launch airstrikes without putting pilots at risk. Code is eating the world, just as writing did before it. These combinations seem obvious and intuitive to those of us who make software, but they are neither obvious nor intuitive to everyone else. Jeff is spot-on when he says everyone should know enough code to know "when code might be an appropriate way to approach a problem you have" but his implication underestimates how many problems can be approached with code - i.e., almost all the problems.

What does a code-literate world look like?

Jeff has a laundry list of other problems with the "everyone should learn to code" movement. My vision of a code-literate world is quite different:

  • There's less code. Coders undoubtedly realize that fully 90% of our time is spent reading code rather than writing it. When we do write code, we often refactor existing code. In a code-literate world, more people are aware of this, not fewer. So more people buying code understand that less is more.
  • There's more solutions than code. Even if code hasn't eaten the problem space already, more people are aware of the ability to re-use code, especially open-source code. More people understand how and when to apply code to problems.
  • There's new jobs in place of old ones. Jeff's right about entry-level programming jobs, though I dislike the trace of Silicon Valley hubris. Sure, "many people in the U.S. and around the world lack the education and skills required to participate in the great new companies coming out of the software revolution." But, "This is a tragedy since every company I work with is absolutely starved for talent. Qualified software engineers, managers, marketers and salespeople in Silicon Valley can rack up dozens of high-paying, high-upside job offers any time they want, while national unemployment and underemployment is sky high. This problem is even worse than it looks because many workers in existing industries will be stranded on the wrong side of software-based disruption and may never be able to work in their fields again. There's no way through this problem other than education, and we have a long way to go." -Andreessen

Jeff makes fun of the notion that NYC mayor Bloomberg learning to code will help him make public transit improvements. But Tulsa Web Devs are dealing with this right now as we write code for Tulsa Transit to put our local bus routes and schedules onto Google Maps. Even in the IT department, coding literacy seems low. They're "able to get around on the Internet" and they have "a basic understanding of how computers, and the Internet, work." But they buy code from Trapeze Group - they can't read it and they certainly can't write it. If the Tulsa Transit General Manager went thru Codecademy he could go to our github repository and read the code he sees. But because he doesn't know how to code, our code is as arcane to him as the box of software he buys from Trapeze. From my interactions with Code for America Brigade, I detect this scenario plays itself out in many places and in many sectors.

Code is eating the world. If people don't learn to code, they'll be eaten by it. Coding shouldn't be practiced by an elitist cabal of programmers selling software charms to illiterate masses. Our world is full of consumerism and starved for makerism already. We should encourage and teach others to code. Like writing, it creates opportunities, enables progress, and advances all of society.

{{ your_town }} Hackathon

Main Street PixelsLast weekend we did our Tulsa Hackathon - the summary post has links to sites and code we made and a local media live stream where I talk too much like an idiot.

It was a great experience. Mozilla sponsored our after-party (thanks Stormy!) where I emphasized Mozilla's mission to open and improve the web for everyone - from 450 million Firefox users all over the world to 40 developers in Tulsa, Oklahoma. Here's a quick summary of the projects that more-or-less finished (more details at the website):

At Mozilla we have lots of remote employees who live in towns outside of the "hugeness bubbles" like Silicon Valley. I want to encourage any and all remote employees to get involved with their local technology and developer communities. To promote the Hackathon, I went on a whirlwind tour of our local groups - I spoke about Solr @ Tulsa Java, mobile web development @ Mobile Tulsa, attended a Tulsa .Net developers meeting, arranged an HTML5 track at Tulsa Tech Fest (where Dave gave us the big auditorium stage!), and attended our community leadership town hall. It was tiring, humbling, and inspiring. I'm still processing it all.

Programs like Mozilla Reps help amazing and effective volunteers to promote the Mozilla mission in local communities. In fact, out of all this activity, one of our Tulsa Web Dev's is applying to the program. But that shouldn't offset employees evangelizing for a free, open, and better web right in our own back yards!

[‘Tulsa %s’ % e for e in (‘Tech Fest’, ‘Hackathon’)]

Tulsa Driller in PixelsTulsa Tech Fest

In addition to our work on MDN, this is a busy week for me in Tulsa - the annual Tulsa Tech Fest is Friday Oct 7th. Our Tulsa Web Devs group is doing an HTML5 track; my talk is the intro - HTML5: Code for all the platforms! (Soon to be a link to the slides)

TTF is a Microsoft-heavy event, but we've come a long way since TTF 2007 when Steven and I did the entire PHP track ourselves, covering Eclipse & PDT, PHPUnit & Selenium, CI w/ Phing & CruiseControl, DB refactoring w/ dbdeploy - sophisticated topics for 2007!

As far as the Tech Fest goes, I'm really looking forward to the community town hall the night before - developer group leaders from all around Tulsa get together to talk about how to grow the Tulsa developer community. I'm eager to see how the other groups are doing and to share experiences.

I'll spend all of Friday in the HTML5 room, unless I'm pulled off to the

Tulsa Hackathon

Tulsa Hackathon is a big event for me, as I've done a bunch of work for it.

It all started when Tulsa Web Devs took it upon ourselves to put Metro Tulsa Transit Authority data onto Google Maps. After a few hack days we made it work - barely. We still don't have all of MTTA's data, and we didn't make a shape file to smooth out the way Google draws the bus routes to match the roads, but we did pass the GTFS validation test! All that's left is to get MTTA to use our tool to publish the feed for Google - something that's proving harder than any of the code, I think.

In any case, most of us enjoyed working on a cool project that improved Tulsa. So, I reached out to other organizations to see what other projects we might try. Over the last couple months, we've set up projects for INCOG (another transit org in the area), Tulsa City County Library, Community Food Bank of Eastern Oklahoma, and Fab Lab Tulsa. We're an official Random Hacks of Kindness community event!

Scott Phillips and I have arranged all the facilities and venues, logistics, swag, meals, etc. I'm anxious to see how much we actually get done. But really, there are just two goals - improve Tulsa, and our developer community.

Thank you Stormy (and Mozilla) for helping to sponsor our Hackathon! Everyone in Tulsa loves having Mozilla involved! I love that Mozilla promotes the web for public benefit - from hundreds of millions of Firefox users to a few dozen hackers in Tulsa Oklahoma.