Development and UX from Michael Mahemoff. Maker of Player FM. Previously: Google, BT, O'Reilly author.

Menu

Tag Archives: html5

This comes from a talk on mobile web given by PPK the last time I was in this part of the world, before a full house at the very large eBay/PayPal “town hall” in San Jose on April 6. I decided to hold off posting it as he mentioned he’s not releasing the slides so he can deliver the same talk a few more times. With two imminent talks on mobile HTML5 today at Google IO, timing is right to hit the Publish button.

This is still a live blog (I’m far too lazy to edit such things even after the event), so usual typo etc caveats apply.

(>Picture from a different event on the same topic…but how could I not include this one?)

Amid a frenzy of mobile HTML5 hacking at the HQ, I spot a tweet from the veritable @dalmaer:

I’m in the area and not going to let the opportunity pass. So here I am.

PPK, Quirks man that he is, explains that the mobile web is more exciting than desktop these days. Twenty browsers and counting! But beyond the proliferation of browsers to pore into, mobile matters. Eventually around five times the number of desktop users in PPK’s estimate.

Luke Wroblewski invented the “Mobile First” mantra. The mobile constraint forces you to design lean. Even a big screen is 480*360…that’s what you get to deal with, and any fluff sends them right to your competitor. Consider a news site. All you see is headlines. Funny about that, it’s all you really need.

On Mobile Browsers

PPK lists a plethora of mobile browsers and asks, “Do you have to test on each of these?”. Answer: “In theory, yes. In practice, don’t be silly.” PPK continues to drive his message that there’s “no” mobile WebKit. Witness the comparison of mobile WebKits at http://quirksmode.org/webkit.html.

It’s important to be aware of the Proxy Browsers, namely: Opera Mini (not Opera Mobile), Ovi (upcoming from Opera), Bolt, and UCWeb. With these browsers, a highly compressed image is sent to the client, and this actually has two (potential) benefits: less network cost and less device requirement. However, once you get fancy with client-side scripting, these devices won’t do much at all. It’s just not what they’re made for.

The Stattage

Time for some stats. According to StatCounter, in Q4, 2010:

Safari: 23%

Opera: 22%

BlackBerry: 18% and dropping

Nokia: 16%

Android: 12% and growing fast

NetFront 4% (on basic Sony Ericsson and Samsung)

Samsung 1% (on Bada)

MS doesn’t feature here because many manufacturers introduce Opera (or other) instead of relying on the default IE browser. Interestingly, the Bada browser was met approvingly when PPK showed it to folks recently, and does well in performance.

It’s important to be aware of your own stats and circumstances too, e.g. PPK noticed, for his site at least, social media referrals cause disproportionate queries from iPhone and Android. So people dependent on social media should think about those.

PPK says right now, the browsers for most developers to consider, are Safari iPhone, Opera Mini, and Android Webkit. Beyond that, it depends on geography. In the US, BlackBerry is next to consider. Unfortunately, a recent stat said 90% of BlackBerry users are still on 5.0 or older, ie no WebKit and a very quirky browser. In Europe, Nokia WebKit matters more. Beyond that, Dolfin for bada and Opera Mobile are worth considering; fairly low mobile share, but pretty easy if the others worked.

“Mobile gives us the opportunity to practice what we preach when we talk about web standards”

We all talk about progressive enhancement, but who actually uses it? Again, mobile forces your hand! Basic JavaScript, to augment your semantically sweet HTML, is fine. But advanced – Ajax requests and beyond – may not, so think of progressive enhancement as a spectrum. Also, remember Ajax reuests go over the network, so they can slow things right down and require caution.

PPK argues for feature detection where possible, but experienced developers say browser detection is the only way in some cases.

The Future of Apps

HTML5 is not just a technology that runs in the browser, but one that powers apps. This is a conversation PPK just about kicked off a couple of years ago, and recent trends have begun to vindicate this view. Plugs for http://apparat.io and http://build.phonegap.com from PPK right about now.

PPK Questions the Future of App Marketplaces

