Bruno Abrantes

Photo taken by Thomas Hawk

So this Flash vs. HTML5 thing is definitely turning some heads in the web industry. On one hand you’ve got Flash, a time-honored tool which helped propel the Web forward when all HTML did was clumsy tables. On the other hand there’s the spanking brand-new HTML5 spec, which some promise will deliver us from the evil Flash has become. (Disclaimer: yes, I have a Mac, and Flash makes my computer cry.)

Alas, this post isn’t about that struggle, that last paragraph was just for context (phew!). What I’d like to talk about is one of the main arguments people come up with when defending the viability of Flash:

Until there is a tool that allows non-developers to create nice HTML5, JS etc. without the need for code, Flash will still exist.

Ah, the Flash IDE. The sweet calming song of the timeline-based animation, the drag-and-drop magical controls. This stuff is exactly what gave Flash such a bad rep among the Web Development community. Overlooking the fact that these ready-made components are (sometimes) poorly coded, perform terribly and allow for little customization, I’ll try to make my point without sounding like an elitist jerk:

Why are “non-coders” developing websites/web applications anyway?

When did it become acceptable to program without actually writing a single line of code? I must’ve been too busy playing Halo 3 to notice. Last time I checked, hand-coding your application was still the way to go. Even popular Javascript frameworks definitely required some programming skill to be applied to a serious extent. Why should HTML5 be any different? Just because you can now animate stuff, all of the sudden everyone and their mother should be “developing” web experiences?

So I totally sounded like an ass back there. But hey, designers complain when developers try to design their own stuff (and most of the time they fail miserably at it), so why shouldn’t professional designers feel betrayed?. Why shouldn’t developers complain when designers want glossy ready-made controls that wholly trivialize the work of a programmer? As long as we’re at it, let’s allow architects to not only design houses but to engineer them and lay the bricks themselves. That would turn out awesome. No, totally.

What you should take away from this post is that we, as an industry, made up of designers, developers and everything in between, should learn to collaborate. Have this awesome idea but don’t know how to code? Find a programmer that is willing to do it. On the other hand, do you have mad backend skills but can’t develop the whole project on your own? Don’t try to design, just ask one of the many talented web designers out there. Respect the divide, don’t hop all over the place just because jumping is easy to do.

Yesterday, at the Google I/O conference, the search behemoth released, among other goodies, the brand-new Google Font API. This new API lets developers easily embed fonts into their pages for usage with the CSS font-family directive. And it’s really drop dead easy to include a font.

You can insert any font in Google’s catalog simply by linking to it as if it were a stylesheet:

<link href='http://fonts.googleapis.com/css?family=Droid+Sans' rel='stylesheet' type='text/css'>
</link>

After this initial step, all you need to do is use the font as you’d normally do for regular, web-safe fonts:

body { font-family: 'Droid Sans', arial, serif; }

Easy as can be, right? Oh, and here’s the kicker: the behind-the-scenes voodoo allows browsers all the way down to IE6 to take advantage of linked fonts!
The catalog is pretty barebones right now, but this is Google, and this is sure to be a project that will soon gain traction and favour among the Web Development community. I’m sure pretty soon the list of available fonts (which are all open-source, by the way) will grow exponentially.

What does this mean for the upcoming CSS3 @font-face directive? It’s potential is definitively great, however browser adoption and legal issues have prevented it from becoming as commonplace as other CSS3 novelties. Will Google change the way we think about typography on the Web?

This is a video from last year’s edition of FOWD, but I’ve only just stumbled upon it. 37 Signals‘ Ryan Singer delivers a great talk about Usability in Web Applications. Topics covered range from using emphasis to make your designs more usable up to using human language people can actually relate to. It’s a long video, but definitely worth the watch.

The concept of fiddling with and tweaking your design project on the final stages of development is probably not foreign to you, but the idea of doing it after your project is done might be.

If you work as a freelancer, you probably live on a project-by-project basis, and you realize that you just can’t spare the time to gradually refine each and every one of your projects. However, if you’re an in-house designer or developer (or if you’re just a freelancer who runs his/her own blog), you can probably appreciate the merits of a product-oriented mindset which is concentrated on getting a product out and then refining it continuously through it’s lifespan. (…) more after the jump ›

On the Web, first impressions are everything. Your page may have great content, it may just be what users are looking for, but, if your design fails to captivate users in a mere 5 seconds, your content might just never get noticed.

Enter the 5 Second Test, a quick Usability Test that costs next to nothing and can deliver great results. It’s basically  like any other usability test you’ve probably conducted before: there are users, tasks, and the application/site you’re testing.

At the start of the test, give your user a task to perform:

You’re on Application X’s home page. What are the ways you can subscribe to the application?

After informing the user that the page will only be visible for a short period of time, ask her to try and remember everything she sees.

You would then show your user the home page for about 5 seconds, and afterwards have her write down everything she remembers about the page. Finish up by asking one or two questions to assess whether the user has completed her task.

Sounds useful, doesn’t it? There are several benefits to using this method, the most proeminent being that it’s cheap and that you can conduct a whole lot of tests in a small window of time.

Even though conducting this kind of usability test is easy, I’ve found a handy tool that simplifies it even further. As a developer, you can create three kinds of test: classical (which is the one I described), compare (in which users compare two different interfaces) and sentiment (in which users describe their mood and most and least liked elements in the interface). As a user, you can take random tests and, as the page puts it, make an interface designer happy!