Inkwell: Authors and Artists

    
An enthusiastic Inkwell welcome to Jesse James Garrett, founding partner
of Adaptive Path, the world's premier user experience consulting company.  
He is author of The Elements of User Experience (New Riders), and is
recognized as a pioneer in the field of information architecture. Jesse's
clients include AT&T, Intel, Crayola, Hewlett-Packard, Motorola, and
National Public Radio.

Since starting in the Internet industry in 1995, Jesse has had a hands-on
role in almost every aspect of Web development, from interface design and
programming to content development and high-level strategy. Today,
information architects around the world depend on the tools and concepts
he has developed, including the widely acclaimed "Elements of User
Experience" model. Jesse is co-founder of the Asilomar Institute for
Information Architecture, the only professional organization dedicated to
information architecture. He is also a frequent speaker and writer whose
work has appeared in numerous publications, including New Architect,
Digital Web, and Boxes and Arrows.

Leading the discussion: Jim Leftwich, IDSA, Director of Human Interface
and Industrial Design at PEMSTAR Pacific Consultants in Mountain View,
California. Jim has over 18 years of broad consulting experience in the
area of Human Interface development in devices, products, software, and
combined systems. Educated as an industrial designer, he was founder and
Principal of Orbit Interaction, a pioneering and broad-based interaction
design and intellectual property development consultancy in Palo Alto,
California.

Jim's interaction architecture and design has spanned a broad range of
products, devices, systems, and software and has been part of numerous
award-winning products, ranging from Sun Microsystems OpenLook(R) OS GUI
and SPARCworks(R) programming environment, the acclaimed and award-winning
Nike Triax(R) line of runners' watches, Macromedia's Dreamweaver(R)  
web-building software, Kensington's VideoCAMworks(R) software, and
Acuson's Sequoia(R) Ultrasound System. He was recently responsible for the
Industrial Design and complete hardware and software interactional
architecture and design for the Natus Algo3i(R), a new generation handheld
newborn hearing screener. This device was developed, won FDA approval, and
announced publicly in just under a year's time. The Algo3i(R) is being
simultaneously released in 22 countries and in 7 languages, including
Japanese.  He has also had extensive experience developing non-PC
interfaces, ranging from wearables, palmtops, gestural slates, webpads,
and gyroscope-based remote controls in the fields of consumer, industrial,
military, and medical devices and systems. Other clients have included
Apple Computer, Disney Epcot Center, Ericsson, Gemstar, Hewlett Packard,
Polaroid, Xerox PARC, and Texas Instruments.

Jim holds eight utility patents in hardware, software, and systems, and
has several currently pending. He earned a B.F.A. in Design from the
Kansas City Art Institute in 1983.
  

    

Welcome Jesse!  I am very much looking forward to this forum and the
opportunity to discuss the various issues and ideas raised in "The Elements
Of User Experience - User-Centered Design For The Web."

While not having been directly involved in the design of websites in my work
(other than fairly simple ones for myself, including a weblog), I was very
amazed to discover just how much overlap exists between the ideas and models
you describe in your book, and the very similar, yet unvoiced, elements and
interrelationships I've noticed in the development of human interfaces for
software, devices, and systems.

I'm so glad to discover that you've undertaken the effort to finally bring a
cogent model of these issues to light.  I've read many books on these issues
over the years, and yet your insights resonate more with my own experience
and are expressed with a simple clarity that I find most refreshing.

There are so many areas where this discussion could lead, and eventually I
would like to get around to discussing some of the more meta issues involved
with developing the User Experience and having a professional career in this
emerging field.

But I will start by asking you to expound a bit on the events and
experiences that led to your finally deciding to put pen to paper and
develop the Elements framework.

Can you describe some of the experiences that you had and witnessed during
the extraordinarily fast evolving period between 1995 and 2000?  And in
conjunction with that, can you tell us about your education and earlier
experiences that led you to this career and established the base from which
you were able to perceive and construct your Elements model?
  

    
Hi Jim! I'm interested to hear how the Elements model has worked for
you in your non-Web work. I never really thought about applying the
Elements beyond the Web context in which it was originally conceived,
but I've heard from a number of people that they've found it useful in
doing other kinds of creative work.

As for me: Technology and media have always been twin passions of
mine. So naturally the Web, as a new publishing technology, exerted a
strong gravitational pull on me from the moment I first saw it when I
was in journalism school.

