Excellent video by Alex Faaborg, a UX designer for the Mozilla Firefox project. This debate has been going on for ages now, and the Firefox team is settling it once and for all. All of the issues Alex brings up sound perfectly valid and well sustained to me. Totally the right move for Firefox.
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?
So last time I wrote a little about the conceptual and practical challenges of adding emailing capabilities to the SAPO Campus platform. I was adding some final touches to the design proposal for the new feature, and it’s pretty much done by now, so I thought I’d finally put it out there, and discuss some finer points of the design.
As email clients go, this solution is pretty much standard, so no revolutions here. I went to some length discussing this on the last post so, if you haven’t read it, go do it now. It’s the least you can do. The best I can do then is try to make the whole experience not suck. Part of this is still up for grabs, since I don’t know yet how fast and responsive the interface will be. For now, I’ve focused my efforts into making it as simple and clean-cut as possible: Email in general has evolved into one hell of a gargantuan system, with lots of features most people don’t really give a crap about. So my main task involved getting rid of as much feature-creep as humanly possible. I thought about the features most people use on their day-to-day emailing and put those in the front row, and hid or altogether scrapped the more obscure ones. (…) more after the jump ›
After much discussion and back-and-forth of ideas, I think we’ve finally nailed it, and, let me tell you, this is going to be wayyyyyy better than the iPad. Ok, not better, but still pretty damn close. (…) more after the jump ›
