From the Unimportance of Competition to Complex Emotions

Posted on July 2, 2010 by Jeremy Horn

Every week I read thousands of blog posts. For your weekend enjoyment, here are some of those highlights. What are you reading this weekend?

Have a great weekend!

Jeremy Horn
The Product Guy

Facebook PDQ

Posted on February 15, 2010 by Jeremy Horn

A company can have the best product around, but if the pages are too sluggish, if the product suffers recurring outages, if the user-product interaction is varied and inconsistent, the product’s overall Usability can, and does, suffer.

Quick-UX provides for the rapid, simple and quantifiable assessment of a product’s User Experience (UX). Among the various components that define a product’s Usability, as well as Quick-UX‘s, are Accessibility, Consistency, Recognition, Navigation, and Page Load Time.

In answering the question of Usability, "Can I use it?" the sub-category of Page Load plays an instrumental role. Page Load, often obfuscated or connected with other perceived causes of a product’s dissatisfaction, ultimately, either positively or negatively, presents an unquestionable influence on a product’s overall Usability.

Example: Prompt Load Time (value = 1.0)

When I recently twittered my followers asking for their opinion of a web product that best exemplified a Prompt Load Time, some of the most common responses were…

WordPress and
Basecamp.

But, the product that received the most votes was Facebook.

Facebook is not only a good example of a product with a Quick-UX Usability Page Load Time variable value of 1.0, Prompt Load Time, but also a wonderful example of improvement along the same lines.

Amazingly, as recently as January 2008, Facebook was seen as one of the slowest, most inaccessible social networking products.

Now, Facebook, is one of the promptest, fastest web products, with 350 million active users, 50% of which log on every day, with the average user spending 55 minutes interacting with the product.

Whatever part of the product with which the user chooses to interact, the end result is always and consistently the same… quick reaction and responsiveness – from visiting and interacting with one’s Inbox…

… to participating in conversations in the News Feed.

Should Do

With all the positive efforts being taken, some ‘flourishes’ of the user interface continue to inject a sluggishness into an overall snappy Page Load Time and user experience that would best be redesigned or redeveloped inline with the rest of the product’s established Page Load Time expectations. An example of such an interface event, with sluggishness caused by either the method of display, and/or of content retrieval, is the user action of adding a friend.

If a recent interview with an anonymous Facebook employee is accurate, Facebook can be viewed as being very much on the right track to further improvement of their already Prompt Load Time.

On the continued optimization of downloaded file size and its client-side performance…

"…actually found out it increased the number of page views by 77%, essentially because we were reducing 77% of the page load, and therefore it was loading faster, and thus generating more clicks. We not only reduced our bandwidth, and how much we have to pay for our Internet, but we made the site faster and increased the clicks-per-minute, which is what we’re truly interested in."

On the optimization of server responsiveness…

"…this guy right now is single-handedly rewriting, essentially, the entire site. Our site is coded, I’d say, 90% in PHP. All the front end — everything you see — is generated via a language called PHP. He is creating HPHP, Hyper-PHP, which means he’s literally rewriting the entire language.

"We’re going to reduce our CPU usage on our servers by 80%, so practically, users will just see this as a faster site. Pages will load in one fifth of the time that they used to."

Next…

Over the course of this series we explored many real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Subscribe now (click here) to make sure you don’t miss any part of exploration of Quick-UX, the quick and easy method of generating quantifiable and comparable metrics representing the understanding of the overall User Experience of a product, as well as other insightful posts from The Product Guy.

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

Slow Paced Conversation Pieces

Posted on February 8, 2010 by Jeremy Horn

Example: Delayed Load Time (value = 0.5)

Conversation Pieces is a web product that provides an online venue from which indie designers can sell their creations. This product has also earned a Quick-UX Page Load Time variable value of 0.5, Delayed Load Time.

According to a report that Akamai released in 2009…

40% of consumers abandon the site after 3 seconds of load time

23% of consumers stop shopping due to long page loading time

These are 2 concerns that Conversation Pieces would be well served to pay attention to.

Store, Set Up

