Programming for Information Architects

“You might have more in common with programmers than you think. Both programming and IA are mindsets oriented towards abstraction. We both generally want to find patterns and rules that describe and predict.”Have you ever been sitting in a meeting that takes a sudden turn for the incomprehensible? “I’ll subclass the DataProvider class to add an array of names, then you can override the sort method on that.” Yep, that’s a programmer talking. Nothing to do with information architecture, right? Well, not really.

You might have more in common with programmers than you think. Both programming and IA are mindsets oriented towards abstraction. We both generally want to find patterns and rules that describe and predict. We both appreciate the value of modular parts and components. We both are often concerned with handling structured content and metadata. But more often than not, IAs don’t know what’s going on with code. In this article, I’ll introduce you to some of the basic building blocks of programming.

I should make it clear right away that I’m not proposing a new method of doing IA or a better way of thinking about content, users, or context. But a better understanding of the programmers’ work might inspire your own. It’s important to focus on users during research and design, but to explain our ideas, IAs need to be able to create design documents that show some awareness of systems, programs, and other nuts and bolts. And of course, shared vocabularies and common understandings can go a long way in fostering better team communication.

What is programming?
Programming means giving instructions to a computer in a language it understands. It’s design in that it is organized, creative problem-solving. Like IA, it’s ideally both an art and a craft, combining learned techniques, creativity and an understanding of material restrictions.

The actual act of programming is almost always writing text, and programs are often written as one or more (often many more) text files and some associated assets, like images. (It’s only when the program is compiled that it’s bundled up into a software application, like the double-clickable software that sits on your desktop. Programs in some languages, like PHP or Perl, aren’t ever compiled into single entities, and always remain text files. Web-based applications are good examples of applications that aren’t compiled.) Except for some programming software that lets you program by dragging and dropping or filling out dialog boxes, coding usually means writing lines of text statements that together make up sets of rules and instructions for how a program should work.

There are “high-level” languages like Java or Perl which let programmers write in an English-like syntax, and “low-level” languages like machine language that aren’t really meant for humans to interact with. A Java programmer relies on several layers of interpretation and translation software to translate her Java instructions into an efficient low-level machine language optimized for the computer’s abilities and needs; in other words, silicon chips cannot flip bits on and off by directly carrying out Java code. Programming languages are, in fact, layers of increasing abstraction built upon each other, each written on top of lower-level languages: Flash’s ActionScript language is part of a program written in C++, which itself is a language written in Assembly language.

But the basic nuts and bolts of most contemporary high-level programming languages aren’t really that different. The rest of this article will look at these common building blocks: variables, conditional structures, loops and functions. In the next article, we’ll look at Object-Oriented Programming, a design and coding methodology used in most projects.

Variables
Like IA work, the problems programmers solve tend to be focused on how to represent and access data in efficient, scalable ways, and how to break a problem into its component parts and instructions. This is a process of abstraction, and the fundamental component of it is the variable.
It’s a lot easier to worry about data that changes, like my age, or the set of books currently in my Amazon shopping cart, by giving those concepts defined names, like myAge or itemsInCart. These names are variables. Variables are named containers for data; they’re like boxes with labels written on the outside. By putting a piece of data inside the box and referring to it by the label, the programmer has created an abstraction of that data which is easy to manipulate with code. You can also think of a variable as a placeholder for data, just like a box on a wireframe can be a placeholder for the information that will eventually appear there.

A programmer can create a variable pretty much any time he wants, simply by declaring it exists. This line of code creates a variable called myName with the value of “Andrew”:

      myName = “Andrew”;

Your name probably isn’t the same as mine, so this variable, myName, lets the programmer write code that handles any name. The variable could have any name, although a descriptive name like “myName” is more explanatory and useful than “x.” There are certain words that are not allowed to be used as variable names in each programming language (“new” is a common one), but naming is mostly a matter of personal preference and informal standards among collaborators. Variables are amazingly flexible things; you can put strings of text (like “Boxes & Arrows”), numbers, lists of things (usually called Arrays), or even complicated types of structured data into them.

