Podcamp has come and gone once more in Toronto.
The annual event took place at the Rogers building at Ryerson University in downtown Toronto, and was well attended by people of many different backgrounds interested in podcasting in general. There were technical presentations as well as others based around issues of ethics.

One of the best presentations of the day was delivered by Brad Buset from Espresso, who spoke upon the issues surrounding online privacy protection.
Privacy protection is a complicated issue becoming ever more sophisticated as companies and individuals attempt to strike the right balance between transparency and personal information. At times, the line has been crossed, mostly due to the newness of some of the channels with which we can publicize our information. As an example, Brad pointed out how enterprising criminals could create correlations between an individual’s twitter posts to figure out likely times to rob them, in effect creating a cost/benefit analysis. That was an eye-opening thought.

On the other hand, he also pointed out quite succinctly the benefits of social media and information sharing.
“For each person who got fired because of their facebook account” he asked, “how many more were hired because of the insights they were able to reach in 146 characters or less?”

During the presentation, it was pointed out that there is a privacy equation, in which information and utility are balanced. In other words, we’ve come to accept that we must offer up certain information to achieve the utility that we seek. Sometimes that information is simple, sometimes it is more personal or valuable, and we must balance that against the perceived value of the utility we are seeking.

My observation is that there is certainly a generational bias in terms of how much information and of what type people are willing to offer for utility. The younger that audiences skew, the more likely they are to offer personal information to achieve what they want to do. That is interesting as it correlates with something I’ve noted in working with a lot of young people (college age or younger) – they are not paranoid like those who have gone before them. Perhaps because they have grown up in an environment online where they are asked to sign up so often.

This trend is even reflected in the utility of software. To try out a free trial of some online application, the user is often prompted right away in very clear terms “click here to begin” – even before the benefits of using the software are explained. In the past it was harder to get people to engage without first clearly explaining the utility. Now more often it is accepted that people will dive in and begin.

Could this be a tacit recognition that most people are now arriving at the site for the trial software on recommendation from a friend or user-review? Certainly it is not uncommon for people to seek out reviews rather than reading through the documentation printed up on the actual site for a product. Why trust the people who stand to make money off of it when you could read about it from an unbiased user of the product? And if the potential user has already gathered all the information they need, why complicate their lives by presenting it to them again. You’d be better off giving them a clear way to get started straight away.

That same willingness to enagage is not far off from the willingness to offer information. If we trust what our network of ‘friends’ has offered up to us, we are far more likely to volunteer information about ourselves in order to engage with it. For those who have grown up seeing the internet as more of a social experience rather than an information retrieval mechanism, the level of comfort with offering information is much higher. For them, the internet is a place populated by friends where most of their content is given to them from trusted resources.

Perhaps this explains why younger users are far more likely to set their information to public, and why advertisers like to target young audiences.

In this show we look at Microsoft Surface from Advertising Week in Toronto. We also talk a bit about independent video game creation, and finally thoughts on open standards, the web, Flash and the iPad.
Hope you enjoy!

Part Four

In this series of articles, we’ve been looking at the state of things with the technologies shaping the web. Quite frankly we’ve barely scratched the surface but hopefully we’ve covered some ground that has not already been examined in depth elsewhere.

At the end of it all, the fact remains that no single factor will determine the future of the web and we should all be skeptical of blanket statements proclaiming that any technology is either dead, or the next big thing. There are so many interests that can sway the direction that things are going between the developers, the software creators, the hardware manufacturers, the advertisers and yes even the education system.

Elsewhere on this site we’ve talked about how the fittest are not always the survivors, and that more often it is the most appropriate who pass through at any given time.

For the moment, HTML 5 is not a particularly viable option. It likely will be in the future if companies that have a lot of influence continue pushing forward in adopting it into their browsers, but there is likely to be a great deal of fragmentation if they keep pushing ahead of the regulating bodies like the W3 consortium. If they don’t push ahead though, the standards progress at a snails pace and sometimes just die.

Runtimes like the Flash player do not suffer from the slowdown of regulating bodies – they can issue updates whenever they wish and the challenge is a technical one. They have to keep the player working well in multiple hardware configurations. The rise of mobile devices illustrates this nicely. It is forcing major changes to the player such as OpenGL rendering.