Bandwidth utilization resulting from the speed of the product’s server(s) plays a critical role in the understanding, and consumer’s perception, of a product’s Page Load Time. However, Page Load Time, the Quick-UX variable, is a quantification of the perceived time it takes to load the page, content, or complete an action. If the product’s page downloads everything in 100ms, but does not show anything to the user for 5, 10, or more seconds, then the page has a Page Load Time problem.

As far as bandwidth utilization is concerned, going beyond the basic hardware of the servers…

unoptimized images
Resizing the used images, reducing the number of colors used, and selecting the proper compression algorithms (GIF, PNG, JPG), can have a tremendous impact on the final file size delivered to the consumer.

uncompressed files
Using products like YUI Compressor or Google Compile on files containing the likes of JavaScript and CSS can remove whitespace and restructure your underlying code to be compact and small in file size.

no HTTP compression
Compressing HTTP requests and responses are very common on many servers and typically demonstrate as much as a 70% reduction in response size, a.k.a. the files the consumer is receiving via their browser. note: depending on your server setup there may be CPU overhead

uncombined files
The more file requests that are made, the more overhead that is involved in the process, and the slower the Page Load Time. Various methods can be used to reduce the files, from using sprites to combine many images into one, to concatenating CSS and JavaScript files.

… all use up unnecessary bandwidth, resulting in superfluous seconds wasted in Page Load Time. Some more best practices to optimizing Page Load Time can be found at http://developer.yahoo.com/performance/rules.html .

Minding the Store

The Conversation Pieces product exhibits occasional, inconsistent delays, everywhere from the initial home page load to the display of various purchasable content .

These delays are most likely caused by the way the Flash and the caching of images has been coded. The resulting experience created is a very real concern in the product’s Usability, with the consumer sometimes waiting, sometimes instantly getting what was requested, with no apparent pattern to the behavior.

Such inconsistency of Page Load Time does more than wreak havoc within the online shopping experience. Beyond the impact on the product’s Usability, there is enough inconsistency present to assuredly have an impact on the actual pocketbook of the company; resulting from consumers leaving to go elsewhere, to a more stable, more consistently usable website.

Should Do

Perceived page load time is the ‘real’ Page Load Time as far as the consumer is concerned. With that in mind, specific steps can be taken to improve the Page Load Time of the Conversation Pieces product.

Focus the product on providing content in manners empowering the rapid actions and decisions of its consumers.
Whether sticking with a full Flash web product, or not, further optimize the dynamically loaded images and perform smarter caching and, especially, preloading of content with better user feedback as to what is actually going on, e.g. image X of Y loaded, W% loaded, Q time remaining.
A good deal of what can be accomplished in Flash can be done in a much more lightweight and prompt fashion via the latest techniques of HTML and JavaScript. With the availability of very powerful JavaScript libraries (MooTools, YUI, jQuery, …) companies are hard pressed nowadays to justify the absolute requirement of Flash over that of HTML.

Next…

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Subscribe now (click here) to make sure you don’t miss any part of this series exploring the Usability and Page Load Time of Quick-UX, the quick and easy method of generating quantifiable and comparable metrics representing the understanding of the overall User Experience of a product, as well as other insightful posts from The Product Guy.

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

Twine Tied Up in Load Time

Posted on January 25, 2010 by Jeremy Horn

Example: Poor Load Time (value = 0.0)

Based on a recent study commissioned by Akamai…

2 seconds = Page Load Time when customers become impatient

Twine is a web product that goes beyond the basic user contributed content model of more familiar sites, like Digg and Mixx, and performs semantic analysis on your contributed content and interests to help identify both related content, as well as additional information of potential interest to each active user.

I have been a user of Twine since being accepted into the early Beta. Beginning with my initial interaction with the product, and despite the evolutions of the user interface, it is apparent that the product’s Usability has been degrading over time — most notably in the department of Page Load Time, earning Twine a Page Load Time variable value of 0.

From the inability to login due to page timeouts…

… to the incredible unresponsive (or barely responsive) interfaces…

10+ seconds later