After college, I picked up HTML and Web design work in between writing
jobs. As Web sites became more sophisticated and complex, I had to
learn a lot about interface design. I started seeing connections
between the way a Web designer shapes the experience a user has and the
way a writer shapes the experience a reader has.

At one point I was managing a team of writers struggling to stay on
top of all the content on a sprawling corporate site. As the site grew
and grew, I found myself spending less time on the traditional duties
of an editor and more on the structural and experiential aspects of the
site. Finally they hired somebody else to take on my editorial
responsibilities and I became a full-time information architect.

By that time, the Web industry was accelerating at an astonishing
pace. Venture capitalists were pouring money into startups, and
established offline businesses were investing tremendous resources to
try to keep up. All of this was good for Web design consultancies,
which were constantly adding staff to keep up with demand.

One of those consultancies, with a strong grounding in traditional
graphic design, hired me as their first information architect. It fell
to me to define my role in the organization as the designers adjusted
to this new specialty being added to their project teams. It was out of
that need to communicate where information architecture fit into the
larger realm of user experience concerns that the Elements model --
eventually, after a few false starts -- was born. Since then, it's been
enormously gratifying to see how others have been able to apply it in
their own work.
  

    


Over the years I've been fascinated with the various paths that have led
people to the broad field of interaction.  Your story is a classic one, of
someone with graphic design and media experience, with an overlay of passion
towards technology.  Many, if not the majority of people working in the
field have arrived via these shores.

Other fields from which people have come include technical writing, theater
and film, architects, and game designers (which have a very different
culture from desktop software developers).

I probably fall into another and much smaller group of immigrants to the
land of interaction.  I came from the fields of product and industrial
design, which also included a major component of graphics and typography.
Throughout the 1980s I consulted as a product designer, working on many
kinds of things.  Medical devices, consumer products, aircraft interiors,
toys, military systems, and more.

From the outset in 1983, I had set my goals on aiming my design career at
the field of interaction.  Having been educated in Design in a very
European, Bauhaus-style generalist tradition, I intuited that a completely
new form of design would be possible, focusing on the intangible, but very
real and dynamic aspects of how we use things.  Instead of bricks or
plastic, I would apply my knowledge of whole-system design to the
architecture of the interrelationships of function, usage, and their
hardware and software affordances.

At one point in the mid-1980s I was co-consulting with an industrial
designer named Tom Noonan, who had been on the Xerox PARC team in the 1970s
that had developed the Star workstation.  The Star, which stood upon the
shoulders of the Alto and the earlier work of Doug Englebart at SRI, was the
first commercially available system to use what we think of today as the
basic GUI or Graphical User Interface.  Tom designed the Star's mouse.  He
introduced me to Norm Cox, a graphic designer and also a Star Team member,
who had designed all the original bitmap icons, including the dog-eared
page, the folder, and others.

I ended up working with Norm Cox and Alan Mandler to design and develop the
look and feel for Sun Microsystem's GUI, Open Look(tm).  That project gave
me my first experience with working on all the aspects of not only a single
application or device interface, but an entire operating system GUI.
Subsequent to that, I moved to Palo Alto, where I continued to work on the
boundaries of products, software, and systems.

Through that period I witnessed the emergence of the mutlimedia field, which
in the late 1980s and early 1990s was mostly about hyperlinked media.
HyperCard stacks gave way to CD-ROMs and the whole field of digital
multimedia design.  I resisted jumping into that field, as my goal was to
stay in product and systems design.  But multimedia had expanded greatly by
1993, and it was from this group which the vast majority of web designers
that I was familiar came from.

But the Element Planes which you use in your model, 1) Strategy, 2) Scope,
3) Structure, 4) Skeleton, and 5) Surface, are very applicable to the
various levels and aspects found within all interactive systems.  For
instance, in a handheld medical device that I did the industrial design,
ergonomics, and software interface for during the past year, all of these
elements came into play.

There was the Strategy of the company, both in their overarching mission,
market positioning, patent strategy, and internationalization
considerations.  For Scope, there was a complex set of functional needs,
based party in functions and processes from earlier and larger devices, and
partly distilled from analysis and observation of clinical settings.  For
Structure, there was the need to co-evolve both a complex software system
and establish the physical controls configuration.  My approach is always to
reduce the interaction to a simplified syntax of archetypal visual
representations, functional symbols, and actions.  But this distillation
must co-evolve along with understanding the basic functionality and
implementational considerations as you go.  Quite a challenge in today's
drastically-compressed development environment.

