Latest MySky (HDi) update

The latest (and heavily publicised) MySKY (HDi only?) update was released today.  Oddly, our update was applied around 2 p.m. – the currently showing program was replaced by a very ugly notice that the system was being updated.  I can’t understand why the update wasn’t deployed during the night (e.g. 4 a.m.), when the number of viewers must be significantly lower.  What if I had really cared about the program that was showing?

My initial reaction was very negative.  After it was pointed out (via Twitter) that many of SkyTV’s mistakes are correctable via new options in the settings back, I’m slightly less negative, but it’s still not an improvement.  This is especially frustrating considering that the UI is so terrible, and has been ever since MySKY was introduced about five years ago (I’ve had MySKY since just after the launch).  Being told that they know about the many problems and fixing them isn’t possible until the hardware is revved doesn’t inspire any confidence at all, since the problems existed with the original MySKY and certainly were not fixed when the hardware was revved (with HDi).  Someone at SkyTV is responsible for selecting the hardware – if the platform doesn’t support creating a decent UI, then they should choose something else.

(Has anyone on the MySKY team used an Apple product?  Or even Windows 7 or a Zune product?  Would they recognise good UI when they saw it?  Do they have anyone that has any UI talent or experience?  If so, perhaps they could give that person a bit of power to fix things?)

The “what’s new” page has a feedback form where you can comment on the recent changes.  I encourage you to do so.  My comments were:

Planner Search

Sorting by time is a pointless way to organise the planner – it caters to people that don’t understand how to use a DVR properly (e.g. who are using it like they would have used a VCR). Sorting by A-Z is vastly more useful, because the typical planner task is either finding a specific program to watch (I always know the first letter of the name, I rarely know or care when it was broadcast/recorded), or browsing through programs to find something to watch (I don’t care what’s oldest/newest, I care what the program is).

The changes in this update make things worse in this respect. Although it’s possible to turn off the video and set the “search” interface to A-Z sort by default, you’re then in an interface where you have to go right/left to get to delete/keep. The planner should default to A-Z search, or at least have that as an option.

Confirm Delete

Although it’s fantastic that after 5 years the “tiny button right next to ‘don’t delete this’ deletes irrevocably” problem has been addressed, a confirmation dialog is (although common) generally the wrong UI decision to make. Users (a) get into habits of just ok’ing such dialogs, decreasing their value, and (b) are less willing to try things out. It is almost always better (and certainly would be here) to simply make any action reversible (i.e. have an undo delete).

Preview

The preview in search seems completely pointless. I almost certainly know what the program is based on the title, and if I don’t, then starting to show the program isn’t going to help. This is exacerbated by the fact that with the “automatic” buffer setting the preview generally starts with the end of the program that was on before the program that you’re looking at.

It *would* be useful to have an episode name & number (where applicable) in the main planner screen (e.g. to distinguish between several episodes of a kid’s program that is played out-of-order), or to only show each series once (and selecting it goes into a submenu where specific episodes can be selected; this is common in other interfaces where screen space is limited). Showing the synopsis in search helps with this, but takes up a vast amount of space (only five rows of text – even on a huge screen!), and comes with the annoying and loud video.

Positive

After five years, the guide finally shows an indication of which programs are scheduled to be recorded.  This feature was present in the old Sky Digital system (which didn’t record, but did allow you to schedule reminders), and it’s amazing that it’s taken this long to restore it.  However, it ignores series-link, so it only highlights the next episode.  It would be nice to get the feature right.

My 2GB, 4 day 0.0.1 iPhone update

A few days ago, Apple released version 3.0.1 of the iPhone OS, which addressed a pretty major SMS vulnerability.  When Olyvia tried updating her 3GS to 3.0.1, something went wrong.  The iPhone entered “Recovery Mode”, which means that it displays an image indicating that you need to connect it to iTunes, and you can’t do anything else (no phone calls, no iPod, no applications – absolutely nothing).  Connecting the phone to iTunes prompted a message indicating that the phone needed to be recovered – doing so downloaded the 3.0.1 update, and then got stuck on the “Verifying Restore with Apple” step for a long time, until it would finally fail with error “3104”.  This process could then be repeated, with the same results.

What this meant in practice was that the phone was bricked as of last Friday.  An update should never be able to brick a (legitimate, not jailbroken) phone! Even more, failing to verify a restore with Apple should never leave the phone in a broken state.

I tried many thing to resolve this:

• Restoring on three different computers (three OS X Leopard, one Windows XP).
• Using three USB cables.
• Using two Internet connections (different router, different physical location, different ISPs).
• Restoring with five different user accounts, including one that was created solely for this purpose.
• Removing iTunes and the Mobile Device helper completely and reinstalling.
• Restoring with an administrator account (both OS X and Windows XP) and a standard account.
• Redoing the restore at many different times of day, including times when most of the US would be asleep (so the server load should be fairly low), over Friday, Saturday, Sunday, and Monday.

None of this worked.  It did mean that I downloaded the 300MB+ update six times (one for each user account and once to refresh) over the four days.  That combined with the iTunes installation brings the total download cost to around 2GB.

I eventually gave up.  Google found many other people with this problem, but only a single solution, which involved opening a terminal connection to the phone and changing an environment variable.  I wasn’t particularly comfortable doing that, since if something goes wrong I want Vodafone/Apple to just replace the phone without any argument.  Since there isn’t any real support available over the weekend, I waited for Monday morning.

I wasn’t sure whether to contact Apple (expecting a “please call Vodafone” answer) or Vodafone (expecting a “what do you mean you updated your phone?  Can you do that?” answer).  Thankfully, Vodafone NZ has a very responsive and helpful Twitter presence (@vodafoneNZ).  I tweeted, asking who to call, and was asked for details.  I provided these (going into more detail in an email), and got back a (unfortunately not helpful at all) suggestion.  Since that didn’t work, Paul Brislen provided me with an 0800 number for the “iPhone Team” (I’d call them “iTeam”, subtitled “there’s an ‘i’ in iTeam”, but anyway…).  Unfortunately, since I had to do a lot of travelling and offline things on Monday, I wasn’t able to get to this until Tuesday.

I certainly appreciate a (free) phone number I can call.  However, I don’t have a great deal of time to spend talking on the phone, explaining a rather complex problem and the many steps that I’ve already done to try and resolve the problem.  I also have poor cellphone coverage (Vodafone’s fault) and a rather noisy landline (Telecom‘s fault), so voice calls aren’t a great solution to a problem.  Faced with a (presumably) long and difficult phone call, the ‘hack’ solution of altering the environment variable looked a little more appealing.

I downloaded iRecovery and opened a terminal (shell) connection to the iPhone.  Typing “printenv” gave a list of the environment variables – the ones that had a “P” at the start were presumably non-default values (these included “auto-boot”, “bootdelay”, “backlight-level”, and “platform-uuid”).  The article indicated that the “false” value for “auto-boot” was the problem (and the solution to use setenv to change it, then reboot the phone).  This seemed a reasonably safe thing to do (and also easily reversed), although I imagine that it would be rather scary to a non-programmer (who has no idea what “printenv” or “setenv” might mean).

Thankfully, this worked.  The iPhone rebooted – although it went straight back to the recovery page in iTunes, which wasn’t hopeful.  However, this time the recovery process worked flawlessly (using the existing four-day-old copy of the download).  The phone was recovered from the automatic backup, and then sync’d.  Some of the settings are a bit out as you expect in a recovery, but the phone actually works, which is really all that matters.

I don’t know what would have happened if I called the “iPhone Team” (and don’t need to find out now).  I suspect that we wouldn’t have got far, or maybe would have ended up doing exactly this (or perhaps having to return the phone for service).  I could be wrong about that.  I do feel that Vodafone (specifically @vodafoneNZ) handled this pretty well (and Apple extremely badly).