Why we do things the way we do them (or TheoreticalFoundations)

When people (or dogs, I suppose), grab their computer/iphone/ipod/etc, fire up a browser, and start to interact with one of these things we build, they show up with a rich history that led up to that moment. What's more, they do so in an ever-changing environment, and each of them does so in a different ever-changing environment. The punchline is that the legacy of how (western? hmmm, gotta go ask my buds...) culture thinks of information (and computers) is to leave users (all users, including you and me) blissfully unaware of all (or at least some of) this lovely contextual info. And so we hammer away at whatever tool someone else has lovingly built, demanding why the thing can't read our minds. read more... -- HilaryHolz - 20 May 2008

How we work (or approach)

Having the user understand the issues isn't enough, the designer needs to understand them, too. Which may explain the substantial overlap between the human-computer interaction community, the interaction design community, and the agile software engineering community. Some agile methodologies, in our experience, provide a framework for sense-making (and perhaps collaborative Sense-making?) among stakeholders w/re mediating computational artifacts. Recognizing the integral nature of the mediating artifact and its theoretical grounding in embodied cognition and sense-making as the context for the design, development and agile evolution of mediating artifacts is the basis of Digital Arts and Sciences.

How does all of that relate to the practical question of designing a new skin? It means that we had to start by observing and recording how we interacted with existing skins in the context of existing tasks, using techniques such as list, lump and label to analyze the leading candidates from those skins, and extracting a preliminary set of interaction themes.

A Prelim Design

We tried out both PatternSkin and NatSkin, and ended up with NatSkin partially because a number of us found NatSkin cleaner. We wanted to start with a set of interaction themes and build the design around those themes, whereas with PatternSkin we found ourselves having to subtract a bunch of irrelevant graphics. NatSkin also had the benefit of allowing us to prototype some of the theme-based interaction. (We also looked at a number of other skins, such as ClassicSkin, which never made it to the trial stage for various reasons.)

That said, NatSkin has some really problematic behavior, the most obvious having to do with editing. TWiki:NatEditContrib, in its native form, provides gentle assistance along the learning curve to the TWiki Markup Language (TML). For whatever reason, not only does NatSkin hide TWiki:NatEditContrib behind a WYSIWIG editor, it also removes the vast majority of the Wikiwyg tools. We had a very hard time (apparently this is common) getting editing to work at all with TWiki:NatSkin.

KoalaSkin, e.g., http://biowiki.org/ has many nice features, but it was never ported to Dakar, let alone the current release of TWiki. The developers are no longer maintaining it. They considered NatSkin, but decided not to adopt it. They are now working on a new skin...

Looking at how we had using our alpha installation, and at the default configuration for NatSkin, we identified an initial set of five over-arching themes that affect interaction, comprised of a mix of actions and organization:

• web & subwebs
• utilities
• topics
• search
• personalization

You can read more about the process of sorting out interaction themes based on what users want to accomplish using the twiki in InteractionThemes.

We settled on a prelim customized skin design, which I'll make up in some drawing program and attach as a PDF.

I'm doing the actual interaction design development in Sandbox, so if you want to watch, you can check it out. Actually, I am happy to have you do that, as I welcome any and all comments and feedback.

AhatSkin

I implemented AhatSkinV0dot01 quite quickly (about a week), using NatSkin's WebComponent system (view a screen shot.) I presented it in lab that week to get people familiar with it and to get some feedback. That skin is what is running on the whole TWiki installation at present.

re-factoring

• NatSkin's default presentation had notification split into multiple topics that were spread all over the place, with a very tool-centric presentation of the information. This became apparent once we went live with Ahatwiki.AhatSkinV0dot01, leading to the following todo entry:
  • mailnotify
    • move see also refs to rss and atom feeds to top of page
    • remove utilities entries from main pages
    • we ought to be able to do this in one consolidated place, say in People, then propagate it out. I don't think we want different notify topics in each subweb, do we? I think we'd rather have a single notify topic in each main web, and have people customize themselves. I suspect we have lots of notify topics because we didn't really know what we were doing.

Reality as opposed to expectations...

I never actually got around to making up the prelim skin design in a drawing program - NatSkin's WebComponent system was so useful as a bootstrapping tool that I ended up being able to do my layout work with the IddWeb itself. OTOH, no one saw this and responded to my comments about the IddWeb, etc. Until we got rid of TinyMCE and got NatEditContrib working right, we were fighting with the interface so much that it was really hard to get much of anywhere. Also, until we bootstrapped AhatSkin, it was really hard for people to find anything. Finally, natsearch is a real liability, WebSearchAdvanced is a much better system. To use natsearch effectively, you have to retain a really flat web structure, however, subwebs help a lot with refactoring. -- HilaryHolz - 20 May 2008

