When I was hired at LexisNexis back in 2003, it was to develop HTML templates, often to take to Usability testing. I’d been building actual web sites professionally for four years, so initially I felt this was “a step backwards”. Soon, however, I realized that template building is really more of an art, and indeed more elegant.

When you’re working on a website, you know what you’re building. When building a reusable template, there is a level of abstraction that must be accounted for. It’s a focus on the presentation layer for its own sake, rather than as the wrapping paper laid over the all-important data.

Over several years of template building, I’ve found there are several important notions that increase the efficiency in template creation as well as the overall quality of the deliverables.

Pick a Server-Side Scripting Language

PHP, JSP, ASP- I don’t care.

Identify variations in user or system state

A site of any complexity will have some level of variation in user or system states (authenticated vs unauthenticated, empty shopping cart vs non-empty). Identify these states up front, and determine what the implications are to the UI.
Create variables to represent each of these states. (loggedIn, cartEmpty). Use these variables to manipulate each individual variance across the site, in response to a query parameter being passed in. It is important to identify a default state.
By treating each variation itself, we are able to account for a greater number of combinations of states.

Be Lazy

Never code ANYTHING twice. Anytime something is on a design, ask if it will occur elsewhere. If so, make a generic version of it and include it. Coding anything more than once is not only inefficient, it risks introducing unwitting variation. If I pass off two pages to a development team and they each treat the same thing differently, which should be used? Leveraging the same code also helps to ensure the code is at an appropriate level of abstraction and can account for variation of data.
For me, the best template project involves the fewest number of discrete URLs.

Remember: this is a TEMPLATE

A template is commonly defined as a pattern. It should be simple to follow and easy to apply elsewhere. Remember madlibs? Enter in the appropriate type of word and it populates where it’s intended to be. That’s what templates should do. Define the rules around the content, and then just give it a slot to plug it in. If you have a column to hold images, build the framework around it to give the images the appropriate spacing you need; don’t expect the next person you hand the code to to apply your specific class names to elements. Dummy-proof it Make your code apply to the whole, and then only code for exceptions as needed. If possible, push back on designs that necessitate “exceptions”.

Respect the Data (Unknown as it is)

Data coming from an external source is like a box of chocolates.. In the absence of specifics, the diligent developer must anticipate the possible areas of variation and recognize the boundary cases. A certain design may work wonderfully if there are three lines of text with a font size of 10px, but what happens when more (or less!) text is needed, or the visitor increases the font size? This is the difference between the designer and the template developer: one is in search of the ideal design, and the other anticipates the limits to which it may be pushed.

Know Where You Are

Relative paths can make or (literally!) break a template project. The use of absolute urls means you don’t need to worry what page is trying to access your assets from.

Assign Appropriate Class Names

This is related to the points above, but is still worth calling out on its own. Reuse code, recognize you’re creating a pattern, and be lazy. Use generic class names related to the overall semantics or layout (i.e. navbar), not the specific data you are trying to markup (search-results-sidebar). Naturally, exceptions can be coded with more specificity, because there must be some knowledge about the particular data for it to be recognized as an exception. But manually calling out the same type of layout of multiple pages is once again introducing the possibility of error: if we have 12 pages we’ve templated out and manually apply a style to 11 of them, is that an oversight or intentional? What do we do when we have to create a new page?

Plan for failure

Depending on the level of fidelity, a template project may or may not have javascript interaction in it. If so, it’s a best practice to check to ensure an element exists before acting on it. This should go without saying anytime, but it’s particularly important when the same footer (and JS script block — you DO put your JS at the bottom of the page, right?) is being pulled into different template pages. Always check to ensure an element isn’t null before attempting to manipulate it.

Explain, explain, explain

There is no shame to commenting code. Especially exceptions or default states. A name and initials is a nice touch as well, particularly when a project is in the early development stages. Many development teams will comment in the server-side scripting language so that it is not rendered in the outputted source code, and outsiders will not be able to see it. This is great; it is only the developers who need to be aware why things were handled as they were.