… Page Load Time is a present and seemingly growing issue of Usability with this product.

One set of interactions, experienced in December 2009, best exemplify the negative impact on Usability of this product experienced due to Poor Load Time. In addition to sluggish interface interactions, for example when expanding the ‘related people,’ that would leave all but the most patient of patient people to conclude the product was merely unusable/broken, was the common and (hopefully) trivial task of accepting a friend request.

From the time starting with clicking the link within the email to accept or check out the friend request, to finally accepting, many minutes of delays and frustration transpired. For every click on the inbox, every time, every action involved in the process, 3-5 seconds was spent waiting, locked in a frozen state, unable to use the product in another way, locked into the current glacial path, of click, wait, click, wait, click, wait…etc.

While the Twine product does have its good moments and days, performing lickety split, the Page Load Time experience is one of (increasingly) frequent and long delays as well as the inability to access and load content.

Should Do

In addition to a basic focus on reliability and duration of Page Load Time, there are other improvements that a product, such as Twine, would benefit…

For the times where delay is unavoidable…
- provide better user feedback to better align the user expectations of time remaining — e.g. progress bars instead of endlessly spinning wheels, clear messaging of server timeouts and delays instead of generic ‘unable to login’ messages
- allow for the asynchronous performing of actions within the product, so that while one action processes, other actions, by the user, can be taken and content explored

Next…

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

Twitter’s Crawl

Posted on January 17, 2010 by Jeremy Horn

Example: Poor Load Time (value = 0.0)

Twitter is fast becoming, and for some already is, an essential communication tool.

Yet, Twitter earns a Page Load Time variable value of 0, due to its intermittent slow performance, but more so contributing to this value are the constant outages felt through the year, month after month.

If the page doesn’t load, if requested action takes an interminable amount of time, if the likelihood of the next user action failing is constantly looming, the overall Usability of a product takes a terrible toll.

In 2009, according to Pingdom, Twitter experienced a total of 20.82 hours of downtime.

Outages of Twitter were not isolated to merely the entire site being unavailable, but also consisted of sub-sections, or sub-features not working or resulting undesirable or unexpected behavior. Contributing to the pervasive problem of Page Load Time is both the inaccessibility of the product as well as the inability of the users to obtain key information (missing updates, etc) and other bugs leading to incomplete or otherwise incorrect Page Loads.

A Quick Study

I quickly examined and compiled a list of incidents that affected the Page Load Time of the Twitter product, distinguishing between total downtime, and partial downtime and information inaccessibility, based upon the public posts on Twitters blog.

http://status.twitter.com/archive

I did my best to not double count any problems, but it was difficult since many of the problems occur so frequently, and it is often difficult to distinguish, from these status blog posts alone, between a persisting problem being experienced or fixed, from that of a new emergence of a similar or same problem. Furthermore, I also excluded the impact on Page Load Time arising from scheduled maintenance/downtime – periods of time over which the user expectation would be most aligned with the product’s promise of Page Load Time.

Some of my notes regarding my review of Twitter’s 2009 product Page Load Issues…

Dec 17	Site Outage	DNS records compromised	http://status.twitter.com/post/288586541/working-on-site-outage
Dec 14	sms service unavailable		http://status.twitter.com/post/283934158/sms-service-temporarily-unavailable-we-are-working-on
Dec 8	unplanned downtime		http://status.twitter.com/post/275824585/responding-to-unscheduled-downtime
Dec 7	unplanned downtime		http://status.twitter.com/post/273515629/brief-downtime
Dec 6	high rate of failwhales		http://status.twitter.com/post/272315876/responding-to-whales

Nov 30	Unplanned downtime	high error rate; tmp disabled list feature	http://status.twitter.com/post/263867698/responding-to-high-error-rate-lists-feature
Nov 23	elevated error rate		http://status.twitter.com/post/254725789/fixing-elevated-error-rate-on-twitter-com
Nov 11	high number of errors		http://status.twitter.com/post/240542434/working-on-high-number-of-errors
Nov 6	elevated errors		http://status.twitter.com/post/235296654/were-looking-into-the-cause-of-elevated-errors-on-the