Right now, the proverbial developing-national fisherman might pay $25 for a Nokia feature phone. Stuff is changing. This year, we’ll probably get $75 Android phones, says PPK. Too much for the fisherman right now. But give it a few years and the fisherman’s phone is running apps. Is he using a marketplace? Right now, those mostly require credit cards, so what happens? Download from the net? Too expensive.

So this is where PPK talks about transferring apps device-to-device. The apps are transferred by bluetooth or NFC and the data transferred with JSON-over-SMS. PPK says it’s hard right now to transfer via bluetooth on newer phones, where it works fine on future phones. The end of app stores is a consequence of this vision, sharing Eric Meyer’s quote: “Why is everyone so exercised? As with all walled gardens, the web will interpret the App Store as damage and route around it.”

(MM – This opens up a lot of security concerns.)

Why does PPK think the marketplaces won’t work for all the platforms in the long term?
* Discoverability – worked in the past, but is harder in a more cluttered environment.
* Distribution – the web works just as well or better for distribution
* Works for Apple – it’s proven that the average Apple consumer will spend money on Apple. PPK argues Google has more leverage with developers than consumers. He says that’s the opposite for Nokia, Samsung, and RIM – in his theory, they have high leverage with consumers and low leverage with developers.
* Cost of Ownership – Marketplaces need payment systems, sysadmins, content checkers, documentation and best practices writers, and they cost money.

Mobile is about to explode – where the web escapes and comes with us, to the car and walking around etc.

Same way you had to sit down and listen to the record player instead of having music mobile. “I can’t believe you had to sit down to use the web”. Use it like a phone, e.g. avoid long forms, make phone numbers clickable, don’t include word docs!

The Web is evolving:

Web of documents is becoming a web of applications

Declarative HTML becoming programmatic DOM

Templates becoming APIs on the server-side

URLs becoming arguments (ie command-line)

RequestResponse becoming synchronisation

The HTML5 mobile stack looks basically like a native mobile stack

Browsers are much stronger these days, including IE9’s effort. But nevertheless, there’s still a range of varying support for the browsers.

So can’t rely on everything, but some features are there now and diversity is something web developers do have to live with. These tools help:

James walks through some of the frameworks. Compared to jQuery mobile, Sencha is more of a pure client-side library – less reliant on a server outputting HTML. Tends to be more script focused than markup. In an MVC way.

Demo: http://sencha.com/x/5e

What W3C calls Thematic Consistency – should get same content on different devices, even if laid out differently. Lots of possibilities – e.g. do you have a special mobile version.

We can have user interface, business logic, and storage on the client; and security and storage on the server.

Whoa – security on two sides means we have a new problem for the web. Storage on both sides. But it’s a well-understood problem outside of the web.

Share this:

I did my talk on Single Page Apps and this morning at QCon today on Single Page Apps and HTML5 History. The demo raised a number of interesting design principles/patterns which I’ll cover in a later post…but for now, I’m going to post a few live blogs from sessions here. [Update – AlBlue’s posted a summary of talk.]

First up, Dave Recordon explains how HTML5 is being used at Facebook.

Dave Recordon explains he works with Facebook’s developers to promote web standards and HTML. What is the promise of HTML5?

He begins by asking the obligatory, “What is HTML5”? His definition agrees with mine – not just a spec, but the technologies that let developers make awesome apps, and a brand that developers can rally around.

HTML5 at Facebook – Today

While some say HTML5 isn’t ready till 2025, Facebook wrote on their blog about “Using HTML5 Today”, a look at a bunch of things they’re already working on:

History.

Facebook has a framework called Big Pipe which loads the overall page structure, and then a second structure called QuickLink which overloads links to reload just parts of the page. This led to ugly URLs, with fragment IDs e.g. http://www.facebook.com/profile.php?id=24400320#!pages/Engadget/5738237369, and history gets them around that.

Recently, they created a new photo app which involves photo sharing and lightboxen to show the photos.

Web Video

Dave explains that Facebook hosts a lot of web video, and there’s no clear way to deal with it rigt now because of codecs…but, he says, it’s fair to say most people today would go with H.264 or WebM. Today, H.264 is Safari and IE, WebM on Chrome, Firefox, IE, and Opera. This difference, as well as DRM, is one of the reasons why people are still choosing Flash for video.