These are just a few of the tricks I’ve picked up over the past several years. It has occurred to me that template building is almost a different skill than straight-forward web development, and I wanted to capture some of the nuances. I imagine my friends and former coworkers could add to the list!

As I mentioned in my last post, I am taking some time to look back on my time in grad school. A list of course titles and descriptions doesn’t really speak to what I got out of the course, or what I put into it.

4. Application of Artificial Intelligence - This was the first elective course I took in my program. Much of the course time was centered on discussion, and there was a major project of our choice. I continued to focus on natural languages, and whether a machine could “learn” language in the same way a child could.
I had initially wanted to perform some first-hand research with children, but I wasn’t sure about my ability to gather, tag and analyze the amount of data that would be required. As well, I would only be able to observe the children’s output, I would have to infer how they arrived at such input. I decided therefore to focus my attention on accepted linguistic concepts like Universal Grammar and Principles and Parameters. As it turns out, the idea of “teaching” a machine in the same ways as a child was not a novel idea, and it has seen some success. This project was intended to serve as a starting point into more detailed research, for at the time I anticipated my capstone project would be related to natural language processing.

5. System Architecture and Engineering - I had been nervous about this course prior to enrolling in it, but it ended up being one of my favorites in the program. This course was the first to introduce us to Martin Fowler’s book “Patterns of Enterprise Application Architecture”, to which we’d end up referring in several more courses through the program. Immediately, I loved the idea of patterns: identifying possible solutions for common problems, without getting into the specific implementation details. The course clearly contrasted functional and non-functional requirements, and spoke to how different requirements complemented and conflicted with each other. It was for this course that I wrote the Critique of ‘the value of a usability-supporting architectural pattern in software architecture design’ paper. At the time I was working in the Design and Usability/User Experience department at LexisNexis, and as was noted in the paper, often usability is not an initial consideration in architectural decisions. In the few months following my taking this course (and enthusiastically talking about it to everyone who would listen), I was selected as the departmental representative on the newly formed “Architectural Advisory Board” at work. We reviewed new project concepts and identified any architectural implications from the standpoint of the department or organization we were representing. I completed this course heartily acknowledging that “I want to be an architect!”.

6. Project Management of Information Systems - This was the second elective in the program. I will admit that I enrolled primarily because of the instructor, Roger Engle. On the first day of class, every student was asked what they hoped to gain from the class. I was blunt when I stated that my perception was that project managers were really baby-sitters, and I wanted to have a better sense of what they really did. Over the next twelve weeks, I gained a much better appreciation of the role of project manager, and I will admit I even toyed with the idea of PMP certification. I believe that this appreciation has made me a better individual contributor and a better team member.

7. Issues in Database Management - I’ll admit, this was one of the courses I was least looking forward to. I’ve taken database courses before, but I don’t have a particularly strong background in them. This was another case, however, where it was an ability to grasp concepts and strategies that proved to be more important than a background in a specific technology. Indeed, many of my classmates often struggled with the theoretical aspects of the class. “but how do we do this in SQL?” they often asked. We were being introduced to general concepts or best practices, and often my classmates were unable or unwilling to look beyond what they had been exposed to. We looked at object-oriented database models unlike any that current exist in the industry. Because of the lack of immediate applicability, some students resisted even learning about such. In contrast, I held no strong convictions about “how things are” (and therefore, how they are meant to be) so I was more open to the suggestion of different conceptual models.

Today was our day off after 9 days of ATG training. Yesterday afternoon, we were all mentally “full” of all we’d been learning. I wasn’t sure how productive I’d be at work today.. and as it turned out, it was one of those great days where you just can’t get enough done!

The morning started somewhat slow, but we had a major meeting scheduled from 11-12:30 for an upcoming project in which we’re to flex our new ATG skillz. The meeting went really well, we went over the strategic and creative briefs before getting into some more technical details.
Because I’m trying to get into an IA role, I was really excited about dissecting the tiny pieces that went into what we saw on the screen. For me, IA isn’t just about sitemaps and wireframes. I come to it from a programmer’s perspective: so what different objects make up the site; what are the properties of each.

techie minds at work