Oct 21	elevated error rate	http://status.twitter.com/post/219264090/elevated-error-rate-being-worked-on
Oct 18	network connectivity problems	http://status.twitter.com/post/216351172/responding-to-network-connectivity-problems
Oct 13	account lockouts after username/pw change	http://status.twitter.com/post/212318608/researching-username-password-change-problems
Oct 12	errors and inability to tweet	http://status.twitter.com/post/211258987/responding-to-increased-errors-inability-to-tweet
Oct 7	Unplanned downtime	http://status.twitter.com/post/207018761/recovering-from-unplanned-downtime

Sept 10	site slowness		http://status.twitter.com/post/185079863/working-through-site-slowness
Sept 9	secure connection failed issues		http://status.twitter.com/post/183975122/secure-connection-failed-issues

August 24	unexpected service interruption		http://status.twitter.com/post/170695014/we-are-responding-to-an-unexpected-service-interruption
August 16	Oauth and API problems		http://status.twitter.com/post/164410057/trouble-with-oauth-and-api-clients
August 15	unexpected downtime		http://status.twitter.com/post/163603406/working-on-unexpected-downtime
August 11	Site outage		http://status.twitter.com/post/160693237/responding-to-site-downtime
August 6	Site is down	DOS attack	http://status.twitter.com/post/157160617/site-is-down http://status.twitter.com/post/157191978/ongoing-denial-of-service-attackhttp://status.twitter.com/post/157191978/ongoing-denial-of-service-attack
August 2	Search Down	problem coming from migrating data centers	http://status.twitter.com/post/44516325/twitter-search-temporarily-down

July 10	site latency	widespread	http://status.twitter.com/post/139238308/working-on-site-latency
July 5	restoring accidentially suspended accounts		http://status.twitter.com/post/136164828/restoring-accidentally-suspended-accounts

June 15

Outage

problem w/ maintenance by provider

http://status.twitter.com/post/124145031/maintenance-window-tonight-9-45p-pacific

May 30	unscheduled downtime	fatal software error	http://status.twitter.com/post/115523264/unscheduled-downtime
May 28	unable to create new accounts	captcha problem	http://status.twitter.com/post/114566780/unable-to-create-new-accounts
May 27	site latency		http://status.twitter.com/post/113959453/working-through-site-latency
May 27	Unplanned downtime		http://status.twitter.com/post/113891094/recovering-from-unplanned-downtime
May 22	search down		http://status.twitter.com/post/111769727/search-temporarily-down
May 21	robot errors		http://status.twitter.com/post/111054487/fixing-robot-errors
May 20	user search unavailable		http://status.twitter.com/post/110639419/user-search-temporarily-unavailable
May 14	unplanned downtime		http://status.twitter.com/post/107824532/unplanned-downtime
May 8	latency issues	resulting from a scheduled site maintenance	http://status.twitter.com/post/105202075/back-from-site-maintenance-working-on-site-latency

Apr 28	elevated error rate	fail whales	http://status.twitter.com/post/101237008/fixing-the-elevated-error-rate
Apr 13	slow load times and high error rates		http://status.twitter.com/post/95787359/responding-to-slow-load-times-and-high-error-rates
Apr 9	high latency	also fb not updating	http://status.twitter.com/post/94536362/twitter-com-is-experiencing-high-latency-were-also
Apr 7	high site errors; downtime/load issues		http://status.twitter.com/post/93850673/update-on-delivery-delays-errors
Apr 6	maintenance (no advance warning); downtime		http://status.twitter.com/post/93641925/one-hour-maintenance-starting-at-5-45p-pacific
Apr 6	errors; downtime	fail whales, robot pages; missing tweets	http://status.twitter.com/post/93501130/working-through-some-errors-this-morning
Apr 3	errors; downtime	fail whales, robot pages	http://status.twitter.com/post/92659539/recovering-from-errors-this-morning

Mar 16	unplanned maintenance	widespread slowness	http://status.twitter.com/post/87009894/unplanned-maintenance
Mar 4	problems logging in		http://status.twitter.com/post/83602310/problems-logging-in
Mar 2	power failure	degraded performance	http://status.twitter.com/post/82874378/power-failure-this-morning