Whenever the programmer wants to use the value in the variable, he simply calls it by its name:

      print(myName);

That line of code uses a function to print whatever the current value of myName is. (Let’s assume for now that “printing” is a built-in function of this programming language. There is more on functions below.) Again, this is a type of abstraction. This line of code will print the current value of myName, no matter what name’s been put in the variable.

Conditional structures
Conditional structures (sometimes called branching structures) are chunks of code that can examine a situation and determine how to respond to it. Assessing conditions and reacting appropriately is what makes software flexible and powerful.

Conditional structures have lots of obvious parallels in IA work, since this is how people think as well as computers: ifI have the time, then I’ll call my parents; if I’m signed in as a member, then I can access the archived articles; if the gas gauge in my car is lower than a quarter-tank AND if I have some cash AND if I’ll still have enough money left over for lunch, then I’ll get some fuel.

Checking a condition and responding to it is typically done with an if/then statement, and most programming languages let you write these in pretty much plain English.

Here, an if/then conditional statement checks to see if the variable myAge is greater than or equal to 18, and prints a message if it is:

      if (myAge >= 18) then {
        print (“You’re old enough to vote!”);
      }

Why is the “myAge >= 18” inside parentheses? That’s the condition that’s checked when the program arrives at that line of code. If the condition evaluates as “true,” (here, if myAge is equal to or greater than 18, the overall condition is true) the computer will carry out the instructions between the { } brackets, otherwise those statements are ignored and the program skips to the next line of code after the closing bracket.

Loops
Computers are good at doing things fast. They’re really good at doing the same thing, or the same thing with slight predictable variations each time, over and over again. You might not enjoy searching through a list of ten thousand names looking for a particular one, but your computer will do it happily and quickly, thanks to the power of loops. Whenever a program needs to count a quantity, or sort things, or find something specific in a mass of information, it relies on some sort of loop.

Programming languages usually provide several ways to set up loops depending on what the programmer needs to do. Usually this means an action can be carried out a specific number of times or carried out repeatedly as long as a certain condition exists.

It’s common to use a “counter” variable to set up loops that run a specific number of times. Here’s an example of a “for” loop:

      for (n=1; n <= 10; n++) {
        print(“The current value of n is” n);
      }

Let’s read this closely. “for” is a keyword that means “do something for this many times.” The three statements separated by semicolons inside the parentheses are the instructions for how to carry out the loop.

  1. First, we’re creating a counter variable called n with an initial value of 1 (n=1;). The counter will tell us where we are in the loop.
  2. We want the loop to keep running as long as n is less than or equal to 10 (n <= 10;).
  3. With each pass through the loop, we increment n by 1 using a shorthand (n++;) that means “add one to the current value of n.” (By the way, this shorthand is where the C++ language gets its name. It’s based on the older C programming language, but it’s “c+1”.)

Just like in conditional structures, the brackets { } contain instructions that are carried out as long as the stated condition is true, in this case as long as n is less than or equal to 10. Here we just print the current value of n. The key is that n will be different each time through the loop. The result would look like this:

The current value of n is 1
The current value of n is 2

The current value of n is 9
The current value of n is 10

Why not just type ten single print() commands and get the identical result? In this case we knew how many times we wanted to loop, but what if our code had to handle a set of search results? How many results are there? There’s no way to know in advance. A search could result in 1, 37, or any number of hits. To display and format those results on the screen, a programmer must use a loop. Why? Because the instructions for handling one search result are the same as those for five, or fifty, or an unknown number, it’s just a question of how many times they’re carried out. Code must be able to handle both predictable and unpredictable situations, or else it will fail. Let’s improve our code with a variable called “totalNumber.”:

        for(n=1; n < totalNumber; n++)
          print (“The current value of n is” n);
        }