There will likely be multiple updates to Flash and other runtimes before HTML 5 gains much traction, so comparing the current player to an HTML standard that may get adoption in the future is a bit of an exercise in futility.

For today, not much has changed in the desktop landscape and Flash (along with other runtimes) will continue to be quite popular for their reach and the interactivity they allow. And until such time as good tools start appearing that allow the same speed of production for HTML/JS solutions that the the Flash IDE offers, it will be a hard sell for many designers and developers.
And lastly, the advertisers – one of the most influential and under-noted players in this debate, will continue to show love for Flash for the ease with which it allows them to create notable interactions in an easy to distribute manner.

In mobile however, Flash is not currently a viable option. That may change with the 10.1 release, but since we are talking in practical terms, for right now there is little reason to use Flash or other runtimes for mobile devices. The landscape favors native applications, or web-apps built specifically for mobile using HTML/JS/CSS solutions.

There are always trade-offs when selecting a technology to promote your content. The key lies in really analyzing your users to ensure they get the best experience.
One of the key things to note is that much like the AJAX/Flash debate of a few years ago, we’re not looking at an either/or situation. People came to realize that the two things were not mutually exclusive and so in time they stopped positioning them as rival technologies.
In this case, Apple’s stance currently attempts to control and allow only their solutions, so in a way an artificial rivalry has been created. Whether they will be able to maintain that level of control remains to be seen as many other companies work to adopt Flash for that very reason. Again, there is no end of conjecture on that subject.

The final conclusion is, don’t hold back interesting designs and interaction from users today, based on awaiting the next big thing. There are far too many factors to weigh and the wind blows in many different directions. At the same time, a solid understanding of the best principles of design and interaction will be useful no matter what technology is being employed today, or ten years from now.

Part 3

In this series we are examining the future of Flash and whether it will make its way to Apple devices.

As part of the discussion, we’re looking at the viability of HTML 5. This is fair because when people speak of a possible replacement for the features of Flash, they often cite HTML 5. To do an honest evaluation, we need to look at how HTML 5 actually performs.

HTML is a markup language no matter what version we’re talking about. Using Javascript/CSS/HTML, you can already do some pretty interesting things in terms of moving things around the screen and creating masks. As a result, sites that use some minimal animation to add to the user experience and direct attention in a specific flow can be accomplished already.

The Languages

Javascript is the language used to manipulate the DOM (HTML) client-side. That is not going to change, nor is Javascript likely to change much given the death of the ECMA 4 update to the language.
JS is a very loose language, not object-oriented as one would usually think of it. There are no classes, no access modifiers, no abstracts or interfaces. That said, it is a well-known language and there are a great many resources online for it and many instructional books. Coding in JS is pretty predictable. Most of the difficulties in coding for the web come not from Javascript, but from the exceptionally poor and fragmented HTML treatment of the DOM (the document object model that determines how a web page should render in a browser).

The DOM is the Thing

Different browsers treat the DOM differently, and in fact they have their own layout engines, including WebKit, Gecko, and Trident to name three of the most popular.

I won’t mince words when I say that standards for HTML and the DOM move along at the pace of a large lumbering committee. HTML 5 is no exception. Nor is it a new idea. The next version of HTML has been in the works since mid-2004. This from the w3 site: “The current HTML working group charter was issued on 7 March 2007. The group is chartered to continue its work through 31 December 2010″.
Does this mean we’ll have HTML 5 by the end of the year? No. The actual W3C candidate recommendation is slated to possibly be available in March of 2012. And that is the recommendation, not the actual approval. The full approval…who know? Possibly 2022, but it faces many obstacles before then.
Keep this in mind: along with the actual recommendation, the group is required to create a comprehensive test suite for the HTML specification, as well as all validation tools. And they need a ‘classic HTML’ version as well as an XML version.

Given the very slow process of approval for the next HTML, different organizations have decided they simply can not wait for the W3C approved candidate and have begun implementing individual parts of HTML 5 on their own. But what feature is adopted into which layout engine for what version of any browser is completely unregulated. Worse than that, the makers of the various browsers compete for market share and it is all to easy for them to differ on how HTML features should be implemented. This is not a new tale, it goes back to the netscape days. As an example, we could look at the canvas element.

