Wednesday, 22 September 2010

Learn later

There's been a fair amount of talk recently about how the internet is affecting our intelligence and cognitive ability. It's been a while since Nick Carr wrote his seminal piece "Is Google Making us Stupid?", and the recent flurry of interest arises because he's since followed up with a book called The Shallows. The general premise is that the way we use information on the web is less immersive than traditional long form writing, and this is affecting our ability to learn and use information in general. Meantime, JP has weighed in with a three part blog post exploring whether the web makes experts dumb. All good reading.

It's a fascinating subject, because while most of us can agree the impact will be profound, it's still very much early days, and fun to predict how we'll evolve. Our brains are getting used to processing information in different ways, scanning text of different length, following or ignoring hyperlinks, learning where things can be found rather than actually finding them and learning them by rote. It could very well have an impact on us at a species level, at a physiological level, over a period of generations, even if we ignore the societal and technological leaps that will also take place in the meantime.

This blog post is about my own personal, recent experience of how the web is helping me to learn. There's a terrific iPhone application called Instapaper, which allows you to save web pages from your computer for reading offline later on your phone, simply by clicking a link marked "read later". It's much the same as opening new tabs in a browser, except saving it for a time and a place when you're not distracted by work. This improves the chances of actually reading it (or sometimes not).

But here's the interesting thing. If you're reading an article in Instapaper on your iPhone, and you click on a link, you can 'read later' there too. There's no cognitive dissonance as you follow link after link, a'la the web. I'm getting to finish the article safe in the knowledge that the distraction is saved for me to look at when I'm ready. All in the context of having no distractions - the time when I'm commuting, mostly. It's the ultimate way to read Wikipedia - for me, anyway.

And in this fashion I've filled gaps in my knowledge, as well as learning about loads of cool stuff too. The Lewis and Clark Expedition. The Mason-Dixon Line. The Louisiana Purchase. The Manhatten Project. Space Fountains. The Interplanetary Transport Network. Dyson Spheres. Human experimentation in the United States (macabre but fascinating). Unit 731. Boltzmann brains. The life of Mohandas Karamchand Gandhi. And so on. Wonderful stuff.

Personally, I think that the internet can only improve our ability to learn from each other. Sure, we'll need to adapt to process information (and maybe information overload) in increasingly sophisticated ways, but we're an adaptable species. Furthermore, maybe one way of looking at things is that the internet has reduced the real barriers to learning, whereas tools such as Instapaper reduce the perceived barriers? The Wikipedia / Instapaper combination has been potent for me, I wonder what works well for others?

Friday, 23 July 2010

Spending the BBC licence fee

There's an interesting discussion doing the rounds on Twitter today (kicked off by James Governor) around whether the BBC should be spending licence fee money building tools for the iPhone and iPad. The argument goes that public money should not be spent investing in technologies which require the public to use products only available from a single supplier.

It's an interest debate because, under normal circumstances, I'd support this line of thinking. Public money should be invested in open technologies, because the information and services should be available to all, and open technologies is the way to do it. Seems obvious.

However, there are some important points to make here:

- Even with the creation of iPhone and iPad apps, the BBC and the public don't have to depend on proprietary hardware or software to get at the information. The exact same information is available over many other channels and services, including their website.

- There are at least 2 million iPhones in the UK, and Lord knows how many iPads. Surely we shouldn't ask the BBC to ignore this size of group, many of whom also pay their licence fee? Aren't they entitled to access the service in the way that they want? That last bit is important, by the way. Convenience and user experience are part of the service.

- If the BBC is to deliver on the promise of "delivering to the public the benefit of emerging communications technologies and services", then this shouldn't exclude proprietary platforms. No one can deny that the iPhone is one of the most influential, innovative and popular platforms around. To exclude it for idealistic reasons would be petty, not to mention uncompetitive.

Essentially, I think it comes down to this. The BBC is about connecting users and information / services. It should remain agnostic about the technology required to do this.

Thursday, 22 July 2010

Berlin

I went to Berlin recently - and it was fab. But the main point of this post is to see what the Flickr slideshow looks like when embedded in a blog. We're building a site for some kids called Events Academy, about which more later, but in the meantime here are some photos of Berlin:

Monday, 31 May 2010

Publishing on the iPad

There's little debate now that the iPad will be a roaring success, and customers will be demanding content via this format very soon, if they're not already. It's tempting to think that the design process can be inherited from traditional web design, or iPhone design, or both. There's some truth in this, but there are also some new considerations to take into account. Publishing on the iPad is more complex than it seems, so I thought I'd share some early thoughts on how to approach this challenge.

Range of options

There are numerous ways to get written content onto an iPad, ranging from the cheap and cheerful through to expensive and sophisticated. The right option will depend on several factors, not least of which are budget, audience and business model. Let's start with the low cost options first:

PDF: The iPad opens PDF files in Mail or Safari, whether emailed or downloaded from a website, and they look pretty good there. Pinch to zoom in and out works, although it's worth testing the specific file before release because there are some rendering issues.

ePub: the free iBooks application can open any document in the ePub format. Users can download the file from your website, drop the file into iTunes, and sync the file to the iPad in much the same way as music. However, getting the document into the ePub format in the first place can be a bit tricky. You can use a tool such as Calibre to convert a file from pdf into ePub, but in my limited experience you end up with a messy document (lots of irrelevant content, gaps in words, that kind of thing), and it's far better to create the ePub document using the original software used to create the pdf. There's a handy list of supporting software here, from which it looks as though Adobe InDesign users are in luck.

If you need to charge for publications, but these publications will be rare or ad hoc, you might consider using a service like Lulu, which charges users to download your file and they take a cut.

Improve your website: If you already publish content over a website, have a quick look to see how it renders using Safari, the iPad browser. This does a pretty good job helping users view content, and your site might look just fine. Simply being mindful of how it looks could inform the publishing process, leaving you safe in the knowledge that the content looks good on all platforms.

Applications

Depending on budget, readership, business model, the competitive landscape and other factors, there may well be justification for creating a bespoke iPad application driven by a Content Management System. Even if competitors aren't yet publishing on the iPad, there's a good chance they will be soon - and there's a lot to be said for first mover advantage.

The cost and effort for creating and maintaining such an application is comparable to creating a web site - and in some cases can be even higher. So the decision making process at the start is critical to success.

One of the first considerations will be the business model. Do you charge for the application and / or each issue? What about advertising revenue (Apple have created a bespoke platform called iAd for serving adverts via applications)? What about subscriptions? What about sponsored publications? What about downloading offline versions (done to great effect in the FT app)? Again, this is an area where there will be much experimentation. As Popular Science editor-in-chief Mark Jannot says "we'll see what the market can bear".

This business model will inform the level of investment and, as we've seen, there's a range of solutions available depending on budget. As with iPhone apps, there will be several agencies offering cheap iPad applications - but it's essential for the savvy publisher to understand why cheap might not be best. The design process for new iPad applications requires deep thought, and it will be easy to overlook many of these key issues.

Gestures

The iPad is truly the first of a kind. While finger based gesturing has been around for a while on the iPhone and Mac laptop trackpads, the size and responsiveness of the screen invite the user to explore with touch. And the early iPad application developers have jumped at the opportunity to explore the potential of this new paradigm.

I've played with a few apps (Financial Times, Wired, Popular Science, The New York Times, Epicurious, Marvel) to form these views. What I've found that various gestural paradigms have been explored, and the variety - the lack of consistency - across multiple apps is difficult for a user to process.

For example, the Wired app is pretty intuitive - single finger swipe to turn page - while the Popular Science app (while beautiful to look at, and lovely to interact with when you get the hang of it), has several lessons to learn before you can navigate without thinking.



Bear in mind that the previous page said "Move across for the next article >>", and only needed one finger. So, what's a "section"? How will I get back? It also takes 1-2 seconds for the images to turn hi-res, during which time swipes don't work. But they're stored up, and activate all at once when the page loads. That's bad design. I'd love to know how they populate the Popular Science app, because from the outside it looks as though it will require a large amount of bespoke tailoring each issue.

It was interesting to read that Wired use the same software that publishes their paper version to publish their iPad version. This could prove a very interesting route for publishers when the relevant functionality in InDesign is made public later this year. I'm wondering whether the necessary simplicity of publishing the Wired app to the iPad encouraged them to keep innovative gestures to a minimum? I'd also like to know how they go about embedding video content into the application, whether this is added after the event or during the design stage. Either way, by the looks of things, Wired and Adobe have created a much simpler mechanism, and a much simpler experience as well.

On the balance of things, I'd recommend all designers to get a solid understanding of the iPad library elements provided by Apple. While various publishers are experimenting with different gestures, the ones most likely to gain traction with users are those which are most familiar - and those provided by Apple will prevail in the long term. Innovation should, of course, be encouraged but great care should be taken to introduce new paradigms with respect to the user.

Orientation

Orientation change on the iPad is much more of a problem than with the iPhone. The smaller screen on the latter means that the width is simply increased or decreased when the screen is rotated. However, the iPad screen size allows for a more complex screen architecture meaning that it's easier to lose where you were after orientation change. This is called 'context shift'.

Indeed, if you've got screen assets that go full width in both orientations (this includes menu bars), then you have a less space for other (main) content. As you can see on the New York Times app, you'll lose content when you switch from portrait to landscape:


In this case it's a photo missing (see bottom right on portrait version), but I've seen text missing in the past.

You need to give some thought to the various states the user context may be in when they switch orientation. If, say, someone is half way through a task when they switch orientation, they should be able to resume their task without breaking stride - and this is very hard to design for. One way this can be helped is via the transition. If the exact same assets are on the screen in both orientations, and the assets don't change size, then you can simply move each element. I expect (but don't know) that Apple include this feature in their developer libraries - it's not unlike the 'Magic Move' feature in Keynote (which is demonstrated here). Of course this is a problem if you're losing content between orientations, but the New York Times have handled this quite nicely by sliding all the panels out and then all the remaining ones back in, very quickly. It creates the impression of content being rotated, but actually replaces it. Still, the context switch is unnerving, especially if you're reading text missing after an orientation change...

A case in point is the polished iStudiez Pro app, which is beautifully designed, but I found a problem within minutes of playing with it. When writing a lesson note, I changed orientation and the bottom of the note - where I was writing - was hidden by the keyboard.

Oddly enough, I haven't been able to repeat the error. It goes to show that designing for two orientations, and allowing for multiple context changes between the two, creates a much larger burden on the testing programme. There might even be an argument for testing every single release of content, if the app is for Publishing. Bugs such as the one I found on iStudiez Pro will be hard to find without a rigourous test programme - and at £1.79 for the app it's going to be financially hard to justify for smaller software houses.

Conclusions

While it's fun to write criticism of the early iPad applications, the fact remains that these pioneers are doing a great job showcasing the potential of this new device. The public will vote with their feet, and it will take some time for the results to come in - time will tell whether the early front runners will retain their readership, or whether the price points will need to change.

In the meantime, it's essential for all those considering publishing on the iPad to spend some time experimenting with existing options and applications, and just as critical that designers become mindful of the vagaries of the iPad. Let's push the boundaries without making it difficult for users. The UX guidelines produced by Apple - while excellent and compulsory - only take you so far. That said, I'm just thrilled that we get to be the generation that designs all this stuff! And the onus is on us to make sure that users get the same amount of pleasure out of using the device as we get sharing our content and design with the world.

Bonus link: Well worth checking out Jacob Neilsen's comments on the iPad as well. Although given that their website looks likes it came from the 90s, you can take their design critique with a pinch of salt...

++

UPDATE 2 June 2010

More information on how the app was created (the use of images cut to 1024x768 explains why text can't be selected, but also why each page looks so darn good), plus the official press release from Adobe.

Wednesday, 28 April 2010

Spotlight Weirdness

I'm having a problem with Spotlight, and was wondering if anyone who reads this has had a similar problem.

I've just had a clean install on my laptop, and when I do a Spotlight search I get this:



Note that the problem isn't that the search query isn't included in the index, or that the indexing process isn't complete yet, it's that the index isn't even being interrogated. Nothing ever appears below the search request box.

I've tried removing com.apple.spotlight from my Preferences folder, and also tried adding my hard drive to the Privacy section of Spotlight Preferences before adding it again (to force a re-index), but it makes no difference. Tried Google, but there's a similar problem which takes up the first few pages of the results, so I can't find a solution.

Help?!

Wednesday, 14 April 2010

An open letter to o2

Dear o2 (cc Apple),

I've just read your announcement that you'll have dedicated tariffs for the iPad when it launches in the UK at the end of May, but I was hoping you would go one step further.

I already have an iPhone, and pay a premium for the 3G connection. It seems wasteful having a second 3G connection when I already have one in my pocket and, I would've thought, would also reduce the burden on your infrastructure if I only had one connection.

So, I was wondering whether you'd be willing to find a way to tether my iPhone to my iPad? It would mean I only need to buy the wi-fi iPad, saving me about £70, and would get you a more loyal customer. Although the hardware and software are made by Apple, I'm sure you could pull some strings.

You may be worried that my combined iPhone and iPad bandwidth will be much higher than just the iPhone. But I won't be using both devices at the same time. Any increase in usage because the iPad is more pleasant to view the web will be offset by a reduction in page changes, because I'll be more likely to read a whole page rather than just the small bits my eyes can tolerate at the small text size.

Waddayasay?

All the best,
Phil

Saturday, 3 April 2010

In response to Cory Doctorow (or "Why I won't not be buying an iPad")

Having just read Cory Doctorow's piece on why he's not going to buy an iPad, I'd like to offer a counterpoint. It's rare for me to disagree with Cory (I've got huge admiration for him and his writings), but it's worth challenging his views on this one because they're fairly one sided.

He asserts that the iPad locks its users into the whims and fancies of Apple and the content providers, while at the same time resisting the efforts of hackers wishing to take it apart to learn how it works and try to improve it. The implication is that this somehow represents a trend leading towards some kind of dystopian future where most content, hardware and software looks this way.

There are several areas I area with, strongly. Content providers must not be put in a position where they can limit our choices. And the hacker culture is one which should be cherished and nurtured - it's a critical part of how our industry evolves.

However, I would argue that, on the balance of things, the iPad will do more good than harm.

I can't help wondering whether, because Cory has invested so much time explaining why the old publishing business models have collapsed, he's lost sight of what was good about these models. So long as our rights aren't affected, why shouldn't the publishing industry look for (legal) ways to make money out of their content? It's their content, and they've got just as much right to try and monetize this as I have not to pay for it. There's also still a lot to say for investigative journalism still being funded - sometimes the big stories need money behind them. Not to mention all the careers at stake. So long as we can still access a huge breadth of alternative content elsewhere on the web, where's the harm?

I was perfectly happy to buy the Guardian app for the iPhone at £2.39, because it's one of the best ways to read news *on that device*. It in no way threatens the other ways the same content is shared elsewhere. As we collectively explore the new frontier of user interfaces on mobile devices, I'm tempted to thank the Guardian simply for advancing this cause. This benefits all content providers for all mobile devices, not just the Guardian on the iPhone, by demonstrating - extending - the art of the possible. Proprietary software has often served as a source of inspiration for open source developers looking to achieve similar aims.

And iPad users can still view content via the web browser (which promotes open standards, natch). The iPad user has full choice in this matter. No harm done.

As for hacker culture, this will continue to prosper because hackers still have other devices to take apart. This is an unstoppable force. Dedicated hackers will still find a way to hack the iPad, as evidenced by the community which has grown around hacking the iPhone [Update 5 April 2010: already jailbroken. And dismantled]. And, besides, just because something can't be hacked, it doesn't necessarily indicate a trend.

At the end of the day, the iPad is just a utility which, admittedly, sits atop the web. I would argue that the iPad extends the reach of the web further than it presently goes. It makes browsing the web more comfortable and convenient in certain scenarios (bed, train, sofa, others), and in doing so it will reach new people and increase usage for others (as a second or third device) - some of whom may become hackers as a result. Just as happened on the iPhone, we can look forward to innovative apps and websites that make the most of the new paradigms. And these will feed back into the various cycles of innovation happening elsewhere. In the long run, I would speculate that the web will benefit from the iPad, just as much - if not more - than the iPad benefits from the web.

As for the way in which comics used to be shared, and no longer can be, well that's a shame. But it isn't the iPad's fault - that's simple a side effect of digital content in general. Where you can still share URLs if you want to point at something. The web doesn't stop you buying a physical comic and sharing it, and in fact provides a wealth of social mechanisms and tools to augment real friendships. In fact the iPad is bringing comic reading to a new audience, who may become interested in the culture of sharing physical comics as a result. Cory should be thanking the iPad for this, not chastising it for the nature of web content in general!

I will be buying an iPad.

Monday, 29 March 2010

Cleaning the Apple Mighty Mouse

This post is just to help people with a similar problem - hence the search term friendly title.

There's a problem with the design of the Apple Mighty Mouse, in that it tends to gather in dirt under the track ball. This means it doesn't scroll, sometimes in one direction, sometimes in more. It's impossible to get under the track ball without dismantling the mouse, and then dismantling the track ball carriage - and then it's almost impossible to put it all together again. Needless to say, this will void your warranty.

There are a few HOWTOs out there explaining how to perform the above process, but as my mouse was under still under warranty I gave Apple support a call. They advised me to dab the track ball with a wet finger, turn the mouse upside down, and then roll the mouse / track ball around on a clean, white piece of paper. It worked! My mouse trackball now scrolls in all directions.

So I recommend you try that before getting out your screwdriver...

Sunday, 28 March 2010

Adventures in Python

I've decided to spend some time learning how to program, and as I encounter problems (and, hopefully, solve them!) I'll drop notes here on my blog in case they help others. Plus this has the added benefit of giving my developer friends a steady stream of entertainment....! And finally, in the style of Julie Starr's TiddlerToddler, it may even provide an interesting beginner's insight for those who are creating or updating documentation.

Why learn to program? Well, because it looks like fun. I've enjoyed working with developers for years now, and while I've dabbled in HTML from time to time, I haven't taken it any further than that. In terms of choosing a language to program in, I really wanted to get building things quickly, so I've plumped for Python, as a route towards using Django. I often hear Python and Django being referred to as a fun and quick route to build quality apps. So let's see how we go.

My starting point has been Alan Gould's Learning to Program guide. I should pause here and say, from my experience working with the TiddlyWiki community, that creating this kind of guide is incredibly time consuming and rarely gets the appreciation it deserves - and its free! So I'd like to start by putting my thanks and appreciation firmly on the record. Thanks, Alan!

It's been a great guide so far, but I came across two problems which I'd like to document here. I'm using Mac OS X (toggling between Leopard on my iMac and Snow Leopard on my Macbook Air), which has Python installed by default, but this isn't the most up to date version. I wanted the most recent version so that my new skills would be as relevant as possible, and the most stable release is v3.1.2 - so I went ahead and downloaded this (it's just a .dmg file, containing an .mpkg file - simple to install).

But for the life of me when I went back to the terminal, and typed "python", the old version kept coming up like this:


It launches Python 2.5.1. I even tried explicitly ticking the "Shell Profile Updater" option during installation - it made no difference. I even tried Google, but had little luck. At this stage I was getting hugely frustrated that I couldn't get over this first hurdle, so I sent out a message on Twitter and was amazed to get help within seconds from Victor Miclovich:



Victor, you are a legend - thank you! And you've inadvertently proved out my assumptions about how helpful the Python community is!

(Incidentally, I've found you don't need the dollar sign - just typing python3 works too)

I also encountered a second problem. Alan's tutorial presents the option between using the terminal (which my colleagues generally favour) or IDLE - an integrated developer environment, which came with Python. Well, the terminal wasn't really working out for me at that point, so I tried IDLE, and followed a link from Alan's tutorial to this IDLE help page.

But when I tried the "Hello world" example, I kept getting a syntax error as follows:


Fortunately, this one was easier to solve. It turns out that Python 3 requires a different syntax from Python 2. Instead of:
print "Hello world"

I needed to type:
print ("Hello world")
Success! (this shows the terminal again, though it worked in IDLE too)

OK....I'm easily pleased, I know!

So..this could be the start of an interesting journey. I can't help thinking about Nicole Lazarro's game theory talks at SXSW and Supernova last year. She talks about "hard fun" - the notion that people are willing to spend a certain amount of time being frustrated in return for the elation of a breakthrough (this applies to games such as Halo, too). So, let's see how long I can keep this up...

Wednesday, 17 March 2010

From Entourage to Mail.app and iCal

I've recently made the jump from Leopard to Snow Leopard and, with it, have been able to move from Microsoft Entourage to Mail.app / iCal (Snow Leopard provides better Exchange support, which means iCal should now allow things like viewing other people's schedules). After the initial jubilation, it turns out that things aren't quite that rosy after all. So I thought I'd capture what the down points are in case anyone is considering a similar move.

I've actually found Mail and iCal to be a bit clunky.

- Messages that have been sent have still been saved in draft, and sometimes didn't appear in the sent folder. This led to me sending messages a second time, causing confusion. Sometimes these messages were incomplete, because the draft had been saved before the message was completed.
- There's been at least one occasion where I sent a (very important) message but all evidence of it has disappeared, even when I use Webmail to look directly on the server.
- Sometimes i've tried to delete a message from drafts but Mail.app wouldn't let me, claiming that it couldn't connect to the server. Yet I was able to carry on sending and receiving other emails with no problems. The only way to remove it was to send it!
- In iCal, when changing a meeting, it seems to struggle when looking for certain invitees using auto-complete, even when the recipients are all on the same domain
- Entourage used to give frequent recipients in my address book priority over those I never email (who just happen to be in my domain). Annoying because for Stephen Waller (with whom I share a project), I have to type "Stephen Wal", because there is something else in the org whose name starts with "Stephen Wad".
- When changing / removing an event in iCal, you have to inform all participants / the meeting organiser - you don't have an option not to send a message. Annoying as I sometimes want to remove or change something in my calendar without sending the organiser an email.

These are just the ones I can think of off the top of my head. There are others.

Anyway, I never thought I'd say this, but I'm seriously considering moving back to E-Rage - sorry, Entourage. Not cool.

Wednesday, 6 January 2010

Thoughts on the Nexus One

In case you've been in a cave, you will have noticed that Google have released their own branded Android phone, the Nexus One (in the States, at least).

I can't help smiling at the responses saying it's some kind of 'iPhone killer' - it falls a long way short in so many important areas - seamless syncing with iTunes, a high quality app store and the user experience to name but three (emphasis mine; I know it's possible to sync with iTunes and there is an Android app store, but there's a gulf in quality at the moment).

A designer friend of mine maintains that Google are making a mistake targetting developers, rather than users. Obviously the user experience is one of the key reasons for the iPhone's success, but I think other factors (functions and features) will come into play as well. You can help users through helping developers, so long as you pay very close attention to the user experience as well.

So, what can Android / Nexus One offer that the iPhone can't? Freedom. You can install whatever you like on the Nexus One, whether it's on the (currently unappealing) official Android App Store, one of the other Android app repositories, or handed to you directly by the developer (I haven't seen the Android App Store as seen on the phone itself, but Tim O'Reilly claims its pretty good).

My prediction is that, over time, we'll start to see more and more benefits available on Android phones that are unavailable on the iPhone. I think we can expect the UI to improve somewhat - Google have money to spend on design. While it's unlikely it'll ever catch up with Apple in this department (a very subjective debate), perhaps it doesn't have to. The additional functionality will, for many, outweigh the less effective user interface.

What can we expect in terms of additional features? Some obvious ones spring to mind. Tethering the phone to a laptop so you can access the web over 3G (without a costly bolt-on) is very worthwhile. Making calls using your favorite VOIP client is another. Pornography apps is a third category - snigger all you like, it's popular! Have a look at all these apps that get rejected, thanks mainly to Apple's restrictive app store policy. Tasty.

The presence of another big name smartphone on the market will increase the size of the market overall, and the competition will do the iPhone no harm at all. And there will always be enough differences between the two offerings to appeal to different customer types. Bring on the competition!

Incidently, articles such as this one in Ars Technica claiming that the option to buy the phone free of a carrier is a game changer are off the mark. You can buy unlocked iPhones in France for an extra cost, but only 5% of early iPhone customers chose to do so. The vast majority of phones would need to be sold unlocked before quality of service would become the key differentiator between carriers - at least to the point needed to justify the huge expense of bolstering their networks (recommended: Fake Steve takes AT&T to task, hilarity ensues).