Wonderful video by Hyperakt (& friends). Do you also have PSD?

Website developed for an Environmentally themed conference at the University of Aveiro. Developed using the CakePHP Framework. Visit the website

Click here to view the embedded video.

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.

Click here to view the embedded video.

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?

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.

So yeah, here it is.

The first iterations were all designed sans colour, using only shades of gray. It’s tremendously helpful to do this before slapping your colour scheme on the design, to make sure there’s enough contrast and that the hierarchy and element states are properly conveyed. The image shown here is what I consider to be the “final” interface iteration.

In full-blown Technicolor®

Same deal as before, but now in full colour. Although I say “full”, the interface actually uses colour (the SAPO Campus trademark greenish) very sparingly. I think this does a good job of highlighting key elements in the application without confusing and cluttering up the user experience.

Basically, the application is composed by four key elements: the toolbar, the accounts pane, the message list pane, and the message viewer pane.

The toolbar

This area exposes the main actions available to the application, from left to right: Getting new mail, Composing new mail, Replying, Replying to All, Forwarding, Deleting and Marking as Spam and, finally, Searching through your mail.

There was a lot more I could’ve fit in here but I decided I’d keep it simple. Only the most useful actions are available in the toolbar and, furthermore, all the buttons are contextual, meaning that some of them stay inactive (visually less opaque) until a message is selected in the message list pane. You may notice the interface is lacking several common features such as filtering options and “Mark as…” buttons. The way I see it, filtering is kind of useless if you provide an awesome search function (and yeah, that’s my idea here) and marking stuff as read/favorite/whatever probably makes a lot more sense if it’s done in the same place where the message is displayed.

The accounts pane

Since the client we’ll be using essentially uses an IMAP connection, the folder list for a given account will be automatically populated by the folders already on the server. It’s also possible to add multiple accounts, and they’ll be listed hierarchically and labeled by their actual email address. The folders display the number of unread messages, and the whole accounts pane is resizable (using the small dot on the border as a drag anchor). The only thing left to solve here is adding and removing folders: I’m not yet sure if this should be directly present in the main interface or if it should be tucked away in some kind of settings view.

The message list pane

Each row on this pane is a message. You can sort messages by clicking on the list headers, and you can visually tell apart messages that are unread, carry attachments or the ones which you marked as favourites. Marking a message as a favourite or as unread (once you’ve read it) is as easy as clicking on the appropriate row + column combination. This ensures that marking messages as favourites/unread is cognitively linked to to the message itself, and not distant from it as would occur if the UI had a specific “Mark as…” button(s). Once more, the entire pane is resizable using the small dot below as a drag anchor.

The message viewer pane

There’s little to be said about the message viewer. The interface should take a step away here and just let you read your email comfortably enough. Most email clients use disclosure triangles and such to feed you a bunch of metadata about the message. I’m waging that most people don’t really care about such data (and actually get confused when seeing it) so I chose to simply make it go away. Only the utmost important interface elements remain: Subject (in bold), From, To and Date Received. There’s also this tiny icon on the top right corner of the pane that lets you view your message in all of its fullscreen glory.

Composing messages

Alongside reading messages, composing and sending are at the crux of the email experience, so this screen better be really well designed. Again, the goal was to keep message composing as pain-free as possible, providing simple interface controls and a well thought-out rich text editor. Once you click the “Compose” button on the toolbar, a dialog window pops up with the compose interface. This dialog window is draggable/resizable, it’s not modal (meaning you can still interact with the UI below) and it’s not exclusive (so you can type out two messages at once, or keep one message you’ve received earlier while composing a new one).

The left column on the compose window lets you keep track of your attachments and upload new ones. Since this is isn’t a desktop app (and the HTML5 drag-and-drop spec is not quite there yet) you can’t just drag attachments into the message body itself, which I think is the most awesome way ever of adding attachments to a message. Uploading attachments is done by AJAX magic and never forces a reload, so I believe it’s a pretty much stress-free process.

