SSH is undoubtedly a useful tool and the iPhone and iPod Touch are great portable ways of connecting to networks; put both together you can be a sysadmin on the move! So what are the options for this? The Apple AppStore currently has two SSH clients, SSH and iSSH, and I took both out for a spin.

SSH

First up is SSH, marketing at $3.99 (£2.39). Opening the program greets you with a screen where you can type in an address to connect to in the form user@hostname:port (the address is added to a list on the first screen so you don’t have to type it next time). Once this has been entered you’re presented with a password entry screen, although you have to press the password entry box to get a keyboard.

If this is successful you get a retro green monospace on black terminal, with a white command line bar at its bottom. This white command line is the only way you can send commands over ssh, you press it to bring up a keyboard with which you type your command and press ‘Send’. This command is then echoed to the terminal and executed. Basic shell commands work well, but once you want to use some basic programs such as less, more or man problems start to show.

Navigation is the main problem with these programs through this client, I’m used to using the arrow and return keys to navigate them (I know there are other ways, but these are the ones I remember). The client has no emulation of arrow keys, so we lose that form of navigation and there is no return key on the keyboard. After looking up some of the other navigation commands available for these programs I was able to navigate them quite successfully, but the process of touch command bar->type command->send for every bit of navigation felt very tedious.

Another basic command I tried and expected to work was top, but alas SSH fails again and produced this output:

which is hardly usable. You can try and scroll the output, using screen swipes, but each time top refreshes your scrolling is lost.

As arrow keys are not implemented command line history is harder, meaning you have to type in commands to access your history, which is annoying and slow if you are using SSH’s input method.

The client allows you to use control commands using the ^ key, so Ctrl-C becomes ^c. This works and is functional, but to reach the ^ key you have to go through two keyboards, which is annoying. Why can’t there be a Ctrl button on the screen ready for me to use whichever keyboard I’m in?

iSSH

Disappointed with SSH I went on to try iSSH (marketing at $4.99 or £2.99). When you start it up for the first time you must add a connection configuration. This is a form where you fill in a name for the configuration, the hostname and at your choice a username and command to execute on connection.

There is no option for which port to connect to, you are stuck with port 22. With a configuration now saved I could choose to connect to it. This dropped me into a terminal where ssh asked me for a password, the bottom half of the screen is filled with a keyboard which types directly into the console. The terminal used is much better than the one SSH used, it has a gray monospace font on a black background, and it supports colours which makes using such a small screen more bearable.

There is a bar above the terminal which contains buttons for the Ctrl, Shift, F# and Tab keys (which can be used in combination), along with Exit. This allows you to use niceties such as tab complete on the command line, a great time saver when using the iPhone’s user input.

Seeing that SSH had been so abysmal when I tried to run top I tried to run top on iSSH, which produced this result:

Hurrah! top is usable using iSSH. Running more, less and man was also successful using iSSH, which gives access to arrow keys through swiping the left 2/3 of the screen, and the keyboard has a return key (the right 1/3 of the screen is reserved for scrolling). This means you can also use the arrow key emulation to scroll the command line history.

Tilting the device the appropriate way will change the display from portrait to landscape. In landscape mode you have the option of hiding the keyboard using a button on the top bar. This is rather useful if you wish to read a file using less; you can invoke less then hide the keyboard giving the whole screen to the file which you can navigate using the emulated arrow keys.

Conclusion

Comparison chart of both clients:

In terms of functionality iSSH beats SSH hands down, there is only one feature the latter has the former does not: port selection. For some users, this will be essential, and they will use SSH and put up with the bad user experience. For everyone else, there is iSSH, which makes ssh usable on the iPhone.

I have just been playing around with Stylizer, a Windows CSS editor. Why, you may ask, is the CTO of a mobile software company messing around with CSS editors? A very good question. Someone was extolling the virtues of this program on the Business of Software forum, and how everyone should take a look at the first-run experience. I went to the website, which is simple, clean, and attractive, and downloaded the program, which instantly launches into the tutorial.

Stylizer’s tutorial is well implemented, and compelling. I am no expert on CSS, and not much more knowledgable about CSS than I was when I started the tutorial, but I know a bit more about how to use Stylizer, and I agree that it is easy to use. Right up to the point where it asked me to hold down my left mouse button and then click with the right while the left button was still down.

Now, not only did I have to read that twice to work out what I needed to do, I could not actually do it. I use an Apple Mighty Mouse, and it is simply not possible to press any two buttons simultaneously, unless you press very hard enough (i.e. hard enough to break it).