The Skeleton plane came into play in developing the coordinated, yet
individually specific layouts for the different functional modes within the
software.  And then the Surface was the aspect of developing the general
aesthetic of form and color usage, and coordinating this with the color and
symbology of the interrelated button controls.  Developing the Surface plane
for this device was particularly challenging, as the inexpensive 240 x 320
display had only black, white, and six primary colors.

So you see, your model for the Element Planes fits perfectly well with the
reality of interaction design as pertaining to product design.  That's what
most amazing and satisfying to me.  Your model represents a major step in
understanding not only the issues involved with website interaction design,
but for interaction design in general.
  

    


And with that contextual background established, I'd like to return to the
primary focus of your field - the development of good and effective
websites.  One of the first things you bring up in the book is ROI, or
Return On Investment.  I found this particularly important to place up
front, as I've learned that understanding how to maximize ROI, and
effectively communicate this to your clients and/or stakeholders is the
first thing that must be accomplished in order to begin a successful
project.

One irony that I've discovered is that when interfaces (in any realm or
field) are done correctly, they're essentially transparent.  Interfaces are
often not noticed at all, if they're properly affording the desired
functionality without getting in the way.  Or, to put it inversely, people
only notice interfaces when they're problematic or difficult.

Last night I caught a rerun of Futurama, that had the perfect quote for this
issue.  Bender the robot was floating lost in space, and came upon a
sentient group of stars which speak the following quote to him, "When you do
things right, people won't be sure you've done anything at all ."

That quote, more than almost any others I've heard, seem to sum up good
interaction and interface design.

It's very challenging to adequately describe and make the case for the
importance of good interaction design.  Your Elements model actually helps
greatly in establishing the boundaries between those things that people can
most easily see and notice - Surface, and those planes which support and
actually constitute the basis for the user experience, the most crucial of
which (in my experience) has been the Structure plane.

Everybody loves cool graphics!  Everybody loves hot product aesthetics.  But
very few, and most importantly, few clients and stakeholders, realize the
degree to which the entire gestalt of the user experience rests on these
harder-to-discern planes.

Jesse, can you elaborate a bit on these issues?  The job of quantifying the
ROI aspects in strategic goals, and then effectively communicating and
selling these to key stakeholders and those who hold the pursestrings to
development projecs?  Have you discovered that your work with Elements has
greatly improved your ability to do that effectively and quickly?
  

    
Great to see you here, jjg. I still owe you a review of your book,
somewheres.

You write, "I started seeing connections between the way a Web
designer shapes the experience a user has and the way a writer shapes
the experience a reader has."

I'm not suprised to hear you started as a writer. I found that some of
what I learned as a writer and as a developmental editor in
more-or-less traditional book publishing carries over quite nicely to
information architecture and user-experience design contexts. A lot of
it still comes down to where and how to present information, and what
dependencies follow from that. Of course, the web offers many more
explicit dimensions to work with than do the older, more linear media.

There seems to be some more awareness these days that the web's
fundamental unit may be the link (or linkable item) and not the web
page we all started out on. As databases serve up multiple nodules of
text-y goodness and blogs address items on the permalinked-entry level,
do you see ramifications for IA? Will the sitemaps, wireframes, and
process flows we all crank out now have to start looking different to
reflect this greater degree of granularity?
  

    
Detailed responses are forthcoming, but I think at this point it might
be useful to point folks toward a couple of PDFs so they can see what
we're talking about.

First, here's a version I call the "simple planes" diagram that takes
a very high-level approach to the Elements model:
<http://www.jjg.net/elements/elements_simpleplanes.pdf>

There's more detail in the original diagram I did back in 2000:
<http://www.jjg.net/ia/elements.pdf>

And still more detail in Chapter 2, "Meet the Elements", from the
book:
<http://www.jjg.net/elements/elements_ch02.pdf>
  

    
(NOTE: Folks reading this who aren't WELL members can participate in the
conversation by sending their queries or comments to inkwell-hosts@well.com)
  

    
Jim, thanks for your thoughts on applying the Elements model to
product design. It looks like you've found the model useful in your
work, which has always been my first criterion for its success.