This interface also provides a toolbar, and I’ve tried to keep the number of buttons down to a minimum. You can basically send your message (and this button is repeated at the bottom, just in case), check spelling and save it as a draft. These last two could’ve been avoided, since spell checking and periodic saving of your message should be done automatically without user input once every few seconds. However, most users are, I believe, extremely distrustful of “automagic” systems, and a big fat button that users can click feels all the more safe. If the application crashes or the user closes it by mistake, she’ll then be pleasantly surprised that the email client was smart enough to save her work. Phew!

Glancing at the interface, you might notice some standard fields lacking, namely “BCC” (Blind-Carbon-Copy) and “Reply-to”. These are without a doubt useful features, but ones that most people don’t care about. I’ve chosen to tuck them away in a nice little dropdown field that expands when you click a button named “Add field”.

Finally, actually writing text was made as simple as possible. There’s a small tabbed navigation that allows you to switch between a rich-text editor (the one turned by default, since it’s the most likely option for most people) and a plain-text editor. The rich-text editor is as uncluttered as possible, providing only the most crucial text-editing features: think Bold/Italic, linking to pages, aligning text, etc.

Searching

Without complicated things such as filters and fiddly controls to allow you to find the stuff you need, you naturally turn to the search facility. While nowadays the sort of “magical” search first introduced by Amazonis pretty much standard, there are still lots of applications who still don’t quite “get” it. By this I mean the application forces the user to refine her search before actually searching: there’s usually this list of checkboxes that can be turned on or off and your search will be limited those fields which were selected. This is just plain nonsense, and the geniuses at Amazon knew it. People don’t want to make tough choices and worry about the kind of metadata they’re searching for. That’s what computers are for! Search should be as easy as:

1. Type in query.
2. Found it?
3. No? Okay, look at some of the other results.
4. Maybe try applying a filter or two?
5. There you go, you found it!

This is the exact experience I had in mind while designing the search feature. It’s dead-simple to use. You can search for whatever you want, and then filter the results later should you need to. The search is live and begins as soon as you type, so I bet you’ll find that lost message in a matter of seconds.

Sweating the details

The devil is in the details, or so they say. Details can also make or break a design, so it’s important that you spend a good amount of time working out the finer aspects of your application. Everyone else does the obvious stuff, so what gives your users that final push is the little things that make them smile when they notice them. I’ve already discussed the importance of periodically saving the user’s work, but there’s a few other things to consider when designing the email application.

First up is history management. Since the whole application is powered by Javascript and AJAX, users won’t be able to rely normally on the back/forward buttons in their browser. Since other areas of the PLE already address this concern, it makes sense to develop a history stack for the email client as well. You’ll be able to use your browser’s built-in history buttons to go through your messages or to make your compose screen disappear or reappear.

The ability to undo your mistakes (ie. deleting a message) is something I normally strive to implement, but I’m not sure this will be as straightforward to do with Roundcube as if we were developing the whole application. It’s something to keep in mind though.

We’ll also try to make Roundcube play nice with our Notification Server so that, when using the PLE, the user doesn’t need to keep checking the email page. The email icon (by the way, these are not the final icons in the screenshot above) will itself tell you how many new mails you have in your inbox, anywhere you are. In the future, advanced functionality could include message previewing using floating dialogs that are shown wherever you are in the PLE.

Finishing up

If you’ve read this far, then you deserve a cookie. No, really, this post kind of got out of hand. But hey, at least the mockups had a superhero theme going on! (Extra cookie if you noticed)

SAPO Campus (my full-time project nowadays) is supposed to provide this wonderful set of happy magical fun tools to a University. It’s a tough crowd, we’re aware of it. On one hand you have Internet savvy students, skipping class for a few Farmville dollars, and on the other, teachers and support staff, most of them struggling to get this “social networking facemagazine thingamajig”. Oh, and everyone in the middle. While we’re convinced we already offer some very compelling tools that should please both ends of this crowd, there’s this one thing that some (yours truly included) consider pretty damn central to the whole “unified” experience: an email client. While we’ve kept pretty much silent on the matter, this has always been on our list of awesome-must-haves (yes, i’m hyphenating it). Albeit pretty old, email is still pretty much central to the whole Internet experience, and the Gods, in all of their godliness, would surely scoff at a PLE which failed to provide at least a simple email client.

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.