Dave bigs up video.js as a way of dealing with the complexity, and says they’re still using Flash for the most part, with the following advice:

Use your own Flash player if you’re already built one.

Use the same size poster image, raw video file, and Flash player.

iOS devices only support H.264.

Storage for double (or even triple) encode become costly, quickly.

Sprites and Gaming

They analysed the requirements for gaming. 10fps gets you minimum interaction for a game, but really you need to focus on 30+ frames per second, so this is where they focused. How many sprites do you need for a game? 5 sprites for a simple baord game, leading up to 100 for a 2D game (that’s the scope they focused on). They found the modern browsers can deal with the requirements well, e.g. with WbGL, Chrome 11 can handle 4000+ sprires.

He walks through various options for showing a spaceship. Just an image? A sprite? But if so, a div with a background image or a mask over the big sprite sheet image. They’ve done research to this end.

See http://github.com/facebook/jsgamebench

Mobile

Hundreds of millions of people access Facebook from their phones, so Facebook’s looking into how HTML5 can help here. Which platforms do you need to target?

Features phone

iPhone

Android

BlackBerry

Palm Pre

Windows Phone 7

Dave says that even for Facebook, let alone a startup, it’s hard to keep up with all these devices. The wurfl project maps devices to capabilities (e.g. does it support JS? what screen resolutions?), which Facebook is using and feeding data back into it.

The popularity of WebKit makes it easy to target multiple devices at once, and this is apparent in the way PhoneGap works to let you target multiple devices in the one go.

Assorted Questions

Dealing with IE6?

Decided not to support chat on IE6, but generally try to support older browsers as well, simply by way of the numbers.

HTML5 speaks to what games are very well – and the opportunities Canvass presents means good things for gamers. That combined with the new avenues to purchase new apps and content through PCs and mobile, when you combine that delivery with the development environment for the industry there is a real opportunity.

Classy

No, not THAT “Classy”. This “Classy”:

HTML

No, not THAT “HTML”. This HTML:

The Classy HTML Pattern

Pretty simple: Store important app state as classes in your root (“html”) element.

For example, consider a countdown app. Its significant (from a UI perspective) state can be summed up as being one of three things: “fresh” (app just started), “counting”, “done”. Your app is, in effect, a state machine transitioning between those states according to a set of rules. (Acknowledging that reality and subsequently managing those state transitions with JavaScript can also be an interesting problem ripe for a parsimonious design, but let’s just take that for granted here.)

You would set your HTML class as “fresh” to begin with, and then programmatically switch it over to “counting” or “done” as the app plays out.

/* We choose the default case to reflect the most common case, ie "counting" or "done" */

html.fresh.welcomeMessage{display:none;}

html.fresh{background:white;}

html.fresh.counter{ opacity:0.3;}

html.done{background:red;}

The important thing here is the selector idiom, which can be summed up as “html.statedescendentSelector“. We’re styling our classes all the way down, based on the overall application state.

I haven’t done too much of this kind of design, but I can see myself doing more of it as apps get more complex and everything becomes single-state. I’ve been contemplating refactoring the Hacker News Reader along these lines, since (thanks mostly to Paul), it now has sliding panels, and so can effectively be in three states: stories, story (one story above the list of stories), comments (comments above one story above the list of stories).

I guess all this is obvious to CSS design pros, i.e. it’s a natural consequence of the CSS model, but I’ve not thought about doing it much and I mainly got the idea from this FOUC trick, which uses this pattern, but in a very restricted and specific way. The main insight really is that single-page apps usually have a small number of key states which can affect the entire UI.

As with any good pattern, it raises further questions:

Should you use “class” or an HTML5 custom “data-something” attributes. I think it’s in the spirit of HTML/CSS to use “class” to represent a state, so that’s fine. And CSS attribute-based support won’t work on older browsers, so that’s another tick for “class”. BUT custom attributes have the distinct advantage that you can be more precise about what kind of state you’re referring to. So while it could just be “data-state”, it could also be “data-phase” or (a boolean) “data-active”. Which takes us to the next question …

