Midterm: How to Survive a Shark Attack

Mission Statement
Shark attacks are pretty rare and the chances of being killed by a shark are one in 3.8 million. Sharks don’t even like the taste of humans. Most attacks are the result of mistaken identity. They bite into our flesh because they think we’re a sea lion or they’re simply curious about what kind of animal we are.

The majority of shark attacks in the world occur in the United States. Outside of the U.S., Australia and South Africa have had the most attacks. There are over 360 different shark species in the world, but only 20 species are known to attack humans. And of those 20 species, only four have been involved in a significant number of fatal, unprovoked attacks on humans; the Great White, Tiger Shark, Bull Shark, and the Oceanic Whitetip Shark. Even though shark attacks are rare, it can’t hurt to know how to defend yourself if you should ever find yourself face-to-face with one.

midterm midterm2

11 hard truths about HTML5

HTML5 heralds some nifty new features and the potential for sparking a Web programming paradigm shift, and as everyone who has read the tech press knows, there is nothing like HTML5 for fixing the Internet. Sprinkle some HTML5 into your code, and your websites will be faster and fancier — it’ll make your teeth white, too. But the reality of what HTML5 can do for those seeking native-app performance on the Web falls short of the hype.

After several years of enjoying HTML5’s sophisticated new tags and APIs, the time is ripe to admit that there are serious limitations with the model. Not only are there reasons to grouse about HTML5 failing to fulfill our Web nirvana dreams, there are even reasons to steer away from HTML5 in some cases.

The truth is, despite its powerful capabilities, HTML5 isn’t the solution for every problem. Its additional features are compelling and will help make Web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchonization challenges, and politics should have us all scaling back our expectations for the spec. After all, every technology has its limitations.

What follows is a list of 11 hard truths Web developers must accept in making the most of HTML5.

HTML5 hard truth No. 1: Security is a nightmare

The fundamental problem with client-side computing is that the user ultimately has control over the code running on the machine. In the case of Web apps, when your browser comes with a great debugging tool, this control is easier than ever to abuse.

With a JavaScript debugger like Firebug, anyone who is curious about what Facebook, Google, or any other website is doing can just start inserting breakpoints and watch the code. This is great for debugging and learning how websites operate, but it’s a nightmare for security.

Suppose there’s a variable that holds a value you’d like to change; well, Firebug or any of the other browser debuggers is happy to help you tweak the data to be anything you desire. Do you want to trick your friends into thinking you’re in another geographic location? It’s easy to edit the variables that hold latitude and longitude to place your browser anywhere in the world. All the neat features of your Web app can be modified, and the browser environment makes it easier than it would be normally with native code.

There are limits to the security problems that can be incurred. Some JavaScript tools such as Google Web Toolkit are nearly as complicated as standard compilers. Their output can be fairly inscrutible. Luckily tools like the JavaScript Deminifier can help.

The danger depends, of course, on the nature of the application. It’s one thing when someone edits their latitude and longitude to play tricks on their friends by checking into a website while pretending to be halfway around the world. The trouble begins when someone qualifies for all of the rights, privileges, and free beers accorded by being crowned the mayor of some location. When money gets involved, the games can only get worse. All of this means that client-based HTML5 apps can’t be trusted with serious data collection, and it’s better for everyone to be aware of their capabilities.

HTML5 hard truth No. 2: Local data storage is limited

The local databases buried in your browser are one of the neater features that make it simpler for Web apps to cache data on your computer. But for anyone hoping to offer desktoplike data functionality in the browser, these databases can save bandwidth and improve performance. However, they won’t give users the same power over their data that they’re used to enjoying with desktop apps.

HTML5 data storage capabilities are certainly an important addition, but you still can’t move stored data to another machine, make copies, back it up, or open it with a different app. It’s all buried deep where the browser hides it.

In a sense, these databases are the worst of both worlds. You get all of the responsibility for hosting the database but none of the control.

Some of the latest browsers allow you to see which databases have been created on your machine, but this information is limited. Safari even lets you delete the database. But you can’t browse the information or move it to another machine. The files aren’t designed to move easily, although you can do it if you know where to look.

Nor can you dig into the files to see what is stored there. Sure, a programmer can take them apart, but only after studying the format and doing some hacking. They’re not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app.