Feb 18	latency issues	very long load times	http://status.twitter.com/post/79456053/working-on-site-latency-issues
Feb 14	downtime	db problem	http://status.twitter.com/post/78228774/back-from-maintenance-mode
Feb 11	Site down	db problem	http://status.twitter.com/post/77438630/site-back-up

Jan 20	site slow	slow load times	http://status.twitter.com/post/71824634/slowness
Jan 16	downtime	notified user of potential for more downtime	http://status.twitter.com/post/70991844/twitter-downtime

Dec 17	timeline delays and missing tweets		http://status.twitter.com/post/287676075/known-issues-timeline-delays-and-missing-tweets
Dec 10	problem posting tweets to FB	problem resulting from FB latency issues	http://status.twitter.com/post/277958642/not-all-tweets-from-facebook-app-being-posted-to

Nov 5

missing mentions

http://status.twitter.com/post/234412987/missing-some-mentions

Oct 28	no dmsg emails		http://status.twitter.com/post/226186595/not-receiving-emails-for-direct-messages
Oct 15	timelines 0.5h behind		http://status.twitter.com/post/214053142/timelines-currently-30-minutes-behind
Oct 8	timeline delays	bug	http://status.twitter.com/post/207632462/timeline-delays-this-morning

Sept 16	missing tweets	bug	http://status.twitter.com/post/189862465/tweets-from-users-you-follow-may-be-missing-from-your
Sept 14	missing tweets for some		http://status.twitter.com/post/187786359/missing-tweets-from-some-users
Sept 4	short delivery delays		http://status.twitter.com/post/179752377/working-on-short-delivery-delays
Sept 2	some tweets & followings delayed	small subset?	http://status.twitter.com/post/178076369/some-tweets-and-followings-delayed

August 12

timeline delays

http://status.twitter.com/post/161638570/working-on-timeline-delays

July 28

missing followers for new users

http://status.twitter.com/post/151217980/working-on-missing-followers-for-recently-joined-users

June 29	viewing other people followers/following disabled	bug	http://status.twitter.com/post/132761078/viewing-other-peoples-followers-and-followings
June 16	unable to find new users		http://status.twitter.com/post/124832153/working-to-get-new-users-into-find-people
June 12	search delay	new tweets not being picked up by search	http://status.twitter.com/post/122606485/search-delay
June 3	delayed followings	resulting from spam attack	http://status.twitter.com/post/117482837/delayed-followings

May 13	timeline delays	hardware failure	http://status.twitter.com/post/107561169/temporary-timeline-delays
May 4	search running behind	search not processing real-time	http://status.twitter.com/post/103533181/search-running-behind

Apr 22	data inconsistencies	bug [still being fixed on the 27th]	http://status.twitter.com/post/99180872/tracking-down-data-inconsistencies
Apr 22	missing user images		http://status.twitter.com/post/98960090/missing-user-images
Apr 14	delayed search results		http://status.twitter.com/post/96196695/search-results-are-delayed-about-20-minutes
Apr 10	missing updates		http://status.twitter.com/post/94970050/were-working-to-resolve-an-issue-with-some-missing
Apr 6	missing avatars and dmsgs		http://status.twitter.com/post/93589702/missing-user-icons-avatars-and-direct-messages
Apr 2	not finding self in people search	bug	http://status.twitter.com/post/92334992/not-finding-yourself-in-people-search

Mar 18	missing tweets	db inconsistency, etc.	http://status.twitter.com/post/87625680/some-users-experiencing-missing-tweets
Mar 16	Delays on following and dmsgs		http://status.twitter.com/post/86986973/some-delays-on-followings-direct-messages
Mar 12	missing updates & actions		http://status.twitter.com/post/86067236/some-missing-updates-actions
Mar 11	inconsistencies	data inconsistencies (msg, counts, other data)	http://status.twitter.com/post/85644965/update-on-inconsistencies
Mar 9	inbound sms delay		http://status.twitter.com/post/84921942/inbound-sms-delay