Should you use more than one type of state? I think for complex apps, yes. And you can then use custom data attributes to manage the type of class. Or you could just use them as a list of free-floating class names on the HTML tag.

Should you use multiple selectors, e.g. [data-phase=”counting”][data-authenticated=”false”] to be more precise? In general, I think no. It would lead to ridiculous combinatorial complexity, so it’s better to treat each state variable – if you must have more than one of them – as being orthogonal. That said, there are probably special cases where it makes sense and fortunately modern CSS makes it easy to pull off.

What’s the base case? Should it be the initial state or the “typical” state?

Looking at the bigger picture, when do you switch pages versus switch states inside the app?

My weekend project was a Hacker News Reader (source code). It works on Chrome, Safari, and Opera. Sorry, Firefox doesn’t work at present, reasons why speculated below. Mostly started this project because I want one with Twitter integration, but also to play with a few technologies, which I did. Among things explored and demonstrated:

Server-Less App The app is entirely browser-side. The server serves only as a repository of static files. Content comes from the iHackerNews unofficial API, by way of JSONP, the protocol we’ll still use for cross-domain calls until CORS becomes eminent in the hopefully not-too-distant future.

CoffeeScript. The app logic is written in CoffeeScript, and compiled to JavaScript in the browser with coffee-script.js.

Less. The UI styling is written in Less and compiled to CSS with less.js.

Chrome Web App. The app is also a hosted web app on the Chrome Web Store, which is to say (a) it can be discovered by users of the store; (b) it can be installed into the New Tab page of Chrome, for convenience sake; (c) if I wanted to, and added some extra server smarts, I could charge for it. I wrapped it up as an app with Paul’s super-handy Appmator utility.

Mobile HTML5. Although I didn’t (yet) optimise the site for HTML5, I did make it available on mobile, with the right icons for being added to the Home Page, and used Build.PhoneGap.com and Apparatio to roll it up as a native mobile app.

CoffeeScript

I wanted to try out CoffeeScript. While I’ve been skeptical about languages which are said to “compile down” to JavaScript, as if JavaScript was a complicated tangle of 1s and 0s rather than the high-level language it is…CoffeeScript is different. It’s more like JavaScript++ as the name implies. While I do find JavaScript to be pretty good, its syntax can get too verbose. Especially for closures, where you have too many curly braces and “function” keywords getting in the way of the actual logic we care about. You can also be more expressive with keywords like “unless”.

As ~98% of code people write never sees high-scale production use, I like to opt for quick and dynamic over tedious and “it just feels like the right way to do it”. So I employed coffee-script.js to compile dynamically, in the browser when the web app loads, instead of pre-compiling it on the command-line. Doing it dynamically means I can just type some code and reload the browser page, about the smallest possible debug-test cycle that is possible.

I found it slow-going at first, because I ran into some coffee-script.js gotchas and learned a few things about the language on the way:

Keep CoffeeScript in a separate server. Although CoffeeScript supports inline CoffeeScripts in your HTML (<script type=”text/coffeescript”>…here is my script….</script>) – perfect for quick hacking), I recommend you stick them in a separate file (<script type=”text/coffeescript” src=”myscript.coffee”></script>. I can’t explain exactly why, but when it was inline, things were note very deterministic and I found my CoffeeScript script was getting executed three times!

Use a server, not file:/// URIs. As with less.js, CoffeeScript mocks the browser’s script-downloading behaviour, using XMLHttpRequest to pull down any scripts specified in “text/coffeescript” script tags. Unforuntately, Chrome doesn’t let you XHR one file from another file, so you need to set up a server, if only to serve these static files over HTTP.

Don’t bother with window.onload (or jQuery intializer). I *think* coffee-script.js guarantees any CoffeeScripts you provide will be executed after the window has already loaded. I haven’t confirmed this, but seems to be that way on Chrome, Safari, and Opera. OTOH, the app doesn’t work on Firefox – CoffeeScript isn’t executed at all – and this may be related.

Declare before you use. A consequence of the previous rule is that your initialisation sequence will run in the order you specify it. This is different to the usual JS situation where you make a window.onload handler, which might call things that you’ve declared further down in the file. So in the code further down, note that I declare “show” before I call it. Pretty obvious, but JS habits and lack of descriptive error messages meant it caught me out.

Whitespace matters. There are no semi-colons and no braces here; similar to Python, whitespace dictates structure. However, you can also use parantheses to keep things on the same line, so I didn’t find this threatening to concise code.

Use “window” for global. Declarations like “x=5” out in the open will *not* make global variables; and nor is there a “var” keyword. The only way to hook into global space is to explicitly reference the “window” object; e.g. “window.x = 5”.

How’s the code look? See for yourself, CoffeeScript keeps it pretty tight. I couldn’t find many examples of jQuery-CoffeeScript combos, so this will hopefully be useful in that regard:

Less fails silently. Unfotunately, you don’t get error messages, so develop things gradually and be prepared to undo.

Less

If I was going to take a sip of CoffeeScript, it would only be fair to munch on a slice of Less too. If CoffeeScript is JavaScript++, then Less is CSS+. It’s really augmented CSS, because you can present a regular CSS stylesheet and it will be valid Less too. That’s not true at all about CoffeeScript; a typical JavaScript script has Buckley’s of passing the CoffeeScript compiler.

The other thing they have in common is JavaScript compilers. Which is not the case with SASS for instance.

Less talk:

Same XHR issues. As with CoffeeScript, the Chrome cross-domain restriction means you have to use a server even though the files are static. Also, it doesn’t seem to be possible to include Less stylesheets inline, or to get hold of the less compiler, which I think is a shame if true.

Silent fail. If any Less doesn’t parse, the entire stylesheet won’t be applied, and there’s no error message.

So some downsides, but the upside was a cleaner stylesheet with less redundancy. Gradient macro makes the ridiculously verbose gradient declarations completely DRY:

Chrome Web Store

This is a full-screen, focused, app which therefore meets the criteria for Web Apps I outlined in Thinking In Web Apps. (It would be more so if it showed the actual stories and comments in the app too, but that’s something for later.)

So it made sense to submit to the Chrome Web Store. Fortunately, my colleague Paul Kinlan had the gall to attempt building a web app that packages up Chrome apps … and then he actually pulled it off! Appmator asks you for the address of your web app, asks a few other basic questions, and then makes a Zip file you can drag to your desktop and upload to the store. All in all, a 30 minute submission to the Chrome Web Store and a nice way for people to discover your web app. I would only recommend this for true “Apps” as opposed to general websites, and ideally those apps should be tailored to a full-screen experience.

PhoneGap, PhoneGap Build, Apparatio

The app is NOT optimised for mobile at this time, but the cool thing about HTML5 is, for the most part, it “just worked” when I pointed iPad and Android phones to it. Some things need improvement, but this is good to see.

For exploration purposes, I decided to build it as a native mobile app anyway. I was lucky enough to receive beta invites for PhoneGap Build and Apparatio, two web services which let you do PhoneGap without actually installing anything on your PC. I built this app with both products.

PhoneGap Build supports GitHub like Apparatio, but also allows uploading a zip file. I actually had a problem pointing it at my GitHub repo (as with Apparatio, it needs to provide clearer instructions on exactly what form of URL is required). After I uploaded the zip file, it showed me a dashboard of 4 packages being built, and just went ahead and built each of them. Nice and simple!

Android, WebOS, Symbian, Nokia. Conspicuous by its absence is iOS, which Apparatio does support.

DropBox on my Macbook and Galaxy made it easy to copy the APK downloads to my Galaxy and install it. The Apparatio one took some time to download initially, but worked fine. The

Other Notes

Block-level “a” element, NOT. HTML5 makes it possible for “a” elements to be block-level, i.e. to include other tags including other “a” elements. This would be ideal for the Hacker News Reader UI, where the entire story block is a link to the story itself, but the block also contains links to comments and authors. It turned out to be legal in modern browsers, but with blatantly wrong layout, as someone else found earlier. Shame as I had to introduce considerably more JavaScriptCoffeeScript and CSSLess.

InnerHTML, Templating, and Live(). Seems like every project I do these days, I’m building dynamic content with innerHTML, as opposed to DOM manipulation. The first reason is I’ve become accustomed and satisfied with templating, and see it as a growing trend thanks to language-agnostic formats like Mustache as well as server-side JavaScript. (Though in this case, it’s a pure browser-side app.) So make a template and stick it on the page with innerHTML (or jQuery’s .html() ). The second reason is jQuery’s live() command makes it easy to handle events against the newly formed elements, which was previously a pain with innerHTML().

Setting text size. As you can see, text size varies with the number of points a story has. The relevant line appears in the template:

font-size:<%= Math.log(Math.log(Math.max(s.points,10))) %>em;

Using a log scale ensures a story with 2000 points isn’t 2000 times bigger than a story with 2 points. To dampen the effect further, which I think is important in mobile displays, I used a double-log and applied a minimum threshold of 10 points.

Future Things

There was actually an itch to be scratched here, beyond trying out various tech. Specifically, I’ve been wanting a mobile HN reader that would: (a) tweet; (b) quickly mark for instapaper reading, and ideally when I’m offline. (It would show the latest stories it saw when online, and cue them up for later…in general, I wish more offline apps would support cueing things like Tweets and Read Laters for when you’re back online.)

Fin.

So is this the Web App of 2015 or not?

There are definitely elements here that are not in wide use now, but will be in wide use by 2015. The whole “write once, run many” aspect of HTML5 is just getting wheels. It’s now clear that Apple won’t dominate the landscape by 2015, so regardless of their ever-fluctuating stance, HTML5 will be able to power the apps of the majority of smartphones and tablets…not to mention the possibility of apps on TV, cars, watches, washing machines, etc etc etc. (Can you tell it’s been CES week?)

And with HTML5 being able to power these apps, we’ll need ways to fit them into the App ecosystem, and that’s where PhoneGap and friends fit in. As I’ve said in various places, I always found it painful to have to set up Eclipse, PhoneGap SDK, and so on just to make a native app from HTML5. These are the things HTML5 developers don’t want to do, and the PhoneGap team is well aware of it, hence their PhoneGap Build effort. Apparatio provides relief in the same way and we can expect the same from others, especially so in light of Heroku’s high-valuation acquisition bringing attention to the whole idea of cloud programming. GitHub is also a vital component of this vision becoming reality. The next step will be to automate deployment into the stores, hopefully something that app-hungry stores will be happy to facilitate.

The Chrome Web Store is a related concept aiming to “app-ize” we apps. Mozilla is investigating a similar idea, and we’ll see a lot more of it in the next few years too. Some people say “but it’s just a bookmark”, an understandable reaction, but I think people are starting to get it now. It should only be an app if it really is an app, ie. if the underlying URL is really a media-rich, focused, app rather than a big collection of information and hyperlinks. And the Web Store is not just a place where you can buy and install apps; it’s also a directory where you can find all the cool apps on the web, with screenshots and reviews and comments to help you decide if they’re worth trying out.

Offline is important in the app story too (although this app doesn’t (yet) do any offline). You don’t type in URLs when you’re on a plane, but you do click on app icons to launch them. So offline web apps need an app-like presence to meet user expectations.

How about those languages, CoffeeScript and Less? CoffeeScript seems promising and I’ll definitely be using it more. At the same time, I’m weary because I feel like JavaScript may be “good enough” and CoffeeScript becomes a maintenance problem if others need to see your code. But the leap is not a big one.

As for Less, I’m more convinced it’s the way to go. We nowadays have an absurd proliferation of “-webkit-” “-moz-” “-o-” “-msie-” prefixes and the various syntaxes to go with them. It’s for good reason, but it’s also as much an affront to the DRY principle as any agilist could ever fear, and it’s unfortunate the standards don’t provide better support for dealing with this sort of thing. Likewise, the need for variables/constants and calculations. Less allows for all of that, and in a way that will work on legacy browsers even when some of these features do come about. So, yes, I’ll be committing to Less in the future.

What’s very cool about both Less and CoffeeScript is the JavaScript frameworks. It’s ideal for starting off a project, and when performance gets to be an issue, you can easily switch to the compiled version after that.

Finally, I’ll mention that templating is a design pattern that’s also going to be big in 2015. There’s much more framework support these days and it’s easy to use the same templates on the browser and the server.

The problem that a lot of HTML5 demos have right now though is that they only work in a certain environment. Showcase presentations like Paul Irish’s The State of HTML5: Inaugural Address even need more than one browser to work and Paul switches them during his talk. This is a feat of HTML5 right now – not everything works the same across browsers and you want to show off some of the cool things by sticking to one browser and others in another browser.

Whilst the original Tweet by Tobias stated that a Chrome Dev Channel build is needed as the browser to see the demo, retweets and others omitted that piece of information. This is bad. As you can see in the screencast above all I saw was broken implementations – even in Chrome. Only Safari showed it the way it was intended.

A few things:

I agree with Chris insofar as yes, it’s better and communicates the portability coolness factor of HTML5, if we can write demos that work across many browsers and devices.

Agile is good. It says you work lean and don’t do unnecessary work. The main point of a demo is to provoke imaginations and discussions. 80-20 rule…80% of its value is already served in one browser, but it could easily take twice as long to make it work across all the modern browsers. That’s a lot of work for the 20% of extra value derived by the demonstration of portability.

People are willing to suspend their imagination. With demos, it’s important to know when and how people suspend their imagination. If you stand there and blag through a Powerpoint presentation, the credibility of your underlying idea is zero or less. But on the other hand, if you show something in Firefox or Chrome, it uses standard HTML5 features which are already supported, or in the process of being supported by other browsers too, people can make the stretch.

It’s a good idea for showcase makers to publish which browsers the showcase is expected to support. And then let other browsers try it out anyway once the user understands it probably won’t work anyway. Such a declaration unburdens Tweeters and other sharers from always including disclaimers.

This is something that happens across the board. I’ve been incessantly showing http://chalk.37signals.com in European events this past week, despite the fact it’s iPad-only. It’s just that damn new and shiny, I’m willing to overlook that detail. Likewise, I wish the various Moz round video demos worked in Chrome, but they don’t, but I’ve still talked about them.

BTW I was one of those who tweeted the demo, Chrome-only disclaimer missing and all. I’m also the guy who invited Toby and Uxebu to present in this session. I also have a Flip recording of the event which I’ll upload as soon as I’m in a comfortable wifi situation, i.e. in a couple more days.)