Up to this point, all the shortcuts had been with the keyboard, so I didn’t quite see why we were suddenly using the mouse, particularly in a click combination that is hardly standard. In the case of Stylizer, it is simple enough just to achieve the desired action (insert a new rule) using the Insert key, but I am left asking myself why someone found it necessary to come up wth a completely non-standard action to implement a common action. In the same thought, I realise that Apple disabled simultaneous button clicks on the Mighty Mouse precisely to prevent people coming up with complex, non-standard UIs. More power to them.

Airsource woke up this morning to Nokia’s announcement to make Symbian an Open Source platform, and with it all the concrete platforms like S60, UIQ, and so forth. While Motorola, Sony Ericsson, and NTT DoCoMo are all mentioned in the press release, it seems to me that they had little choice but to jump on board. From an Airsource perspective, S60 pretty much meant Nokia - and now Nokia will mean S60. At the very least, that might make our sales presentations easier.

This announcement is good news in two ways for Airsource’s business. Firstly, from a commercial perspective, it removes some of the cloud of doubt about what Android means for the market. Android did not exactly threaten the future of S60, the established leader in the convergent devices market , but it did cast some doubt on the subject. How would an open source competitor affect the market? Businesses, of course, hate doubt, and while S60 was ahead of Android on pretty much everything apart from source access, the playing field there has now been made more level. Obviously a $1500 charge (annual) for source access is not free, but it is vastly cheaper than the old fee to become a Symbian Platinum Partner.

Secondly, from a technical perspective, access to the underlying platform code helps the developer produce more stable products, faster. Some areas of code are always technically more complex and more poorly documented than others, such as MTMs. Access to source code will significantly ease development on the really cool stuff.

We at Airsource look forward to seeing more developments.

The Cambridge CAMRA Beer Festival has arrived in town again.

An annual event in Cambridge, the Beer Festival features hundreds of brews from all over the UK and Europe. The key message is that the best beer is “Real Ale”; not stuffed with preservatives and artificially carbonated but the genuine, hand-crafted article.

As a team bonding training exercise, the Airsource team went along to learn more about Real Ale and to sample a few ounces of the amber brew. The work was strictly investigative and rigorously scientific.

The main hall features food and, obviously, large quantities of beer.

A few hints for those unaccustomed to the beer festival;

• Work a half-pint at a time
• The cheese stall is brilliant
• Leave the more potent brews for later in the evening

Inside the Cambridge Beer Festival compound.

My vote for the best beer experienced this year is “Comrade Bill Bartrams Egalitarian Anti Imperialist Soviet Stout” which is very much worth your time and energy.

As part of our scientific study, obviously some beer needs to be consumed.

I stayed at the Yotel in Heathrow Terminal 4 the other day. I had an 11am flight to the US, and decided that instead of a 6am start from Cambridge, it made much more sense to stay literally 50m away from the British Airways checkin desk. This made me an accidental, but much appreciated, beneficiary of the T5 shambles - BA are keeping a lot of their long-haul flights in T4 until the new terminal has properly bedded down.

I arrived at the Yotel’s reception, aka “galley” at about 10pm. After a slight modification to my booking, I headed off to my “cabin” (there’s a bit of a shipping theme), gained access with the ubiquitous card lock, and then headed straight for the shower. Two seconds later I realised that there was a window in my room, facing directly onto the corridor! I promptly closed the blind, but I really don’t see the point of this window. Why would I want to be able to see onto the corridor - and vice versa?

The Yotel concept is that you get a small room - about seven square metres - comprising an electrically folding bed (think business class seats) which is actually pretty comfy, a bathroom, a tv, and so forth. There’s even a desk and chair, both of which fold away. Except the desk didn’t. It got stuck half-way down.

Fortunately it didn’t obstruct the bed, but it did mean once the bed was extended, the only path from bathroom to door was to climb over the bed.
Careful readers will be wondering where your baggage goes. Yotel have thought of that - the bed is pretty high off the floor, and there’s storage space underneath it. There’s also somewhere to hang a suit up.

The desk has power points and a network connection just above it, though I have to report that the network connection didn’t work. For the technically minded, it assigned an IP address, but failed to pass any packets. Rather than try and fix Yotel’s network for them, I just went outside (too much metal inside to get a signal) and made a phone call instead, over a pleasant pint at Weatherspoons.