Feb 6	inconsistent follower/following counts		http://status.twitter.com/post/76219963/delays-in-posting-text-messages
Feb 6	txt msg posting delays	problem w/ provider	http://status.twitter.com/post/76219963/delays-in-posting-text-messages
Feb 2	Missing updates		http://status.twitter.com/post/75182201/missing-updates-were-bringing-them-back
Feb 2	missing self	new users missing from search	http://status.twitter.com/post/75102341/unable-to-find-yourself

Jan 30	follower/following counts wrong	due to replication lag	http://status.twitter.com/post/74360199/were-looking-into-inconsistencies-with
Jan 19	slow search	search fell behind realtime due to maintenance	http://status.twitter.com/post/71697063/search-behind-realtime
Jan 8	Delivery delays	tweets slow to appear in the timeline	http://status.twitter.com/post/69184677/catching-back-up
Jan 6	Delivery delays	tweets slow to appear in the timeline	http://status.twitter.com/post/68751921/delivery-delays

That said, a clear picture of the Page Load Time experience felt by the Twitter product’s user base quickly emerged.

Approximately 14% of all days in the year experienced delays and disruptions, directly altering the Page Load Time of the product. And, another ~10% of the year’s days experience pages loading with missing information, resulting in a total number of days experiencing disruption at around 24% of the year or 86 days! (note: there may be some day overlap that is not taken into account in these numbers)

Note: Data for December is complete (only goes through December 21, 2009)

Should Do & A Clear Flight Path

When using Twitter, tweets, responses, searches can and sometimes do occur quickly and without incident. However, with such consistency of problematic service, fail whales, site latency, etc. Twitter earns no more than a value of 0 for Page Load Time; but with a clear path to improvement…

first, focus on the reliability of the Page Load, drastically reducing downtime,
then, focus on the missing data and other inconveniences, some of which are touched upon in my table of notes above.

Next…

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

On the Page Load Time of Quick-UX

Posted on January 11, 2010 by Jeremy Horn

There are some products out there (Twitter comes to mind) that could not possibly have an easier to use interface coupled with a simpler purpose (to say "what’s happening"). However, simple purpose and simple interface are not all that constitute a product’s Usability.

Accessibility,
Consistency,
Recognition,
Navigation, and
Page Load Time.

In answering the question of Usability, "Can I use it?" the sub-category of Page Load plays an instrumental part. Page Load, often obfuscated or connected with other perceived causes of a product’s dissatisfaction, ultimately, either positively or negatively, presents an unquestionable influence on a product’s Usability.

The more engaged a user is with a website, the more they are able to interact, the more they can interact. The slower the website, the slower the rate and capability to engage.

Think of the last time you were shopping online when you made a purchase. Where you able to rapidly get to and purchase the product you sought? The answer most likely is yes. Now, think of the last time you visited a shopping website, where the pages were slow to load. Did you make a purchase? Most likely, the resounding takeaway characteristic you can recall today is one of frustration, in navigating, in seeking, that drove you to other websites — that facilitated your decision process through their greater Usability, and responsiveness.

If the user can forget what they were doing, due to sluggish responsiveness for actions taken in a textfield, the Page Load Time is too slow. The slower a page, the more opportunity a user has to be distracted by other websites, tabs, in-office activities, that can easily pull them from the initial web product.

The perceptions of acceptable Page Load Time are always changing. As the Internet and web continually accelerate, so too do people’s expectations regarding what they consider, ‘instant’ or ‘slow.’ At one point, over dial-up, ‘instant’ was many seconds, or even a minute, but today, a second is nearly ‘instant’, and many seconds is mostly unusable.

Assessing the Page Load Time variable requires very little of your time. However, I do recommend that you average at least a few data points over the course of a day or days to make sure you have an accurate sense of the normal product responsiveness.

If the product typically loads the information promptly (within acceptable expectations) then the Page Load Time variable is assigned the value of 1.
If the product exhibits the occasional, inconsistent delays, use 0.5.
And, if the product (like Twitter) has frequent and long delays (including outages) the value for Page Load Time variable is 0.

