Jon Lebkowsky (jonl) Wed 11 Jun 03 05:16
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.
http://www.orbitnet.com/ (jleft) Thu 12 Jun 03 11:15
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?
Jesse James Garrett (jjgdotnet) Thu 12 Jun 03 17:36
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.
James Leftwich, IDSA (jleft) Fri 13 Jun 03 11:49
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.
James Leftwich, IDSA (jleft) Fri 13 Jun 03 12:10
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?
Christian Crumlish (xian) Fri 13 Jun 03 13:15
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?
Jesse James Garrett (jjgdotnet) Fri 13 Jun 03 14:08
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>
Cynthia Dyer-Bennet (cdb) Fri 13 Jun 03 16:45
(NOTE: Folks reading this who aren't WELL members can participate in the conversation by sending their queries or comments to firstname.lastname@example.org)
Jesse James Garrett (jjgdotnet) Sat 14 Jun 03 11:26
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.
Jesse James Garrett (jjgdotnet) Sat 14 Jun 03 11:27
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.
Jesse James Garrett (jjgdotnet) Sat 14 Jun 03 11:28
P.S. Christian, it's a short book. It'll take you no time at all. ;)
bloggleby the scrivener (xian) Sat 14 Jun 03 12:10
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.
James Leftwich, IDSA (jleft) Sat 14 Jun 03 13:07
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?
Brian Slesinsky (bslesins) Sat 14 Jun 03 16:33
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.
James Leftwich, IDSA (jleft) Sat 14 Jun 03 17:48
<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.
Jon Lebkowsky (jonl) Sat 14 Jun 03 19:23
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).
Brian Slesinsky (bslesins) Sat 14 Jun 03 19:58
My apologies. Carry on...
Jesse James Garrett (jjgdotnet) Sat 14 Jun 03 20:42
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.
James Leftwich, IDSA (jleft) Sat 14 Jun 03 21:10
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?
Jesse James Garrett (jjgdotnet) Sun 15 Jun 03 13:49
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.
James Leftwich, IDSA (jleft) Sun 15 Jun 03 14:24
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.?
James Leftwich, IDSA (jleft) Sun 15 Jun 03 14:30
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")
www.noodlebrain.com (davis) Mon 16 Jun 03 12:29
interesting topic. thanks for the graphics links to your book.
Jesse James Garrett (jjgdotnet) Mon 16 Jun 03 13:34
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".
James Leftwich, IDSA (jleft) Mon 16 Jun 03 15:57
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.
Everything's for the best in this best of all possible acid trips (tinymonster) Mon 16 Jun 03 19:17
(I wonder if you meant to make this topic visible yet?)
Members: Enter the conference to participate