After the formal meeting, several developers and our director were chatting about templates, and all of a sudden I got what was described as an overwhelmed look on my face. I was thinking about templates on two levels: templates that referred to data: mapping a template to a particular type of content, and then templates as they related to presentation. The scribbling to the right was my attempt to get some of this stuff out of my head: we could describe an object (say, a press release) as an aggregate of its parts: title, description, accompanying image(s), accompanying link(s). There could be a generic template used for this type of content, with variations based on the existence of different aspects of the element. Still, the underlying template would be of a press release.

But a template could also be used to vary presentation: a template could use the same attributes of a press release, but vary in terms of its orientation (image on the right versus the left). Where does the specification of this lie? Is it on the level of an individual instance (press release 1 could have the left-hand images, press release 2 could have the right-hand images), or should there be consistency across item types. (My personal thought is that for optimal user experience, items of similar types should be displayed in a similar fashion).
It’s like the post I had not long ago about areas of variation, or all the common UI building blocks discussions we had at LexisNexis. It’s about building a web application, not a web site.

After our group pow-wow, I still had all these questions on my mind, and I cheerily sat down to go through the wireframes. I tried to identify major item types, trying to consider all the information I’d taken in over the last few weeks. One major consideration is content updates, and I think sitting in training on the managerial track next week will help me understand what tools we need to provide for people to achieve their goals. (granted, we’re talking about my colleagues, who work at an interactive agency. We all have an abnormally high familiarity with the web, so we’re not indicative of a typical client)

I’m not the architect on the project, but I can’t help but see how the various pieces will fit together. I have a strong opinion on tying together semantically related content: an individual page describes a particular item, it is not simply a group of “stuff”. The challenge is looking across items to figure out how the compare and contrast. In training I asked about the possibility for a slot to be populated with different types of media — an image, a video. The response was that a slot can only contain a single item type: but the solution is to make a generic enough “type” that all media can be supported. I want us to see these patterns from the outset, rather than pigeon-holing ourselves into having unique, un-extensible content scattered throughout.

I’m really looking forward to this process…