None of this says demos shouldn’t be portable. In the equivalent session at GDD Russia, we had a wonderful demo from Opera’s Vadeem Makeev. When I spoke to him in the lead-up to prepare the presentation, he told me we can just load it up and it will work in any browser. That’s the great thing about the web, and it’s excellent to have demos like this to point to, to show it really can work across all browsers. But should every 0.1 alpha edition showcase go that length? I don’t think so.

Share this:

I’ve been in Kiev, Ukraine, this week, where I was fortunate to attend several events. The developers in this country and this region are super-talented, and I’m glad I was able to meet many of them directly.

Casual Connect

As with CC Seattle, there’s a big focus on social games right now. They are not only better for distribution – the viral nature – but often more profitable due to revenue sources which have no/little relevance in a single-player context. Namely, status-improving virtual goods; status-improving level advancement by way of automating/bypassing the grind; and, controversially/riskily, improving player capabilities.

I gave the following presentation on HTML5 Gaming. Fortunately, the HTML5 Game Jam we ran a couple of weeks earlier provided great evidence that it’s here and real, and I was able to make use of that in the examples. (I also came up with the idea of an iFrame player for these slides; so you can click on some screenshots to replace them with an iFrame showing the game. This is raw and needs more work, e.g. a big play button for starters.) All this emphasises the importance of micropayments/in-app payments for the social gaming segment.