HTML5 hard truth No. 3: Local data can be manipulated

The user may not have control over the data, but the central website is also hampered when dealing with client data. Did the user switch browsers? Did the user switch machines? Many Web developers just toss up their hands and use the local data storage for caching short-term content. They can’t let the user create much because of the problems of synchronization.

Web developers also need to worry about the security of the local database. While there are no tools that make it easy for a user to edit the local data and upgrade their privileges, there’s no way for the central server to prevent it. All of the security holes introduced by letting the user tweak the JavaScript code affect the databases, too. They’re wide open and waiting for someone to write a Greasemonkey script or some native code to change the data.

HTML5 hard truth No. 4: Offline apps are a nightmare to sync

HTML5 local data storage is vastly improving the ability to use Web apps offline. The only trouble is data synchronization.

If a Web app is connected to the Internet, it can continually save data to the cloud. When it’s offline, changes aren’t always stored in the cloud. When someone switches browsers or uses a different machine, copies begin to proliferate and the difficulties of synchronization rear their head. To make matters worse, clocks themselves may be unsynchronized, making them unreliable for finding the latest saved data.

Of course, this has always been a problem with native apps, but the difference is that the native model makes it obvious who is responsible for synchronization: humans, who manage synchronization troubles by looking at file names and change dates. But because HTML5 doesn’t give users control over the databases stored deep inside their browsers, developers must provide the user interface and piping to handle synchronization. The specification doesn’t offer any help.

This isn’t a completely intractable mess. Programmers manage these headaches by using version control systems, which have become increasingly more sophisticated to handle such problems. Yet just having the technology doesn’t mean it’s an easy solution for programmers to use. Merging the various GIT repositories can take time. HTML5 developers will need to master these issues if they’re going to manage the synchronization of HTML5 Web apps.

HTML5 hard truth No. 5: The cloud owes you nothing

It’s not really fair to blame HTML5 for all of the structural problems with storing your data in the cloud, but the cloud is an essential part of the vision, which leverages the cloud to fix all of the headaches for installing software and backing up data.

Given the limitations of HTML5 local data storage, the bulk of Web app data storage will remain in the hands of servers, and there are moments when this approach can be devastating. Just recently Facebook decided it didn’t like one Linux-based plug-in for uploading photos. With a wave of the caliph’s hand, the plug-in was gone, along with all of the photos that were uploaded using it.

These stories aren’t common, but they’re appearing more and more often for many reasons. Are you sure that the cute Web startup promising free everything with their HTML5 app is going to be there in a few years or even a few months? You’d better be.

It gets worse. As the terms of service for many Web apps make clear, it’s not your data, and in most cases, you have no legal recourse to recover the data. Some of the more outrageous service agreements insist that the data can even be deleted for “no reason at all.”

Not only does HTML5 avoid fixing this issue in any way, its structure practically ensures that any of the local data cached on your browser will be stored in the cloud, out of your reach and control. The HTML5 hype says this is a feature, but it could easily turn against the model.

HTML5 hard truth No. 6: Forced upgrades aren’t for everyone

One story, perhaps apocryphal, tells of a person who used a Gmail account for casual hookups with people in bars. When Google+ came along, all of the memories came flooding back, because Google+ linked those old addresses into the discussion forums. Every day, the old names and old faces are there asking to be put into discussion circles.

When the Web app companies need to upgrade, they must upgrade everyone at the same time. While this is said to relieve users of having to manage the software installation, it can be a nightmare for anyone who doesn’t want the new features. This isn’t just a problem for people’s privacy, as in the case above. New software can often crash other packages that relied on the old features being where they were supposed to be.

HTML5 hard truth No. 7: Web Workers offer no prioritization

Web Workers are among the more intriguing additions to HTML5. Rather than depend on copious JavaScript wait, delay, and pause commands, Web developers can now split apart their code and segregate the CPU hogs into Web Workers. In other words, HTML5 Web Workers make the browser operate more like an OS.

Alas, they do not duplicate all of the features of the OS. While they do provide a way to fork the workload and separate it, there is no way to manage the workload effectively or set priorities. The API just allows messages to be passed into and out of Worker objects. That’s all — the browser handles the rest.