I'd like to see more of this kind of cross-pollination. While the
relative isolation of Web user experience from other disciplines has
been a boon in that it has allowed us to chart our own course, it's
also been something of a burden as we've sometimes had to rediscover or
reinvent concepts and approaches already well understood in other
areas. I'd love to talk to more product designers (among many others)
about the work they do.

You're right that the parts of user experience that have the greatest
influence tend to be the hardest to perceive. (Peter Morville once
referred to information architecture as "an invisible competitive
advantage".) This is one of the ideas that was somewhat latent in the
original Elements diagram that I really appreciated being able to
elaborate on in the book.

It sounds like some sort of hokey aphorism, but if you focus only on
what's tangible, you're really missing the most important part. In the
book I try to illustrate those interrelationships between the abstract
areas like strategy and structure and the concrete final product.
Hopefully, some people will come away from it with a clearer
understanding that if people don't like their site, changing the color
of the navigation tabs might not be the right solution.

Convincing business people that creating a great user experience
involves more than pushing pixels is just the first step, though. The
only two things that matter in business are time and money. Selling the
work requires you to get them to stop thinking of it as *costing* them
time and money -- i.e., time and money spent on user experience
flushes away, never to be seen again -- and start thinking of it as an
*investment* of time and money that will pay off *in terms of time and
money*.

That's the challenge our whole industry is struggling with right now.
So far, we only seem to be able to win business people over one by one
-- a long, slow process. We haven't yet reached that critical mass of
business-side advocates for user experience who can help us communicate
our value to their peers.
  

    
Christian, that's a great question. I've been mulling over the future
of the page paradigm myself lately.

For content on the Web, the page might not be as dead as it seems.
Content still has to be delivered in units; those units still need to
be addressable. Whether that address is a document in a filesystem (as
in the page paradigm), an anchor link in an HTML page (as with weblog
permalinks), or a database query passed through a REST interface (as
with content delivered via Web services), the challenge for the
information architect remains the same: structuring the user's movement
through that content so that it reflects the user's needs and way of
thinking about the subject matter.

Web applications are another story. Even though Web app interfaces are
far more sophisticated than they were just a couple of years ago, HTML
still places difficult constraints on interface designers. Meanwhile,
Macromedia is slowly but surely transforming Flash from an animation
tool to a full-blown interface engine. I would not be at all surprised
to see, in the next three to five years, all but the most basic
query-and-response interfaces migrate to Flash. I think we'll look back
on the first ten years of the Web and be amazed at how much
functionality interface designers were able to squeeze out of the page
paradigm.
  

    
P.S. Christian, it's a short book. It'll take you no time at all. ;)
  

    
the trick is how to say "how seminal! how useful! how cool!" in some
new way.

seriously, when i first saw the diagram it made me say to myself "this
is why i'm having so much trouble communicating with the artists and
developers" - we were jumping back and forth between the information
and application models willy nilly.

Agreed that the page unit won't go away - just that addressability may
need to be apply to the elements that can show up on multiple pages,
pages that themselves may encompass multiple such elements. It can be
tricky.
  

    

Jesse, in relating the issue of now having to convince one business person
at a time, you've identified another reality that all fields of design must
contend with.

I agree, and my experience has borne out that interaction is indeed
difficult to express and educate, and is still very much in the era of being
widely understood.  I think that your Elements model will go a long way
towards being a powerful tool in addressing that.  Industrial Design, as a
field, is essentially sixty to seventy years old, and it's only been in the
last twenty years that it has built up enough recognition and a compelling
business case to make to industry.  So we now see Business Week magazine
having a large annual issue devoted to it.  There are also Design Management
publications, which focus on the business aspects of incorporating good
design into a successful business.

So, from my perspective, we are simply faced with the understandable
challenges of a young field.  Luckily, there is beginning to be, through the
efforts of those like you, to be an emergent set of principles and models
that can help accelerate the necessary understanding in the business world.

I think it might work well now to move on through the five element planes,
and discuss them both individually, and within the context of their
interrelationships with the others.

I thought you described well the need to both begin work simultaneously and
concurrently within the five planes, but that no upper plane can be stamped
final until the planes beneath it are finalized.  This is a very key
understanding, I think.

