web_based

Interacting with video with HTML 5 VIDEO and CANVAS tags

Tue, 20 Apr 2010 22:13:41 GMT

We've got HTML 5 on the brain these days! Check out Sean Christman's awesome demos of interacting with videos via the HTML 5 VIDEO and CANVAS tags:

http://www.craftymind.com/2010/04/20/blowing-up-html5-video-and-mapping-it-into-3d-space/

comments

HTML 5 Data Storage and Offline Applications

Tue, 20 Apr 2010 22:00:48 GMT

The HTML 5 specification has a lot of new features. I just did a presentation on the data storage and offline application features:

I used Eric Meyer's S5 presentation system, to which I spliced in jQuery UI transitions and a mobile stylesheet.

comments

The new &INPUT

Thu, 08 Apr 2010 18:12:52 GMT

Many moons ago I got my first home computer: an Apple ][c. Included with my shiny new Apple were a set of disks with demos, guides, and utilities, many of which were written in AppleSoft BASIC. The interactive capabilities of BASIC were pretty rudimentary, and on these disks there were BASIC programs that seemed to be doing more.

So I took a look at the source code for these programs and lo and behold, Apple had built themselves library of custom BASIC commands that were tied to the & character (so instead of using INPUT they would use &INPUT and so on). This custom library was a simple binary file, and if you loaded that file into memory you could use the nifty new commands in your own programs. This added a lot of polish to what were otherwise simple BASIC programs. Other programmers learned about this, and soon many libraries were available with custom BASIC commands.

Fast forward to today. Apple has just released their iPad. The iPad comes with a Safari bookmark for the User Guide, which opens as a web application in Safari. And like the old disks included with the ][c, this guide seems to do some pretty amazing things for something done entirely in HTML, CSS, and JavaScript.

Turns out that once again Apple built themselves a custom JavaScript library for this app, and someone has already found it:

http://almost.done21.com/2010/04/adlib-apples-secret-ipad-web-framework/

I hope Apple will release this library for public use. It would be awesome. Even if they don't, like the old BASIC library this new library shows what's possible.

comments

Our first iPad app!

Fri, 02 Apr 2010 15:23:31 GMT

Today we launched Ideate, our first iPad application. It's a digital sketchbook with templates, custom pens, and sharing capabilities. It's almost enough to make me want an iPad.

Check out the Ideate blog too.

comments

Happy Birthday

Thu, 01 Apr 2010 16:23:29 GMT

Happy 5th Birthday, EffectiveUI!

comments

More EUI in the news

Fri, 19 Mar 2010 17:08:29 GMT

On top of our success at SXSW, Peyton and Rebecca were interviewed by Vidya Drego for Q&Agency.

My favorite quote is where Peyton says, “We get developers involved out of the gate and they put as much thought into the solution as designers do. We don’t believe that designers own the great ideas and developers just execute them.” That is one of the most important aspects of EffectiveUI for me, and I’m happy that it’s a principle that starts at the top.

comments

Dealing with Hidden Complexities

Mon, 15 Mar 2010 06:02:07 GMT

The other day I had a conflict with a colleague. (I always tell people, when you gather together smart people who are really good at what they do and passionate about their work, there’s going to be conflicts. This is actually a good thing; I know I wouldn’t be nearly as good at what I do if it weren’t for being pushed out of my comfort zones.) The topic of the conflict wasn’t all that uncommon: she was advocating for great user interaction--which is what we are known for--and I was pushing back because I was worried about the aggressive development timeline which didn't leave any room for recreating complex interactions and designs. And I was frustrated because I didn’t have a way of quantifying my concerns in a meaningful way for her.

Ordinarily, my team is committed to taking the awesome interaction and graphic designs that our colleagues create and reproducing them exactly in browsers. About the only time we’ll usually push back is if there’s something the technologies simply can’t do, such as an issue with an older browser or something. Generally speaking, we can build just about any interaction or graphic design given to us, assuming we have enough time. And that was my worry here: not enough time.

Down the Rabbit Hole

In this case my main concern was hidden complexities. Even having done this sort of work for the better part of fifteen years, I’m still regularly caught off-guard by having something that sounds simple turn out to be a 40-hour job--40 hours that you didn’t plan for and have to come at the expense of something else.

HTML RIAs are particularly vulnerable to hidden complexities because the technologies involved (HTML, CSS, and JavaScript) are designed for fairly specific capabilities, and modern interaction and graphic design push those technologies to their limits. The more the technologies are pushed, the more brittle the solutions become and the more rabbit holes appear.

What’s worse, spotting these rabbit holes in advance is particularly hard to do, especially when approaching the problem from a design point of view. That’s what makes it so hard to quantify these issues in a meaningful way, especially when providing project estimates. It’s sort of a vicious cycle.

Uncovering the Complexities

One of the ways to mitigate the risk of hidden complexities is to be aware of the situations where they are most common. And really, there are only a few:

Customizing the Appearance of Form Fields Let’s face it, the default quality of the user interaction in standard HTML forms isn’t exactly stellar, and the problem has only grown worse as users have become used to more sophisticated interactions. And there’s not a graphic designer in the world who likes the default appearance of HTML form fields. They want rounded edges, and background gradients, and graphics inside of dropdowns and select boxes.

So you would expect use to have awesome control over the appearance of form fields using CSS, right? Wrong. CSS control over form fields is wonky at best. From browser to browser, from platform to platform, the same CSS rule will have varying effects on form fields. This is because of incomplete CSS specifications on the topic, which left CSS control of form fields up to the individual browser manufacturers, which in turn led to inconsistencies.

This is probably the largest minefield of rabbit holes, if I may mix my metaphors. Even something as simple as "we need to put graphics inside of our dropdowns" turns into a trip through browser hell.

Animation With a notable exception I cover below, HTML is not the right medium for animation. Anything more than simple stuff--fading or scaling elements, or simple motion--can not only be difficult to implement, debug, and maintain, but also prohibitively resource-intensive.

Interaction with the Local System Because of browser security limits, interacting with the local system is problematic at best. Simple drag-and-drop between a browser-based application and the desktop is an enormous undertaking.

If your project is moving through any of these minefields, focus on these areas as having potential hidden complexities.

Mitigating the Risks

So let’s say you know you’re wandering through a warren of potential rabbit holes. How can you avoid stepping in one and breaking your project’s proverbial ankle?

Use a Library JavaScript and CSS libraries are legion, and there are some really good ones out there. jQuery is my personal favorite, especially for dealing with custom form fields and random rabbit holes that don’t fall into the three main categories above. But I know people who swear by Prototype, or Dojo, or any of a number of other libraries. Just remember, libraries are abstractions, and as such they are subject to the Law of Leaky Abstractions. They can come with their own rabbit holes, so beware. A library can be as much of a hindrance as it can be a help.

Apply Tiered Browser Support A core concept in progressive enhancement, tiered browser support specifies different levels of support for specified groups or tiers of browsers. This differs from standard browser support methods, which generally specify a group of browsers and require exactly the same interaction and graphic design for all of them. Tiered browser support isolates older or less-functional browsers

Use Appropriate Technologies Sometimes HTML isn’t the best tool for the job. In those cases, consider using a tool better-suited to the needs at hand. Don’t be tied down to one set of technologies out of dogma, embrace your full toolbox.

Use New Technologies HTML, CSS, and JavaScript are constantly evolving, and are growing in response to our needs. CSS-3 specifies more rigorous (though still not 100% complete) control over form fields. HTML 5 has the canvas tag, which provides a useful API for 2-D animation. HTML 5 also specifies a native drag-and-drop interface that can even interact with the OS desktop and other applications. Of course, CSS-3 and HTML 5 support is spotty even in modern browsers, so be careful here as well. But chances are you only need one or two of the new capabilities. If you combine this with tiered browser support and a solid library, it can be enormously powerful.

For example, consider asynchronous interactions. Not too long ago we had to rely on hidden frames or other sleight-of-hand to create the illusion of asynchronous interactions. Today, we have AJAX interactions. One simple solution eliminated a huge headache and pretty much single handedly ushered in a new era in web-based user interfaces.

Work With Your Colleagues Depending on the sort of shop you work in, this is either a no-brainer or a laughable suggestion. I’ve worked in both kinds of places and I can tell you I certainly prefer the former over the latter. Either way it bears mentioning and is probably the most important tool for mitigating the risks of hidden complexities. In fact this is such an important tool that I won't work with people who aren't open to collaboration. I've tried it many times, and every single time it reduces project quality, results in angry clients, and irritates my blood pressure. Life is too short.

Climbing Back Out

Aside from the near-omniscience that comes from vast amounts of experience with a technology, I know of no way to really avoid having to deal with hidden complexities. Even with a thorough knowledge of the riskiest areas and a good set of mitigating tools in your toolbox, you are still going to fall down the occasional rabbit hole. What do you do then?

In my experience, it comes down to time management. You know, as a developer, when you’ve fallen down a hole and are spending too much time on something. (And here you have to be honest with yourself; sometimes it’s downright fun to tackle these problems, but your time is valuable and you need to spend it wisely.) When that happens on a project where you simply don't have the hours to spare, put a time limit on yourself. If significant progress isn’t forthcoming, it’s time to put the kibosh on it. Apply a new tool, work it out with the client or your colleagues, whatever, but do what it takes to pull yourself out of that hole.

Hidden complexities are a fact of our industry, but they don’t have to be fatal. With a good set of tools and an understanding of the risks and you can produce awesome user interfaces on an aggressive timeline.

comments

Project release: I'm a PC

Thu, 25 Feb 2010 20:08:03 GMT

I'm a PC, and I built this website.

This is what I've been doing for the last four weeks (longer than that, actually...we've been sprinting for four weeks, I was doing the dev for about a month before that). Please note this is an entire DHTML webapp done with semantic markup, standards-compliant Javascript, and progressive enhancement. Also modern browser support (though some bits are still a little off in IE6).

At the moment we're having some glitches with server farm integration, but we'll get them ironed out shortly.

The markup is mostly mine, about three quarters of the CSS is mine, and about half of the scripting is mine. I laid the foundation, and I produced the DHTML prototype/proof-of-concept (which helped convince Microsoft to go forward with the project).

comments

Project release: Gallavants

Thu, 25 Feb 2010 19:17:27 GMT

After many weeks of hard work, we're releasing a project:

Gallavants!

This is the first kid's site I've ever done. We have a couple of quick changes yet to do to bring everything into COPPA compliance, but it's good enough to launch.

If anyone out there has kids that would be interested in taking a look at the site, I'd love to hear what they have to say.

Point of professional pride: It's a flash-intensive site, but it's compliant with the XHTML 1.0 Transitional standard. (Mostly. Any page with a form will have issues, since our Java back end does not produce compliant HTML.)

comments