Crafting the SAPO Campus platform, a thousand pixels at a time.
Latest posts

High Performance Javascript - dealing with JSON

No Widget is an Island

Designing Email - Part II

Designing Email - Part I

The amazing "widget" object

The Facebook Witch Project

SAPO Campus keynote from OSL Unesco demonstration session

SAPO Campus session at the UNESCO OSL Seminar

SAPO Campus - Eden Seventh Open Classroom Conference

SAPO Campus leaflet for the UA freshmen


Janeiro 2011

Novembro 2010

Fevereiro 2010

Dezembro 2009

Novembro 2009

Outubro 2009

Setembro 2009

Julho 2009

Maio 2009

Abril 2009

Março 2009

Fevereiro 2009

Dezembro 2008

Novembro 2008

Outubro 2008

Setembro 2008

Sexta-feira, 5 de Fevereiro de 2010
Designing Email - Part II
So yesterday 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.

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.


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 Amazon is 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)

Published by bruno-abrantes às 00:56

Quinta-feira, 4 de Fevereiro de 2010
Designing Email - Part I
[caption id="attachment_362" align="alignnone" width="424" caption="The Interwebz LOLz at your lack of email facilities."]Zeus, sporting some lightning.[/caption]

So yeah, SAPO Campus 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 as 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 Home widget-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!

A huge statue of Bender, dressed up as a Pharaoh.

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 & 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:

So anyway, I started mocking up some interface designs, rocking it out to the Glee soundtrack. This was a few days ago, so they're ready (I think). Part II of this post (hopefully coming out tomorrow) will expose my new baby to the harsh spotlight that is the Web. Tough luck, kiddo.

Published by bruno-abrantes às 00:10

About us
Janeiro 2011








todas as tags

subscrever feeds