Will CPU-rich applications like code crackers sneak their way into the background running on popular websites? Will people begin luring users to cycle-stealing websites? Malware already piggybacks with useful software, so it’s likely just a matter of time before this functionality is exploited. There is little users can do about it because they have no way to watch for the creation of Worker objects or track what they do. Their computer will just get slower after navigating to the targeted Web page.

HTML5 hard truth No. 8: Format incompatibilities abound

HTML5 heralds the introduction of <audio> and <video> tags, which at first blush look as easy to use as image tags. Just plop in a URL, and the browser streams the data. Yet, if it’s so easy, why have I wasted two weeks trying to get basic audio files to play in all of the major browsers?

It’s not really the HTML5 committee’s fault that individual browser builders decided to implement some but not all of the various audio and video formats out there. People are human, and humans fight for dominance. But the developers have to deal with the fallout when a file that works perfectly well on one browser fails to do anything on another. How does one test for this? API developers were smart enough to include the function canPlayType, but even that function is not supported by all browsers.

HTML5 hard truth No. 9: Implementations are browser-dependent

The idyllic vision of HTML5 is one thing; the grungy reality of its implementations is another. True, programmers are trying their hardest to build the architects’ dreams, but some of the tags and objects don’t work correctly.

For instance, there are many things to like about HTML5’s geolocation API. It offers some protection for privacy and a bit of control over its precision. If only it worked consistently — one browser always times out, even though it should be smart enough to know that the desktop doesn’t have a GPS chip.

Ultimately, this is more of a complaint about how browsers fail to implement the feature consistently, as opposed to being one aimed at the structure of the API itself. This hard truth highlights the browser-dependent challenges that Web developers face in making the HTML5-based Web app nirvana a reality.

HTML5 hard truth No. 10: Hardware idiosyncracies bring new challenges

It also seems unfair to complain about how some browser builders are going above and beyond the call of duty to provide much better performance, but no good deed goes unpunished. As the new Ferrari owner finds out after wrapping their car around a light pole, sometimes extra power isn’t always a blessing.

Microsoft has done a great job of increasing the Canvas object performance of its IE browser by integrating it with low-level hardware drivers. The company has even commissioned neat games like pirateslovedaisies.com to show off the power.

But now programmers must pay attention to whether these additional features are available, and it’s not clear how to find out how fast your code is running.

The game designers at pirateslovedaisies.com, for instance, included a switch to turn on and off the features that IE enables. Is there an API that makes it possible to guess about these features? Not really. The simplest thing is to test for the browser name and try to estimate the frame rate. Yes, I know that native game developers have been dealing with the wide range of available hardware for years and the only real solution is to ban innovation, but this is yet another wrinkle for Web developers to come to terms with.

HTML5 hard truth No. 11: Politics as usual

Some folks call Ian Hickson, the main drafter of the HTML5 standards, the Supreme Dictator for Life. They’re joking, I guess, but the title doesn’t match. The standard writer is just making suggestions, and the coding geniuses at the browser companies are the ones who make the real decisions. They may or may not choose to implement a feature, then the Web developers get to decide whether the results are stable. After a few years, the standards are often changed to match the implementation.

Many JavaScript developers have left the issue of compatibility to those who create the libraries, such as jQuery. These layers insulate us from the cross-browser differences. Will they be strong enough in the future to smooth over the differences? Only time will tell.

This issue highlights the fundamental problem for the field. We want the freedom, creativity, and cornucopia of features that come from pitting many browser companies against each other in a tough competition. The pace of innovation is great, but it creates even more differences, as the browser developers rush to add new features to gain an edge.

But we also want the stability that comes from putting one central dictator in control of the platform. Alas, the world has never found an ideal solution for the battle between authoritarianism and democracy. Instead of grousing too much about the headaches that come from the differences, we might want to adopt the attitude of Winston Churchill, who told the House of Commons, “Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.”

Top 10 Reasons to Use HTML5 Right Now

So you’re still not using HTML5, huh? I guess you probably have your reasons; it’s not fully adopted yet, it doesn’t work in IE, you don’t like users, you’re out of touch or you are just passionately in love with writing strict XHTML code. HTML5 is the revolution that the web needed and the fact is, it is the future whether you like it or not — suck it up and deal. HTML5 isn’t hard to use or understand and even though it’s not fully adopted yet, there are still plenty of reasons to start using it right now like right after you get done reading this article.

