dw2

3 January 2011

Some memorable alarm bugs I have known

Filed under: Apple, Psion, usability — David Wood @ 12:24 pm

Here’s how the BBC website broke the news:

iPhone alarms hit by New Year glitch

A glitch on Apple’s iPhone has stopped its built-in alarm clock going off, leaving many people oversleeping on the first two days of the New Year.

Angry bloggers and tweeters complained that they had been late for work, and were risking missing planes and trains.

My first reaction was incredulity.  How could such a first class software engineering company like Apple get such basic functionality wrong?

I remember being carefully instructed, during my early days as a young software engineer with PDA pioneer Psion, that alarms were paramount.  Whatever else your mobile device might be doing at the time – however busy or full or distracted it might be – alarms had to go off when they became due.  Users were depending on them!

For example, even if the battery was too low, when the time came, to power the audio clip that a user had selected for an alarm, Psion’s EPOC operating system would default to a rasping sound that could be played with less voltage, but which was still loud enough that the user would notice.

Further, the startup sequence of a Psion device would take care to pre-allocate sufficient resources for an alarm notifier – both in the alarm server, and in the window server that would display the alarm.  There must be no risk of running out of memory and, therefore, not being able to operate the alarm.

However, as I thought more, I remembered various alarm bugs in Psion devices.

Note: I’ve probably remembered some of the following details wrong – but I think the main gist of the stories is correct.

Insisting on sounding ALL the alarms

The first was from before I started at Psion, but was a legend that was often discussed. It applied to the alarm functionality in the Psion Organiser II.

On that device, all alarms were held in a queue, and for each alarm, there was a record of whether it had been sounded.  When the device powered up, one of the first thing it would do was to check that queue for the first alarm that had not been sounded.  If it was overdue, it should be sounded immediately.  Once that alarm was acknowledged by the user, the same process should be repeated – find the next alarm that had not been sounded…

But the snag in this system became clear when the user manually advanced the time on the device (for example, on changing timezone, or, more dramatically, restoring the correct time after a system restart).  If a user had set a number of alarms, the device would insist on playing them all, one by one.  The user had no escape!

Buffer overflow (part one)

The next story on my list came to a head on a date something like the 13th of September 1989.  The date is significant – it was the first Wednesday (the day with the longest name) with a two-digit day-in-month in September (the month with the longest name).  You can probably guess how this story ends.

At that time, Psion engineers were creating the MC400 laptop – a device that was in many ways ahead of its time.  (You can see some screenshots here – though none of these shots feature the MC Alarms application.  My contribution to that software, by the way, included the Text Processor application, as well as significant parts of the UI framework.)

On the day in question, several of the prototype MC400 devices stopped working.  They’d all been working fine over the previous month or so.  Eventually we spotted the pattern – they all had alarms due, but the text for the date overflowed the pre-allocated memory storage that had been set aside to compose that text as it was displayed on the screen.  Woops.

“The kind of bug that other operating systems can only dream about”

Some time around 1991 I made a rash statement, which entered into Psion’s in-house listing of ill-guarded comments: “This is the kind of bug that other operating systems can only dream about”.  It was another alarms bug – this time in the Psion Series 3 software system.

It arose when the user had an Agenda file on a memory card (which were known, at the time, as SSDs – Solid State Disks), but had temporarily removed the card.  When the time came to sound an alarm from the Agenda, the alarm server requested the Agenda application to tell it when the next Agenda alarm would be due.  This required the Agenda application to read data from the memory card.  Because the file was already marked as “open”, the File Server in the operating system tried to display a low-level message on the screen – similar to the “Retry, Abort, or Cancel” message that users of MS-DOS might remember.  This required action from the Window Server, but the Window Server was temporarily locked, waiting for a reply from the Alarm Server.  The Alarm Server was in turn locked, waiting for the File Server – which, alas, was waiting (as previously mentioned) for the Window Server.  Deadlock.

Well, that’s as much as I can recall at the moment, but I do remember it being said at the time that the deadlock chain actually involved five interconnecting servers, so I may have forgotten some of the subtleties.  Either way, the result was that the entire device would freeze.  The only sign of life was that the operating system would still emit keyclicks when the user pressed keys – but the Window Server was unable to process these keys.

In practice, this bug would tend to strike unsuspecting users who had opened an SSD door at the time the alarm happened to be due – even the SSD door on the other side of the device (an SSD could be inserted on each side).  The hardware was unable to read from one SSD, even if it was still in place, if the other door happened to be open.  As you can imagine, this defect took some considerable time to track down.

