Unfinished Businesses

Problem: We all spend plenty time trying to connect to the internet in places where we know we do have it (hotels, coffee shops etc) and places where we’re just curious.

Solution: Given that we go through similar steps every time, why not write a computer program to do it. Program should go through every unsecured wireless network one by one and:

• Connect to it
• If it connects, see if a web browser will load a page
• If it loads some page you weren’t expecting, look for some sort of “accept agreement” or “connect” buttons and click them
• If still got no internet, try the next public network

I’d imagine this can all be done from a taskbar app.

Problem: Often, one finds onesself looking at things and wondering the exact details of what they are. Dogs, cars, mountains, landmarks, trees, flowers, presidents, patio furniture. All sorts of stuff.

Solution: Take a picture with your phone and email it to our whattheheckisthis.com service. Within 20 minutes you’ll get a message saying what the thing is.

I haven’t quite worked out the details of how this will work. Perhaps there will be a web site where anyone can identify the incoming nonsense and get paid for it. I’ve also got no idea how it would make money. Perhaps you pay once we have determined that we definitely can identify your thing? Well, a few things to sort out. But this is the general idea.

I am, right now, covered in mosquito bites. Whilst I was being savagely attacked on Sunday, something occurred to me.

The itchiness of a mosquito bite comes from the fact that the mosquito injects some saliva before drawing blood. This acts as an anticoagulant, amongst a few other things. Wikipedia says that this saliva compound is fairly simple, and it’s definitely what causes the itchiness.

I would be quite happy giving some blood to a few mosquitos if their saliva did not cause irritation. Surely, therefore, we ought to be able to find some sort of a medication we could take which would prevent the irritative aspect of mosquito saliva, but not actually prevent us being bitten?

Obviously there are some tricky details to be worked out but, well, get to it.

Problem: Progress bars never seem to accurately reflect progress

Solution: “Am I done yet” custom form control for developers. Just tell the control how far you are through the operation (e.g. step 5 of 20), and the control will tell you what proportion of the way through the entire operation you are time-wise (e.g. 50%). You can then use this to update a progress bar which really does show chronological progress.

I know what you’re thinking. How does it work? Well, you’ll be glad to know that I’ve already worked all that out. The control knows how far you are through the operation because it sends all your data to our web service, which has a huge database of previous results for that same operation and can therefore tell how long there is left based upon data from previous instances of the same operation. When the first guy goes through your install routine the control has no idea how long each of the stages take but, when the ten thousandth guy goes through it, the control can tell him with reasonable certainty that he’s got another three minutes left, because that’s what it took the other ten thousand people.

Examples always make things easier, so let’s say the application we’re going to create a progress bar for does three things:

1. Copy three zip files from the current folder to a temp folder on your C drive
2. Unpack those zip files into a program folder on your C drive
3. Create 100 registry entries

While it’s doing this, the application shows a userform on the screen with a progress bar on it. We’ll use this nifty new “Am I done yet” control to make that progress bar show accurate percentage numbers.

First, the developer needs to get an ID for his application. Let’s imagine he gets that from our web site or something.

Secondly, the developer needs to think of what the various steps are in his task. It might be her, I suppose. But, let’s be honest, it’s probably his. In the task above, I’d say the steps are:

1. Copy file 1
2. Copy file 2
3. Copy file 3
4. Unpack file 1
5. Unpack file 2
6. Unpack file 3
7. Create registry entry 1
8.  Create registry entry 2
…
105. Create registry entry 99
106. Create registry entry 100

These steps obviously don’t take the same amount of time. That’s fine. If they did, the developer wouldn’t really need this nice new thing.

Finally, the developer needs to add an instance of our AmIDoneYet control onto his form and call it when necessary. This control has one method:

 void AnnounceProgress(int id, int stepnumber)

id is the ID he got from our web site. stepnumber is, well, the step number. I think these argument names are well-chosen. The developer must call AnnounceProgress whenever he hits one of these steps. The control has one single event:

 UpdateStatus(double proportionthrough)

Inside this event, the developer will update his percentage bar.