Over the next several weeks I will be providing real-world examples of Page Load Time values…

Poor Load Time (value 0) [Twitter, Twine]
Delayed Load Time (value 0.5) [Conversation Pieces]
Prompt Load Time (value 1) [Facebook]

Enjoy, Discuss & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

You and the Future of Gmail

Posted on December 8, 2009 by Jeremy Horn

Recently our journey began. From the humble origins of Outlook to the portable synchronicity of the Windows Mobile platform, I did travel, did evolve, as needs, desires, and demands of communication and productivity so evolved and changed. Through the darkness of masked potential so emerged new and exciting opportunities.

what brought about this conversion, (1) (2)
why it took so long, and (3) (4) (5) (6) (7)
what should be done to encourage greater Gmail adoption. (8) (9)

Over the past many weeks I have explored, elaborated, and exhausted the extent of the then existent exercising of resistance. Now, with such resistance eroded, drawn out through my conversion by an Android, let’s explore what improvements remain undone, those of the ‘Should Do’ variety that would directly facilitate the conversions of many, many more to the ways of Gmail.

Should Do

Seemingly, the most obvious steps that could be taken in easing the path to conversion for the average Gmail user are those that would directly both Encourage and Assist in the change.

Provide tools that can synchronize email, to-do, and calendar with other client-based and web-based solutions; allowing for the parallel use of communication platforms.
Automate the complete or partial porting of existing email organizing and sorting rules to Gmail from platforms like Hotmail, Automate, and Outlook.

Gmail takes a very unique approach to t he email paradigm, from tags to discussion threads. Such uniqueness can take some time to adapt to, while also being very intimidating to both the experienced and novice web user. Gmail would benefit from helping users gradually gain comfort, be in control of the transition from one way of thinking about email to another, by addressing the needs for Familiarity and Usability.

Allow for multiple paradigms to co-exist. Let the user decide which parts of the current Gmail UX they want right now and what aspects they want to keep in their ‘old,’ more familiar ways. Maybe tags are too much for a user to absorb in conjunction with discussion threads. For example…
- let the user optionally use a folder hierarchy if, and until, they want to toggle over to the tag model, and/or
- allow for different signatures per email account; signatures with pictures, links, etc.
Allow for the gradual transition to the Google perceived ideal of email and online communication, as well as the non-committal experimentation with all and/or parts of this newer email pattern.
With the incorporation of the very commonly found preview pane, the ability to scan through communications and discussion threads can be seriously accelerated.
Permit email reminders and the capability to schedule emails to be sent in the future.
Gmail and the other Google communication and time management tools should ease the performance of multiple simultaneous tasks, composing multiple emails, scanning another, planning an event, browsing contacts, without having to open quite so many additional browser windows.

With Google’s integral strategic goal to ‘make the web faster,’ one place they can most certainly focus on is the Speed of Gmail. Using Google search for the web is the fast way to find something online. The problem with that, of course, is that the user of Google Search does not differentiate between searching for something on the web and something in their email box when both seem to possess the same goals — "find what I want." Further raising the need for speedy email searching, especially for those converting from Microsoft Outlook, is Outlook’s Instant Search, a near real-time search of all one’s indexed email. It’s super fast. So when switching over to Gmail or even experimenting with it in prelude to a possible conversion, to experience performance slower than that of Outlook as well as the average Google web search, for an application so very central to a productive day, it isn’t surprising to see some continue their resistance.

Beyond accelerating the speed of displaying search results, Gmail would greatly benefit from a form of Instant Search, as would its users’ productivity.
Initial loading of Gmail, as well as individual page loading, should be greatly reduced. With long page loads, Gmail often regresses to a website feel, away from the target application experience desired by all. One such approach can be to always start in an ‘Instant Offline Mode’ and then update and populate the content; at least in this way, users won’t be delayed in getting into their email and finding what they want. Only the updating of the content would be slowed — much more inline with current application behavior expectations.

Now