Apart from the desk and the network connection, I was pretty pleased with the room. There was some building work inside Heathrow that night, but earplugs (available from reception) completely blotted that out - and if you sleep in a standard airport hotel you just get to hear planes and traffic in any case. I slept well (almost too well, I missed my watch alarm, but had set up a backup wakeup call on the TV, which I recommend, because it turned the lights on as well), the shower was good, and it was a 1 minute walk to check-in in the morning.

Does it have some issues? Yes. Would I stay again? Yes.

I’ve just been taking a look at Device Atlas, which in its own words is the “world’s most comprehensive database of mobile device information”. I had high hopes, but unfortunately it appears to be rehash of the kind of information which is readily available, without anything more useful. I appreciate that this database is not designed for my sole delectation, but I surely can’t be alone in wanting to get a list of devices running S60 FP1 which have a camera? Not only does the Device Atlas apparently not allow any sort of search, it doesn’t tell me what operating system a phone runs, what JSRs it has, or allow any kind of user commenting (e.g. “HTTPS is broken on this device”).

My favourite part of the site is in the FAQ, where it says “Can I have a job? Yes, we’re hiring world class staff for the DeviceAtlas project. Call us.” Errr, call who? There’s no phone number. Click on “Contact” on the nav bar at the bottom of the screen. Still no phone number. I presume you’re supposed to call dotMobi (one more click away) rather than Device Atlas, but that’s far from clear. Also in the FAQ, we read that “We intend this to be the single largest, most comprehensive, and accurate device database on the planet”. A worthy goal - but Device Atlas has a long way to go to reach it.

When we set up Airsource, we set it up as a BREW consultancy. We rapidly sold a number of BREW projects, and built on the expertise we had acquired while at QUALCOMM. In the process, however, we inevitably found ourselves working on other software platforms, particularly on Series 60, which now accounts for about half of Airsource’s work. Series 60 and BREW are often held up as competitors, though in practice I would argue quite strongly that they target very different markets.

A BREW phone, such as the Motorola V3M has a primary display is 176×220, it has 23MB of memory, and a processor clocked at perhaps 40MHz. A Nokia E65 costs nearly twice as much, has twice as many pixels, can store five times as much, and runs fives times faster. Pundits will immediately point out that the V3M is a pretty slow example of a BREW phone. That’s certainly true, but the V3 series accounts for a very significant fraction of the US market for BREW phones. The Nokia E65 is similarly chosen for comparison as an example of a popular Series 60 v3 phone.

Comparing the two is pointless. The BREW phone is clearly a much lighter-weight platform, targetted primarily at games. The Symbian phone has considerably more memory, more storage, faster CPU, and generally faster network data transfer. It is also significantly harder to program for - in the same way that coding for a Windows XP PC requires rather more knowledge than writing a program in BBC BASIC did. A Symbian phone is simply more capable than a BREW one, and consequently the APIs are richer, and the learning curve steeper.

That’s not to say that that Airsource’s clients do not want to target their application at both BREW and at Symbian. They absolutely do. But the Symbian application will always have more functionality and tighter device integration than the BREW application, in the same way that a dedicated BREW application will have more functionality and tighter device integration than a web-based application. Clients come to us because they want to get the most out of the phone, and to do things that are non-trivial, whether that be linking into the messaging menu of a Symbian phone, porting a multi-process application to BREW, or simply writing an application that Just Works.

What this means is that while the mobile market is certainly split into markets that may not directly compete with every other platform, they form an overlapping whole that represents the mobile space. Companies want to get their application “on mobile”, and by that, they mean on the maximum number of phones, with users who will spend money, for as little cost as possible. Choice of platform, like Symbian, or BREW, is therefore just a business decision, not a technical one.

After a much-awaited Release Day and the obligatory pub afterwards, last Thursday marked the end of January and Android Code Day in London and Tel Aviv. It was my first time in Israel, which made it more exciting As much as I’d like to visit Israel, I wouldn’t be able to justify the expense (it might happen in the future with the current trend in ticket prices). The good news is that the train journey into London is relatively short and painless.

After waiting around in the lobby, we were eventually escorted through brief NDA-signing (is it legally binding if there’s no expectation for you to read it at all?) and then upstairs, into a meeting room just big enough to hold 40 people and their laptops without feeling crowded.

The first half of the day was taken up by a brief presentation by Jason Chen, interleaved with a not-so-brief and highly interactive question-and-answer session. Then there was lunch, with the usual perks (who wouldn’t work for Google for a freezer full of Ben and Jerry’s?) and some insight into Google’s business strategy.

Top-secret plans