“Death city Arizona”

At roughly the same time, an even worse alarms-related bug was uncovered.  In this case, the only way out was a cold reset, that lost all data on internal memory.  The recipe to obtain the bug went roughly as follows:

  • Supplement the built-in data of cities and countries, by defining a new city, which would be your home town
  • Observe that the operating system created a file “World.wld” somewhere on internal memory, containing the details of all the cities whose details you had added or edited
  • Find a way to delete that file
  • Restart the device.

In those days of limited memory, every extra server was viewed as an overhead to be avoided if possible.  For this reason, the Alarm Server and the World Server coexisted inside a single process, sharing as many resources as possible.  The Alarm Server managed the queue of alarms, from all different applications, and the World Server looked after access to the set of information about cities and countries.  For fast access during system startup, the World Server stored some information about the current home city.  But if the full information about the home city couldn’t be retrieved (because, for example, the user had deleted the World.wld file), the server went into a tailspin, and crashed.  The lower level operating system, noticing that a critical resource had terminated, helpfully restarted it – with identical conclusions.  Result: the lower priority applications and servers never had a chance to start up.  The user was left staring at a blank screen.

Buffer overflow (part two)

The software that composed the text to appear on the screen, when an alarm sounded, used the EPOC equivalent of “print with formatting”.  For example, a “%d” in the text would be replaced by a numerical value, depending on other parameters passed to the function.  Here, the ‘%’ character has a special meaning.

But what if the text supplied by the user itself contains a ‘%’ character?  For example, the alarm text might be “Revision should be 50% complete by today”.  Well, in at least some circumstances, the software went looking for another parameter passed to it, where none existed.  As you can imagine, all sorts of unintended consequences could result – including memory overflows.

Alarms not sounding!

Thankfully, the bugs above were all caught by in-house testing, before the device in question was released to customers.  We had a strong culture of fierce internal testing.  The last one, however, did make it into the outside world.  It impacted users who had the temerity to do the following:

  • Enter a new alarm in their Agenda
  • Switch the device off, before it had sufficient time to complete all its processing of which alarm would be the next to sound.

This problem hit users who accumulated a lot of data in their Agenda files.  In such cases, the operating system could take a non-negligible amount of time to reliably figure out what the next alarm would be.  So the user had a chance to power down the device before it had completed this calculation.  Given the EPOC focus on keeping the device in a low-power state as much as possible, the “Off” instruction was heeded quickly – too quickly in this case.  If the device had nothing else to do before that alarm was due, and if the user didn’t switch on the device for some other reason in the meantime, it wouldn’t get the chance to work out that it should be sounding that alarm.

Final thoughts re iPhone alarms

Psion put a great deal of thought into alarms:

  • How to implement them efficiently
  • How to ensure that users never missed alarms
  • How to provide the user with a great alarm experience.

For example, when an alarm becomes due on a Psion device, the sound starts quietly, and gradually gets louder.  If the user fails to acknowledge the alarm, the entire sequence repeats, after about one minute, then after about three minutes, and so on.  When the user does acknowledge the alarm, they have the option to stop it, silence it, or snooze it.  Pressing the snooze button adds another five minutes to the time before the alarm will sound again.  Pressing it three times, therefore, adds 15 minutes, and so on.  (And as a touch of grace: if you press the snooze button enough times, it emits a short click, and resets the time delay to five minutes – useful for sleepyheads who are too tired to take a proper look at the device, but who have enough of a desire to monitor the length of the snooze!)

So it’s surprising to me that Apple, with its famous focus on user experience, seem to have given comparatively little thought to the alarms on that device.  When my wife started using an iPhone in the middle of last year, she found much in it to enchant her – but the alarms were far from delightful.  It seems that the default alarms sound only once, with a rather pathetic little noise which it is easy to miss.  And when we looked, we couldn’t find options to change this behaviour.  I guess the iPhone team has other things on its mind!

28 January 2010

The iPad: more for less?

Filed under: Apple, complacency, iPhone, strategy — David Wood @ 12:36 pm

There are plenty of reasons to be critical about the Apple iPad.  If they feel inclined, Apple’s competitors and detractors can lick their lips.

For example, an article in Gizmodo enumerates “8 Things That Suck About the iPad“:

  1. Big, Ugly Bezel
  2. No Multitasking
  3. No Cameras
  4. Touch Keyboard
  5. No HDMI Out
  6. The Name “iPad”
  7. No Flash
  8. Adapters, Adapters, Adapters (“if you want to plug anything into this, such as a digital camera, you need all sorts of ugly adapters. You need an adapter for USB for god’s sake”)
  9. It’s Not Widescreen
  10. Doesn’t Support T-Mobile 3G (“it uses microSIMs that literally no one else uses”)
  11. A Closed App Ecosystem.