Hopefully you can see what happens here – when the developer calls AnnounceProgress the id, the step number and the current time will be sent to our web service. That web service will look at previous data from the same task and establish how far the user is through time-wise, and return that as a proportion. When that data comes back, the UpdateStatus event will fire and the developer can update his percentage bar. Of course, the UpdateStatus event doesn’t only have to fire when the developer calls AnnounceProgress. Let’s say that file 2 in our example is much larger than the others – our control knows from the historical data that step 2 takes a long time, so it will fire the UpdateStatus event a few times during that file copy just to update the progress bar and show the user that something’s still going on.

I know what you’re thinking now. Why not just fire one AnnounceProgres at the beginning of the entire operation, and one at the end? The web service will know how long the entire operation normally takes anyway, so the progress bar will steadily update all through your install. Well, as a developer you certainly could do that but you’d miss out on the nattiest feature of our service.

[Drum roll]

In our case study above, certain things are likely to take the same amount of time on all computers. Creating the registry entries, for example, is going to be pretty much the same. But there could be a huge difference in the time that the first stage (copying the files to a local drive) takes – perhaps they’re already on a local drive, or perhaps they’re on a network. Perhaps they’re on a wireless network.

Our web service will be able to deal with this by splitting clients down into profiles. As more and more data gets collected, similar patterns will develop in certain situations. The people on a wireless network will take ages over steps 1-3, but will be just the same speed as everyone else for steps 4-106. Once you’ve taken a while for step 1, the web service can determine that you’re probably one of those wireless guys, and give you the appropriate time estimates for the rest of the progress based on the experiences of other users who took a long time on step 1. Steps 4-6 probably use a lot of memory – if those slow to a crawl, you’re probably one of those guys who are running low on memory, so your expected completion time will be profiled accordingly. Perhaps you’re running on remote desktop and the animations the developer chose to show during install are slowing the whole thing down – after a few steps, the control can realise that for some reason a bunch of people ended up on this super-slow install path and, because your profile matches those, show an appropriate time estimate.

Of course, the web service doesn’t actually know that you’re on wireless or you’re out of memory or that the developer choose poor animation – it just knows from the data that a bunch of people went slow on this particular step and you’re probably one of them.

To get all of this wonderful data, all the developer needs to do is pepper his code with step updates. The more steps he puts in and the more times a user installs his app, the more accurate the estimates will turn out. Eventually there will be enough data to profile every eventuality, and the progress bar will show perfect time estimates even if you’re connected to the internet with a modem, are running out of memory and have a hard disk that writes ten times faster than it reads.

Of course, there’s a lot of work that has to be done. The profiling of use cases is by no means simple. There would also have to be some sort of offline story, where the app came with a bundle of standard profiling data which would suffice on most occasions. And the web service has to be smart enough to discard the data from the guy who put his laptop to sleep halfway through and resumed it again the following day.

This all may look like too much thought dedicated to something that’s not really of much importance – do we really care that the “sending/recieving mail” bar in Outlook doesn’t exactly scroll linearly? Does anyone really sit and wait for their World of Warcraft to be patched? Well, one of the ways that computing is headed is towards “happier” user experiences and higher levels of trustworthiness in interaction. The iPhone is a great example of this – Apple opted for a slightly reduced feature set and a lower level of customisation but they concentrated their efforts on nailing those features perfectly and building a feel-good environment around those features and making the way in which the user interacts with them feel intuitive. This is just one of many areas in which we should strive to make the user believe what the computer is telling them. We don’t wait outside to the “one hour drycleaning” store wondering whether our drycleaning is going to take three minutes or four hours. We don’t stand anxiously next to the door of the train all through a 40-minute train ride, just in case it finishes in ten. We accept what we were told, and go and do something useful instead.

Installing this is going to take twenty minutes. Honestly. There’s no point in you sitting here waiting for it. Why not tidy the spare room?

Update: I did this myself (for Windows Mobile phones), and it’s now for sale here.

Problem: Couple of beers after work. Get on train. Fall asleep. Wake up at the end of the line.

Solution: Phone app to wake you up as your station approaches. Simply tell the app the station you’re intending to get off at, and how many minutes’ warning you want, and stick it on your pocket. You may now doze off happily on the phone, safe in the knowledge that it’s going to vibrate and make alarming noises when it’s nearby your station. It’s a pretty simple app – you just need a list of stations and their latitudes and longitudes, and you’re pretty much good to go. You can probably even get these from Google Maps or similar (I think there’s a Google API for the iPhone, and I know there’s a Bing one for Windows Mobile).

