Mobile Innovators Falling Back?

antoniocapo: Blog Post: A twittering life. http://tinyurl.com/33esrk. Yours similar?

You can never be too fast to follow the latest trends in the World. Being slow, on the other hand, is unacceptable; it means you're not cool! Last night I was sitting around, doing some work, then @antoniocapo sent this out on Twitter, and the post got me thinking... (It also got me thinking that I'm probably the only one amongst the 8,000 people at RIM that uses Twitter. Facebook is catching up :)).

Well, for those of you who don't know, I work at Research in Motion, RIM for short. We make the BlackBerry. We are THE innovators in mobile technology. To be more specific, I work in the group that makes your Gmail, Yahoo!, heck all your personal emails delivered to your phone so you get more addicted to your device (more info here). We are the kings of push mail technology which saves you gazillions of dollars on mobile data bills.

So, what has this tweet got to do anything with what I do? It got me to realize that we're still very much on the corporate side. RIM's not trying hard enough to tap into the consumer market. Yes, last couple years we've done a lot to tap into the consumer market and achieved great success (ever heard of Pearl, Curve ?). But we can do better, we should be doing much better.

Then what happened next? We said, let's tap into social networks. I bet only people that had Blackberry's heard about the infamous (!) Facebook app. In my opinion this brought the biggest shame on the company's profile but nobody has realized it yet. First of all it's no where as cool as the Facebook iPhone app - it's not even close, it hurts. Let me tell you what this app does. You know, Facebook sends you emails on certain things - like somebody sent you a message, wrote on your wall, added you as a friend, right? All this app does, is sees these emails on your inbox and displays them to you in a pretty application. You can reply to the wall posts, etc from this app but that's about it. You can also tag the pictures you took with you BlackBerry and upload to Facebook, but that's the cool part of the app - so unimportant. Why don't I like this app? Because it relies on Facebook sending you an email (I'm already pissed off at Facebook because it never delivers these emails in a timely fashion anyways).

If you ask me, any application on BlackBerry that doesn't use push data somehow is LAME. A Twitter app that refreshes every 15 minutes is LAME (The coolest thing so far - which is kind of accidental, is to have Twitter send notifications to your Google Talk on your BlackBerry; but still, that's not a true, native Twitter application). A Facebook app that doesn't send you all the notifications is LAME. We provide really good infrastructure so you can write apps that will deliver real-time data to the device, i.e. push! Push, push, push, push.

What can I do so I don't cry myself at night? I take it as a personal goal to raise awareness of the BlackBerry API to the masses, a la iPhone SDK. We already have a great network of sources for BlackBerry developers, however - for some reason - it's not as cool, or popular as the iPhone's. Why isn't there any buzz about BlackBerry apps? What saddens me the most is the fact that even thought there is a tremendous amount of BlackBerry apps out there (yes, even US government has in-house apps built on BlackBerry infrastructure) the mass media - aka non BlackBerry users - don't know about them.

All BlackBerry developers out there - make sure you drop me a line. I want to hear your thoughts and ambitions on how to improve your experience so YOU can design and develop the coolest applications.

All BlackBerry users - drop me a line as well. What kind of cool applications do YOU want to see on your device so iPhone and other smart phone users are jealous of your BlackBerry?

PS: I'm no where related to the group that publishes the BlackBerry APIs, nor am I a PR person. I have no influence what so ever on those groups and I don't want to be. This is totally a non-work-related initiative of mine.

Can You Really Export Software?

