Author Archive: hatch Performance

Hi all,
Since there has been some buzz about the performance of, I wanted to post a statement on the matter from some folks on the team who have been working on the issue. See below:

Traffic to has grown enormously during the last year, and at peak times site performance has suffered as a result. The 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.

Remote User Testing Musings

I went to a BayChi meeting last night with my web UE team. The title
of the talk was “Hello
Morae, Farewell VHS!
” by Emily Hebard and Joanna Sim from Intuit. The
talk was good and I learned a bit about Morae.
But for some reason I had got it into my head that Morae could be used
for remote user testing (with the users being remote as opposed to just
the viewers). It was my bad basically for not doing the research.

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 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.

Day Next ( + = New


I wanted to talk a little bit about the new web site
which launched April 30th. This event also coincides
with the permanent retirement of the web site. Quick note
for all those sentimental types out there, me included (as I worked on many 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 site is now
part of 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.
    created merged site sections where
    before there were 2:

  2. Page migration prioritized by user traffic
    Migrate high level pages based from into Dreamweaver templates
    affording us 100% control over layout using CSS (all
    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

      • 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

      • 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 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

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 pages
    will result in the appearance of the old 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


David Hatch
Chief Information Architect
May 2, 2006 “Day 1” Web Site

The "Day 1" web site has arrived! The "Day 1" site is how we've been referring to the modified web site that would go live once Macromedia became "the company formerly know as…".
Which is now! As the chief info architect for the web site I wanted to have
the chance to explain some of the things we did and why.


Design goals for Day 1 Web Site

(1) Ease transition pains for users
We knew we had to make some changes
to 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
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
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