Round 1

Our first idea, and one that actually got quite a bit of traction, was to slap a mean and lean email client on a widget. It would use IMAP, and so would let you keep track of any account on whichever service you use (most provide an IMAP connection these days). This sounds neat, until you realize that a widget has precious few real-estate. Doing this in a widget meant we’d have to severely cut down on some features (dropping message composing and sending was tossed around), and simply would not do as the only email features in SAPO Campus.

Round 2

After ditching the widget format, we started to think about how we’d fit an email interface alongside our already existing interfaces. Right about at the same time, we started a major overhaul of our user profile system, and decided we’d integrate these new features in tandem with the already existing My Homewidget-based PLE. Under this new system, a user’s url (take mine, for example) would provide access to his/hers Profile, My Home and Portfolio platforms. Taking into account this new structure, it dawned on us that it made perfect sense to add an Email icon to the top navigation, and integrate the now illusory email client into the user’s PLE.

Neatorama! But wait!

Designing and developing an email client is no walk in the park. In fact, here’s how I think the experience would go down. Go ahead and read it, inhale the pain etched on those words, and then come back. Seriously, I’ll wait.

Design-wise, it’s just very hard to come up with an email client experience that doesn’t suck. All of the clients I’ve gone through sucked. Some of them sucked a little less (wink wink Gmail & Mail.app) but, at the core, most of the whole email thing is boring and hard. Whenever I’m emailing, I actually wish I was having a taco somewhere in Mexico with some random girl named Consuela.

Development-wise, there’s all these hoops to go through. Using IMAP takes away some of the pain, but it’s still like giving birth to a small elephant. I’m not going to pretend I know what the actual problems would be, because just thinking about it makes me want to get another taco and ring up Consuela. Let’s just agree it’s a pain in the rear end of the human body.

Enter the Roundcube

After some Googling around, Roundcube started sounding like one of the best open-source webmail clients out there. Technology-wise, everything they use seems to be compatible with our setup. The interface is actually pretty decent, and it’s clearly designed to look and feel like a desktop application, so it’s pretty well in line with our existing platform.

Using an out-of-the-box system such as Roundcube allows us to skip much of the boring stuff and get a functional version out the door very soon, but it does pose a few obstacles:

• It’s pretty much your standard email client, so this means I won’t get to reinvent emailing (again!) anytime soon. According to my own reasoning, this means it will suck. The challenge is in making it suck as little as possible, and try to live up to the decent email clients already out there.
• It’s supposed to be a standalone solution, so getting it to play nice with our own user database tables is probably going to resemble that scene in Lion King where Simba is trampled by a crazed pack of Gnus.

Click here to view the embedded video.

Click here to view the embedded video.

Take a look around the room you’re in right now. See all those devices, all that furniture, all those DVDs? All that stuff? Have you ever wondered where it comes from? Annie Leonard at The Story of Stuff did, and she wants to share her findings with the rest of the world in this amazing video.

“The Story of Stuff” is a 20 minute, down-to-earth and approachable animation that goes through the various stages of the product lifecycle (Extraction, Production, Distribution, Consumption and Disposal) while providing enormous insight into what she believes to be a fundamentally crippled business model. Make sure you watch this and pass it on. You won’t be disappointed, and hey, this girl might just end up saving the world.

If you’ve spent some quality time with Javascript, then you probably already figured out it’s an event-driven language. This means that most things done with Javascript are simply reactions to what can be defined as interesting moments in your application. Arguably, the most common of these interesting moments, or events, are the ones pertaining to direct actions performed by the user, such as clicking a link or entering text in a field. Most of these user interactions are already implemented in the DOM, so all that’s left to you as a developer is to listen to those events and perform some actions when the browser triggers them.