There are lots of articles touting the use of HTML5 and praising the benefits of it, yes this is another one of those. With all these articles, with Apple pushing it, with Adobe building new dev products around it, and with so many web sites devoted to it, I still talk to fellow designers and developers who haven’t or won’t adopt it for a variety of reasons. I think the main problem is, it still seems like a mysterious creature to many. To many it feels more like the jet pack or the flying car — an awesome idea that is fun to think about but still not practical in its use. Wrong, the reality is that it is extremely practical right now! It’s not the latest Mercedes concept car being towed around form car show to car show, it’s a reality and it’s not going anywhere.

In order to further demystify HTML5 and help these knuckle dragging designers and developers to jump on the bandwagon I’ve put together a top ten list of reasons why we should all be using HTML5 right now. For those that currently use HTML5 this list may not be anything new or ground breaking, but hopefully it will inspire you to share the benefits of HTML5 with others in the community. We’ll do this Letterman countdown style (minus the celebrity presenter) and start with number ten – accessibility.

10 – Accessibility

HTML5 makes creating accessible sites easier for two main reasons: semantics and ARIA. The new (some currently available) HTML headings like <header>, <footer>, <nav>, <section>, <aside>, etc. allow screen readers to easily access content. Before, your screen readers had no way to determine what a given <div> was even if you assigned it an ID or Class. With new semantic tags screen readers can better examine the HTML document and create a better experience for those who use them.

ARIA is a W3C spec that is mainly used to assign specific “roles” to elements in an HTML document – essentially creating important landmarks on the page: header, footer, navigation or article, via role attributes. This has been well overlooked and widely under-used mostly due to the fact that it wasn’t valid, however, HTML5 will validate these attributes. Also, HTML5 will have built in roles that can’t be over-ridden making assigning roles a no brainer. For a more in depth discussion on HTML5 and ARIA please visit the WAI.

9 – Video and Audio Support

Forget about Flash Player and other third party media players, make your videos and audio truly accessible with the new HTML5 <video> and <audio> tags. Getting your media to play correctly has always been pretty much a nightmare, you had to use the and <object> tags and assign a huge list of parameters just to get the thing visible and working correctly. Your media tags just become these nasty, huge chunks of confusing code segments. HTML5’s video and audio tags basically treat them as images; <video src=”url”/>. But what about all those parameters like height, width and autoplay? No worries my good man, just define those attributes in the tag just like any other HTML element: <video src=”url” width=”640px” height=”380px” autoplay/>.

8 – Doctype

It’s actually that dead simple, however because old evil browsers out there don’t like our HTML5 friend, you’ll need to add a little bit more code to get them working correctly… but this code isn’t nearly as gnarly and messy as the <object> and tags:

Yup that’s it, that is the doctype, nothing more, nothing less. Pretty simple right? No more cutting and pasting some long unreadable line of code and no more dirty head tags filled with doctype attributes. You can simply and easily type it out and be happy. The really great thing about it though, beyond the simplicity, is that it works in every browser clear back to the dreaded IE6.

7 – Cleaner Code

If you are passionate about simple, elegant, easy to read code then HTML5 is the beast for you. HTML5 allows you to write clear and descriptive code, semantic code that allows you to easily separate meaning from style and content. Consider this typical and simple header code with navigation:

<div id="header">
 <h1>Header Text</h1>
 <div id="nav">
  <ul>
   <li><a href="#">Link</a></li>
   <li><a href="#">Link</a></li>
   <li><a href="#">Link</a></li>
  </ul>
 </div>
</div>

So this code is pretty clean and simple? But with HTML5 you can clean this up even more and at the same time give your markup more meaning:

<header>
 <h1>Header Text</h1>
 <nav>
  <ul>
   <li><a href="#">Link</a></li>
   <li><a href="#">Link</a></li>
   <li><a href="#">Link</a></li>
  </ul>
 </nav>
</header>

With HTML5 you can finally cure your “divitis” and “classitis” by using semantic and HTML headers to describe your content. Previously you would generally just use div’s for every block of content than drop an id or class on it to describe its content but with the new <section>, <article>, <header>, <footer>, <aside> and <nav> tags, HTML5 allows you to code your markup cleaner as well as keep your CSS better organized and happier.