The biggest concern game developers have with HTML5 is graphics capability. Handling a hundred avatars real-time on the screen at once, that kind of thing. I hope to work with a few of them to get some useful data and feedback for the browsers.

Kiev GTUG

I gave a talk on HTML5 and ran a #chromekyiv hack day, where people built HTML5 apps and Chrome extensions. It was the first time anyone had participated in a hack day and it worked fine; I think hack days are more about how you present them than whether they suit any particular place or culture. Mainly, as with HTML5 Game Jam, I aimed to very clearly explain the process, and very explictly tell them I’m here to help, and then wandered around a bit; as people won’t often ask for help if the organiser’s head is buried in their laptop.

We had about 6 hours of hacking, completing at the fine hour of 10pm, and 2 minute presentations. Around 20 attended the talk and 14 hacked till the bitter end. Got some footage on the Flip which I’ll try to upload at some point. Kyiv GTUG managed to sneak past Kyoto GTUG for #1 Pulse spot

in the process :). Nice job!

The winner was an excellent Chrome extension from @yasik, @shooshpanchick, and, and @webdizz. Scrapes addresses from any web page and shows them on a map. I also realised when I met him that I have used @yasik’s Delicious extension in the past (his was the first for Chrome). Watch his GitHub as they work towards a stable version of this extension.