(The last three items on the list were added after the article was first published.)

In similar vein, Robert Scoble reported the view of his 16 year old son: “iFail“:

  1. It isn’t compelling enough for a high school student who already has a Macintosh notebook and an iPhone.
  2. It is missing features that a high school student would like, like handwriting recognition to take notes, a camera to take pictures of the board in class (and girls), and the ability to print out documents for class.
  3. He hasn’t seen his textbooks on it yet, so the usecase of replacing heavy textbooks hasn’t shown up yet.
  4. The gaming features aren’t compelling enough for him to give up either the Xbox or the iPhone. The iPhone wins because it fits in his pocket. The Xbox wins because of Xbox live so he can play against his friends (not to mention engaging HD quality and wide variety of titles).
  5. He doesn’t like the file limitations. His friends send him videos that he can’t play in iTunes and the iPad doesn’t support Flash.
  6. It isn’t game changing like the iPhone was.

However, let’s remember that iPhone initially received a similar swathe of criticisms.  It, too, omitted lots of features that everyone took for granted would need to be part of a successful smartphone: multi-tasking, 3G, MMS, copy-and-paste…

The iPad shouldn’t be judged against existing markets.  Rather than participating in a “red ocean” that’s already swarming with active competitors, it has the chance to define and participate in an empty “blue ocean”.

  • Here, I’m using the language of W. Chan Kim and Renée Mauborgne of INSEAD.
  • Blue ocean products avoid matching existing products feature-for-feature.
  • They miss out some items completely, but, instead, deliver big time on some other points.

It’s similar to how Palm made the first commercially successful pen-based handheld computer.  In comparison to predecessors – like the Casio Zoomer, the General Magic “Magic Cap”, and (ironically) the Apple Newton – the Palm Pilot delivered much less functionality.  But what it did deliver was a delight to use.  (I made a similar point in an earlier blog posting, reviewing the growth of the iPhone market share: “Market share is no comfort“.)

This is the “less is more” philosophy.  It’s a good philosophy!

Around the world, hundreds of millions of people are saying to themselves: the iPad is not for them.  But a different, large, group of potential users are likely to be interested.

It’s early days, but it looks as if the iPad will support excellent browsing of many kinds of content – content that previously would be read in physical books, newspapers, and magazines.  That’s a big market.

What’s more, reports suggest that the iPad packs tremendous speed.  For example, John Gruber reports the following on Daring Fireball:

…the iPad is using a new CPU designed and made by Apple itself: the Apple A4. This is a huge deal. I got about 20 blessed minutes of time using the iPad demo units Apple had at the event today, and if I had to sum up the device with one word, that word would be “fast”.

It is fast, fast, fast…

I expected the screen size to be the biggest differentiating factor in how the iPad feels compared to an iPhone, but I think the speed difference is just as big a factor. Web pages render so fast it was hard to believe. After using the iPhone so much for two and a half years, I’ve become accustomed to web pages rendering (relative to the Mac) slowly. On the iPad, they seem to render nearly instantly. (802.11n Wi-Fi helps too.)

The Maps app is crazy fast. Apps launch fast. Scrolling is fast. The Photos app is fast.

…everyone I spoke to in the press room was raving first and foremost about the speed. None of us could shut up about it. It feels impossibly fast.

Speed, for the iPad, might the special extra blast of usability that the new pen interface was the iPhone.

7 January 2010

Mobiles manifesting AI

Filed under: AGI, Apple, futurist, intelligence, m2020, vision — David Wood @ 12:15 am

If you get lists from 37 different mobile industry analysts of “five game-changing mobile trends for the next decade“, how many overlaps will there be?  And will the most important ideas be found in the “bell” of the aggregated curve of predictions, or instead in the tails of the curve?

Of the 37 people who took part in the “m2020” exercise conducted by Rudy De Waele, I think I was the only person to mention either of the terms “AI” (Artificial Intelligence) or “PDA” (Personal Digital Assistant), as in the first of my five predictions for the 2010′s:

  • Mobiles manifesting AI – fulfilling, at last, the vision of “personal digital assistants”

