Boxes and Arrows: Stories by David Heller

Why I'm Not Calling Myself an Information Architect Anymore

David Heller — Mon, 06 May 2002 20:55:38 GMT

I could probably put it in one simple word—respect. But if I left it at that, it wouldn’t make for much of an article, nor would it provoke discussion, in the squares & directions community, toward moving to an answer to the dilemma of industry labels. To start, let me say that I learned so much about this issue due to my first real “Information Architecture is not the same as interaction design or user experience design.” set of industry conferences (back-to-back). The AIGA: Experience Design forum was an amazing get together that took the seeds that have been developed and started turning them into saplings. I feel very energized by what I call a movement in our sphere. The CHI conference for me was a loci where practitioners and researchers came together, not to listen, but to talk. This was a tremendous experience outside the papers, panels and demos that helped shape a lot of what I’m going to put forth. At the reception on Tuesday night I had the opportunity to step into a guru’s conversation about her first attendance to the IA Summit. This person has been around since there was something to be around, and I very much appreciate her contribution to the field, especially around field research and usability. She was speaking with others, who are more old school than myself, about the IA Summit and she was explaining her surprise at how the IAs want to “own the process.” Her surprised stemmed from her previous understanding of IAs as library scientists interested in facets, categories, vocabularies and maybe, at most, navigation. She never thought of IAs as those who make layouts, design behavior, do usability or field research, etc. It was at this point I interjected my feeling that IA is what she thinks it is, but because of the history whereby IA is also what Richard Saul Wurman expressed it was, that many informally (and formally) trained designers have come to feel at home within this title. It is a title that seems to generate understanding among clients where “user experience” and “usability” have left clients confused or seem too widely or narrowly focused. It’s just what worked and has built up, especially in the consultancy community, a big following that can’t be ignored. Of course there was the usual cry from those of the old STC, UPA, HCI school, “but we were doing this for centuries” and more discussion ensued. They have been doing this for a long time. But only if you think “this” is user-centered design. But IA isn’t user-centered design. IA is IA and it was with this that I was convinced. Actually, convinced is not the right word. Turned—yes, I was “turned.” I don’t think there is anything I can say about her argument that actually convinced me of her position, but it was more a feeling I got about the state of IA and what people need it to be, if we are going to move our field forward, that changed my thinking. That feeling is clarity. Clarity was missing from the Experience Design group, and that wasn’t good, but the ED group is not trying to define a title or a discipline but a philosophy (in my humble opinion), so the lack of clarity isn’t really an issue. But this is not just about clarity. As I said, the single word is respect, and clarity is just one way of expressing that respect. I know I am not an Information Architect because I know what Information Architecture is, and I respect those that can do it. I also want to make sure that those who can do it, aren’t obscured by those that can’t. Information Architecture is not the same as interaction design or user experience design. The line is very clear and the only reason we allow it be blurred is because early adopters from different disciplines within the field coopted the term and have applied it to a broad swath of responsibilities. Does this mean we are all clear and cozy? No, it doesn’t. There is still a definition, an early definition, of IA that is out there that needs to be reckoned with. As noted above, Richard Saul Wurman coined the term in 1972. He used it in a great and informative way for its time (for all time in fact) by saying that the writer and graphic designer need to be one. He felt that the visual display, layout, texture, surrounding iconography, etc. that set the mood and set context for words directly affect their inference by the reader. This sets in motion (IMHO) the idea of user experience in the print world. But how do we reconcile this early use of the word IA with that which is taught in universities? The IA tied to the library science community that discusses organization and classification (of which RSW spoke about, but did not focus on), and is within the digital and interactive domains. What I suggest here is that Information Architecture is an arrow in an interaction designer’s quiver. Sometimes that arrow is a whole other human being, who works beside an interaction designer, and that person is known as an information architect. But it works both ways. An information architect should also have interaction design theory as an arrow in their quiver, and sometimes that arrow is a person called an interaction designer (or similar). I would say the same for a usability engineer. Usability is both a set of theories and a person who specializes in those theories that add support to the creation of interactive digital experiences. What is important to me is that Information Architecture doesn’t get lost. at CHI, I attended a paper presentation by an HCI researcher and it was so obvious to me that most of the answers this person needed, to fill in her admitted holes, were already known by the Information Architecture community—the official one. Not the one that allowed me to take that title without any knowledge of thesauri, facets, and classification theory, but the one that the Polar Bear book was trying to teach people about, get them excited about, and entice them to join in. So respectfully, I remain a member of this community, but I revoke (retroactively) all titles I ever held that included Information Architecture in them. I believe that those who hold this title have more to gain through its controlled use, than through it being drowned out in the debates raging for what should we call this evolving genre of designing human-centered interactive computer experiences. It’s really a battle that is a waste of time (as Alan Cooper said at the Forum). And I believe that IA would win more by not joining in.