Our code will still just print a list of numbers, but now it can handle whatever amount we throw at it as long as we set the variable totalNumber beforehand. We’ve actually done something very powerful here by using abstraction. We could set totalNumber to the number of times the user clicks the mouse in 5 seconds, or the digit the user types in a form field, or the number of results in a search query. Since we’ve successfully abstracted our code by removing the specific value of 10, it doesn’t matter what totalNumber is.

You should see a clear parallel with common information architecture components in loops. Besides lists of search results, loops show up when you list “the five most recent entries in the Resources category,” or “all authors in the system, grouped by Department,” or just “links to our most popular articles.”

Object-Oriented Programming
Variables, conditions, and loops are the basic building blocks of a programming language. You could write a simple program using just these, although it would be pretty inflexible, and it would be very hard to translate any real-world program requirements into code. Luckily in the early 1960’s some Norwegian programmers addressed these problems by inventing object-oriented programming.

What is Object-Oriented Programming?
Object-Oriented Programming (OOP) isn’t a programming language, it’s an approach to designing and building software. Before object-oriented programming, many programs were written as systematic sets of procedural instructions, often with lots of small subsections. Everything depended on everything else, so problems could creep in anywhere and have far-reaching consequences. This approach didn’t scale well, and as software got more complex, a new methodology was created.

Object-oriented programming turns out to be a very reasonable, common sense way of thinking about programming problems, because it breaks those problems down into their component parts and sets out rules for how those components can interact. Using code that’s built out of components means it’s easier to isolate problems and to reuse working components in other situations. If you’ve ever designed a page out of architectural components (like category lists, search box widgets, or “most popular topics” lists), you know how effective this approach can be.

How is it done?
Design using OOP is actually a lot like a top-down IA process: programmers break a large problem down into smaller discrete parts and arrange those parts in a parent-child hierarchy. Each component has a few specialized abilities and probably knows how to communicate with a few other objects in the system. Think about your car as an example: there’s an engine, an electrical system, a steering system, and several others. Your car’s exhaust system and electrical system don’t really have too much to do with each other, though they work together in an overall way to make the car run. Each of these interacting components is itself made up of smaller, replaceable components, like an ignition switch or a muffler. Some of these smaller components are themselves made up of standardized component parts bolted or wired together. This is the essence of OOP: a hierarchical system of independent component objects communicating though predictable ways to achieve an overall goal.

Programmers create classes to define each of the parts of the hierarchy. A class definition is a template from which individual objects can be generated. Typically not much more than a page or so of code, each class definition describes all the things a type of object knows how to do and the data it needs to carry out its functions.

Properties
To write a class definition for an Engine, for instance, we would first identify the crucial properties an engine has, such as having some number of cylinders, some amount of horsepower, running on either unleaded or diesel fuel, and so on.

Notice that our Engine class didn’t describe a specific “six-cylinder, 250 horsepower, unleaded fuel, Ford engine.” That would be one possible object that our class definition would permit. It would also permit a “four-cylinder, 130 horsepower, unleaded fuel, Toyota engine.” The power of the class definition is that it allows a programmer to create any number of objects with lots of variations. It’s only when an object is created (or instantiated) with these kinds of specific details that the programmer has something to work with.

Creating an object from an existing class definition is done by simply creating a variable:

        var fordEngine = new Engine(6, 250, “unleaded”);

I’m glossing over some details here, but that line of code would create a variable named fordEngine that is a new object derived from the Engine class, with 6 cylinders, 250 horsepower, and using unleaded fuel. “new” is a command meaning “create a new object.”

Functions
So far, objects aren’t that different from the content objects you might define as an IA. For example, a document might have properties like Author Name, Last Modified Date, Keywords, or User Rating. But full-blown objects aren’t just a collection of properties like “horsepower” or “fuel type.” Their real power is that they also know how to do things. A phone “knows” how to ring when it gets an incoming call, a CD player “knows” how to play, stop, fast-forward, and pause discs in response to buttons on the remote control. A programmer would call these behaviors functions (or methods) of the phone and CD player objects. (You might think of properties as nouns and adjectives, and functions as verbs.) The functions in our Engine class definition would describe in detail the actions that all engines can perform, such as starting, stopping, or responding to changes in the amount of gasoline.