Using jQuery, here is how you listen for a click event:

$(".button").click(function(){
//Perform some actions
});

Simple, right? Every line of code inside that function() gets executed when the user clicks an element with a class value of button.

What if you need more?

All these events automatically made available by the DOM are very useful indeed, and they probably cover about 90% of your application’s needs. However, sometimes it’s just beyond useful to be able to define your own events, which are triggered on your application-specific interesting moments.

The main advantage of using custom events is that it gives you a lot more flexibility in your work, allowing you to effectively decouple all the different modules in your project. Instead of one module directly invoking some public method of another module, you can just trigger a custom event and have whatever module is listening to it react. If this is confusing to you, try to think of it like this: Normally a part of your application would have to directly tell another part to do something. With custom event listeners, all that part would have to do is shout out “Hey, it’s that time again!”, and, if the other part was listening, it could decide whether it would act on it.

So how do you implement all of this?

Luckily for you, if you’re using jQuery, implementing this custom event/listener model is rather easy to do. Firstly, you’ll need to create an Event object with whatever properties you desire:

var event = jQuery.Event("mailsent");
event.to = "foo";
event.message = "bar";
$().trigger(event);

That last line is of special importance, since it’s the code which actually triggers the event out there for listeners to listen to.
Next up, you’ll want to define a listener, using jQuery’s bind() method:

$().bind("mailsent", function(){
//Code that executes when the event is triggered goes here.
});