Many projects have difficulty in achieving that, because it becomes
increasingly difficult to identify and reach consensus among all the key
stakeholders regarding the underlying planes, particularly the Strategic
Plane.  The Scope Plane is generally a matter of getting a good handle on
the functionality and capabilities to be provided and the Structure Plane,
as I see it, is very much where the designer/designers are laying out the
design direction.

Can you speak to the issues involved in the Strategy Plane?  What has been
your range of experiences and challenges here?  One particular challenge
that I've seen is that some clients or stakeholders have better or worse
handles on their overall strategies.  Sometimes this is related to their
overall corporate or entity mission, and sometimes it's simply a matter of
understanding how this particular website or design fits in with that.

Also, and in a related manner, do you see the Strategy Plane as the place
where you can best position and raise awareness about the importance and
priority of good design within the overall corporate or entity mission?
  

    
I have to say when designers go all abstract they tend to lose me. 
What about validating that a design works - that is, user testing? 
That seems like the best way to prove to even the most skeptical that
as a designer you've done something useful.  And yet I'm sure there are
still a lot of places that don't do it.
  

    

<bslesins>, I expect that the discussion will eventually move to that point
and Jesse has a number of points in his book regarding user testing, and the
place within the design and development process where it's appropriately
used.

The goal of moving through the Element planes, as laid out in the book, is
to ground our discussion within the ideas and approach that best guarantee
that testing will yield superior results and feedback for the iterative
refinement or adjustment of various aspects of the design and
implementation.

The greatest strength I see in the Elements model is that it's a way of
maximizing one's grasp and control over the many different types and levels
of issues involved in planning and executing a design and development
program.
  

    
We strongly encourage participation in Inkwell discussions by anyone who's 
interested, but I'm aware that Jim wanted to discuss the five planes Jesse 
mentions in the book at length before dealing with more general 
questions... so it might be worthwhile to hold questions until the 
discussion has progressed further, or bear with Jim and Jesse if they 
don't respond immediately to something that's posted (we'll catch it later 
in the discussion).
  

    
My apologies.  Carry on...
  

    
What we at Adaptive Path are seeing right now -- and I think this may
be an artifact of this particular historical moment -- are clients with
a very weak handle on their Strategy issues. They've woken up from the
five-year bender known as the New Economy with a splitting headache
and a Web site they have no idea what to do with. So we're spending a
lot of time helping our clients understand and articulate what value
the site offers the users, and what value the site offers the business.

The big challenge here is that we are often brought in under the
auspices of some sort of redesign initiative that's already been
approved and funded. Then, in the course of doing our work, the client
realizes that they don't know what the redesign is even supposed to
accomplish -- and that taking the time to define those strategic
objectives would derail a train that's already left the station, so to
speak. In some cases, we're brought in early enough to be able to help
them define the strategy before resources have been allocated. Not
coincidentally, those have been our most successful projects.

Brian touches on another important aspect of defining site strategy:
understanding the needs of your users. Talking to real live users of
your product is enormously valuable, and can help with the user
experience decisions you make all the way through the development
process. If you have to choose between doing research before you design
or doing testing afterward, I'd favor the pre-design route, simply
because it allows you to make better, more informed choices. Thorough
pre-design research plus skilled designers equals fewer problems in
user testing.
  

    

One possible upside, is that clients and stakeholders with poorly defined or
stabilized strategies create opportunities for designers to step in a offer
a bonus of that as an aspect, or perhaps side benefit, of their work.

So perhaps by shifting to explore and define the users, the variety of
directions from which they come, and the range of things they want, the
Scope plane can be a good place to move next.

I certainly agree with your statement regarding the value of understanding
your end users, and the degree to which that lays the groundwork for a
design that meets real needs.

Jesse, can you talk a bit about the various processes you go through when
uncovering contextual user needs then applying that to the design process?
Sometimes I find that clients have a laundry list of functional needs.
Other times clients want to expand their user base, sometimes into
demographics beyond their existing users.  Who do you interview and what
types of information are you looking for?

Also, in working from the Scope plane, do you fill in missing pieces from
the Strategy plane with things you discover as you go, so as to leave the
customer with a much more solidified understanding of their website's
strategy, even if they didn't have one to begin with?
  

    
Often, the people inside the client organization who can shed the most
light on the needs of the users are the people who deal with them
every day: customer service representatives. The ideas these people can
offer frequently evoke a kind of "why didn't I think of that?"
reaction from the Web team. Most of the time, customer service is so
isolated from Web operations that there are no communications channels
for these insights to get back to designers and developers.