Some resources worth checking out:

6 – Smarter Storage

One of the coolest things about HTML5 is the new local storage feature. It’s a little bit of a cross between regular old cookies and a client-side database. It’s better than cookies because it allows for storage across multiple windows, it has better security and performance and data will persist even after the browser is closed. Because it’s essentially a client side data base you don’t have to worry about the user deleting cookies and it is been adopted by all the popular browsers.

Local storage is great for many things, but it’s one of HTML5 tools that are making web apps possible without third party plugins. Being able to store data in the user’s browser allows you to easily create those app features like: storing user information, the ability to cache data, and the ability to load the user’s previous application state. If you are interested in getting started with local storage, check out Christian Heilmann’s great 24 Ways article from last year — Wrapping Things Nicely with HTML5 Local Storage.

5 – Better Interactions

Awe, we all want better interactions, we all want a more dynamic website that responds to the user and allows the user to enjoy/interact your content instead of just look at it. Enter <canvas>, the drawing HTML5 tag that allows you to do most (if not more) interactive and animated possibilities than the previous rich internet application platforms like Flash.

Beyond <canvas>, HTML5 also comes with a slew of great APIs that allow you to build a better user experience and a beefier, more dynamic web application — here’s a quick list of native APIs:

  • Drag and Drop (DnD)
  • Offline storage database
  • Browser history management
  • document editing
  • Timed media playback

4 – Game Development

Yup, that is correct, you can develop games using HTML5’s <canvas> tag. HTML5 provides a great, mobile friendly way to develop fun, interactive games. If you’ve built Flash games before, you’ll love building HTML5 games.

3 – Legacy/Cross Browser Support

Your modern, popular browsers all support HTML5 (Chrome, Firefox, Safari IE9 and Opera) and the HTML5 doctype was created so that all browsers, even the really old and annoying ones, er, IE6 can use it. But just because old browsers recognize the doctype that doesn’t mean they can use all the new HTML5 tags and goodies. Fortunately, HTML5 is being built to make things easier and more cross browser friendly so in those older IE browsers that don’t like the new tags we can just simply add a Javascript shiv that will allow them to use the new elements:

<!--[if lt IE 9]>
 <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]--

 

2 – Mobile, Mobile, Mobile

Call it a hunch, but I think mobile technology is becoming more popular these days. I know, that is a pretty crazy assumption and some of your are probably thinking — mobile is just a fad… right. Mobile devices are taking over the world. The adoption of mobile devices continues to grow very rapidly and this means that more and more users will be using their mobile browsers to view your web site or application. HTML5 is the most mobile ready tool for developing mobile sites and apps. With Adobe announcing the death of mobile Flash, you will now count on HTML5 to do your mobile web application development.

Mobile browsers have fully adopted HTML5 so creating mobile ready projects is as easy as designing and constructing for their smaller touch screen displays — hence the popularity of Responsive Design. There are some great meta tags that also allow you to optimize for mobile:

  • Viewport: allows you to define viewport widths and zoom settings
  • Full screen browsing: IOS specific values that allow Apple devices to display in full screen mode
  • Home Screen Icons: like favicons on desktop, these icons are used to add favorites to the home screen of an IOS and Android mobile device

1 – It’s the Future, Get With It!

The number one reason why you should start using HTML5 today is this: it’s the future, start using it now so you don’t get left behind. HTML5 is not going anywhere and as more and more elements get adopted more and more companies will start to develop in HTML5. HTML5 is essentially just HTML, it’s not scary, it’s not anything you really need to figure out or relearn — if you’re developing XHTML strict right now you are already developing in HTML5 so why not take full advantage of it’s current capability?

You really don’t have any excuses not to adopt HTML5 and begin your new love affair with it. Truly, the only real reason I prefer to use HTML5 is just to write cleaner code, all the other benefits and fun features I haven’t even really jumped into yet, but that is the great thing about it, you can just start using it right now and not even change the way you design. So, start using it right now, whether you are just simplifying and making your markup more semantic OR you are gonna build some sick new mobile game that will take over the world — who knows, maybe you can start selling stuffed animal versions of your gaming characters too.