David Heller, is currently a Sr. User Interface Designer at Documentum. His current projects include new web-based clients to Documentum’s currently powerful set of Enterprise Content Management solutions.

HTML's Time is Over. Let's Move On.

David Heller — Sun, 26 Jan 2003 21:50:09 GMT

“Ultimately, I don't see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing.”As the web finds users and builders demanding more and more richness, we need to re-evaluate the technology that 99% of it is built on. No matter how sophisticated our back ends get, the front ends seem to remain stagnant. Yes, HTML transformed to XHTML, but that is such a small step and it is a problematic one when we consider the still eminent requirement of multi-browser, multi-platform, multi-device support. Macromedia has been making an all out push of what they call Rich Internet Applications and have been trying to get developers to make this their new front-end web-based technology standard. What went wrong? What went right? What other options are there? What are the real requirements that we as user experience designers face that all these technologies miss the boat on? Background The web browser has changed the very shape of what it means to create applications with centralized or peer-to-peer shared repositories of structured and unstructured data. For most users, the web is a bank, a store, or an information-gathering tool. For others, the web has become their primary means of interacting with cross-enterprise and intra-enterprise applications. What has made most of this possible is the tremendous re-architecting of server- and mainframe-based systems that are now able to communicate with each other through agreed upon standards (usually called web services), as well as the development of application servers that generate web browser-interpretable pages. Most of the time this is done solely in HTML, and that is the point of this article. Examples of application servers are BEA WebLogic, IBM WebSphere, Microsoft’s Internet Information Server and the free Apache Tomcat. These are powerful systems because of the amount of logic that can be programmed into them, and because of their connectivity to complex databases. This logic remains resident on the server, and limits the amount of bandwidth required to send information to the end-user’s local machine for processing business logic or doing dynamic interface layouts. The problem Application servers send a combination of HTML, JavaScript, and Cascading Style Sheets (CSS) to the web browser. These combined technologies are called Dynamic HTML (DHTML) and are standardized around a Document Object Model (DOM). While the basic core of these technologies has remained consistent, the interpretation of them has not been standardized across all platforms and web browsers. For example, while Netscape 7 and Internet Explorer 6 both claim they support specific standards, the way they interpret these standards differs dramatically. Then there are issues with backwards compatibility, bandwidth, and other technology limitations. For example, how many people can say, “I’m only going to design my site for Netscape 7.0 and IE 6.0 for Windows (which Windows?), IE 5.5 and Netscape 7.0 for Mac (which Mac?), and Netscape 7.0 for Unix (which variety?).” The truth is that no one with a conscience can be that specific. Netscape 6.2 is still the Netscape standard and, in many ways, is a far cry from Netscape 7.0. Even the Macintosh world is still not clearly aligned around a single browser. Where does this leave us? Most companies developing what are commonly called thin-clients use a “lowest common denominator” level of DHTML that is not able to take advantage of what few advances in DHTML technology there have been. It also leaves us with the issues mentioned above that don’t go away with any version of DHTML, and design issues beyond those, including: Bandwidth Bandwidth limits how much data can be downloaded to the client. Visual representations used to be the big problem, limiting graphics and the like, but today these issues are mostly under control due to better education of most web designers. Now, the bulk of the size of a web page in a web application is in the non-display code and in assets such as JavaScript and style information (CSS). In applications with large data sets, the end HTML size becomes so important to the overall performance of the application that reducing attributes in tags is a requirement. Accessibility The use of DHTML, or more importantly JavaScript, seriously impedes accessibility. Where it doesn’t impede accessibility, engineers will often need to add to their code logic and variables to handle the differences between browsers and platforms. This increases both coding time and quality assurance resources in order to accommodate accessibility. Where is the application? A thin-client isn’t just an application; it is an application that runs inside another discrete application. The end result is that standards such as a menu bar or tool bar become redundant to the workings of the browser itself. Users get confused about which “File,” “Edit,” or “View” they should use. Users also insist on being able to use a ”Back” button, which can cause page and link management issues, especially if you are trying to use frames to solve other problems. Accessing the desktop DHTML requires assisted technologies in order to gain access to the user’s desktop. Any sort of desktop registry information with any substance cannot be accomplished with DHTML. JavaScript doesn’t have access to the local files system or to the primary components of the browser system, such as Open and Save dialogues. For example, anyone who has tried to add an attachment to a web-based email program knows that you have to choose one file at a time, initiate the upload, and then repeat for each new file. Sometimes, being able to transfer data from the local system to the centralized one is of such primary importance that it must not only be done in bulk, but it must be able to be controlled both visually and logically. Another side of this issue is that using standard GUI conventions like Drag and Drop and Clipboard are not available between the desktop and the application in the web browser. Technology solutions for weary designers Now that we understand the problem set a bit, lets talk about what is out there to help a weary and frustrated designer. This list is far from being comprehensive, and a real programmer or system architect would probably evaluate these technologies in a different way. Some of these options run inside the browser while others do not. Macromedia Flash MX, www.macromedia.com/flash Probably the 2nd most ubiquitous browser-based technology in the world (behind HTML). Flash, until recently, has been relegated to random acts of usability terror when used as a GUI front end. Most people think of it is an animation and game-making tool, and many “serious” business people think of it is as eye candy that they will only consider for their custom marketing needs. The latest version of Flash is part of an initiative by Macromedia to lead the back and the front end of middle-tier web development. By making Flash more accessible, easier to internationalize, and including widgets and other components, Macromedia hopes to make their product an HTML killer. Upgrading to newer versions of Flash has become almost painless. Also, the footprint of the Flash runtime engine is relatively small compared to other similar plug-in player technologies. The footprint of the transferred media is also small due to several factors: all graphics and text are rendered as vector information, which is a lot smaller than traditional raster bitmaps like gif or jpeg; flash applications can be streamed in components as they are needed, or components can be pre-loaded and stored for later use as other components. Flash can also connect to the desktop, and uses a programming language based on ECMScript (the standard for JavaScript). What about back-end connections? Can an application server work with Flash? Yes! J2EE, JSP, ASP, and .Net can all work by using the Flash Remote Server to send data to and from Flash-based applications. While Flash hits the mark on its new front-end capabilities, it doesn’t do it from a developer’s perspective. The overall developer environment is still focused toward animation development. The program uses a score in which you add cast members within a timeline – a method used for traditional animation. But linear timeline-based development just doesn’t make sense in an application environment. One last positive note for Flash: other companies have begun developing tools for creating Flash player files. Adobe (www.adobe.com) is one and a startup company Lazlo Systems (www.laszlosystems.com) claims to have a tool geared specifically to applications. There is hope that either Macromedia or other third-party companies will come up with a robust developer solution. Curl, www.curl.com Developed by MIT University and now owned by a privately-held corporation, Curl was developed as an alternative to HTML. It requires its own runtime engine in order to interpret proprietary files. If you go to the Curl site there is a great demo which shows an enterprise business application running. It is clear that there are definite widget controls and customization abilities which lend to a desktop application feel, even though much of the logic is on the server. Curl lacks maturity and support. The demos are interesting but they are just that, demos. Curl also lacks end-user support. In an enterprise environment, you might be able to dictate the use of a plug-in that isn’t widespread, but in a cross-enterprise environment this becomes increasingly difficult. The run-time environment - which they call Surge - is currently only available in Windows, another limiting factor. Java 2 (with Swing) , java.sun.com Well, we can always use Java, right? Java is a great cross-platform, cross-browser, just-in-time development language. And in Java 2 and Swing there are even significant APIs available between the applet and the operating system, as well as a very juicy set of controllable and customizable widgets. However, the footprint of most Java applets is pretty large. In addition, Java applets are dependent on raster images in many situations. More importantly than any of this, Java, regardless of its promise, has many kinks that make cross-platform use very hard to manage from a quality assurance standpoint. The other problem with Java 2 is that it’s not a ubiquitous standard; even Flash is more widely used and accessed. The Sun Java Virtual Machine (JVM) is required as a separate install to run Swing-based applets. And to run the Sun JVM, the Microsoft JVM that some other sites and applications may be using must be turned off. This complicates things tremendously, as it forces the user to download Swing code every time the application is used. This tacks a significant footprint onto “easily distributed” applications. Honorable Mentions Water, www.waterlang.org Water is more like an HTML replacement than a true thickening agent for web-based thin-clients. It is also immature with very few developers. It requires Java 2 to be installed. XWT, www.xwt.org This solution shows some promise. It is a Java-based interpreter for a new XML language. There is a widget set that you define using its easy to learn XML standard. Because it is XML-based it is very flexible, but it still requires a special download and currently has a very small developer base. One of the things that I really like about it is that it can be initiated from a browser, but runs exclusively in its own OS window. Norpath Elements, www.norpath.com Norpath’s Elements product is very similar to Flash except that the primary programming methodology is visually based. It can connect to databases and have logic based on data or behavior. It also uses a timeline development environment like Flash, but this is secondary to its primary interface for adding visual elements and logical elements. There are pre-fabricated widgets, and you can also build your own. Resulting files are XML packaged with images and accompanying text. The problem with Norpath is market saturation – there isn’t any. Otherwise, there is a lot of promise here. I think Macromedia, Adobe, and Microsoft can learn a few things from Norpath, especially from their visual programming model. General models to consider What do we really need? Are there examples of distributed thin-client applications out there that have enough client-side functionality? The answer is yes and no. There are simple applications out there in the world, many with very specific purposes. The best example I can think of is Instant Messaging (IM) software. Some IM software runs on Java, so it is portable across platforms. More often though, it is developed specifically to the operating system. While this means that you can’t have a single code base, these applications succeed because they are practically self-updating. From an user perspective, they are easy to maintain. The most complex thin-client I have seen to date, has to be Groove’s client. Some might even say it isn’t a thin-client at all, but I would define it as such because its components get installed individually. A calendar or a meeting applet are requested and maintained separately. The connectors between the applets are not clear, but overall the experience of using Groove is very good and easily maintained. The idea of self-updating software is not new. At Documentum, we have internal applications that do this already. An outdated version of our software will lock a system and force an upgrade. Upgrades in the LAN-space are relatively easy. But over a 56k modem, the experience can be painful; even a single megabyte applet is a dread to download. This, however, has not stopped companies like Microsoft, Adobe, Macromedia, AOL, et al, to rely on the concept of self-updating software. Microsoft’s Windows Update is probably the most ambitious, as it updates the operating system in chunks instead of all at once. Apple has followed suit with similar updating functionality. Taking it to the enterprise Taking all this to the enterprise requires special design considerations. The biggest is that “out of the box” applications are seldom used. Most applications by PeopleSoft, SAP, Siebel and Documentum, for example, are extremely customized for the individual end user (enterprise). These customizations are time consuming. This also means that having multiple code bases for each platform can be cost- and resource-intensive. Because of this, a single code base is practically a requirement. When a vendor updates its core offering, how are updates achieved? Can they occur without upsetting the previous customizations? This is a big question, as many vendors make revenue on these upgrades, and the customers want these upgrades because they mean bug fixes and added functionality. So when updates are done, they need to be done with a minimal effect on the customizations. Even with current HTML solutions, this is not easy to achieve. Conclusion Ultimately, I don’t see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing. The reality is that we are trying to do too much with a language that was never meant for such heavy-duty applications. We have used incredible ingenuity to make up for the faults of HTML by putting all of the real processing effort on the server side, but the time has come to create a new system that is low bandwidth, utilizes a single code base for all platforms, and is componentized enough to make updating and customizations easy using internet-based distribution. Lastly, we need to develop these applications to run in their own space, without a web browser In the end, this may change the way we think of web browsers. It will also change the way platforms need to be developed, in order to support a wide array of thin-clients that are accessed and addressed directly from the operating system as opposed to from a browser.

David Heller is currently a Sr. User Interface Designer at Documentum. His current projects include adding new web-based clients to Documentum's currently powerful set of Enterprise Content Management solutions. Before arriving at Documentum, David was the director of Information Architecture for a small firm in NYC called Vizooal, where he worked as lead consultant on projects developing marketplace solutions in the transportation, media, and supply-chain management industries.