Functions are small sections of code that usually describe a single action. Like variables, they’re named, so print(), sortItems(), or cancelYesterdaysOrderList() could all be functions. The parentheses are used to indicate these are functions, not variable names. Functions can be used (or called) from other places in your program by referring to them by name. For instance, you could define a reusable function for the Engine class called start() that might handle the details of starting an engine. This function has comments instead of real code:

        function start() {
            // all the actual details of starting would be
            // spelled out here, like specifying how electricity
            // goes from the battery to the starter motor
        }

Once defined, you could call your start() function on any Engine object and they’ll all work the same way. Typically, a function of an object is called by appending it after the object’s name and a dot. We’ll use our fordEngine object:

        fordEngine.start();

Functions can also accept values to work with called parameters. Parameters allow functions to work as general-purpose tools that take some raw materials, perform some predictable action on them, and hand back a result in a predetermined form. For our Engine class, regulating the current speed is a function that depends on how much gas the driver’s giving:

        function regulateSpeed(gasAmount) {
          newEngineSpeed = currentEngineSpeed + gasAmount;
        }

Ok, that’s a bit oversimplified, but you get the point. This function regulateSpeed expects a value (gasAmount) to work with and adjusts the speed of the Engine based on that number. You’d call this function just like the start() function, but with some number for gasAmount:

        fordEngine.regulateSpeed(5.13);

There are a couple more key ideas to understand about OOP: inheritance and encapsulation.

Inheritance
In any object-oriented system, some classes will be variations on parent classes in a top-down hierarchy. This is called inheritance. The concept of inheritance means that a programmer can create a child class that adds to the abilities of a parent class without affecting existing abilities or data the child learned from its parent. In other words, child objects are born knowing everything their parents know, and more.

That sounds complex, but we can easily state this in a way that will be familiar to IAs. Imagine some information with a general class of content types called “Product Documents” that are different from “Forms” and “Presentations.” “Product Documents” might have metadata properties associated with them that might not be relevant for “Forms” such as “product name,” “author”, “department”, “last updated date” or others.

Perhaps each Product Document could be “subclassed” into more specific sub-types, such as “Technical Documents,” “White Papers” and “Marketing Reports.” As “children” of the Product Document type, these all inherit their parent’s metadata fields, but might also in addition specify metadata fields exclusive to their own uses. For example, Technical Documents might need to keep track of an associated “version number” field. To an IA, these documents are content types with metadata, organized in a meaningful hierarchy. To a programmer, these are custom data types and good candidates for class definitions. They’re objects, each with a set of properties, hierarchically organized according to the principle of inheritance. One big difference is that information architects don’t typically add functions to content types; what does a Product Document “know” how to do, for example?

Encapsulation
Objects are “black boxes.” Do you know how your digital clock works inside? Neither do I, and why should we? It’s basically an enclosed unit that hides its inner workings and exposes a few useful functions to me in an interface, such as the buttons for setting the time and turning the alarm on and off. As long as it keeps time and wakes me up, I don’t need to know much else about it. The concept of encapsulation says that objects should also be “black boxes” that hide the details of how they work, while exposing a few functions in an interface. Since they’re not physical objects, their interfaces aren’t buttons and dials, but specific “public” functions that are available for other programmers and objects to interact with.

If a programmer wants to put a clock into a piece of software, he doesn’t spend time writing a bunch of logic to add 60-second units into minutes and 60-minute units into hours. Instead, he would use an existing object that provided a simple interface to the most useful functions such as showCurrentTime(), setAlarmTime(), snoozeButton() and so on. To the programmer, these functions work exactly like a physical interface. I don’t really know what happens when I smash the Snooze button on my clock except that it stops ringing for 10 minutes. The principle of encapsulation means that the programmer using the digital clock object can confidently write code that uses its snoozeButton() function, without worrying about how that function is implemented.

