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. Read the rest of this entry »
The Interwebz LOLz at your lack of email facilities.
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.
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.
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.
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.
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:
When developing widgets in conformity with the UWA spec, there is a seminal Javascript object which makes the UWA environment available, exposing essential methods that handle widget events, grab preference values and modify the widget’s HTML. I’m talking about the widget object. This handy page lists every method readily available to use in the widget object.
All these methods and callback functions, as useful as they are, are also very platform agnostic (hey, it’s a good thing), thus failing to cover the particular interesting moments of a platform such as our very own PLE. I’m talking about basic stuff here, such as a widget knowing whether it was hidden, shown or closed.
Ok, that’s all fine and dandy, but how about a solution? After fighting a somewhat uphill battle trying to access an iFrame’s DOM (not the HTML per se, but rather its Global javascript objects) in a way that did not crash in certain browsers (ahem), I finally settled on this little line of (slightly ugly) code:
document.getElementById(frameID).contentWindow;
Armed with this code, I could now access random iFrames and have them execute arbitrary code (maniacal laughter ensues). So I decided it would be cool to let widgets implement some PLE specific functions, allowing developers finer control over how their widget reacts to specific platform events. The functions should be declared in your widget, inside the widget object. They’re not required though, so if you have no need for a specific function (or all of them), it’s cool, I guess. Not that I care. Hm. Anyway, here’s the complete list:
This method is triggered when a user resizes columns in the platform. Since this causes the widget to resize as well, you might need to perform complicated Math equations or stuff. I don’t know, just saying.
Unsurprisingly, this method is fired when the user hides the widget body using the little collapse button on the left of the widget chrome. This is useful if, for example, you need to stop a Flash movie in case the user hides the widget.
In 99% of cases, and if you’re not CUI - Coding Under the Influence, you should use this method to undo anything the onHide() method did. It fires when the widget is uncollapsed and is thus once again visible to the user.
This method is triggered when a user deletes your widget (if your widget is awesome, this will never happen). Once again, use this to stop Flash movies or timed function executions.
The reverse of onClose(), this is triggered when the user undoes the delete action (yay, the user loves your widget again!).
Sadly, this tale does not end with every one of the main characters being killed/kidnapped in the woods by a crazy hermit/ghost/monster. I say sadly because that movie ending is so awesome every other movies should be ashamed not to end the same way. Anyway, I digress.
A couple of days ago, our team decided it would be sweet to get some Facebook loving in our newly-launched PLE in the form of a widget. Upon discovering there’s a great Facebook widget in the Netvibes Ecosystem, I giddily smiled and immediately thought we’d have a fully functional widget in under 15 minutes. Oh boy, was I wrong.
Telling our local widget to directly load the Netvibes widget remotely proved to simply not work. So I downloaded the code and ran it locally. Eventually, I found an if statement that seemed to be the culprit, and, upon stripping it from my code, the Facebook Connect badge finally appeared. And then all hell broke loose.
The Netvibes Facebook widget, very sensibly I might add, uses its own API key, which I later found out is actually tied to a specific domain (netvibes.com in this case). Put simply, when accessed from our domain, Facebook Connect would go down in flames. Not about to give up, I registered a new Application at Facebook and got our own API key. Yay, now Connect worked! Well, not really. Since our widget runs in an iframe, I couldn’t get Connect (which opens in it’s own popup window) to tell the iframe that yes, it was ok to login the user.
After trying to fix the issue for what seemed to be hours I finally gave in to the frustration and officially broke up with Facebook. While she is indeed hot, she was way too high maintenance for a simple guy like me.
I was kind of heart broken (let’s face it, it wasn’t that long a relationship) when I met Facebook’s younger, hotter sister. If you’re beginning to feel lost in the girl metaphor, I’m talking about Facebook’s iPhone Web App, which was the way folks with iPhones and iTouches accessed Facebook before the awesome native app came. In fact, this iPhone Web interface was so damn cool I figured I just had to have it.
In about five minutes I had a functional widget that displayed the iPhone Facebook page inside an iframe (which itself is inside an iframe… get it? I know, I know, it’s ok). This was already pretty awesome, but still not anything near my usual awesomeness level, so I quickly tried to get to second base (there it is again, the metaphor!) with this new, hotter girl who didn’t seem to mind me embedding her inside weird, deprecated HTML elements.
Second base means, of course (aren’t you reading? Get with the program!), designing an auto-login system. With the widget the way it was, users had to login every single time they loaded the SAPO Campus PLE, which is no good in my book. So, i quickly hacked together some Javascript (plus some PHP magic provided by José which is far too complicated for me to make fun of) to automatically fill the login fields with information the user supplied in the widget options menu and click the button. Did I mention it did all of this automagically? Oh, baby, now we were getting frisky.
Then Internet Explorer crashed our party (I guess a sock on the door knob really isn’t all that universal anymore). The iPhone interface would not load at all in any version of IE (gasp!). It’s okay, IE, I understand. After all, this web app is specifically tailored to work in Webkit browsers (although Firefox doesn’t seem to mind), so I really didn’t expect you to just be cool and hang out with the rest of us. It turns out this beauty of a mobile web app has a cute cousin who, although slightly older and way less hotter, actually works in every browser alive today (and what does that say about you, m.facebook.com?). Two lines of browser sniffing code later and voilá, a working Facebook widget! IE users are served the traditional Facebook mobile interface, while other browsers get the shinier iPhone interface. Most of Facebook’s funcionality is available in both versions, though.
Oh yeah, here are a few images of the new widget in action:
You should also be able to date Facebook’s hot little sister very soon. I just finished testing (cause these days you just have to get tested before diving into anything serious), and our server wizard is making sure the widget goes live without a hitch. Look for it under Categories->Social in our Add Content menu!