However, there were some close matches:

  • Rich Wong predicted “Smart Agents 2.0 (thank you Patty Maes) become real; the ability to deduce/impute context from blend of usage and location data”;
  • Marshall Kirkpatrick predicted “Mobile content recommendation”;
  • Carlo Longino predicted “The mobile phone will evolve into an enabler device, carrying users’ digital identities, preferences and possessions around with them”;
  • Steve O’Hear predicted “People will share more and more personal information. Both explicit e.g. photo and video uploads or status updates, and implicit data. Location sharing via GPS (in the background) is one current example of implicit information that can be shared, but others include various sensory data captured automatically via the mobile phone e.g. weather, traffic and air quality conditions, health and fitness-related data, spending habits etc. Some of this information will be shared privately and one-to-one, some anonymously and in aggregate, and some increasingly made public or shared with a user’s wider social graph. Companies will provide incentives, both at the service level or financially, in exchange for users sharing various personal data”;
  • Robert Rice predicted “Artificial Life + Intelligent Agents (holographic personalities)”.

Of course, these predictions cover a spread of different ideas.  Here’s what I had in mind for mine:

  • Our mobile electronic companions will know more and more about us, and will be able to put that information to good use to assist us better;
  • For example, these companion devices will be able to make good recommendations (e.g. mobile content, or activities) for us, suggest corrections and improvements to what we are trying to do, and generally make us smarter all-round.

The idea is similar to what former CEO of Apple, John Sculley, often talked about, during his tenure with Apple.  From a history review article about the Newton PDA:

John Sculley, Apple’s CEO, had toyed with the idea of creating a Macintosh-killer in 1986. He commissioned two high budget video mockups of a product he called Knowledge Navigator. Knowledge Navigator was going to be a tablet the size of an opened magazine, and it would have very sophisticated artificial intelligence. The machine would anticipate your needs and act on them…

Sculley was enamored with Newton, especially Newton Intelligence, which allowed the software to anticipate the behavior of the user and act on those assumptions. For example, Newton would filter an AppleLink email, hyperlink all of the names to the address book, search the email for dates and times, and ask the user if it should schedule an event.

As we now know, the Apple Newton fell seriously short of expectation.  The performance of “intelligent assistance” became something of a joke.  However, there’s nothing wrong with the concept itself.  It just turned out to be a lot harder to implement than originally imagined.  The passage of time is bringing us closer to actual useful systems.

Many of the interfaces on desktop computers already show an intelligent understanding of what the user may be trying to accomplish:

  • Search bars frequently ask, “Did you mean to search for… instead of…?” when I misspell a search clue;
  • I’ve almost stopped browsing through my list of URL bookmarks; I just type a few characters into the URL bar and the web-browser lists websites it thinks I might be trying to find – including some from my bookmarks, some pages I visit often, and some pages I’ve visited recently;
  • It’s the same for finding a book on Amazon.com – the list of “incrementally matching books” can be very useful, even after only typing part of a book’s title;
  • And it’s the same using the Google search bar – the list of “suggested search phrases” contains, surprisingly often, something I want to click on;
  • The set of items shown in “context sensitve menus” often seems a much smarter fit to my needs, nowadays, than it did when the concept was first introduced.

On mobile, search is frequently further improved by subsetting results depending on location.  As another example, typing a few characters into the home screen of the Nokia E72 smartphone results in a list of possible actions for people whose contact details match what’s been typed.

Improving the user experience with increasingly complex mobile devices, therefore, will depend not just on clearer graphical interfaces (though that will help too), but on powerful search engines that are able to draw upon contextual information about the user and his/her purpose.

Over time, it’s likely that our mobile devices will be constantly carrying out background processing of clues, making sense of visual and audio data from the environment – including processing the stream of nearby spoken conversation.  With the right algorithms, and with powerful hardware capabilities – and provided issues of security and privacy are handled in a satisfactory way – our devices will fulfill more and more of the vision of being a “personal digital assistant”.

That’s part of what I mean when I describe the 2010′s as “the decade of nanotechnology and AI”.

5 October 2008

iWoz inspires iMAX

Filed under: Apple, books, collaboration, innovation, Psion — David Wood @ 8:57 am

Last Wednesday, Apple co-Founder Steve Wozniak addressed a gathering of several hundred business people in London’s large-format IMAX cinema, as part of a series of events organised by the London Business Forum. The theme was “Apple Innovation”. Since the IMAX is just 15 minutes walk from Symbian’s HQ, this opportunity was too good for me to miss. I hoped Wozniak’s account of Apple culture might shed some new light on the all-conquering iPhone. I was not disappointed.

