Posting from Blogpress worked. Now trying it with a photo...
Tuesday, June 23, 2009
Thursday, May 14, 2009
What are Social Networks Good For? How about Saving the Internet
Twitter is inanity, 140 characters at a time. Facebook is the world's most engaging and least profitable website, spending millions of dollars a minute so that people can bore each other with baby pictures. MySpace, already written off by the digital elite, is the lowest common denominator of online interaction, the cheesy strip mall of social experiences.
These are not necessarily my opinion- I'm condensing common criticisms, a distillation of the chatter these brands elicit on the web. However, I have recently begun to think that this activity, so far mostly untapped by frustrated marketers who are looking for a linear return on their ad spending, is what will ultimately redeem the interactive medium and fulfill the promise of this new platform.
Here's why: Trust is at the heart of all successful human transactions.
In an environment of password phishing, Nigerian scammers, Craigslist killers, and doing it for the lulz, we're going to need a way to measure our trust in those we interact with online.
Social networking sites, tools, and services bring a level of transparency, familiarity, and insight to those we choose to interact with. Thanks to his Twitter feed, I know know more about Rainn Wilson's family than I do the family two doors down on my actual street.
Facebook's worldwide membership numbers are approaching the total US population. Twitter's growth keeps accelerating, and LinkedIn has settled comfortably into the professional social networking space. I foresee a time when the average user will refuse to accept email or interact with an online entity that is not socially connected to them somehow, however tenuously, through the 'web of trust' they've constructed on these networks.
Who knows... if I make some friends in Nigeria, maybe I will actually encounter a deposed prince who needs my help in recovering his millions...
Monday, September 1, 2008
Google: Great Web App builders, awful Web Comic publishers
I haven't had an opportunity to use Google's Chrome browser yet, so I'll reserve my opinion on its user experience enhancements until I do. However, I have had an opportunity to read the web comic that Google posted outlining the new features and philosophy behind Chrome. One thing I am able to conclusively say to Google- as far as publishing Web comics goes, don't quit your day job.
Google recruited Scott McCloud, the creator behind the excellent Understanding Comics and its followups, Reinventing Comics and Making Comics. These books really drill down into the essential truths behind what drives the comic book medium on paper, and how it can successfully make the transition to new platforms and distribution methods. Check out this neat web comic that uses an innovative method of inter-panel navigation; it's the closest thing I've seen on the web to simulating the peripheral 'clues' you get from reading a printed page panel-to-panel. This comic does everything right, from screen friendly formatting to an easy to navigate and informative index below the panels:
That's why I was so surprised that the Google Chrome comic suffers from utterly awful usability. In a nutshell:
- The pages are formatted like a printed comic- in a taller, rather than wider (also referred to as 'portrait' vs. 'landscape') orientation. That means that every page is a scroll, even on my 23" HD monitor.
- The navigation is on the very bottom of each page- two Javascript links that go forward, or back. No index or method for jumping to the very beginning, or end- if you're on the last page (38), and want to go back to page 6, you're either hitting 'back' 32 times or starting over from the original link.
- The pages themselves are flat jpeg images, with zero semantic information about the content on the pages. Ironically, Google's own search engine would pretty much utterly disregard these pages, with no textual information about the content and Javascript links its browser would ignore.
I paged through this web comic in utter disbelief- how could Scott McCloud, the paragon of exploring new and innovative methods in creating comics for the online medium, have contributed to such a mess?
The answer is on Scott's site, in an apparently hastily assembled page* linked from his homepage. The comic itself was designed and drawn as a printed piece, intended to be sent to journalists and bloggers as part of the announcement. When the mailing went out earlier than intended, scanned copies of the comic began to appear online. In response to the demand, Google apparently slapped their own hastily assembled Web version up - access was more important than accuracy and craft, in this case.
However, this begs the question- if you're creating a piece of documentation intending to communicate the benefits and thinking behind a new way to browse the Web, shouldn't you anticipate that it will be consumed on the web at some point? And as such, shouldn't you prep a Web version well in advance of an announcement that will, inherently, break on the Web in the first place?
At least it ends up being a program management and product marketing failure rather than an unbelievable gaffe on the part of one of the creators I admire most. I'm sure Scott is cringing ten times as much as I am as he pages through his most visible Web comic to date, and is probably furiously pushing pixels to fix it right now.
In the meantime, I'll leave you with my favorite panel from the work- there's just so much right with the intentional wrongness of this panel- it could be a whole blog post on its own.
*I assume it's a quick reaction to the breaking news because, as of this writing, the title is incorrect - it reads 'Zot! The Complete Black and White Collection' rather than anything to do with Google - and none of the links on the global nav work. Based on the attention this site and comic is getting, it will probably be fixed by the time you read this.
Tuesday, August 12, 2008
Eyes On The Road, Pal
Last week, while traveling for business, I ended up with a rental Hyundai Sonata. While slogging through LA freeway traffic, I adjusted the preprogrammed radio stations to my liking. I then checked to see if there were steering wheel mounted controls, so I could scan the stations and adjust volume without taking my eyes off the road.
Well, yes on one count. The Hyundai did have steering wheel mounted audio controls, but in a curious configuration:
What struck me as odd was that the volume controls were tucked away behind the main face of the steering wheel, while the station controls where on the front. I actually had to duck my head and peer behind the steering wheel to determine the placement and functions of the buttons. Once I sussed out where the buttons were located, I had to modify my grip on the steering wheel to reach them, extending my fingers out as if I was holding a phantom soda can in my left hand. This was uncomfortable and made me effectively steer one-handed.
Contrast this with the button placement on my wife's Honda minivan:
The buttons are all right up front, no neck craning or awkward peering necessary. Additionally, they can all be easily manipulated by my thumb while my left hand is in the normal '10 o'clock' steering grip position.
I can only imagine that the Hyundai designer was trying for something 'neat,' both in terms of visual presentation on the front of the wheel and in terms of functional gimmickry, trying to be different for the sake of being different. The end result is a lack of what I call contextual awareness for the controls.
If this were some trick looking iPod dock, meant to sit on a bookshelf or mantle and exude sleekness, I could forgive odd or non-standard button placement- once you learn where the buttons are, it's not that much more difficult to use it. However, the context of steering wheel mounted audio controls is completely different- not only is the user in a situation where their attention is probably more divided than usual, but they are actually impaired in their ability to perform one of the main functions of the vehicle- steering it clear of obstacles - while using the control. Taken to the absurd extreme, the Hyundai controls could actually contribute to your demise as you fumble and peer for the proper controls.
I highlight this real world example to draw a parallel with controls or input methods in online applications that similarly fail to understand the context of their use. Typically, non-context aware controls on the Web don't lead to a shower of glass shards and an airbag deployment, but they sure can put a dent in the enjoyment of your trip. You've experienced them- usually when you're undertaking some sort of task and you're stopped dead in your tracks, trying to figure out what the web page wants from you to continue.
Some common examples:
• Dropdowns to set data more easily entered as text, such as an event time in a calendar application, or worse- year of birth, with a dropdown listing years from 1945 to the present (I've seen that a few times, sadly). This is typically the result of a desire to limit the possibility for mistakes on data entry, but it shifts the burden to the user when errors could just as easily be checked and trapped in the background in many cases.
• Popups (such as calendars) that set data on the main page. Again, this strikes me as lazy programming - if you want to provide a piece of function that will take up an inordinate amount of space on the page when not being used, there's better ways to manage that than by banishing it to a popup. By moving a control function out of the flow of the page, you introduce ambiguity about what action to take next, and increase the possibility of errors.
• Unnecessarily deep drop-down menu trees. In a misguided attempt to mimic some desktop apps, I've seen web apps that offer three and four level deep dropdown menus for navigation. Typically, your mouse needs to follow an extremely narrow and precise path along those menus to prevent them from popping off and leaving you where you started. I invariably abandon the tightrope act and try and find another means to reach the subpage. In one case, I actually had to view the source of the javascript that generated the menus to pull out the URL I needed when I couldn't manage to thread the correct path.
These are just three of many similarly annoying web gadgets that fail to understand the context of most online applications: to allow you to complete a task or to obtain information as quickly and easily as possible. Forgetting, or worse, flouting that goal is what leads to high bail rates and low stickyness. Are those things worth showing off your neat Flash drag-and-drop skillz on your main site navigation? About as worth it as a car crash when you're trying to find a decent station while driving.
Well, yes on one count. The Hyundai did have steering wheel mounted audio controls, but in a curious configuration:
What struck me as odd was that the volume controls were tucked away behind the main face of the steering wheel, while the station controls where on the front. I actually had to duck my head and peer behind the steering wheel to determine the placement and functions of the buttons. Once I sussed out where the buttons were located, I had to modify my grip on the steering wheel to reach them, extending my fingers out as if I was holding a phantom soda can in my left hand. This was uncomfortable and made me effectively steer one-handed.
Contrast this with the button placement on my wife's Honda minivan:
The buttons are all right up front, no neck craning or awkward peering necessary. Additionally, they can all be easily manipulated by my thumb while my left hand is in the normal '10 o'clock' steering grip position.
I can only imagine that the Hyundai designer was trying for something 'neat,' both in terms of visual presentation on the front of the wheel and in terms of functional gimmickry, trying to be different for the sake of being different. The end result is a lack of what I call contextual awareness for the controls.
If this were some trick looking iPod dock, meant to sit on a bookshelf or mantle and exude sleekness, I could forgive odd or non-standard button placement- once you learn where the buttons are, it's not that much more difficult to use it. However, the context of steering wheel mounted audio controls is completely different- not only is the user in a situation where their attention is probably more divided than usual, but they are actually impaired in their ability to perform one of the main functions of the vehicle- steering it clear of obstacles - while using the control. Taken to the absurd extreme, the Hyundai controls could actually contribute to your demise as you fumble and peer for the proper controls.
I highlight this real world example to draw a parallel with controls or input methods in online applications that similarly fail to understand the context of their use. Typically, non-context aware controls on the Web don't lead to a shower of glass shards and an airbag deployment, but they sure can put a dent in the enjoyment of your trip. You've experienced them- usually when you're undertaking some sort of task and you're stopped dead in your tracks, trying to figure out what the web page wants from you to continue.
Some common examples:
• Dropdowns to set data more easily entered as text, such as an event time in a calendar application, or worse- year of birth, with a dropdown listing years from 1945 to the present (I've seen that a few times, sadly). This is typically the result of a desire to limit the possibility for mistakes on data entry, but it shifts the burden to the user when errors could just as easily be checked and trapped in the background in many cases.
• Popups (such as calendars) that set data on the main page. Again, this strikes me as lazy programming - if you want to provide a piece of function that will take up an inordinate amount of space on the page when not being used, there's better ways to manage that than by banishing it to a popup. By moving a control function out of the flow of the page, you introduce ambiguity about what action to take next, and increase the possibility of errors.
• Unnecessarily deep drop-down menu trees. In a misguided attempt to mimic some desktop apps, I've seen web apps that offer three and four level deep dropdown menus for navigation. Typically, your mouse needs to follow an extremely narrow and precise path along those menus to prevent them from popping off and leaving you where you started. I invariably abandon the tightrope act and try and find another means to reach the subpage. In one case, I actually had to view the source of the javascript that generated the menus to pull out the URL I needed when I couldn't manage to thread the correct path.
These are just three of many similarly annoying web gadgets that fail to understand the context of most online applications: to allow you to complete a task or to obtain information as quickly and easily as possible. Forgetting, or worse, flouting that goal is what leads to high bail rates and low stickyness. Are those things worth showing off your neat Flash drag-and-drop skillz on your main site navigation? About as worth it as a car crash when you're trying to find a decent station while driving.
Thursday, August 7, 2008
Per iPhone: Google is a Verb
Although the Oxford English Dictionary has already decreed that the term Google is a verb, a more culturally relevant institution - the iPhone - has resoundingly confirmed it.
Here's the search screen from the iPhone's implementation of Safari:
Once you've entered your search term, you're invited (by the active, blue button on the lower right) to Google it.
I'm now searching the rest of the iPhone interface for definitive answers on energy independence, gay marriage, and the nature of free will - I will post those revelations as they emerge.
Here's the search screen from the iPhone's implementation of Safari:
Once you've entered your search term, you're invited (by the active, blue button on the lower right) to Google it.
I'm now searching the rest of the iPhone interface for definitive answers on energy independence, gay marriage, and the nature of free will - I will post those revelations as they emerge.
Tuesday, July 1, 2008
Google to index Flash - and why this is a non-announcement
There's a lot of buzz about today's announcement about Google's improved Flash indexing.
For those of you not obsessed with Flash or SEO, the reason this post is getting so much attention is simple: previously, Google's crawlers were unable to index text within Flash movies. Since quite a bit of content (on entertainment sites, especially) is locked up in Flash, a lot of stuff wasn't discoverable via search.
On the face of it, this is a huge boon for those sites that publish interesting content in Flash (like AOL's photo galleries). However, if you read deeper into the Google blog post, you'll see there are two deal breakers for most modern Flash sites.
The first: the crawler will not index Flash that is embedded in the page via Javascript. To avoid the IE ActiveX 'click to activate' security feature, the vast majority of Flash movies published by professional outfits are written into the page via Javascript. Thus, few of them will be indexed.
The second: The crawler will not index externally loaded SWFs or XML. The vast majority of Flash movies published by professional outfits load external information as SWFs or XML. The crawler will follow links to those items and index them separately, but that's fairly useless for the goal of increasing the relevance of the main page.
About all this will effect are designer and photographer portfolio websites, which generally have hardcoded text content. Not exactly an Earth-shattering move for the rest of the Flash-using web.
For those of you not obsessed with Flash or SEO, the reason this post is getting so much attention is simple: previously, Google's crawlers were unable to index text within Flash movies. Since quite a bit of content (on entertainment sites, especially) is locked up in Flash, a lot of stuff wasn't discoverable via search.
On the face of it, this is a huge boon for those sites that publish interesting content in Flash (like AOL's photo galleries). However, if you read deeper into the Google blog post, you'll see there are two deal breakers for most modern Flash sites.
The first: the crawler will not index Flash that is embedded in the page via Javascript. To avoid the IE ActiveX 'click to activate' security feature, the vast majority of Flash movies published by professional outfits are written into the page via Javascript. Thus, few of them will be indexed.
The second: The crawler will not index externally loaded SWFs or XML. The vast majority of Flash movies published by professional outfits load external information as SWFs or XML. The crawler will follow links to those items and index them separately, but that's fairly useless for the goal of increasing the relevance of the main page.
About all this will effect are designer and photographer portfolio websites, which generally have hardcoded text content. Not exactly an Earth-shattering move for the rest of the Flash-using web.
Subscribe to:
Posts (Atom)