Editors (and defaults in other tools) interfering with developing intuitive communicative information models

I become ever more aware of just how much of a role the wrong tools actively play a role in interfering with developing crucial internal models in Digital Arts and Sciences. I really saw that happen in the process of bootstrapping ourselves onto TWiki. Both TinyMCE and the default configuration of NatSkin obscured the informational relationships within the elements of the growing TWiki. I'll see if I can accumulate specific examples of this as I go to illustrate the issue.

Wow! The defaults in 'rename' are truly horrid! It defaults to only checking backlinks in this web Wow! How awful! Geesh, talk about really enforcing a flat useless architecture and throwing everyone back on search, wallowing in no-info land. Yuck.-- HilaryHolz - 21 May 2008

V0.02 Starting to put together an information architecture

Rob, Ifi and I went through several rounds of discussion, mostly in email, about the relationship between subwebs and topics. We looked at how the TWiki folks expect them to be used as opposed to how we were using them, as well as a information-driven vs. architecture-driven view. One of us needs to go back through those discussions, extract some quotes, and explain how those discussion led to our first attempt at an InformationArchitecture, especially as I now think parts of it were quite successful, while other parts not so much.

design response

• need to really use the WebHome topic in each subweb - actually very useful. For example, I removed "I've started to log the AhatTWikiInteractionDesign process. You can help by making TWikiInteractionSuggestions" from WebHome in this web, and started us thinking about organizing the topics in this web.
• see discussion on notify, etc., above

Themes mature

• I found that the interaction themes were starting to mature and stabilize, and I was starting to think about an art model to go with it, so I broke it out into its own topic: InteractionThemes

Getting more formal with sense-making

Content model

TWiki has a very tool-centric way of presenting itself - a page is a topic, regardless of whether that topic is a built in tool for managing the content discussions, or even a lower-level component of such a tool, or an overview of a set of content discussions. From a design viewpoint, that agility is one of TWiki's great strengths - one of the reasons we ultimately chose TWiki over mediawiki and a number of TWiki's competitors. TWiki is a truly lovely tool, elegantly conceived and well implemented. As someone with years in the Open Source world, I deeply appreciate that it is impossible to master everything at the same time. I guess my thought, looking at TWiki, is that its time for those of us with a deeper understanding of sense-making and interaction design in practice, who also have extensive experience with open source development, to step in and try to bridge the discourse and practice communities.