Just a little thought experiment... Today, I came across an article (I really don't remember where) about Pakistan Software Export Board's new goals and expectations and what not. What really struck me the most is the name of the board and I have a gut feeling that it's actually misleading. I really believe i the fact that in the world we're living in today, software really became a mainstream commodity. My question however, is, can you really "export" software or is it the "labour" that you export by the means of outsourcing?

The best resource I've seen on this so far is http://www.emich.edu/ict_usa/exporting_software.htm.

What I'm most concerned about is how can you really regulate the software trade? With products like shoes, books, DVD's at least the Customs Authorities can do something. How can you monitor downloaded software? How about open source software?

All Your Code Base is Legacy

I hope, I'm not the first one two say this but I totally stand firm behind my wisdom! It's usually "legacy this" or "legacy that" but the general terminology lies around the concept of trying to work your way around existing source code.

When the term "legacy system" was first introduced all it meant was that the system had been there long enough that the owner/maintainer didn't want to replace it. But recently I've been hearing the "L" word a lot around my colleagues and the code they are talking about is from our last release which was only a couple of weeks ago. I keep thinking to myself, "Code that young can't be legacy, right?"

Truth of the matter is AS SOON AS YOU CHECK YOUR CODE INTO REPOSITORY, it becomes LEGACY (You have a repository right? Don't make me force you to take the Joel Test!). Little disclaimer here, of course having a repository also means you use it frequently - if you don't, again, please please PLEASE check your code in frequently and in small increments; it's a good practice and you'll actually see your progress easier.

You're in total denial if you don't believe me; how many times have you thought "What the hell does this method do?" or "How am I supposed to use this API?" Off the top of my head, here is a very short list of ways any code becomes legacy:

1. Some guy wrote it 7 years ago, the day before he was let go.
2. You HACKED it for the last release in order to fix your bug, but now, it doesn't click anymore.
3. You thought you had some progress last night and decided to check it in. This morning, how ever, you think you have a better solution but it's so damn hard to retrieve to the last version and you sit in your cube, beingmiserable and all... You get the idea.

Nothing is set in stone in the software world; you have to be able to adopt to changes all the time and often very quickly. One of the first things they teach you in Software Engineering is to design your solution to accept future improvements. No matter how well you designed your product at the beginning, you will come up with avenues of improvements which you would never have thought of before. Hell, even every step you take to approach your solution has the potential to make the solution legacy.

Only defense you have is to be aware that one way or another your code will become legacy and you can't stop that. Live by this rule for the next day, week or month and let's see how your life changes.

Interoperability that Actually Works

If your applications are already talking to each other, at least make them talk correctly! Web services and the ability to communicate between different applications ease our lives a lot. And I mean a lot; imagine going shopping without a credit card. Credit cards are convenient because they actually work (as long as you don't exceed your credit limit, blah blah blah...).

Last weekend I got quite frustrated trying to publish my last entry. I'm using Google Docs as my text editor for this blog. I'm actually in love with it - it makes my life easier in many ways.

1. All my blog entries are in one online place - I can access them from home or work without carrying them around (by the way there needs to be more online storage services; I used to love Xdrive back when it wasn't AOL's puppet).
2. I can easily collaborate my side-project specs with relevant people - Almost everybody now has a Gmail account, so I don't even need to create or manage accounts for them.
3. Automatically publish to my blog since I'm using Blogger to host this wonderful page - Oh, by the way this is what I'm going to be bi*%#ing very soon.

As I said, I was writing the entry on Google Docs, placed my fancy picture in the correct location and finally "Published" it. The experience is perfect until now. Then I go back to my blog to see if the layout actually looks correct; and of course I get disappointed with the results immediately.

Most obvious flaw in this experience is the title of the post - as a matter of fact the lack there of. A Google Docs document has its own title, which is (I'm totally guessing here) the first line of the document when it's first saved. Usually my first line is the actual title of the post which is totally OK. But the title of the post is technically nothing, therefore Blogger picks up the first 6 words that doesn't contain weird characters of the entry. The following is the table of the title and the URLs of my previous posts.

Title	URL	Published From
I Give Up	.../i-give-up.html	Blogger
Design to Interface	.../design-to-interface-were-all-familiar.html	Google Docs
High Fidelity =? High User Experience	.../high-fidelity-high-user-experience-ok.html	Google Docs

As you can see the URL of the one entry I posted from Blogger actually complies to its real title. But the other two, come on Google, you can do better than that. I haven't tried using Windows Live Writer, so Google, you are off the hook for now. I'll keep writing my entries from Google Docs but I'll manually publish them from Blogger to satisfy my OCD.

The point I want to make here is not to blame everything on Google. "Publish" is a very "nice-to-have" feature and I don't know what priority Google gives it; but since both the services are owned by the same people I would like to feel safe and assume that the feature will actually cooperate as expected. I have a feeling (experience speaking?) this is not that hard of a feature to fix anyways.

In the world we're living now, inter-process communication is gaining more and more power every day. I've even heard people talking about Web 3.0 which essentially is the idea of having "Web Data" instead of "Web Pages". The Internet is moving to a place where which client you use is irrelevant, however these clients still need to understand and represent the data correctly. And in order for your products to survive in the wild, you will have to consider every such use case carefully and comply with your own standards.

PS: Wow, creating tables in Blogger is not that easy!!! The real table in Google Docs looks so much cooler.

High Fidelity ?= High User Experience

[OK, so I was going to publish this like 4 months ago, actually before new years, I mean really long time ago. So what happened in he mean time? I moved back to Seattle from my 3-month vacation after graduation; nice!]

Lately I've been looking into the Software as a Service (SaaS) demos Microsoft published. Especially the Litware project, and its architecture explained here and with more details here. It's a great guidance tool that demonstrates how an SaaS application should be.

One of their core take on designing an SaaS application was to define how configurable your application will be. How much of the application's features am I allowing the users to tweak? If I have a dumb, simple application then it will be easier to deploy and maintain it. If I let every single option to be managed by users then they can configure the application to look and behave exactly how they like.

In their presentation they have this nice rainbow spectrum with "One size fits all" on one end and "Fully configurable" on the other. My two cents on this? I totally agree with the rainbow but High Fidelity & High User Experience? OK, I guess UX is not only GUI interaction experience but can also mean to configure the software to such detail to fit my needs perfectly. But then I thought that meant High Fidelity. It's actually a great feature that I can put my company's logo in Basecamp. But then again this example lies on the side of configurability (I don't think this word even exists, my Google Docs spell checker is complaining). Whatever, I'm not here to dis the great work Litware guys have put forth.

Then there is the other question; Does a "Fully Configurable" application give you the best User Experience? My head explodes every time I think about MySpace. I know it's been a hit by millions of users but come on. The only reason I prefer Facebook is the fact that Facebook looks so much elegant the way it is and it would take me days to create a MySpace page that I will like myself. With Facebook, the page is already setup for you, you don't have any options to change your font color or the background image. It's perfect, I'd rather spend time reading my friends' walls and look at their picture.

But then again we're talking about SaaS, it's enterprisey and you need to be scared of those kinds of software. The idea is that my SharePoint page's background should be in sync with my company's logo and I should be able to receive any kind of notifications when the "Company Roster.doc" is updated, right?

Design to Interface

We're all familiar with the concept; always design to interface, not to the implementation. This is very powerful; if I want to use some sort of a list in my code, I just declare a List and don't care whether it's a LinkedList or a DonaldDuckList. As long as I want the object to act as a list, I have no problem since every class that implements the List interface will give me the same functionality.

I want to take the Design to Interface paradigm to another level of abstraction. I say the software should be designed to the user interface. This is often called "Design by Use Case". The major idea here is to design how the user will interact with the application before designing the application itself. I like to believe that nailing down the user interface is the most important part of designing a great application. I don't want to claim that the user interface design is the only thing that makes the application great but rather it plays a very significant role. At the end, if your application has a great interface but doesn't do what it's supposed to, then we're back in square one.

I believe that all good software is created for a purpose. I mean good software, like Gmail or Word 2007, etc. The purpose of this breed of applications is to create a platform so you - the user - can easily pursue your purpose. I want to send and receive emails. Google solved this problem very elegantly; Gmail is a web application that allows me to check my email from anywhere in the world (we're making some assumptions here - that "anywhere in the world" actually means "anywhere with an Internet connection"), with enough storage space that will last me two lifetimes and so easy to use that my 80-year-old grandmother easily started using before she understood what the "start" button is for.

On the other hand Word has always been a controversial product. Word, as well as other Microsoft products are considered to be feature behemoths. Tons of functionality that no one in his or her right mind would try to learn them all, but they are still there. Some people argue that having so many features is unnecessary and any application should only contain the main features used by the most people. But I still believe that Word 2007 is still a very sexy product that is designed to show everybody that they needn't be afraid of it.

This paradox is also known as the "80-20 rule"; 80% of the people use only 20% of the functionality but these functionality are never the same among the users. While the Web 2.0 startups are trying to find the sweet 20%, Microsoft always aims for the 100. Well, I think with Office 2007, Microsoft found the sweet 100%. With the Ribbon, they found a great way that lets the users to find every single feature in Office without having to go through the excessive list of menus. Now even though users are still presented with all the features and options it is easier to accompish for them to accomplish their goals. This Ribbon UI was designed after years of usability tests and revisions, and I believe that shows a great anti-thesis against the simplistic nature of the Web 2.0 applications. It's not a matter of how many features a product has, but rather how they are represented to the user so they can better interface with the product.