I'm off tomorrow to my brother's wedding in Miami. As usual, I'll be traveling with Skip, and I expect to learn a bunch.
Since I'm usually neck-deep in code, testing things, and prioritizing features, it's fun to step back and experience Skip as a user a little bit. When we're building the system, there's always a focus on bugs that need fixing, or features the system doesn't have (yet). So it's easy to forget how well it actually works. That's the nice part.
At the same time, you can't help but feel the pain from all the missing bits. Features that were cut, or haven't been implemented yet, or totally new things that just jump out as must-haves.
We'll see what jumps this time...
Monday, April 24, 2006
Sunday, April 23, 2006
Less Typing
One quick tip for sharing Skip: if a friend is interested in Skip and asks me where to get the client, I'll send him an SMS (via web or email) with the download page URL http://www.goskip.com/dl in the message.
He can then use Extract -> Go from most phones to launch the browser straight there. It's a little thing, but I find some people dislike typing on the phone keypad enough that this makes a difference for them.
He can then use Extract -> Go from most phones to launch the browser straight there. It's a little thing, but I find some people dislike typing on the phone keypad enough that this makes a difference for them.
10^H Things^H to do with Skip
Ok, I thought it would make a cool post to come up with 10 things you can do with a Skip account outside of what it's designed for (namely travel).
Instead I decided to post the 1 thing I've found most useful so far; post your own idea in the comments and maybe we can come up with 10 together.
Just creating entries online, and managing all sorts of notes or lists I might need to keep track of one the go ... grocery lists, gift lists, driving directions, random to-dos ... and being able to get all that data anywhere on a phone, without the mutant mini-browser, is pretty sweet.
Now, if you're reading this blog, odds are you've already got a personal solution to this problem. You have a smartphone, or something that syncs with Exchange or with an online PIM suite like a web portal with address/notepad/etc. Or you've got a wired PDA that you sync.
But you probably know someone (maybe a lot of folks) who aren't so wired, and would be surprised to know they could bring all this stuff with them with just a phone (and without fighting their way through the so-called wireless web).
For my own part, I've always loved the Exchange notes sync with the BlackBerry. I probably use that 10 times a day. But my wife uses a regular Samsung phone, and she was thrilled to see that she could throw all sorts of data in online and have it on the wireless, with no cellphone "typing." Plus she and I can "share" a Skip account, make updates to each other's items, and stay in sync.
I wish the best for the pure-play web/wireless groupware systems out there -- a quick Google search turns up AirSet, which looks very cool! Skip is obviously in a different sort of space, but it's handy that some of the basics are a Skip freebie too. I believe that in the mobile productivity space, the more the merrier, as we are just starting to see a dawning general awareness that the phone is a platform. This awareness -- together with apps that make it real for average consumers -- is key to creating a flourishing ecosystem for mobile software.
Instead I decided to post the 1 thing I've found most useful so far; post your own idea in the comments and maybe we can come up with 10 together.
Just creating entries online, and managing all sorts of notes or lists I might need to keep track of one the go ... grocery lists, gift lists, driving directions, random to-dos ... and being able to get all that data anywhere on a phone, without the mutant mini-browser, is pretty sweet.
Now, if you're reading this blog, odds are you've already got a personal solution to this problem. You have a smartphone, or something that syncs with Exchange or with an online PIM suite like a web portal with address/notepad/etc. Or you've got a wired PDA that you sync.
But you probably know someone (maybe a lot of folks) who aren't so wired, and would be surprised to know they could bring all this stuff with them with just a phone (and without fighting their way through the so-called wireless web).
For my own part, I've always loved the Exchange notes sync with the BlackBerry. I probably use that 10 times a day. But my wife uses a regular Samsung phone, and she was thrilled to see that she could throw all sorts of data in online and have it on the wireless, with no cellphone "typing." Plus she and I can "share" a Skip account, make updates to each other's items, and stay in sync.
I wish the best for the pure-play web/wireless groupware systems out there -- a quick Google search turns up AirSet, which looks very cool! Skip is obviously in a different sort of space, but it's handy that some of the basics are a Skip freebie too. I believe that in the mobile productivity space, the more the merrier, as we are just starting to see a dawning general awareness that the phone is a platform. This awareness -- together with apps that make it real for average consumers -- is key to creating a flourishing ecosystem for mobile software.
Tuesday, April 18, 2006
Midlets in Space
I've been agonizing a bit over whether it is a good idea to create a real, running web instance of the Skip phone client using one of the J2ME-in-a-J2SE-Applet phone emulations like ME4SE or MicroEmulator.
When I first saw a product being shown in one of these emulators (try before you buy!), I thought, "Why doesn't everyone in the mobile software business do this? What a no brainer!" This system lets people see real live apps, instead of screenshots. Here's a great geeky example.
It give a more believable presentation of the app experience that a customer would get (provided her phone has specs similar to what's being emulated, of course). This sort of thing is just what is needed, a lure to get consumers over the hump, where they'll download an app because they've really seen what it's like.
But I'm afraid I'm in a position to recant that statement. There are two issues which argue against that sort of demo.
First, the ergonomics: when you're holding your own phone in your hand, it's comfortable and intuitive to hit the directional keys, softkeys, etc. with your thumb. In the emulator, however, you're using a mouse pointer to click on tiny images of keys that belong to no phone in particular. So a user actually gets an impression of the app in the emulator that is much more awkward than an installation in a real device would be.
More importantly, however, is the user's context, and the way it informs perceptions about the usefulness and value of the application.
Here's an example of how relevant the gap is between the context of user-on-PC and of user-away-from-PC: on a Windows PC, the built-in notepad text editor is the most mundane and unimpressive of apps. But now imagine you don't have a desktop or laptop. You're using a mobile phone or a PDA to take some notes while sitting on a bus. All of a sudden, that notepad experience -- resizable window up to 1280x1024 or more, full-sized 104-key keyboard, mouse for selecting text -- would be a phenomenal luxury. Imagine if you could have that experience somehow with a palm-sized gadget!
Well, mobile software demonstrated on a PC has the same sort of issue: on the giant, 32-bit screen of a 3+ GHz PC, next to Half Life 2 and 4 Mbps of broadband, mobile software in emulation looks like some sort of hokey throwback. "It's so small and awkward, it's not pretty and it doesn't ever do very much." Well, when you're away from that PC, if a tiny piece of software does the one thing you need, it's pretty sweet. Consider BlackBerry email or SMS text messaging. In the right context, these are great communications apps. Never mind how they stack up to Outlook 2003 or a full-on IM client.
And that's basically the issue. I want customers to be intrigued enough to try Skip. But I want their first Skip client experience to be a discovery of how much that handheld device and 3G network can do for them when they're out living life away from a PC.
When I first saw a product being shown in one of these emulators (try before you buy!), I thought, "Why doesn't everyone in the mobile software business do this? What a no brainer!" This system lets people see real live apps, instead of screenshots. Here's a great geeky example.
It give a more believable presentation of the app experience that a customer would get (provided her phone has specs similar to what's being emulated, of course). This sort of thing is just what is needed, a lure to get consumers over the hump, where they'll download an app because they've really seen what it's like.
But I'm afraid I'm in a position to recant that statement. There are two issues which argue against that sort of demo.
First, the ergonomics: when you're holding your own phone in your hand, it's comfortable and intuitive to hit the directional keys, softkeys, etc. with your thumb. In the emulator, however, you're using a mouse pointer to click on tiny images of keys that belong to no phone in particular. So a user actually gets an impression of the app in the emulator that is much more awkward than an installation in a real device would be.
More importantly, however, is the user's context, and the way it informs perceptions about the usefulness and value of the application.
Here's an example of how relevant the gap is between the context of user-on-PC and of user-away-from-PC: on a Windows PC, the built-in notepad text editor is the most mundane and unimpressive of apps. But now imagine you don't have a desktop or laptop. You're using a mobile phone or a PDA to take some notes while sitting on a bus. All of a sudden, that notepad experience -- resizable window up to 1280x1024 or more, full-sized 104-key keyboard, mouse for selecting text -- would be a phenomenal luxury. Imagine if you could have that experience somehow with a palm-sized gadget!
Well, mobile software demonstrated on a PC has the same sort of issue: on the giant, 32-bit screen of a 3+ GHz PC, next to Half Life 2 and 4 Mbps of broadband, mobile software in emulation looks like some sort of hokey throwback. "It's so small and awkward, it's not pretty and it doesn't ever do very much." Well, when you're away from that PC, if a tiny piece of software does the one thing you need, it's pretty sweet. Consider BlackBerry email or SMS text messaging. In the right context, these are great communications apps. Never mind how they stack up to Outlook 2003 or a full-on IM client.
And that's basically the issue. I want customers to be intrigued enough to try Skip. But I want their first Skip client experience to be a discovery of how much that handheld device and 3G network can do for them when they're out living life away from a PC.
Sunday, April 16, 2006
Why the BlackBerry? It's shaped like the future.
After the rush of getting Skip's beta product published, it's nice to take a step back and have a look. The first thing you see (if you're me anyway) is missing pieces or obvious questions not really addressed in the current release. One of the biggest, to my mind, is this: Why the BlackBerry? I.e., why is the BlackBerry client the "flagship" one ... and why are the other clients patterned on the BlackBerry client, rather than simply being the best possible implementations for their respective platforms?
It's hardly that the BlackBerry device or platform is perfect for deploying a next-gen mobile productivity app. The total number of subscribers is not large. They are not, as a group, as likely to download (or -- gasp! -- buy) 3rd-party apps as, say, Palm (Treo) users. There is a mass of underpowered legacy devices in use. The platform features an inordinate number of API changes between minor versions; a vendor tool suite from another millennium (an era that Eclipse and VS.net have put behind us); and a complex deploy environment due to the BlackBerry Enterprise Server which provides the "BlackBerry magic" along with numerous possible fine-grained management/security restrictions.
Well here's the deal:
The BlackBerry platform has the general shape of what a net-connected mobile personal device ought to be:
It's hardly that the BlackBerry device or platform is perfect for deploying a next-gen mobile productivity app. The total number of subscribers is not large. They are not, as a group, as likely to download (or -- gasp! -- buy) 3rd-party apps as, say, Palm (Treo) users. There is a mass of underpowered legacy devices in use. The platform features an inordinate number of API changes between minor versions; a vendor tool suite from another millennium (an era that Eclipse and VS.net have put behind us); and a complex deploy environment due to the BlackBerry Enterprise Server which provides the "BlackBerry magic" along with numerous possible fine-grained management/security restrictions.
Well here's the deal:
The BlackBerry platform has the general shape of what a net-connected mobile personal device ought to be:
- It's always connected, or at least your app can assume that it is. Net problems are handled gracefully, and the stack is clearly optimized to behave well with the squirrely environment of mobile data. But beyond this, the shape: it doesn't feel like network access was grafted on (virtual serial port + PPP + #777, anyone?). It's just transparently there all the time and in that sense it's more like a PC plugged into a LAN and VPN than other systems (which generally resemble a PC with a dialup ISP account).
- Threading works well. That's a big and gnarly statement, but what I mean is: for a basic business productivity app that wants to run tasks in the background, including network access, it works so well that I've never had to wonder what sort of embedded OS might be underneath the Java VM. The same cannot be said for many other devices/platforms.
- Multifunction integration on the device. The code-signing bits for directly interacting with the unit's PIM, telephone, and network are inexpensive and easily obtained. So it's easy to create the kind of smart interconnected apps we all want. The kind where you can dial the phone, if that's what the user wants, or where you can create "hotspots" that automatically integrate with the existing email or web browser tools, or grab a contact from the address book.
- Multitasking. Based on threads (with enhancements) rather than full process independence, but for the average user, it's multitasking. So you're not forced to quit the app just to check your email, make a phone call, or look at your calendar. You can run Skip in the background forever, if you want to.
- Upgradeable. The BlackBerry is upgradeable to new platform versions. While this exacerbates the "mass of underpowered legacy devices" issue, it creates more customer (user) empowerment ... like with your PC, you decide when to toss that monochrome unit, or the one with the old processor for the new one with the Intel XScale. But in the meantime, you can keep your data and upgrade the system! From an ISV point of view, this means it's reasonable to offer an app for, say, platform v. 4.0.0+, instead of having to choose to either support the baked-in non-upgradeable platform version in a particular model, or else not support that model at all.
Subscribe to:
Posts (Atom)