We started the afternoon with a brief demo of an Android app from an audience member. It was pretty decent for only two days’ worth of code and some borrowed sprites — maybe Android phones will compete with the PSP (in keeping with tradition, they’ve tested Quake on Android prototypes, with reasonable performance).

A familiar game…

… stretched by OpenGL in landscape mode

The “hackathon” commenced, but as the average level of experience was “has compiled and run the hello world app” (and the documentation is written in the traditional Javadoc style that never manages to tell you how to do what you want to do), I don’t think much coding actually happened — that wasn’t really the point of the day. Jason Chen is a Developer Advocate; so’s Dan Morrill (the first link in this article). He writes “I get to travel the world to meet developers and talk about cool technologies. I can’t believe I get paid for this!” though Google is keen on hiring more Developer Advocates.

It’s not hard to see why: the room seemed to consist of people from handset manufacturers, mobile OS companies, people wanting to see if Android is worth investing time into, and people there just to keep track of what Google was up to — in fact, the last category seems to cover everyone.^[1] One of the most promising things about Android is an abundance of cool, novel, well-written, currently nonexistent apps — it’s a chicken-and-egg, and Google can only hope that apps are easier to produce than users (what do you think the Android Developer Challenge hopes to accomplish?).

Of course, it’s really future users that give decision-makers the incentive to spend money on a particular platform. Until we invent time machines, we’ll have to settle for a significantly high probability of a significant number of future users. The greatest impediment is actually having phones for sale, but the problems there are largely political, and if I started on politics I’d be here all day. Once phones are on the market, there’s another problem:

Android has to be good.

And by “good”, I mean better than the next phone on the shelf. Of course, customers define what’s “better”, but what do you see when you go phone shopping?

• The brand is difficult to change.
• The design is difficult to do well, but at least the OHA has Motorola.
• The “specs” that the shop decides to show are rather arbitrary.
• The price matters, but in the UK, it’s largely “free on contract” (at least Android is free, so manufacturers can save on licensing fees).
• What your friends say is even harder to change.

Word-of-mouth is often mentioned as the most important form of advertising, and also the hardest to get right (should I be worried that nobody seems to know what Android is?). But personally, if there’s anything that’ll make me recommend one phone over another, it’s the UI, probably because it’s the thing which irritates me every time I use a phone — it’s also where Android has a chance to shine, since (in theory) you can rewrite everything, even if you end up with a bloated home screen app that does everything under the sun.

Without going into technical details (there’s plenty on YouTube), Android has a few distinguishing features; the most notable is that it tries to be designed around the user experience. Intents are a key idea — they encapsulate what the user wants to do. The system passes the request to whichever app says it can fulfil the intent — apps aren’t replaced, intents are.

The problem arises when you have many apps which want to provide some basic enhancement. If I have Skype on my Android phone, here’s what I’d like to see:

• Skype status shows up in the contact list.
• Calling a Skype-online contact makes a Skype call over Wi-Fi.
• Calling a Skype-online contact asks me before using HSDPA, in case I don’t want to end up with a big phone bill and violate the no-VoIP clause of the ToS.

It’s conceptually easy, with one catch: you don’t want to replace the contacts and dialler, because apps can’t access another app’s data. It’s difficult to do the right thing when you change contacts apps between adding, removing, editing, and renaming contacts, and it doesn’t work with Google-talk or Gaim Pidgin, let alone a psychic dialler which reads my brainwaves and calls the right person without me asking.

What users expect is the concept of a global address book, with each contact (an ID) optionally linked to names, phone numbers, e-mail addresses, snail-mail addresses, WGS84 coordinates, IM usernames, and anything you might associate with a person (or group of people).^[2] Similarly, apps which handle intents (”send a text message”) can also advertise a “quality factor” (RFC 2616) that changes dynamically, so that Jabber’s “quality” drastically decreases when I move out of range of Starbucks and my phone starts using roaming HSDPA, hopefully going below a threshold which prompts the phone to ask me first. Suddenly, my phone has a better IM client than my computer: it’ll switch to SMS when Wi-Fi isn’t available, connect to the office’s SIP server, and give me the directions to tonight’s party.

There’s been little work on any platform to address these; as a result, there always tends to be one app that ends up on top with everything else struggling to catch up — IM clients throughout the decades have followed this trend. Phones are a different matter, and unless something reaches critical mass, we’ll just end up with a lot of fragmentation. While compatibility issues aren’t an aspect of fragmentation that the audience seemed to be worrying about (people seemed more worried about OEMs taking Android and making it proprietary), they’re important to the user experience: seamlessly integrating apps together is an important part of a good UI.