Conclusion
There’s sometimes a tendency among IAs and designers in general to distance ourselves from the details of programming work. But as we’ve seen, there’s no reason for it to be puzzling or mysterious. I hope this article has cleared up at least some of the terms used in programming and introduced you to some of the basics. We’ve looked at variables, conditional structures, loops, and objects, and seen that these concepts have direct parallels in information architecture. Maybe you’re not ready to take on coding your next project yourself, but I hope you’re better equipped for your next meeting with a programmer.


Andrew Otwell is an information architect and interaction designer living in Austin, Texas. Andrew earned a Master’s degree in Art History at the University of Texas, where he studied Surrealist and Dada art. In 1997, he finally admitted his real interests were with digital design and the web, and so left academia. Fortunately, it turned out that the analysis of visual culture and the analysis of information for the web weren’t so very incompatible, so Andrew found himself doing and teaching information architecture and interaction design in Austin and Berlin. His website is heyotwell.com

Posted in Methods, Workplace and Career | 24 Comments »

24 Comments

  • Andrei

    April 5, 2003 at 2:13 pm

    “user interface design has nothing to do with coding…”

    Then I guess one could also say that designing a house has nothing to do with wood, steel, pipes, soil and concrete.

    Andrei

  • Laurel

    April 8, 2003 at 5:09 pm

    It depends what you mean by code. I can’t code, I design websites with XHTML transitional, which as we all know is markup.

  • Andrew

    April 9, 2003 at 9:29 am

    I think when people say “UI design has nothing to do with code”, that they really mean “UI designs should not be restricted by assumptions about what can and cannot be done with code: design it right and figure out how to build it.” In most cases, that purist attitude is a luxury, as we all know.

    Laurel is correct: there are types of interface design that aren’t “programming” in the sense that I’ve been talking about. But even if you’re building a site in MoveableType, some of the concepts I describe (conditions, loops) are useful to understand.

  • Kyle Pero

    April 9, 2003 at 12:49 pm

    >>>>>
    one last thing: “…Has anybody ever worked with a “web designer” that doesn’t know how to write one line of code?”
    yea. of course. i think those are the best web designers you can get, because their ideas are not contaminated and bounded to their own smattering. those are the people that push IAs and Coders further and further. those are the people that keep us trying to reach and delay technical boarders. …
    >>>>>

    - WOW! Jan, that’s an amazing statement. “Those people”, as you like to refer to them, are the reason why IA’s and usability professionals exist. I agree with you that “they” are creative, but unfortunately “they” don’t have the understanding of creating usable and intuitive web interfaces while pushing the envelope at the same time.

    This is just my opinion.

  • Kyle Pero

    April 9, 2003 at 12:49 pm

    >>>>>
    one last thing: “…Has anybody ever worked with a “web designer” that doesn’t know how to write one line of code?”
    yea. of course. i think those are the best web designers you can get, because their ideas are not contaminated and bounded to their own smattering. those are the people that push IAs and Coders further and further. those are the people that keep us trying to reach and delay technical boarders. …
    >>>>>

    - WOW! Jan, that’s an amazing statement. “Those people”, as you like to refer to them, are the reason why IA’s and usability professionals exist. I agree with you that “they” are creative, but unfortunately “they” don’t have the understanding of creating usable and intuitive web interfaces while pushing the envelope at the same time.

    This is just my opinion.

  • RegularFoot

    April 12, 2003 at 2:34 pm

    I think it has to do with how abstract you want or need to be. Does a carpenter need to know metallurgy because he uses nails? How much about programming does an IA need to know? Assembler? Does a programmer need to know solid state physics because her code will eventually lead to electrons moving through transistors? Where do you draw the line?

  • Kyle Pero

    April 17, 2003 at 7:44 am

    “Where do you draw the line? ”

    I think IA’s as well as usablility professionals in general should know at least front-end coding. I think it’s crazy to get involved in back-end database and/or object-oriented programming… leave all that to the developers.

    I think at a bare minimum I would like an IA to know/understand how to do CSS, HTML, and even some familiarity with client-side programming (java script).

    I will say this: I expect a usability professional to know much, much more about code than an IA. BUT, I don’t know of anyone who doesn’t have to wear 10 different hats at work. If a company has a person completely dedicated to JUST IA then I guess coding, in that case, isn’t as important.

  • Andrew

    April 17, 2003 at 9:16 am

    “I think it’s crazy to get involved in back-end database and/or object-oriented programming… leave all that to the developers.”

    But for better or worse, that’s the stuff I’ve found I need to know more about to do my job well. Front-end stuff is nice, and it’s true that everyone does everything these days. But knowing about database design and back-end programming can really help when you propose a content organization scheme, or that a project make use of a controlled-vocab, or something more sophisticated.

  • Andrew

    April 18, 2003 at 12:23 pm

    I didn’t mean that designing a controlled vocabulary implies you should know how to code the back-end. I meant that when you arrive on a project and say, “hey, we need a controlled vocabulary,” often programmers who haven’t implemented one before either won’t get it, or won’t take you seriously unless you can explain it in terms they understand. (That’s a generalization, of course.) How do queries to the database make use of the CV? When do they refer to it?

    If you’re planning a complex navigation system, perhaps a faceted system, explaining it in database terms can clarify it for a part of the team that probably has never heard of facets before. If you can basically grasp how the flamenco system is built (see http://bailando.sims.berkeley.edu/flamenco/howtobuild/howtobuild.html) , you’ll be able to get your design approved that much more easily.

  • kyle pero

    April 18, 2003 at 5:46 pm

    “…explain it in terms they understand.”
    I can see what you mean now. I think that’s valid.

  • Xavier Fan

    April 23, 2003 at 1:45 pm

    Andrew,

    Great article. (yes, I finally got around to reading this 3 weeks after it was posted). This is one of the best intros to fundamental programming concepts I’ve seen. Kudos.

    My opinion re: the discussion on what IA’s “need” to know:

    The more that an IA know about processes and knowledge related to their work, the better: they can design according to a deeper understanding of the constraints and capabilities of a medium, communicate and collaborate more easily with team members, etc.

    And while you don’t always have to understand the nitty gritty details of the implementation in order to have an opinion on what the problems are and possible solutions, there are definitely cases where such knowledge will improve the design.

    To put it in programming terms, I think that the details of the implementation are very rarely (if ever) fully encapsulated from the IA.

    So, as members of an integrated design team, it behooves IAs to learn about programming and visual design, and similarly for programmers and visual designers and business analysts…

    xavier

  • Boris

    April 1, 2003 at 9:35 am

    Well, bravo for the article. It is however disheartening for me to realise that there are Information Architects out there who know nothing about programming… or design… or databases… or webservers… or TCP/IP… or HTTP…

    I morphed into an information architect BECAUSE I knew every aspect of web work. I cannot imagine how an web information architect can adequatly do his/her job without such knowledge.

    Damn I should have moved to New York or San Fran or Tokyo years ago. Living in a place where the market is so small (like here in Montreal), means you really really have to not only know your stuff, but ALL the stuff related to it. I couldn’t pay my $425(canadian)/month rent if i didn’t! It’s a double edged sword!

    Cheers. Good article.

  • Andrei

    April 1, 2003 at 1:33 pm

    “… It?s important to focus on users during research and design, but to explain our ideas, IAs need to be able to create design documents that show some awareness of systems, programs, and other nuts and bolts.”

    I think you are being way too diplomatic here. The design and strucutre an IA thinks of should always directly translated into how a programmer constructs the system. They always co-mingle, and while an IA doesn’t need to know the specifics of how the programmer constructed the code to execute the design, they must fully understand how code works from the same point of view as the programmer.

    An IA shouldn’t “show awareness” IMHO. They need to be fully cognizant of the realities of how code works, and how their engineers wrote that code, what can be done and what cannot be done in the realm of code, if IAs want to be able to create fully realized designs.

    I always put it this way: If you’re an architect designing a skyscraper, you have to know how steel works. How it bends, how the *physics* of steel operate in the real world. And then you need to know how the construction crew will put the thing together in order to know how to design the building. It’s impossible to do so without that knowledge.

    Many people in the use interface design field, and not just IAs, need to educate themselves more on the nuts and bolts side of the equation, how code works, how programmers think, etc. if any real progress is to be made in the field.

    Andrei

  • Andrew

    April 1, 2003 at 1:59 pm

    Thanks for the comments, here and in emails.

    Andrei wrote:
    “I think you are being way too diplomatic here….An IA shouldn’t ‘show awareness’ IMHO. They need to be fully cognizant of the realities of how code works, and how their engineers wrote that code….”

    No argument from me, and I’d like to know a lot more than I do now! (I think we should be competent visual designers as well.) I was being diplomatic because there are some IAs who definately don’t think this way, but who I thought could benefit from some new concepts.

  • Andrei

    April 1, 2003 at 2:39 pm

    Well… it’s a very good article. You’re definitely providing forward progress for those who want to advance int he field. Hopefully this kind of stuff will be heard by those who think they don’t need to knwo these sorts of things. And more importantly, acted upon.

    Andrei

  • Kyle Pero

    April 2, 2003 at 10:49 am

    I don’t understand how you can be an IA without knowing how to code or design? I’m not saying you have to be an active coder or designer, but you should have previous exposure with both. The difference between an IA w/ this experience and an IA w/out is completely obvious in the architecture they develop.

    This is not just an issue with IA’s… Has anybody ever worked with a “web designer” that doesn’t know how to write one line of code? You usually end up with a completely un-usable and un-intuiative design that just looks “cool”.

    Even though an IA doesn’t do the development or the design they need to know these two other worlds that they are greatly impacting.

  • Stacy Surla

    April 2, 2003 at 12:29 pm

    Great article, and one I’ve been seeking for a long time. We need more readable, accessible writing about technical topics in this world.

    I’ve found it difficult to get a useful understanding of certain fundamentals, like “what is object oriented programming.” I either find myself in the middle of a high-level, ongoing conversation, OR have to wade through inches of material, OR get the “Dummies” overview. Actually, I haven’t even been able to find the “Dummies” overview in most cases.

    For instance, I’ve recently been trying to understand enough about XSLT to get some demo projects off the ground, with only my college Fortran to draw on. Yes, yes, I KNOW there are concepts I am missing, but I’ve had a very hard time finding the conceptual materials I need to move forward – in this, and in so many other cases. So, Andrew, are you going to write “XSLT for Information Architects?”

  • jan

    April 3, 2003 at 7:37 am

    I don’t agree with some of you.

    I can look at my DVD-player interface and tell what kind of surface-design and information presentation i don’t like and think about how i would have done it without having a clue how a DVD is programmed.

    I can look at the design of a “search” and the presentation of results and tell the client or my designer what i don’t like about it, what i would expect and what will irritate most users without knowing how the search-algorithms are programmed.

    ok. i am not new to programming myself, but still i don’t think you need the one to understand the other. the only thing one should understand is the idea and the power of abstraction.

  • Andrei

    April 3, 2003 at 5:50 pm

    “I can look at my DVD-player interface and tell what kind of surface-design and information presentation I don’t like and think about how I would have done it without having a clue how a DVD is programmed.”

    You can try. Then you can put all of those ideas together and claim you have a better design until you try and get them implemented. At which point you might discover some limitations inherit in DVD recorders and programming them that disallows whatever you think of as the “better” design you just created.

    To me it’s like this:

    You can’t be a good architect without knowing physics and how real materials work in the construction of buildings.

    You can’t be a good film director without knowing how editing a story, or how motion photography works, or even how to get actors into their roles to tell the story properly.

    You can’t be a good industrial designer without knowing how the materials you want to use in your designs will work both in the manufacturing process and in people’s hands.

    You can’t be a good carpenter without knowing how wood behaves in various circumstances.

    I could make a very big list along these lines.

    You can’t be good at a lot of things that require some sort of design or creation aspect on your part without detailed knowledge of the pieces that are used in the creation of your design.

    I’m of the opinion you can’t be a good product designer / IA / interface designer without knowing how code works.

    Note I did not say you couldn’t become any of those people without that knowledge. But I will be presumptious and claim that you can’t expect to be any good at any of them without that knowledge.

    Andrei

  • andrew

    April 4, 2003 at 7:39 am

    Andrei, I think you are right in your comments above. This is really the “IA is a craft” idea: a real craftsperson not only understands her tools, but her materials and processes as well. (Actually, there’s a lot more about real “craft” that makes IA a difficult fit. Check out Malcolm McCullogh’s “Abstracting Craft” for more.)

    I think many IAs do have programming backgrounds. But some don’t and might be surprised that “coding IAs” aren’t familiar with the academic literature on classification theory (for example). I wouldn’t suggest that one is better than the other, or even more capable. That’s what SIGIA is for! (Kidding…)

    If one is really more of a UI designer or interaction designer as opposed to an “organizing-IA”, then I think that programming aptitude is even more important.

  • PeterV

    April 4, 2003 at 8:45 am

    Realize techies have often been conditioned by stupid project managers and will throw lines at you like: “We can’t do that – it will break the object encapsulation”, hoping that will end the argument. So the more you know about their world the better you can talk to them.

    I think IA’s really should have some idea of the capabilities of the technologies they are working with: relational databases, object oriented programming, web services, the limitations of HTML, the possibilities of thin client interfaces. Lots of stuff to study.

  • jan

    April 4, 2003 at 12:57 pm

    LOL – oh yea, i know some of those techies. it’s such an interesting species !

    of course it is always good “to know”. and one should keep learning a whole live through. i totally agree. and please don’t get me wrong. i do like this article.

    But i think IA is very complex. design is very complex. programming is quite complex too. i really don’t think an IA should ever argue with an programmer about OOP, about prototype-based inheritance versus class-based inheritance or Pattern-Models. i mean, why should he?

    take one of our airports here in berlin for example. i think an IA should be able to think about the “best” signboard design and the best places to apply those signs and all that usabillity stuff without having to care about how exactly a lucent sign is build. i don’t care about glass making. i don’t care about plastic illumination. i don’t care about electrical engineering. and if a programmer tells me he can’t do it. i go and get myself someone who can do it.

    can you really think of a case where an IA said “this has to be so and so, because of this and that” and then somebody from the coder department did reply “sorry man. this is technically absolutely impossible – and you should have known better if you just had an idea of recursive loops” ?

    one last thing: “…Has anybody ever worked with a “web designer” that doesn’t know how to write one line of code?”
    yea. of course. i think those are the best web designers you can get, because their ideas are not contaminated and bounded to their own smattering. those are the people that push IAs and Coders further and further. those are the people that keep us trying to reach and delay technical boarders. …

  • Andrei

    April 4, 2003 at 1:47 pm

    “one last thing: …Has anybody ever worked with a ‘web designer’ that doesn’t know how to write one line of code? yea. of course. i think those are the best web designers you can get, because their ideas are not contaminated and bounded to their own smattering. those are the people that push IAs and Coders further and further. those are the people that keep us trying to reach and delay technical boarders.”

    My experience has been completely counter to this point of view. These non-coding web designers are the people that have completely set the field of user interface design back a decade or so by creating products that were both useless *and* horrendously complicated to implement, code and scale.

    How many rules and guidelines of good user interface design were utterly destroyed during the web boom? How much damage was done to the practice of consistency, simplicity, and usefulness in interaction and interface design approaches that were ignored by all these people who simply did not have a clue?

    Don’t even get me started here… If you use this reasoning to justify your point of view, I’ll let it alone as I find that reasoning utterly incredulous.

    Andrei

  • jan

    April 4, 2003 at 2:18 pm

    oh, come on. “These non-coding web designers” you talk about were probably no (web)designers at all. webdesign is more then being able to name the difference between CMYK and RGB …
    user interface design has nothing to do with coding.

Sorry, comments are closed.