To help define the scope, one question I like to ask people at every
level in the organization is, "Have you ever seen something on another
Web site that you wished your site had?" They need not limit themselves
to competitors. Inspirations for features and functionality can come
from all kinds of sites.

The transition from one plane to the next is never rigidly defined --
or at least it shouldn't be. Don't wait until each plane is finished
before you start work on the next. Sure, at some point you do have to
draw a line and say, "We're not going to revise the strategy until we
get this version launched." Otherwise you run the risk of analysis
paralysis, always second-guessing your plans but never finishing
anything.

But that doesn't mean you should ignore findings coming out of the
requirements definition process that cause you to rethink some of the
underlying strategic objectives. Even if you aren't able to answer all
your strategic questions in time for this release, you can document
those questions as candidates for targeted inquiry in the next phase.
  

    

I think that the Elements model can provide a useful scaffolding to help
keep the various issues in relative order and priority, as the twin tasks of
learning and developing proceed.

And the act of developing is a good segue into a discussion of the Structure
plane.

Again, I want to stress that we're merely talking about these five different
planes in sequential order, as threaded discussions are linear.  Jesse is
quick to point out in his book, and here as well, that the five planes are
simply five aspects or filters through which the development work as a whole
can be modeled and understood.

With that in mind, I'd like to ask Jesse to discuss what he refers to as the
Structure plane in his book.  This is a very important perspective from
which to frame a project, I think, particularly from the point of view of
the interactional architecture.  So much of the site's rhythm and flow and
feel and reward emerge from the decisions made and solutions implemented
here.

Jesse, what tools and methods do you employ towards these aspects of a
project?  Are you creating maps in order to visualize the overall system and
flow?  Mockups, storyboards, etc.?
  

    

And also, I might add the additional questions which go more toward your
goals in the Structure plane for the users.  How are you thinking about the
design of the experience within the structure?

Are you going after qualities of "feel" to the experience? (using part of
the traditional descriptive phrase of "look and feel")
  

    
interesting topic. 

thanks for the graphics links to your book.
  

    
The Structure plane encompasses information architecture and
interaction design, both areas where we have to determine the choices
users want to be able to make as they move through the site. In the
case on information architecture, those are choices about which content
elements the user might want; in the case of interaction design, the
choices are actions the user might take.

One way I have described the difference between IA and interaction
design is that if you're dealing with nouns -- content "objects" for
the user to access -- it's information architecture; if you're dealing
with verbs -- actions the user takes, actions the system takes in
response -- that's interaction design.

The whole user experience process is about seeing the product through
the eyes of the user, but Structure is the area where we really have to
immerse ourselves in that user's moment-to-moment existence. What's
going on in their head at this specific point in their interaction with
the site? What are they expecting to see, and what options do they
want available? What can we assume they know, and what should we assume
they don't?

The main tool I've evolved for working through structural issues is a
diagramming system that's become known as the Visual Vocabulary:

<http://www.jjg.net/ia/visvocab/>

I'm not sure that "feel" can be attributed to any particular plane of
the Elements -- it strikes me as a more holistic quality. But Structure
is probably the closest match to that quality of "feel".
  

    

I checked out your Visual Vocabulary diagramming system.  There are number
of things where it's similar to the types of diagramming I do in my work
with devices and product systems and their interrelated hardware controls
and software.

Your use of the word, "holistic" is important too, as the user experience
truly comes from the whole of the site, device, or system.

Jesse, as you and your team begin work on the Skeleton, or page layout
configurations, and developing aesthetic directions and stylistic treatments
in the Surface planes, what type of issues are you juggling?  Are you
reaching into information garnered in the Strategy and Scope planes?  Do you
have special methods, or rely on experience and exposure to the greater
design and development fields for determining how individual portions of a
site should be laid out or how they should look?

Also, can you give some of your thoughts on the art of integrating ideas and
explorations and discoveries across all of these planes, as work really gets
down to business during the very busy initial development phase of a
project?

And please, feel free to go in any other directions that you think would be
interesting tangents or issues.  We will shortly be opening up the
discussion to our wider audience, and I'm certain there are a number of
questions queueing up.
  

    
(I wonder if you meant to make this topic visible yet?)