Traffic to www.adobe.com has grown enormously during the last year, and at peak times site performance has suffered as a result. The www.adobe.com team places a very high priority on site performance. Additional monitors have been installed to track site performance, and there have been multiple initiatives under way that have been incrementally restoring the site to the expected high standard. These initiatives have included the addition of new servers, web server and load balancer tuning, JVM tuning, and content optimization.

North America traffic is served out of a facility in San Jose, California and the rest of the world is served from Dublin, Ireland. Many of the improvements were tested in the San Jose facility first, and these same improvements are being rolled out to the Dublin facility over the next couple of weeks. These hardware and software changes to Dublin will result in significant performance gains around the world.

What my team and I really want to start doing is remote user testing.
I’ve heard a bit about Ethnio, which
looks quite promising for what we want to do here for adobe.com. Also
there is a lot of customizing that can be done to Breeze to
gear it up for use in remote user testing. So there are things out there
that can help us.

More than anything, what I would want out of a remote user testing is
just to allow users to click through a proposed experience on their own
without anyone “watching”. The session would be recorded and include
mouse click data and other actions/events. In addition the user would
fill out a brief questionnaire related to the experience they just had.
They would be compensated in some manner and they’d be on their way.
Then, all the data would be magicked to a central repository where a
user experience professional could browse at will. Something like this
would really ease the overhead of running testing. Over the next month
or so the Web User Experience team will begin to explore and try out
various methods of creating a persistent, predictable, and actionable
input stream from site users (how’s that for a mouthful of mumbo jumbo…).

If anyone reading this has had experience with remote user testing of web sites, I’d
love to hear about it.

I wanted to talk a little bit about the new
Adobe.com web site which launched April 30th. This event also coincides
with the permanent retirement of the Macromedia.com web site. Quick note
for all those sentimental types out there, me included (as I worked on many
macromedia.com site launches during my 9 year tour of duty for that company):
don't get out
your violins yet as many of the best practices from both sites are reincarnated
in the new one. All the content from the former macromedia.com site is now
part of Adobe.com. If for some reason you can't find something please let
me know.

Goals and Objectives of "Day Next”

The basic idea was to create a "one company experience” for the web site.
Where there used to be two sites, now there is one. We also wanted to achieve
a level of technical efficiency by creating a single production environment
where before we had two (but I will leave it up to others to write about this).
I have been concentrating on the user experience aspect so I will focus more
on that in this entry.

Elements of the "Day Next" User Experience

With respect to the user experience we wanted to create
a common experience for users as they navigated across the site (as compared
to pre-“Day Next” where we maintained separate sites and user the
experience moving between them was quite jarring). The way we accomplished
this is below.

1. New UI for combined site sections.
   We
   created merged site sections where
   before there were 2:
   • Single homepage
   • Single global navigation  
   • Single key site section for each area of overlap between the two sites
     (ex: support, search, store, company, showcase, solutions,
     etc)

2. Page migration prioritized by user traffic
   Migrate high level pages based from Adobe.com into Dreamweaver templates
   affording us 100% control over layout using CSS (all Macromedia.com
   pages were already in the templates. The algorithm we used to determine
   which pages we should make it to the migration list is below.

   Algorithm for Page Migration

   • Primary
     Rules
     • Top 90% of traffic (page X is in the top
       90% of traffic)
     • Strategic areas (page/section X is
       very important to the company)
     • High level pages (page X is linked from
       the global nav or home page)

   • Corollary
     Rules
     • User flow continuity (page Y is the
       next click from a page X)
     • Section cohesiveness (Page Y is in part
       of a page X’s section)

3. "Light Touch" reskinning of non-migrated pages
   Reskinned all remaining pages of Adobe.com that did not fit into the above
   migration algorithm so at the very least they had the same global nav,
   were centered within the browser window, and had some minor style updates
   to them. We did this to promote continuity of site experience.

(EDs) Experiential discontinuities we know about

While
the majority of page flows will be seemless, we do know that there are bound
to be some wierd experiential discontinuities (EDs). The most glaring current
EDs are listed below.

• EDs that hurt: Travelling to untouched old adobe.com pages
  will result in the appearance of the old adobe.com global nav… ouch that
  hurts (we know). We are working to convert those pages as we speak.

• EDs that annoy: Travelling from pages in new templates
  to "light-touched" pages will result in your local nav (side nav) jumping
  from right to left… ouch we know that hurts, too. We are working to convert
  these pages as well. We promise!

• EDs that perplex: Sometimes you may get to a page that
  appears to indicate we forgot that Macromedia is no longer exists. If you
  ever stumble across a page like this (you’ll know it when you see it), we
  apologize and are working on it.
  

There undoubtedly are weird experiences out there that we don’t know about
due to the hazards of working on a site with over 300,000 pages, some of
which have existed since time immemorial. In the case you do stumble upon
something strange, please
let us know.

Much more work ahead

While there is clearly much more effort ahead,
the "Day Next" project represents the first major step in creating
a single website that serves the combined users of both previous sites. Did
we do a good job? You, of course, will ultimately
be the judge of that.

If you have comments, concerns, positive feedback (we humans like to hear
the good stuff too), please let us web team folk know.

Send feedback to webfeedback@adobe.com.

David Hatch
Chief Information Architect
Adobe.com
May 2, 2006

Design goals for Day 1 Web Site

(1) Ease transition pains for users
We knew we had to make some changes
to macromedia.com to communicate to folks that we are now Adobe. But we were
concerned that making any drastic changes to the web site would hurt our regular
visitors and customers (or at least inconvenience them, which is the same thing).
Ever since one fateful redesign many years ago, we've been chanting "evolution,
not revolution" every
time a redesign comes due. So our number one design goal for the Day 1 macromedia.com
web site was "do no harm". We wanted to allow developers and others who use
the site on a regular basis to easily get to information and resources they
use regularly (dev center, support, forums, downloads, Labs, etc).

(2) Answer the important question: what about me?
We also anticipated
that folks would have concerns and questions about their products ("are you
still going to support <ProductName>?") and their relationship with
us. So we wanted to provide easy site-wide access to acquisition information
that would help answer these questions.

(3) Allow easy cross-travel
We know that many
of our customers use both Macromedia and Adobe products And
that many are regular users of both sites. For the "Day 1" web site we wanted
to create a convention for crosslinking that would allow easy access to and
from each company's
web site in places where it made sense. Some examples are the home pages for
support, products, downloads, and solutions.

(4) Provide contextual help
The
convention we used for crosslinking not only gets the user to the parallel
area on the other web site, it also provides contextual help where relevant.
For example on the support home the crosslinking pod contains: "Have questions about how this affects your support? Learn more