After 8 years of various “web-” jobs (from Web Director (Jagged) to Web Designer (Maxim) to Web Master (Youthone) back to Web Designer (Common Sense Solutions) to Web Technician (Franklin University) to Web Developer (LexisNexis) to Senior Web Developer (LexisNexis) and now Senior Developer (Resource Interactive), I’m starting to think about a shift in my daily duties.

My earliest work on the web were all centered around fostering community and facilitating communication. I was a geocities community leader. I volunteered for the Open Directory Project (back when everyone thought human-powered search results were the way to go). I was on livejournal before they required invite codes. I worked for a not-for-profit that provided youth with online support and volunteer opportunities.

I waded through a bachelor of science in digital communication, a computer science certificate, a java 2 certification exam, and am nearly finished with my master of science in computer science degree. I definitely have a technical background. But in the end, I’m a liberal arts girl at heart and I just want to give users a kickass online experience, ensuring they can meet their needs in a way that best suits them.

At LexisNexis, I was in the User Experience team, so we primarily built prototypes and went out to usability testing and kept abreast on trends and best practices for providing an optimal user experience. Even as a developer, I attended weekly design reviews and had the opportunity to contribute to crafting the solution to usability challenges. My last year at LexisNexis, I was sitting on several boards and committees (Architecture Advisory Board, Branding and Identity Committee), and was the key Accessibility Contact. Everything was firmly with the users’ best interest in mind.

I can code. Some would say I do it well However, my interests really lay in how information is presented to the user. I’m fascinated by how people use technology to meet certain needs, and how we can best support them in their goals. I am working on that “Rich Internet Accessibility” paper, and the internet has been a great way for me to read up on other opinions, and connect with industry leaders. It’s also helped me to understand the challenges some people face. One article I found on the accessibility of social networks really struck me: one user stated that it was difficult for him to seek out a speaker at a conference to ask further questions, so he preferred to look them up online after the fact. It helped drive home the fact that the internet can really help people with disabilities, if we take the time to consider their needs. (Another great example is the short film “everything I can’t do in the real world, I can do with my Mac“).

In so much as I can contribute to delivering content in an accessible, usable fashion, I will do so. However, I feel as though I want to “move up” in the process, and suggest solutions or approaches, rather than coming in at the Implementation stage. It took me several months to really recognize that I have changed where I fit in the development cycle here at Resource. In the UX group at Lexis, yes, I was coding, but they were prototypes, early in the design phases. Now I work on the final production code, after certain major decisions have already been made.

One of the key reasons Resource is a leading interactive agency is our thought leadership. We do great work, particularly in our Insights phase. Certainly, our implementations are outstanding, but I am really yearning to return back to an ‘ideas’ role, rather than a ’solutions’ one. I have been the only female developer in the company since I was hired, and I can’t help but wonder if that’s somewhat natural: women as nurturers, giving birth to children and ideas and fostering the commuity, and men as providers and problem solvers, delivering on requests and meeting specific needs.

…Hmm.. perhaps that’s not the best thing to post in my technical blog, but I’ll leave it there all the same…

I am going to start doing some light Business Analyst work, with a longerish-term goal of getting into the field of Information Architecture. I think this will be the route I need to step away from specific implementations and focus on common problems (aha, I sense a return to my previous interest in patterns). Ultimately I believe it is the goal of what a site can help a user achieve, and how he feels doing it, that interest me, moreso than the specific details of how.

I’ve mentioned before that I plan to write my grad capstone on usability-supporting architectural patterns. When I heard that UPA’s conference this year was focussed on patterns, I asked a colleague that was attending if I could get her notes. When she got back to work, she lent me a copy of Jenifer Tidwell’s “Designing Interfaces“. She had seen Jenifer speak and evidently there was a fair amount of mention of this book. Unfortunately, the day my colleague lent me the book, I put in my two weeks notice at work, so I needed to look through it quickly!

The book itself is interesting, but it is not quite what I was looking for. These are patterns specifically dealing with Interface design. Useful within a given group, but it is at a lower level than I want to focus on. That being said, I think it will be good to use to contrast with my true area of interst.

This also brings up another issue: the reason why I selected my topic for my capstone was because I had come across several articles written from an architectural or programmatic standpoint that spoke of a lack of a pattern language that could be used to describe usability problems. It seems to me that the patterns in this book do not manage to bridge this gap between the disciplines. However, I may be saying this with bias from my experience. We were fortunate enough to be provided with detailed UI specifications, as well as visual design mockups and wireframes. It is possible that this pattern language could have streamlined some of this.

Even the description of patterns in the preface is slightly different than what I am accustomed to:

“In essence, patterns are structural and behavioral best practices with a given design domain. .They capture common solutions to design tensions (usually called “forces” in pattern literature and thus, by definition, are not novel.) …. This book describes patterns literally as solutions to design problesm because part of their value lies in the way they resolve tensions in various design contexts.”

I am not sure about this notion of ‘habitability’… I suppose from the standpoint of the designer, this makes sense. Rather than recreating the wheel time and again, a given pattern can be used to describe the problem space. I suppose I see it moreso as a way to categorize, not ‘understand’. I don’t know that a given pattern makes a problem more clear, rather, it simply offers up a method to deal with them.
The notion of resolving tensions is interesting, however. Perhaps using patterns forces the designer to make choices that otherwise may not have been evident.

The book contrasts the difference between websites and web applications — as dealing with nouns versus verbs.

The book does break up patterns according to the domain — there are patterns dealing with physical structure (two-panel selector, one-window drilldown),navigation (global navigation, hub and spoke) with comments on which combinations work well together.

There is some discussion on alternative presentational methods (mobile phones), which is refreshing. This changes the model dramatically but is not considered often enough. If we design interfaces to be intuitive for the user, how does the different platform still support this? Browsing via a mobile device often allows for two main navigation keys. Is this something we can (or should) mimic on a traditional webpage?

In a discussion about common UI building blocks, I started thinking more about the development of patterns. Rather than focussing on the implementation of a specific UIBB, perhaps we need to take a step back and look at the common issues that need to be addressed. We are talking about levels of variation (personalization, customization), but perhaps we need to look at suites of patterns, with the UIBB being the ’solutions’..