Looking at the 'out-of-the-box' configurations of PatternSkin and NatSkin, I'm pretty confident that I understand why there's a big chunk of the TWiki world stuck back at Cairo (that would be an interesting study.) In any case, people need to understand how unbelievably difficult it is for a relatively small group of developers to run around trying to meet a dizzying set of needs via software. We'll try to help out with some software, of course, but we'll also try to help out by making everyone more efficient (that's our specialty) via improving process overall, and especially the quality of communication (wait and see.)

We've taken a couple of passes through a sense-making content model (OrganizingContent) for this twiki. -- HilaryHolz - 30 May 2008

A real first pass at that info architecture

• InformationArchitecture funny how you realize what you've done after you've done it. -- HilaryHolz - 30 May 2008

Reality sets in, fast forward to next chance to work on the ID

Some comments on the context in which we ended up working on it again...

Despite our best intentions, we simply couldn't make time to get much work done on the Ahat TWiki ID during June. The last weeks of the quarter are always nuts. The next real opportunity we got to work on this was while volunteering at DIAC 2008. Working the registration desk, when things settled down, Nate Delgado and I did some pair programming on the sidebar to get him started on the TWiki.

Reflections

Working with Nate one-on-one at DIAC 2008 was very useful from a participatory design sense, in part because it got [Nate inside the design process enough to get a real feel for what he was doing while he was still very in touch with being very new to the twiki. Nate is one of my new cohort of undergraduate interns who comes out of having done at least a quarter's worth of classes taught from a Digital Arts and Sciences perspective. Charles Washington, another intern from the same cohort, is currently working on extracting key materials from the course they were both in, as well as several other courses, and presenting the materials and the enclosing context via this wiki for use by anyone who is interested. The impact of teaching from that perspective on the lab has been dramatic, not least in how much easier it has been to recruit undergrads and to get them going as researchers.

What we did

(I really need to keep this window open and keep at least quick and dirty field notes in real time...) Nate and I started by going over the Ahat TWiki OrganizingContent model. That review segued smoothly into a discussion of a good short name for the topic (we settled on 'TWiki Guidelines', which I later realized could sound too easily as if it belonged to the TWiki documentation - i.e., the software package documentation, rather than the documentation for this particular installation of package, so I renamed it to 'AhatTWiki Guidelines'. From there we went into a discussion of palettes and visual chunking, and the layout and content of all the palettes on the left sidebar of v0.02 of AhatSkin.

AhatSkinV0dot02 becomes its own skin

Reflections

I ended up keeping a lot of the day-to-day notes on design, etc., in the header of the css files for AhatSkin, of all places! In no small parts, that was a direct response to my growing frustration with having to use the older version of AhatSkin to interact with this subweb. rofl! Still, we really can't do the 'release early, release often' process with interaction design, because that quickly leads to learning exhaustion on the part of committed users. "I learned your last sub-optimal interface, now let me use it in peace, darn it!" Heck, I feel that way myself w/re cell phones. So I've gritted my teeth and coped as best I could, and kept notes in the files rather than here.

Agile software engineering and universal design

A major focus for our lab is accessibility. We generally approach accessibility through universal design principles, while taking care not to code ourselves into a corner, as it were - facilitating customization to support accommodations for specific disabilities. In this project, we found ourselves in a frequent situation with existing web software; NatSkin's implementation follows very different design principles.

As a hard-core agile type, this situation doesn't change the value of the underlying abstractions in NatSkin, or the lessons learned. I wanted to reuse those, as well as many of the insights of KoalaSkin (which has been so successful in TWiki), and so I decided to implement AhatSkinV0dot02 as a variation on NatSkin as long as possible. That way, I could really understand what would drive the change, and retain at least some of what was best in NatSkin.

Refactoring in layers of the APIs

I find I have no regrets about having decided to start by modifying NatSkin. The multi-lingual toolbox structure of the web APIs have really facilitated the process.

I started with the stylesheets, implementing substantial portions of what we wanted, working side-by-side with various members of the community from time-to-time as I went. The process has proven intriguing to some of the rest of the team, too, which I find interesting, and not necessarily those I might have expected.

Nate went to a talk at Google on universal design and came back with lots of good thoughts. Art Coleman, a long term member of the Digital Arts and Sciences team, decided that he wants to hold off on registering for a little while longer, so he can be our comparison shopper, as it were, not getting used to the AhatSkinV0dot01. I find it amusing that the appearance of the skin varies so dramatically from day to day (and moment to moment) as I am progressing from a software engineering approach.

The process has really helped clarify interaction themes a lot, making it far easier to really extract what it is that our community wants to do with the wiki and rework the skin to really support that, while keeping it fluid and customizable.

Another win resulting from this approach is that I now actually really understand NatSkin's WebComponent system, and so have used it to implement the palettes. It's really rather elegant, and can be used to put a lot of fluidity in the hands of the users quite directly. I'm finding that I am using the template language rather naturally now that I've cleared away a lot of the layers of cruft that were used to make NatSkin behave the way it did. Some of that, of course, is the luxury of implementing now, rather than when they did. Some of that is long experience with DHTML and many predecessors.

Snapshots

I saved a snapshot of the skin project (code, these notes, everything) in the subversion repository at the start of the refactoring process, and again at the transition from working purely with css and WebComponents to involving templates. After all, I could have continued with css (and WebComponents), but involving templates will make the result more robust, so needs to be tracked and later analyzed and revisited.

Some thoughts on tools and toolkits

Sphinx (for Python) is a better mousetrap precisely because it collects all the human readable components of a software artifact together into one larger whole in so smooth and integrated a process. As I've gotten further into this process, I've kept at process notes faithfully. What I've learned over time about such notes, though, is to take them on the spot, and keep them with the aspects of the artifact they concern, so that they inform future work on those aspects of the artifact. This platform has such a natural adaptability and learning curve from an interaction design viewpoint, but it lacks anything like Sphinx, so at present there isn't a central collection of the notes. Have to discuss that with the foswiki folks.

Refactoring to construct an agile foundation

Using valid XHTML and CSS in the templates was a major priority. Trying to debug Javascript without valid XHTML and CSS is, well, silly. As I moved into AhatSkinV0dot1, I worked my way through the NatSkin templates (and the other templates that were included directly or indirectly via the calling sequence), greatly reducing the number and complexity of the templates with the goal of creating a manageable, valid core codebase. Because I had a coherent design motivated by interaction, I found I could negotiate the balancing act of creating an intuitive template set while preserving collected wisdom represented in the existing NatSkin templates.