There were also some nice entries from others. A CSS3 photo gallery and hard-to-describe visual effect involving your name being shown at a million angles and opacities. A wikipedia looker-up using the new context menu capability (pro tip: here’s how you get the selected text). A syntax highlighter for any programming language, using IDEOne’s web service. A localStorage-powered colour setter.

For my part, I presented Control Freak, a GreaseMonkey like extension I started writing a couple of days earlier, and completed to the point of usefulness at the event. Basically a very lightweight way to tweak JS and CSS on the current page, using a browser action (ie address bar button), which I’ll post more about soon.

Ukraine PyCon

This was a fairly large regional PyCon, with a number of talks in English to encourage attendance. It was nice timing being immediately after Casual Connect, and the Pythonistas graciously welcomed a talk about a foreign language in a foreign language.

I gave a talk on Web and Apps, similar to my earlier FOWA talk, but updated to include recent HTML5 gaming activity and a little overview on what HTML5 adds to the basic technologies of HTML, CSS, and JavaScript. The point is to show that HTML5 is an incremental improvement; you’re still dealing with the same language and programming paradigm.

London in a tube strike is not pretty, until you realise you’re in 28 Days Later, and suddenly it’s ace.

I am posting my slides below. They are based on a slide framework that I trend to stitch and mend with each presentation. So they are still very alpha! But getting to be awesome for authoring. Also, I tend to use the biggest-size images available, so download may be slow.

Thanks to Carsonified for doing an amazing job making sure everything was taken care of, and the crowd for their energy, and for actually making it in to the venue on this challenging day of travel.

In terms of questions, we had time for three – one was about which payment solutions are possible on the Web Store (any – it’s open – but the web store provides solutions which should help developers); one was about making native apps (Web Store doesn’t support native apps as such; but tools like PhoneGap let people create native apps targeting iPhone/Android/etc); and one was about whether Application Cache (and, I assume, other features under discussion in the presentation) are HTML5-specific versus Google-specific etc. I mentioned that I want to avoid the HTML5 debate in this talk and I’ll define it here as the spec and everything else going on around it. It’s a good point though to be clear that Application Cache and the other general technologies I discussed are based on open standards.

I had the honour of speaking at London Web Standards this week along with Opera’s Patrick H. Lauke. @otrops, @twitrnick, and the rest of the volunteer organisers put a ton of effort into each event and it shows.

At this event, I presented “Eight HTML5 Features You’ve Never Seen Before”:

It’s the visual elements of HTML5 that everyone is watching right now, but the present surge of web evolution encompasses much more than that. This talk will overview several important technologies in the “everything else” basket of HTML5 and related technologies: application caching, client-side storage, cross-origin resource sharing, websockets, ping, session history, workers, and geolocation.

The new means of presentation – CSS3, Canvas, SVG, Video, etc. – are a perfect complement to all of this new functionality, allowing it to be visualised and interacted with in fun ways.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff