Om Malik asks, 'why Safari on Windows?'
Om notes that alternative browsers don't thrive on the Windows platform, and that releasing software (even a free browser) to the wider Windows platform opens Apple up to the slings and arrows of outrageous (and unfriendly) pundits.
Om speculates that Apple's motives center around switchers- the more Apple interfaces you can acclimate Windows users to prior to their switch, the easier the transition becomes.
I think there's a more subtle, longer term motive to this plan, and it can be summed up in one Ballmeresque sentence: "Developers, developers, DEVELOPERS!"
Here's my reasoning:
1) The iPhone runs Safari.
2) The only way to write 'apps' for the iPhone is to create Safari-compatible widgets.
3) Making Safari available to Windows users makes it easier for Windows developers to create iPhone widgets, widening the pool of potential iPhone developers by a factor of 10.
Safari on Windows, and all the costs and PR headaches that go along with it, are a component of Apple's master plan to democratize mobile application development and create a platform owned by device makers (like Apple) and less dependent on carrier control.
Friday, June 15, 2007
Wednesday, June 13, 2007
iPhone: Crippled Also-Ran or Clever Revolutionary?
In the wake of Steve Jobs' Worldwide Developers Conference keynote, there's been a firestorm of discussion regarding the lack of a 'true' SDK for the much-anticipated iPhone. Most of the negative feedback centers around the assertion that without the ability to write 'true' software apps for the iPhone, Apple is shutting out development of really useful apps. Instead, developers (and by extension, users) will have to make do with widgets- AJAX applications designed to execute in a browser running off information stored on servers.
The interactive experiences I invent are pretty much all browser based applications, so I come into this argument with a bias- but what truly interests me is not what I can get out of the iPhone. In this case, I'm more interested in the business perspective, and what this decision will do to the mobile platform in general.
In my work, I speak with interactive professionals who work in the mobile space, and their #1 complaint is the endless multiplicity of platforms they need to develop and deploy to. #2 is the management layer of the various carriers who control those platforms. As a result, it's a lot harder to gain a critical mass of users in the mobile application space than in the web space- there's no equivalent to making a quick Flash game and having it available to 90% of users overnight.
If you're a web designer, the situation is akin to their being fourteen different browsers you would have to build and test for- plus, these browsers operate differently for Yahoo! users, for AOL users, for MSN users, etc.
Despite its apparent popularity, the iPhone isn't going to change this situation overnight. Even Apple has stated they'd be happy with a 1% marketshare in 2008- that's not going to represent a market mover in terms of platforms.
Instead, I think what Jobs & Co. are doing is more subversive- they are democratizing the mobile application space. That's the core of the dismay we're hearing from developers- the flip side of their argument (they can't make real apps) is that AJAX apps are somehow fake. This is an echo of the old back end vs. front end non-argument that erupts all over the interactive industry map when web developers meet software engineers.
When all it takes is a copy of Dreamweaver, and O'Reilly book, and some copy and pasted Javascript to make a web app, we will see an explosion of single purpose widgets proudly proclaiming their iPhone compatibility. Most of these will be utter rubbish- and the message boards and ratings on Hotscripts and Versiontracker will serve to banish them into well deserved obscurity. However, some will be gems- as a frequent air traveler and motorcycle rider, I rely on the OS X Dashboard 'Radar In Motion' widget to predict whether I will be delayed or drenched. It is completely immaterial to me that this widget is just an HTML fragment and not a compiled blob of code- it does what I need it to do, elegantly and conveniently.
No matter how many Diggers cry foul, when Jobs stands up at Macworld San Francisco and proclaims that thousands of apps for the iPhone have been developed since launch, no consumer is going to care that they aren't 'real' apps. All they are going to care about is: Does this widget let me do something I couldn't do, or make something easier to do? I firmly believe that all the 'fake' developers need is imagination, insight and focus to supply that user experience, despite the sandbox Apple is making them play in.
The interactive experiences I invent are pretty much all browser based applications, so I come into this argument with a bias- but what truly interests me is not what I can get out of the iPhone. In this case, I'm more interested in the business perspective, and what this decision will do to the mobile platform in general.
In my work, I speak with interactive professionals who work in the mobile space, and their #1 complaint is the endless multiplicity of platforms they need to develop and deploy to. #2 is the management layer of the various carriers who control those platforms. As a result, it's a lot harder to gain a critical mass of users in the mobile application space than in the web space- there's no equivalent to making a quick Flash game and having it available to 90% of users overnight.
If you're a web designer, the situation is akin to their being fourteen different browsers you would have to build and test for- plus, these browsers operate differently for Yahoo! users, for AOL users, for MSN users, etc.
Despite its apparent popularity, the iPhone isn't going to change this situation overnight. Even Apple has stated they'd be happy with a 1% marketshare in 2008- that's not going to represent a market mover in terms of platforms.
Instead, I think what Jobs & Co. are doing is more subversive- they are democratizing the mobile application space. That's the core of the dismay we're hearing from developers- the flip side of their argument (they can't make real apps) is that AJAX apps are somehow fake. This is an echo of the old back end vs. front end non-argument that erupts all over the interactive industry map when web developers meet software engineers.
When all it takes is a copy of Dreamweaver, and O'Reilly book, and some copy and pasted Javascript to make a web app, we will see an explosion of single purpose widgets proudly proclaiming their iPhone compatibility. Most of these will be utter rubbish- and the message boards and ratings on Hotscripts and Versiontracker will serve to banish them into well deserved obscurity. However, some will be gems- as a frequent air traveler and motorcycle rider, I rely on the OS X Dashboard 'Radar In Motion' widget to predict whether I will be delayed or drenched. It is completely immaterial to me that this widget is just an HTML fragment and not a compiled blob of code- it does what I need it to do, elegantly and conveniently.
No matter how many Diggers cry foul, when Jobs stands up at Macworld San Francisco and proclaims that thousands of apps for the iPhone have been developed since launch, no consumer is going to care that they aren't 'real' apps. All they are going to care about is: Does this widget let me do something I couldn't do, or make something easier to do? I firmly believe that all the 'fake' developers need is imagination, insight and focus to supply that user experience, despite the sandbox Apple is making them play in.
Tuesday, June 12, 2007
Not So Smart Phones
As part of my job, I carry a Blackberry, which I use as a mobile phone, an email client, and a web browsing device. It has undeniably benefited my productivity and flexibility- I'm tapping this note as I wait in a train, stopped in a tunnel for some unknown reason- but through my incessant usage I've identified some ways in which it could be enormously improved:
1) Always show the time!
The only screen in which the time is visible is the 'home' screen, which is only visible when I'm either doing nothing, or in the process of selecting an app to launch. Once I'm actually doing something (such as composing this blog post on the train) the current time is hidden, and I would have to save this message as a draft and exit the 'mail' application, or look at my watch- which seems like a brutish workaround for an otherwise advanced piece of technology.
2) Allow sensible multitasking
Multitasking has different demands on a mobile device than a desktop computer- it doesn't make sense to have both your web browser and your email client open at the same time, due to limited screen real estate and the methods of interaction unique to mobile email and web. However, there are times when I wish for at least limited multitasking- mainly when I'm using the Blackberry as a phone. Typically, I'll be gabbing away on the phone and the individual on the other side will ask me about my availability for a meeting, or need some info from an email I've sent or received- and I'll have to apologize, explaining that the info they need is on the device I'm using to speak with them, and that I won't be able to access it until I terminate the call.
This may be a limitation of my current device- a corp-issued Blackberry 7250- my carrier's version of the software, or even myself- there may be a way to swap into another app while I'm talking. If there is, I haven't found it- during a call all I see is a button indicating how to end the call. Being able to look up contacts or access email during a call would be a welcome improvement (and something I seem to recall was possible on my dear departed Sidekick II- but that may just be nostalgia talking).
3) More info about incoming email, please!
Similar to the note above about poor multitasking, I'd like some more informative notification of the content of incoming e-mails.
When I'm tapping away at an email, or browsing the web, new incoming email is denoted by a blinking red light on the device. Urgent messages from my boss get the same treatment as a piece of spam... blink blink blink. If I want to stay on top of incoming emails I need to interrupt my session to view the latest messages.
A brief popup preview, with the subject, sender and first line of text, overlayed on the top of the screen would be extremely helpful. If it's something I want to see, I could 'jog' up and select it to view the full message, or I could 'cancel' to dismiss it if its presence offends me- or I could just wait a few seconds for it to disappear on its own. Either way, I could continue my current task secure in the knowledge that I wasn't missing anything important.
4) Spell check- even a painfully slow one, please!
This entire post was tapped out on my Blackberry- it's how I pass the time on various trains and buses I travel on each day. The email composing software is savvy enough to catch common misspellings- it will automatically correct a transposition in 'their' for instance- but it falls down in both grammar (it won't catch the dropped 'd' in 'peas an carrots') nor will it catch longer manglings, such as 'portotyppe'.
This weak spellchecker is unfortunate, since the cramped ergonomics of the thumboard and the pint sized screen make it more likely that I'm going to commit a typo. I understand that space and processing power are limited on a handheld. How about a function where I can submit my composed email to some online spell checker that then returns it with errors flagged along with a little XML payload that lets me choose from possible guesses? Google and Blogger seem to do a pretty good job with online spell checkers- I'd wait ten seconds for a submit and response if it means a cleaner outgoing email from my Blackberry.
I suspect some or most of these shortcomings will be addressed by upcoming handsets, more purpose built for mobile work (such as the iPhone) and more aware of the challenges and opportunities posed by mobile multitasking. None of my requests require new technology to be developed- they just require some thoughtfulness and good interface design.
1) Always show the time!
The only screen in which the time is visible is the 'home' screen, which is only visible when I'm either doing nothing, or in the process of selecting an app to launch. Once I'm actually doing something (such as composing this blog post on the train) the current time is hidden, and I would have to save this message as a draft and exit the 'mail' application, or look at my watch- which seems like a brutish workaround for an otherwise advanced piece of technology.
2) Allow sensible multitasking
Multitasking has different demands on a mobile device than a desktop computer- it doesn't make sense to have both your web browser and your email client open at the same time, due to limited screen real estate and the methods of interaction unique to mobile email and web. However, there are times when I wish for at least limited multitasking- mainly when I'm using the Blackberry as a phone. Typically, I'll be gabbing away on the phone and the individual on the other side will ask me about my availability for a meeting, or need some info from an email I've sent or received- and I'll have to apologize, explaining that the info they need is on the device I'm using to speak with them, and that I won't be able to access it until I terminate the call.
This may be a limitation of my current device- a corp-issued Blackberry 7250- my carrier's version of the software, or even myself- there may be a way to swap into another app while I'm talking. If there is, I haven't found it- during a call all I see is a button indicating how to end the call. Being able to look up contacts or access email during a call would be a welcome improvement (and something I seem to recall was possible on my dear departed Sidekick II- but that may just be nostalgia talking).
3) More info about incoming email, please!
Similar to the note above about poor multitasking, I'd like some more informative notification of the content of incoming e-mails.
When I'm tapping away at an email, or browsing the web, new incoming email is denoted by a blinking red light on the device. Urgent messages from my boss get the same treatment as a piece of spam... blink blink blink. If I want to stay on top of incoming emails I need to interrupt my session to view the latest messages.
A brief popup preview, with the subject, sender and first line of text, overlayed on the top of the screen would be extremely helpful. If it's something I want to see, I could 'jog' up and select it to view the full message, or I could 'cancel' to dismiss it if its presence offends me- or I could just wait a few seconds for it to disappear on its own. Either way, I could continue my current task secure in the knowledge that I wasn't missing anything important.
4) Spell check- even a painfully slow one, please!
This entire post was tapped out on my Blackberry- it's how I pass the time on various trains and buses I travel on each day. The email composing software is savvy enough to catch common misspellings- it will automatically correct a transposition in 'their' for instance- but it falls down in both grammar (it won't catch the dropped 'd' in 'peas an carrots') nor will it catch longer manglings, such as 'portotyppe'.
This weak spellchecker is unfortunate, since the cramped ergonomics of the thumboard and the pint sized screen make it more likely that I'm going to commit a typo. I understand that space and processing power are limited on a handheld. How about a function where I can submit my composed email to some online spell checker that then returns it with errors flagged along with a little XML payload that lets me choose from possible guesses? Google and Blogger seem to do a pretty good job with online spell checkers- I'd wait ten seconds for a submit and response if it means a cleaner outgoing email from my Blackberry.
I suspect some or most of these shortcomings will be addressed by upcoming handsets, more purpose built for mobile work (such as the iPhone) and more aware of the challenges and opportunities posed by mobile multitasking. None of my requests require new technology to be developed- they just require some thoughtfulness and good interface design.
Monday, June 11, 2007
Information Overload Hacks, part 2
In my last post in this thread, I wrote about a corporate cry for help- the internal '24' campaign at a big-name branding agency, designed to create a sense of urgency around emails and voice messages that reference the numeral '24.'
I by no means blame the individual or organization for succumbing to a social hack to solve the problems of information overload, as the issue they're grappling with affects all of us in the connected world. Fred Wilson went so far as to declare email bankruptcy- the public admission that he could not keep up with the constant flood of emails that trickle in throughout the day.
The root of the problem is not that our society is flawed, or that people are workaholics and send too many emails. I blame email itself- the medium, and the technology that expresses it. Like an aging trolley system in a burgeoning metropolis, email has failed to keep up with the task at hand.
The problem with email is that the presentation obscures the important information. We each receive emails of wildly varying importance and urgency each day, but aside from some incredibly minor interface elements (a tiny '!', or language in the subject line ('URGENT' or, at the company I mentioned, '24'), there is no immediately obvious way to differentiate the noise from the truly important emails.
Instead, you begin to methodically examine each email:
- who is the sender? Is it an important colleague, client or loved one?
- if one of the above, does the subject line reference anything I am especially interested in, or does it de-escalate the message urgency or interest?
- assuming the message passes one of the tests above, you then need to open the email, read and evaluate the contents, and then make a decision- reply? Trash it? Defer it for future action?
While the three steps above are simple in themselves, the true cost comes from the frequency and variability of the action. Making hundreds of such evaluation / decision loops a day would be fairly easy if you were inspecting identical flower pots on an assembly line for defects- the work would become automatic, and you might even describe it as mindless. That's because you would be able to focus on the small set of possibilities in each decision set- is there a crack in the pot? Is the rim malformed?
With corporate email, the scenarios you need to instantly load into local memory, evaluate, and render a decision upon are fairly endless- anything (in my case) from obscure automatically generated emails informing me of a forgotten contractor's building access expiring or some helpdesk in India failing to receive my expense receipts, to cloaked cries for help from a staffer unhappy with their job and their relationship with their coworkers. The danger I find is missing the latter in the flood of the former- but ignoring the 'noise' brings its own risks (I've suffered the wrath of the expense receipts department before, and I dare not repeat).
The constant mental switching is what tires us out and frustrates our desires to find continuity and focus in our daily lives. I hear it all the time when staffers feel like they are being unduly buffeted by administrative or procedural requests- 'I just want to come in, sit down, and do my job.' They (rightly) don't consider the constant peppering of emails from all points of the compass to be part of their core duties, and they fear it endangers their ability to succeed at what they were hired for.
Ok, I promised a solution in the last post, and I'll deliver- I think the problem can be mitigated by rethinking what e-mail is, and how email clients work. Obviously, changing a piece of software is not going to alter patterns of behavior that have emerged as part of the information economy, but it will prevent email from taking a bad problem and making it much, much worse.
The core of the problem lies in email's weak answer to the question of importance sorting- the current framework puts the onus on the sender to indicate importance to the receiver. How in the heck is someone external to me, possibly by thousands of miles and several organizational rat mazes away, supposed to know what I'm most concerned about in any given moment?
Email, and all similar messaging, must change to be more user centered- to be more aware of the context in which the receiver is evaluating the messages. It must give the user control- not to sort, delete, or search emails, that stuff has already been developed within its limitations. Email must evolve to the next stage, where it becomes a partner to help you understand and evaluate the incoming information, and provide clarity and control over your precious decision making time and mental bandwidth.
In my third and final post on this topic, I'll outline what a next generation email application that performs these functions might look like, and what it's going to take to get us there.
I by no means blame the individual or organization for succumbing to a social hack to solve the problems of information overload, as the issue they're grappling with affects all of us in the connected world. Fred Wilson went so far as to declare email bankruptcy- the public admission that he could not keep up with the constant flood of emails that trickle in throughout the day.
The root of the problem is not that our society is flawed, or that people are workaholics and send too many emails. I blame email itself- the medium, and the technology that expresses it. Like an aging trolley system in a burgeoning metropolis, email has failed to keep up with the task at hand.
The problem with email is that the presentation obscures the important information. We each receive emails of wildly varying importance and urgency each day, but aside from some incredibly minor interface elements (a tiny '!', or language in the subject line ('URGENT' or, at the company I mentioned, '24'), there is no immediately obvious way to differentiate the noise from the truly important emails.
Instead, you begin to methodically examine each email:
- who is the sender? Is it an important colleague, client or loved one?
- if one of the above, does the subject line reference anything I am especially interested in, or does it de-escalate the message urgency or interest?
- assuming the message passes one of the tests above, you then need to open the email, read and evaluate the contents, and then make a decision- reply? Trash it? Defer it for future action?
While the three steps above are simple in themselves, the true cost comes from the frequency and variability of the action. Making hundreds of such evaluation / decision loops a day would be fairly easy if you were inspecting identical flower pots on an assembly line for defects- the work would become automatic, and you might even describe it as mindless. That's because you would be able to focus on the small set of possibilities in each decision set- is there a crack in the pot? Is the rim malformed?
With corporate email, the scenarios you need to instantly load into local memory, evaluate, and render a decision upon are fairly endless- anything (in my case) from obscure automatically generated emails informing me of a forgotten contractor's building access expiring or some helpdesk in India failing to receive my expense receipts, to cloaked cries for help from a staffer unhappy with their job and their relationship with their coworkers. The danger I find is missing the latter in the flood of the former- but ignoring the 'noise' brings its own risks (I've suffered the wrath of the expense receipts department before, and I dare not repeat).
The constant mental switching is what tires us out and frustrates our desires to find continuity and focus in our daily lives. I hear it all the time when staffers feel like they are being unduly buffeted by administrative or procedural requests- 'I just want to come in, sit down, and do my job.' They (rightly) don't consider the constant peppering of emails from all points of the compass to be part of their core duties, and they fear it endangers their ability to succeed at what they were hired for.
Ok, I promised a solution in the last post, and I'll deliver- I think the problem can be mitigated by rethinking what e-mail is, and how email clients work. Obviously, changing a piece of software is not going to alter patterns of behavior that have emerged as part of the information economy, but it will prevent email from taking a bad problem and making it much, much worse.
The core of the problem lies in email's weak answer to the question of importance sorting- the current framework puts the onus on the sender to indicate importance to the receiver. How in the heck is someone external to me, possibly by thousands of miles and several organizational rat mazes away, supposed to know what I'm most concerned about in any given moment?
Email, and all similar messaging, must change to be more user centered- to be more aware of the context in which the receiver is evaluating the messages. It must give the user control- not to sort, delete, or search emails, that stuff has already been developed within its limitations. Email must evolve to the next stage, where it becomes a partner to help you understand and evaluate the incoming information, and provide clarity and control over your precious decision making time and mental bandwidth.
In my third and final post on this topic, I'll outline what a next generation email application that performs these functions might look like, and what it's going to take to get us there.
Wednesday, June 6, 2007
Beta: The 'Under Construction' of the Aughts
Does anyone remember this icon?
It was the image you placed on your website back in the '90s to signify that you weren't quite done with the page, and that the viewer should pardon any poor table alignments, or groovy background images that didn't tile correctly, or perhaps your accidental wrapping of the entire site text in an unfortunate
The usage of these icons faded away once web designers clued up a little, and realized that the best web pages were continually evolving- and that you did no one a favor (most of all, yourself) by pointing out the deficiencies of your creation.
Fast forward to the present, and we have the concept of 'Beta.' Slapping a Beta tag on your otherwise open and functional site signifies that you're not quite done with your app, and that the user should pardon wonky CSS, or a Flash movie that doesn't quite play right, or the bad Ajax that makes your text every time the user moves their mouse.
Today, I sat in a room of interactive professionals helping to conceive of a next generation user experience around media consumption, and I challenged them to live without the Beta crutch. If we're going to have a Beta, let it be a real one- with a closed, limited group of beta testers, who are tasked with running the site through its paces and reporting on any last minute tweaks and fixes that need to be made.
I think Beta goes both ways- it can be an excuse for limited or half-baked functions, but I bet it sometimes appears when the site owners want the aroma of a fast-paced, innovative release cycle, rather than a cautious, test-until-it-works old school model.
My advice to would be Beta launchers: If it's just a launch where you didn't get everything in there that you wanted, call that version 1 and pick up version 2 where you left off.
Tuesday, June 5, 2007
With The Spinning Blades, and the Screaming...
Seen on the Captivate elevator screen this morning:
"Lawn mower accidents- all of them preventable- send 9,400 kids to emergency rooms each year."
OK, so I understand the point of putting 'preventable' in the sentence, to increase the senselessness of the carnage. However, doesn't it beg the question of what an unpreventable lawn mover accident looks like?
"We were walking on the beach... nowhere NEAR a lawn... when the mower emerged from the waves and bolted up the sand, shredding sunbathers left and right! We tried to run, but it happened so fast- there was no way this could have been prevented!"
"Lawn mower accidents- all of them preventable- send 9,400 kids to emergency rooms each year."
OK, so I understand the point of putting 'preventable' in the sentence, to increase the senselessness of the carnage. However, doesn't it beg the question of what an unpreventable lawn mover accident looks like?
"We were walking on the beach... nowhere NEAR a lawn... when the mower emerged from the waves and bolted up the sand, shredding sunbathers left and right! We tried to run, but it happened so fast- there was no way this could have been prevented!"
Information Overload Hacks
I had a meeting at a big-name branding agency today, and saw something that reminded me how much work we user experience professionals still have to do to make technology really useful for humans.
It was a poster on the bathroom door, with a giant numerals '24' on it. The text of the poster outlined the new office wide '24' initiative- any message (email or voice) that referenced '24' in the subject or body was to be acted upon, responded to, and satisfactorily resolved in 24 hours.
This amused, saddened, and enlightened me all at the same time. It perfectly illustrates how humans make up for deficiencies in applications by hacking around them out of desperation.
Doesn't just about every email system have a method to mark an email 'Urgent?' I can only assume that so many people marked emails 'urgent,' that eventually that function lost its meaning. I bet at that point, users started to add the word 'URGENT' in all caps to messages, until that method was likewise ignored.
Somewhere, someone dropped the ball after ignoring too many 'URGENT' emails, and an operations lead decided the way to reset the urgency meter was to introduce a novel way of indicating something is 'urgent,' some way that people had not yet developed an immunity to, and then reinforcing it with a company wide awareness program using official posters to impress the seriousness of the 24 initiative.
I can just imagine that the overloaded office drones, informed via poster of their misbehavior and the new top down initiative to correct it, began to immediately subvert the system with messages like:
24- lunch plans
Hey, what are you doing for lunch today? 24.
- since that is obviously a question that must be answered well within 24 hours, otherwise it's hopelessly out of date.
The effectiveness of this policy will be directly proportional to its enforcement. Will the first person to take 26 hours to reply lose their job?
Next post in this thread: attacking the root of the '24' problem.
It was a poster on the bathroom door, with a giant numerals '24' on it. The text of the poster outlined the new office wide '24' initiative- any message (email or voice) that referenced '24' in the subject or body was to be acted upon, responded to, and satisfactorily resolved in 24 hours.
This amused, saddened, and enlightened me all at the same time. It perfectly illustrates how humans make up for deficiencies in applications by hacking around them out of desperation.
Doesn't just about every email system have a method to mark an email 'Urgent?' I can only assume that so many people marked emails 'urgent,' that eventually that function lost its meaning. I bet at that point, users started to add the word 'URGENT' in all caps to messages, until that method was likewise ignored.
Somewhere, someone dropped the ball after ignoring too many 'URGENT' emails, and an operations lead decided the way to reset the urgency meter was to introduce a novel way of indicating something is 'urgent,' some way that people had not yet developed an immunity to, and then reinforcing it with a company wide awareness program using official posters to impress the seriousness of the 24 initiative.
I can just imagine that the overloaded office drones, informed via poster of their misbehavior and the new top down initiative to correct it, began to immediately subvert the system with messages like:
24- lunch plans
Hey, what are you doing for lunch today? 24.
- since that is obviously a question that must be answered well within 24 hours, otherwise it's hopelessly out of date.
The effectiveness of this policy will be directly proportional to its enforcement. Will the first person to take 26 hours to reply lose their job?
Next post in this thread: attacking the root of the '24' problem.
Subscribe to:
Posts (Atom)