Wozniak spoke for more than an hour, without slides, running through a smorgasbord of anecdotes from his own life history. It was rivetting and inspiring. Later I realised that most of the material has already been published in Wozniak’s 2006 book “iWoz: Computer geek to cult icon: How I invented the personal computer, co-founded Apple, and had fun doing it“, which was given out at the event.

I warmed to Wozniak early on in his talk, when he described one of his early experiments in software – writing a program to solve the “Knight’s tour” around a chessboard. I remembered writing a program to try to solve the same problem while at roughly the same age – and had a similar result. In my case, programs were sent off from school to the local Aberdeen University, where clerical staff typed them in and submitted them on behalf of children in neighbouring schools. This program was returned several days later with the comment that there was no output – operators had terminated it.

A few weeks later, there was a short residential course at the university for sixth form students, which I attended. I modified my program to tackle a 5×5 board instead, and was happy to see computer quickly spitting out numerous solutions. I changed the board size to 6×6 instead and waited … and waited … and after around 10 minutes, a solution was printed out. Wozniak’s experience was several years before mine. As he describes it, the computer he was using could do one million calculations a second – which sounded like a huge number. So the lack of any output from his program was a big disappointment – until he calculated that it would actually take the computer about 10^25 years to finish this particular calculation!

More than half the “iWoz” book covers Wozniak’s life pre-Apple. It’s in turn heart-warming and (when describing Wozniak’s pranks and phreaking) gob-smacking.

The episode about HP turning down the idea of the Apple I computer was particularly thought-provoking. Wozniak was working at HP before Apple was founded, and being loyal to his company (which he firmly admired for being led by engineers who in turn deeply respected other engineers) he offered them the chance to implement the ideas he had devised outside work time for what would become, in effect, the world’s first useful personal computer. Although his managers at HP showed considerable interest, they were not able to set aside their standard, well-honed processes in order to start work on what would have been a new kind of project. Wozniak says that HP turned him down five times, before he eventually resigned from the company to invest his energy full-time into Apple. It seems like a classic example of the Innovator’s Dilemma – in which even great companies can fail “by doing everything right”: their “successes and capabilities can actually become obstacles in the face of changing markets and technologies”.

Via numerous anecdotes, Wozniak describes a set of characteristics which are likely to lead to product success:

  • Technical brilliance coupled with patience and persistence. (Wozniak tells a fascinating account of how he and one helper – Randy Wigginton, at the time still at senior high school – created a brand new floppy disk drive controller in just two weeks, without any prior knowledge of disk drives);
  • A drive for simplicity of design (such as using a smaller number of parts, or a shorter algorithm) and superb efficiency of performance;
  • Users should feel an emotional attachment to the product: “Products should be obviously the best”;
  • Humanism: “The human has to be more important than the technology”.

There’s shades of the iPhone experience in all these pieces of advice – even though the book iWoz was written before the iPhone was created.

There’s even stronger shades of the iPhone experience in the following extracts from the book:

The Apple II was easy to program, in both BASIC (100 commands per second) and machine language (1M commands per second)… Within months dozens of companies started up and they were putting games on casette tape for the Apple II; these were all start-up companies, but thanks to our design and documentation, we made it easy to develop stuff that worked on our platform…

… the computer magazines had tons of Apple II product ads for software and hardware. Suddenly the Apple II name was everywhere. We didn’t have to buy an advertisement or do anything ourselves to get the name out. We were just out there, thanks to this industry of software programs and hardware devices that sprang up around the Apple II. We became the hot fad of the age, and all the magazines (even in the mainstream press) started writing great things about us. Everywhere you looked. I mean, we couldn’t buy that kind of publicity. We didn’t have to.

In this way, the Apple II quickly reached sales figures far higher than anyone had dared to predict. One other factor played a vital role:

VisiCalc was so powerful it could only run on the Apple II: only our computer had enough RAM to run it.

But sales bandwaggons can lose their momentum. The iPhone bandwaggon will falter, to the extent that other smartphones turn out to be more successful at running really valuable applications (such as, for example, applications that can run in background, in ways that aren’t possible on the iPhone).

Apple also lost some of its momentum in the less reliable Apple III product that followed the Apple II. Wozniak has no doubts about the root causes for the failure of the Apple III: “it was developed by committee, by the marketing dept”. This leads on to the disappointing advice that Wozniak gives in the final chapter of his book: “Work alone”!

Here, I part company with Wozniak. I’ve explained before my view that “design by committee” can achieve, with the right setup, some outstanding results. That was my experience inside Psion. However, I do agree that the process needs to involve some first-class product managers, who have a powerful and authentic vision for the product.

Theme: Silver is the New Black. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 36 other followers