And that’s pretty much all there is to it. Note that you can bind and trigger events to whatever selector you wish (such as $(“#myDiv”), for example). What I did in these examples was define no selector at all, because the custom event created was meant to be abstract, and as such had no relationship whatsoever to any element present in the markup.

Wrapping it up

I’m sure that by now you can begin appreciate the power of custom events in Javascript. They help keep things neatly separated, by foregoing the need for one module to know the specifics of another module (such as function names), proving that ignorance really is bliss. If you’re working in tandem with a team of Javascript developers, you’ll find using events really speeds up everyone’s productivity and provides a nice simple interface for different aspects of the application to communicate with each other.

Browser tracking data from Net Applications Market Share Report.

Some of these are funny and well done, while others… not so much. However, considering these are currently Internet only, I kind of see the market segment they’re targeting. Microsoft obviously hopes these will become viral and spread like funny kittens. A Microsoft product being viral… isn’t that ironic?

S.H.Y.N.E.S.S

Click here to view the embedded video.

G.R.I.P.E.S

Click here to view the embedded video.

O.M.G.I.G.P (Not Safe For Stomach)

Click here to view the embedded video.

F.O.M.S

Click here to view the embedded video.

Click here to view the embedded video.

Click here to view the embedded video.

TypeKit is probably going to radically change Web Design. Yesterday, Jeffrey Veen announced it on the TypeKit blog.

Using Jeffrey’s own words:

Every major browser is about to support the ability to link to a font. This is a massive upgrade for the web. But there’s a problem. While it’s technically quite easy to link to fonts, it’s legally more nuanced. Almost all fonts are protected by copyright — even those available for free — and very few of them allow for linking via CSS or redistribution on the web.

That’s where Typekit comes in. We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.

When CSS3 comes around, designers will once again have (almost) full control over their typography, and this time without having to resort to Flash. TypeKit’s easy one-line hosting solution is setting itself up to be as game-changing for the typography industry as iTunes was to the music industry.

To keep a close eye on the development of TypeKit, you can subscribe to their blog or follow them on Twitter.

Jeffrey Zeldman is one of the fathers of the Web Standards movement. When everyone was using Flash, he soldiered on and shouted for everyone to hear: “Hey, write it in HTML instead!”. Now, according to himself, HTML, CSS and Javascript are the de facto standard the Web is built on. During this year’s SXSW Festival, Zeldman gave an interview to .net magazine where he discusses these and other issues of interest to the Web industry.

Download the article in PDF format (4.2 MB)

Since the release of version 2 of the iPhone OS, developers have been able to write native applications for the iPhone platform, and make them available (free or for a price) in the iTunes App Store. In just nine months, more than a billion apps have been downloaded from the store. As a recent iPhone user, one of the first things I did with the phone was access the App Store and start downloading some applications. After a mere two weeks, I can name at least 10 applications that are so good no iPhone user should ever have to do without them.

I know I didn’t mention a few more outstanding apps, but I wanted to keep the list as short as possible. Comment and tell me (and the world) why a given app is essential for you!

PS: This post marks the first official collaboration by Marta Ferreirinha in this blog. She will act as Editor-in-Chief, making sure everything I write makes at least some sense and that there aren’t any gaping holes in both grammar and logic. Thank you once again Marta!

Click here to view the embedded video.

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.

The problem of an incremental approach

The concept of making small changes for a long period of time is certainly not novel, but there were always costs involved. If you design a billboard and print 5,000 or 10,000 copies only to notice the kerning should’ve been a little tighter, there’s little to no chance your employer is going to let you fix it. If you develop a traditional desktop application (such as Photoshop), it’s difficult to implement small changes for all of your user base at the same time. Yes, you can resort to patches and updates, but there’s always a fraction of users who choose to ignore them, and, if your changes are substantial enough, there’s a probability the marketing people will want to push it as a brilliant new feature in next year’s version.

None of that happens on the web though.

Web, to the rescue!

If you’re a Web application designer, the fact that your software is served from a central location instead of being resident on your users computers can be a great advantage. You can fix bugs, correct graphical or interface inconsistencies and even introduce new features almost seamlessly across your whole user base. This allows you to adopt an Agile Development approach in the long run, since your work is not either set in stone or bound by the need to release periodical paying upgrades. This is great news for both you and your users.

It’s great for you because you don’t need to make sure everything is perfect the first time. Sure, your first release has to work reasonably well within the expectations of your users, but not every corner must be polished. You can work on the glossy finish after the release rush wears off, which means less overtime and cognitive strain put on before the release in order to make the first version absolutely perfect.

It’s also great for your users because you can react to their suggestions and needs really quickly, and can shift resources in order to tackle the organic and changing nature of the Web. This means users don’t need to wait a year to see interface blunders and bad bugs fixed, and also ensures people keep coming back because of new features and enhancements.

Wrapping up

Taking an incremental approach to your design process is certainly a good idea, but it’s unfortunately not always a possibility. However, when you can do it, the fact that not everything is set in stone is freeing at best, and allows you to deliver a vastly superior experience to your users.

What do you think about using an incremental design approach in order to ease the development process and provide a better end-user experience?

No, I don’t mean to say existing Internet Explorer 6 users shouldn’t upgrade to one of the countless newer, faster and safer browsers out there. What I’m talking about is a little gimmick which surfaced a week or so ago called IE6 Update.

The authors came up with the brilliant idea of mimicking the standard Internet Explorer information bar, urging users to update to a newer version of Internet Explorer. You can include the bar on your site or web application using a small code snippet available on the project’s website. It automatically checks if your users are running IE6, only showing the bar to those who are. So why is this such a bad idea?

Stop tricking your users

The way I see it, usage of this script is as close as can be to phishing. According to Wikipedia:

In the field of computer security, phishing is the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication.

By masquerading itself as a genuine Microsoft update, the script (and, by extension, the people who deploy it on their websites) is effectively breaking any kind of trust users might have in the service. Once users realize they’ve been misled, feelings of mistrust and anger arise and you can bet they probably won’t be visiting your site any time soon.

One other issue is that, by employing this script, you are negating your users the power of choice. The same power of choice you’re so proud of when you talk about Open Source Software, bash Microsoft for bundling IE with Windows, etc. If your users can’t or don’t want to upgrade, for whatever reasons, don’t hassle them, just deal with it. I still don’t know which is the correct answer to educating users about IE6, but I do know that IE6 Update is not it.