Another thing which doesn’t exist in Android is input methods — the current emulator only supports primitive touch screen and a keyboard. How will multitap work? What about graffiti, handwriting recognition, or an on-screen keyboard? These tend to require extra screen space, which means it has to be coded into each app or provided by the system; there’s currently no easy way to give another app a certain portion of your screen. Besides, the keyboard should only appear when I’ve selected a text field (and it should let me write/graffiti directly into a text field). What about gestures? Or force-input?^[3]

When you control nearly everything about a device, it’s much easier to make a good UI instead of just a decent one — the iPhone kept coming up as an example of a good UI throughout the day.^[4] Android will stand between everybody’s apps and the underlying hardware, whether there are 30 keys or none, and it needs to provide enough abstraction so that developers can rely on the system to do the Right Thing and still give a good user experience. It’s what Android is designed around.

At last, the day came to an end, and I left for King’s Cross. Though the room was teeming with skepticism, Android is something that I’d like to succeed, and I’ll be watching the OHA’s four handset manufacturers closely over the next few months (maybe Motorola will finally make a phone that looks pretty but doesn’t irritate me every time I try to use it).

There’s going to be another Android Code Day in Boston on the 23rd. It’s worth going to, especially if the impending SDK update, happens first. Besides, you can always enjoy the Ben & Jerry’s on the mission to uncover Google’s master plan.

1. Working with mobile software imparts a strong urge to know what everyone else is doing, possibly to learn from those who have done it better than you, or in search of the next great platform which is reasonably profitable and both a joy to use and code for (my recent experiences with a certain OS/IDE/build system can be summarised as it should not be this difficult!).
2. One can only hope that it won’t be implemented using XML.
3. Want to turn the alarm off? Hit it. This is probably patented. The W380a lets you turn off the alarm by waving at the camera.
4. The iPhone and the BlackBerry the two phones which I hear described as good, not just better-than-something-else.

This blog has been going for nearly a year now - our first post was on January 29th. Airsource has been around for a little longer than that - I quit my job at QUALCOMM to work full-time at Airsource in June 2006. We’re approaching the end of the year, so what better time for a bit of a review. I’m going to stick to the technical side of things - I’m sure Nick will have something to say, and maybe one of our new employees will want to give their view of things too.

There are several key things I’ve learned in my time at Airsource. The most important one is that when it’s your own company, it’s not enough to be good, or even just better than the next guy. You need to be great. Every time I write code, at the back of my head is the feeling that some day this code may be run by a customer. And it had better work, because if it doesn’t, one way or another it will be my problem. No matter how principled you are, that ethos simply doesn’t apply when you’re working for a large company. You write the code, you test it, the QA department passes it, and you walk away. You don’t even have to do any sales!

The corollary of this is that it’s not just enough to write good software. It has to be the right software. By that, I mean that you need to make absolutely sure that you know what the customer is asking for - and that what the customer is asking for is really what they want. And then, you need to deliver that, deliver it well, and ideally deliver just a little bit more. You don’t want to give the farm away, when consultancy is what keeps a roof over your head, but you do want to give the customer a warm fuzzy feeling.

If you are writing a product, you don’t develop the thing in a clean room and then unleash it on an unsuspecting public. Or if you do, it will probably flop. You do some market research first. You do usability testing. You go out there and find out what people want. In the same way, when working on a client project, it’s your responsibility to make sure you are doing what the customer wants. And remember, even if what the customer is asking for sounds stupid, there’s a reason behind it. At least when you’re a small software company, your customers are almost guaranteed to be making a lot more money than you are. Which means they’re doing something right.

When Airsource finishes a customer project, we send someone along who didn’t write any of the code, and had as little involvement as possible with the project. They sit down with the customer, and do a post mortem. The customer gets the chance to voice any and all complaints that they have. They are surprisingly frank. I’ve had some feedback about me that people would never give to my face. And then, when we’ve got the feedback, we sit down together at the office, and figure how to make the next project an even better experience for the customer.

The Airsource team have just been out for their first team-building exercise. One of the benefits of running your own company is that you get to choose what the activities are - and since my sport is running, and Airsource is a four man company, I decided we’d do the Cambridge Fun Run - a four by 1.1 mile relay. I did check that everyone was up for a bit of running first though! We’ve just got back from the race - via the pub, so that’s an average of 7 minutes running each followed by an hour eating and drinking. Seems a good ratio. Not sure how we placed yet, but those who know me will know I’m not exactly uncompetitive, so I’ll be checking the results with interest!