Some refinements that I thought of – this needn’t just set off an alarm. How about it sends your other half a text message at the same time, telling them to come and pick you up? And it doesn’t really just have to apply to stations. What if you’re carpooling and you need to let your carpool buddy know that you’re 2 mins away from his house?

I might actually do this one (Windows Mobile) – if anyone’s interested in knocking up a partner iPhone app, let me know.

Problem: Epilepsy is often diagnosed only after the first seizure, which could potentially occur in a dangerous situation (driving or some such).

Solution: iPhone home epilepsy diagnosis. When the application is started, it instructs the user to hold the phone directly in front of their face. After a brief delay, the application flashes the screen between black and white 200 times in quick succession. The application then displays a message “Dialling 911 in 10 seconds” and the seconds start to count down to zero. A large button on the screen reads “Cancel”. If the user does not click “cancel” within ten seconds, the application dials 911 and reads a pre-recorded message to the operator, explaining that the user has had an epileptic seizure and requires the use of an ambulance. It then reads out the current GPS coordinates to the 911 operator.

Hopefully user is okay.

Problem: We all have things we do that we would like to do a bit less often.

Solution: Put them in our lovely time-lock self restaint box. It’s a sturdy metal box with an electronic lock on it. The box has a time-lock on it, and can only be opened after a set length of time has passed. Once opened, the box will make a loud noise after one minute to point out that it should be closed again. Once it’s closed again, the owner has to wait for that time period to elapse before it can be opened again. These settings can only be changed with the use of a special numeric key which should be given to the box owner’s mother, or someone else the owner will be unwilling to phone after a few beers.

The box would be handy for recreational narcotics, like cigarettes, but could equally easily be used to contain food, credit cards, money allocated to a particular thing or pets. I’m joking about the pets.

Problem: You’re in a meeting/conference call with a bunch of people. You’re supposed to remember their names, but you don’t exactly. Is it that guy from Marketing? Bob something? And is she Susan, or Susanne?

Solution: A computer program of some sort (on phone/laptop/whatever) that will listen to your meetings, and identify on your screen who is currently talking. This will work best if it can connect to some sort of central server (Exchange?) where there’s a database of how people sound. However, I think it would be an equally interesting project even if there wasn’t that database – the program could either listen to people signing into the conference call (when they say their names, you click them off on the screen) or it could store its own database of people’s sounds. When you eventually found out who a person was, you assign a tag to them. From then on, the program will identify them when they talk. It saves you trying very much to remember their name, even if you knew it once.

My New Year’s Resolution this year was to try and better remember people’s names when I was introduced to them. Not sure if conference calls count, though.

Problem: Cleaning a ceramic hob is hard work, repetitive and boring.

Solution: A robot to do it. I’m thinking of something pretty similar to the iRobot Roomba, which is a robotic vacuum cleaner. It wanders around aimlessly, turns around whenever it hits anything and, by luck more than good judgement, eventually it cleans your living room floor. Unless your living room is as untidy as ours, in which case it ends up plaintively beeping in the corner chewing on a shoelace or humping one of the drawstrings from the blinds.

Anyway, a hob-cleaning robot would have a more simple time of it. Hobs are, by and large, square, and the surface is exceptionally flat. So it should be relatively easy to cover the whole surface without having to do too much random wandering or getting stuck on things. I think it would probably do a first pass of laying down hob cleaning fluid and scrubbing, with perhaps the opportunity to do a tough-scraping pass on any dirt that was particularly stubborn. It will be $199, after a mail-in rebate. It will be blue.

Problem: If you were to ever be a part of some world-changing event that ended up with you being interviewed on television, it would be a shame if you weren’t wearing an appropriate T-shirt.

Solution: T-shirts appropriate to being interviewed on television. Some ideas:

“bank robbery witness available for consultancy”
“I escaped a forest fire but I’m still single”
“I survived a plane crash and all I got was this lousy T-shirt”

Obviously these could be more tailored (“I survived this typhoon against all odds – could it be because I’m Jewish?”) or even more specific (“Always wanted to date someone lucky? Well, I survived a tsunami. Call me. 555-401-1996”). Some definite potential here.