First converted to a fan of Android, the platform, then converted to a fan of Gmail, too, I resisted the Android, but eventually succumbed. I, for much longer, both longed for and resisted the conversion to Gmail. Through all of this, despite the long path already journeyed, there remain many more steps to walk, specific steps that those overseers of Gmail can take to further enlighten the experience of ones as of now converted as well as those yet to be.

Remember & Share

Subscribe now (click here) to make sure you don’t miss out on the exciting conclusion to this series exploring the challenges facing Gmail and the most important of what should be done next, and other exciting product explorations and in-depth looks at the people and strategies behind them.

Enjoy & Tweet!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

The Product Guy’s Weekend Reading (July 24, 2009)

Posted on July 24, 2009 by Jeremy Horn

Every week I read thousands of blog posts. Here, for your weekend enjoyment, are some highlights from my recent reading, for you.

On Starting Up…

http://www.pehub.com/45388/zappos-ceo-wanted-to-stay-independent-sequoia-wanted-liquidity%E2%80%94sources/
On Tony Hsieh’s, CEO of Zappos, experience with feeling the pressure of VC’s.

On Design & Product Experience…

http://www.readwriteweb.com/archives/how_usable_is_the_mobile_web.php
A look at the usability and challenges facing the mobile experience.

On Modular Innovation…

http://blog.programmableweb.com/2009/07/23/enterprise-mashups-continue-to-gain-momentum-as-part-of-enterprise-20/
Modular Innovation penetrating the enterprise.

Have a great weekend!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

The Product Guy’s Weekend Reading (January 30, 2009)

Posted on January 30, 2009 by Jeremy Horn

Every week I read tens of thousands of blog posts. Here, for your weekend enjoyment, are some highlights from my recent reading, for you.

On Starting Up…

http://www.markpeterdavis.com/getventure/2009/01/the-4-types-of-exits-secondary.html
Exiting via a secondary transaction to bolster liquidity.

On Design & Product Experience…

http://www.37signals.com/svn/posts/1545-how-we-reduced-chargebacks-by-30-as-a-percentage-of-sales
On the usability of billing.

On Modular Innovation…

http://www.sitepoint.com/blogs/2009/01/26/how-mosembro-uses-microformats-to-improve-usability/
A look at the Modular Innovation and microformats of Mosembro.

Have a great weekend!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

The Product Guy’s Weekend Reading (January 2, 2009)

Posted on January 2, 2009 by Jeremy Horn

Every week I read tens of thousands of blog posts. Here, for your weekend enjoyment, are some highlights from my recent reading, for you.

On Starting Up…
http://www.forbes.com/forbes/2009/0112/066.html?partner=daily_newsletter
Speculation of the final ‘exit’ of venture capital.

On Design & Product Experience…
http://www.usabilitypost.com/2008/12/29/slip-in-wordpress-dashboard-interface/
A interesting look at a simple and quick tweak to improving the Usability of a prominent element of the WordPress dashboard.

On Modular Innovation…
http://www.readwriteweb.com/archives/whats_next_after_web_20_redux.php
From open data to modular websites, the Modular Innovations to expect in the near future.

Have a great weekend!

Jeremy Horn
The Product Guy

Add to Social Bookmarks:

On Starting Up…

On Design & Product Experience…

On Modular Innovation…

Share this:

Like this:

Example: Prompt Load Time (value = 1.0)

Should Do

Next…

Share this:

Like this:

Example: Delayed Load Time (value = 0.5)

Store, Set Up

Minding the Store

Should Do

Next…

Share this:

Like this:

Example: Poor Load Time (value = 0.0)

Should Do

Next…

Share this:

Like this:

Example: Poor Load Time (value = 0.0)

A Quick Study

Should Do & A Clear Flight Path

Next…

Share this:

Like this:

Share this:

Like this:

Should Do

Now

Remember & Share

Share this:

Like this:

On Starting Up…

On Design & Product Experience…

On Modular Innovation…

Share this:

Like this:

On Starting Up…

On Design & Product Experience…

On Modular Innovation…

Share this:

Like this:

Share this:

Like this:

Follow “The Product Guy”