When people mention killing plugins with HTML 5, they’re often referring to the canvas element. This element was introduced into WebKit by Apple for Mac OSX and then the Safari browser. This joined the already proposed SVG (scalable vector graphics) standard which was competing with Microsoft’s proposed VML standard. It is notable that by introducing their own element, Apple was able to patent the canvas element in 2005 making it a proprietary markup. Later they volunteered to provide royalty-free licensing to the W3C for use of the canvas element in HTML 5.
Ian Hickson, author of the current HTML 5 specification had this to say:
“So Apple decided to make up some new tags. To be precise they invented a new element, a new attribute, and a new value. The new element is canvas, an element that does nothing except provide a DOM interface for graphics drawing…Here is Apple introducing their own proprietary markup to the Web, without going through any sort of standardization first…Proprietary markup is proprietary markup, whether it is HTML-based, XML-based, or any other language such as PDF, Microsoft Word, XAML, or Flash.”

Apple dashed ahead, making an element for their operating system, but they liked it so much they included it into their browser as well.
Apple is not along in introducing proprietary markup and formats, others include Adobe, Microsoft, Mozilla, and many more.

The point is that when people talk about HTML 5 being the next big thing, the question should remain ‘what HTML 5 are we talking about?’. Is it the one Apple is pushing, or someone else, or whatever finally gets standardized ten years from now?

For developers and content creators, this lack of any solid standard has meant never-ending frustration with HTML-based content. And it has been going on this way for many years. Perhaps it will get better in the future.

How About Right Now?

But if you deal in the here-and-now, how usable is HTML 5, and if you choose to use it can the canvas element compare to what can be done with Flash?

Regarding animation, the canvas element has serious shortcomings, as stated by the Mozilla Developer Center:
“Since we’re using script to control canvas elements, it’s also very easy to make interactive animations. Unfortunately the canvas element was never designed to be used in this way (unlike Flash) so there are limitations.
Probably the biggest limitation is that once a shape gets drawn it stays that way. If we need to move it we have to redraw it and everything that was drawn before it. It takes a lot of time to redraw complex frames and the performance depends highly on the speed of the computer it’s running on.”

To do canvas animation, one must create a description of the the canvas using HTML markup, and following that it is possible to use javascript to start changing the properties of shapes on the canvas at timed intervals.
You get a simple 2D drawing API to work with.
This next part is my personal observation.
I find it very difficult indeed to find animation and interactivity examples done in HTML 5 using the canvas element online. One of the very best javascript programmers I’ve ever known worked extremely hard for weeks to create a JS-only demonstration, and it was awesome in some browsers, but it ran so badly in others that it had to be replaced by Flash. The Flash replacement was done in a couple of days.
JS/HTML based animation suffers from a serious lack of a decent IDE to work in. At this point, it is not being accomplished by designers or animators – it is being done by people who code in JS. When I look into the source of some of the examples, I find code so long and laborious it makes my eyes rot. Here’s an example:

http://www.cs.helsinki.fi/u/ilmarihe/canvas_animation_demo/mozcampeu09.html

Take a look at the source. I am NOT slamming the developer, indeed I am in awe. But the fact remains this could be done in Flash in an afternoon and require next to no code.
Looking through the source (and it is cool that I can look at the source by the way) of popular examples, I am reminded very much of what was being done circa Flash 5, except without the tools of the Flash IDE.
To do a simple movement or fade is no problem. There is no way to do a “timeline animation” though some smart people have tried to write their own solutions for this.
Without the tools available to Flash developers, creating immersive experiences is going to be a much slower process.

And at the end of that process, you still have to worry about cross-browser issues.

Does it Matter?

Will the viewing public settle for javascript-style animation and interactivity online? With the iPhone, Apple is saying that the web is for interacting in a simple way. For anything more immersive or complex – well there’s an app for that. They want you to leave the browser and do your playing and experimenting in a separate application which you got from their app store.
While that may be acceptable for many (perhaps even preferable) on a small-screen mobile solution, will this be okay on the desktop? We will know in time I suppose.

Additional Reading:
Hixie’s Blog re: unrecognized HTML tags

Game Example with Canvas

Info on HTML 5

Canvas basic animation