ginger coons learns to blog

Design (especially graphic and web) is one of those fields that seems to breed a lot of protectionism among its practitioners. For good reason. As with writing, it's a skill lots of people possess, or at least think they do. Designers grumble a lot (and I'm no exception) about crummy work, over-involved clients, low pay and what I think of as the nephew problem ("Why should I pay such a high rate for your work? My nephew has a copy of Photoshop and can do the work for a quarter that price!"). All of this because lots of people are creative, the tools of our trade are readily available, and the results of our work don't hold human lives in the balance (much).

So designers are often protective of their work and qualifications. Those degrees, portfolios and lists of former clients really matter, because they make us feel a little safer, a little more important, and a little more as if we'll actually be taken seriously. But this can often be a source of serious tension. What brings this all to mind is the comment thread currently building up on an article about F/LOSS design. The article, written by designer, educator and generally cool guy Mushon Zer-Aviv, presents the problems and precedent behind collaboration in design. But it also makes a case for that very thing. The fascinating bit, though, is in the comments. Designer after designer has weighed in, telling some variant of the stupid client story. It's a common trope in design: the client wanted to get her hands dirty, felt really invested in the design, wrote a pile of memos, wouldn't be placated and eventually, the design died a committee death. It ended up pink, with kittens, with 72pt type or some other egregious design no-no that every other designer in the room can identify with and groan about. We get it. Clients aren't designers. If they were, they wouldn't need to hire us. There's a parable about this in the world of F/LOSS, about painting the bikes shed. Because the colour of the bike shed is something that everyone feels qualified to contribute on, they do, even if their input isn't necessarily helpful.

All of this really misses the point, though. Collaboration, with good communication and with good collaborators doesn't need to result in a stupid client story. Of course, as far as the article goes, using the word "committee" in the headline was just asking for trouble. Committee connotes committee syndrome, which designers will automatically get up in arms over, no matter the actual arguments presented. It's our own protectionist nature. In a field where creativity is the going currency and a world where everyone is trying to unleash their own inner artist, of course there are clashes. Those clashes are over ego and self worth. As long as we hunger to be right, valuable and more qualified than thou, those clashes will remain bothersome and every designer will be able to cherish a cache of stupid client stories.

As we know, I'm working on the Open Colour Standard, which is a great big daunting project which fully intends to eat a lot of time. How will I accomplish this while also working on roughly two bajillion other things (at a rough estimate)? It's quite simple: I've turned it into a thesis. It's a win-win situation. I get a degree out of my work and the rest of the world gets the assurance that I'll actually finish the project or suffer certain academic death. This is why I've been basically living in a super secret lab in the basement of a big ugly concrete building for the last eight months, drinking orange juice to ward off the scurvy that would surely otherwise set in from lack of sun. Having done a boatload of preliminary research, I'm now writing the proper thesis proposal which will make the work properly, for serious, official. Below, then, the first draft of one section of the proposal: the introduction to my research question.

The purpose of my proposed thesis is to explore the theoretical, historical and practical underpinnings of the Free/Libre Open Source Software movement, standards, colour and colour standards (especially open ones). Put more practically, the aim is to look at how standards are made, what standards do, what impact they have on professional and institutional practice, what sorts of standards exist, what colour standards are currently in existence and use and how the ideologies and practices of the Free/Libre Open Source Software movement and communities might come to bear on the creation and implementation of professional colour standards.

Put even more practically, the purpose of the proposed research is to look at the processes and problematic practices behind standards, their creation, implementation and use. Further, the research will take a practical turn, in attempting to lay out the groundwork for a new colour standard, one which keeps in mind the needs of users beyond those represented by the normal participants in the standards-setting process. This practical turn, however, is not simply for the sake of creation. Instead, it takes cues from Critical Making and other ideas of reflexive practice. Essentially, its purpose is to better understand the problematics of the standards creation, setting and implementation processes through participation in such processes, although always with a critical eye.

    This proposal offers a brief overview of the history and rationale behind F/LOSS, with background useful in the understanding of the benefit of open standards, protocols and tools. Then, an exploration of literature on what standards are, what uses they serve, how they are made and implemented, what significance they have and what tensions exist in their creation, implementation and existence. Where colour and its related standards are concerned, the review focuses on an overview of common and less common uses of colour, historical and current colour standards, the physical realities of making and viewing colour and finally, the politics of colour. Two theoretical frameworks are approached: Ratto's Critical Making, exploring the value of doing in order to gain understanding, and Star's points on the purpose and concerns of infrastructure. A description of proposed methodology follows, as well as a discussion of limits and ethical concerns which may be associated with the proposed methodology.

When I first moved to Toronto, I had some serious trouble figuring out the subway system. The wayfinding in it seemed pretty nonsensical and opaque. As I got used to it, though, it got easier. Which tends to be the case as people get used to new things. We adjust, we acclimatize, we forget about the problems we experienced as newcomers. As a result of this, I've been thinking about the question of stakeholders in cities. Who are the stakeholders in a city? There are a number of different ones: residents, businesses, tourists and so on. And in many large cities, tourists are an important element of the urban makeup, given the revenue that they bring in. That's group one: tourists, newcomers, occasional users of cities.

So what's a local? A local is someone who lives there, who fits in, who has a habitual view of a city. And that's the trick. it's the word habitual. In fact, a commuter might even be a local, at least in the area that she frequents. Someone from Oshawa who works in one of the tall towers on University Ave. is a local to University Ave., even if she isn't a local to the rest of Toronto. She's a local to the bit of the subway between Union Station and her office tower. She's a local to the restaurants in the area. She's a local to her habits in the space.

That's something I'm profoundly interested in: spatially situated habits. Because we are such creatures of habit. And it's not necessarily an innate understanding of a space that makes us able to use it effectively, it's a habitual relationship with that space. It's the idea that a commuter or local has habits built up around the spaces that are local to her. A tourist or traveller or newcomer has no habits built up around the space. Someone who is new to interacting with the space lacks the habits that serve as coping mechanisms. Which means that they have a completely different conception of what the space is and how it works. They must actually see the space.

The local ceases to have the need to see the space after a while. She doesn't need to really interface with the space because she already has her route through it. I think that's the crux of the issue. It's the idea of habit. With habit, maps and wayfinding systems cease to be necessary. It's not the habitual users, the denizens, who require wayfinding systems. It's the newcomers.

So that's the next question: how much of an understanding of the space do you actually need in order to design a wayfinding system? Is it better to be a habitual user who knows the ins and outs but forgets what the space actually is, or is it better to be a newcomer, looking at the space with fresh eyes? Is an outsider perspective more useful in wayfinding design? In short, do you need to be other in order to properly design an effective wayfinding system?

An aside: a couple days ago, I redid my main website, adaptstudio.ca, of which this blog is a subset. The redesign keeps the spirit of the design intact, but makes the whole thing easier to navigate and easier for me to update. Also, less clutter makes it look much cooler.

The other day, I found myself having one of those nice coffee shop chats that just don't happen often enough. I was in Waterloo, having walked the four km that separate the University of Waterloo Research and Technology park from downtown (are all tech workers meant to have cars?). After that walk, a coffee shop seemed like a good place to set down for a while and get some work done. I asked the man at the next table to watch my computer for a moment. This led, when I got back to my table, to a discussion about computers, the danger of losing them and, more importantly, the danger of losing the data stored on them, which is often so much more valuable than the machine.

Data loss is the main theme here. The gentleman at the next table explained that for his work, he relies heavily on reference management software, being engaged in research. That reliance, among research types, is unremarkable. Reference management software is a pretty common thing to use. I'll somewhat bashfully say that in my own research-y work, I don't use it. I just build reference lists in OpenOffice. It's not a particularly tidy or clever way of doing things, and it probably slows me down, given that, when I need to find something I've cited before, I find myself combing through piles of old files, looking for the right entry.

Given that we were discussing F/LOSS (I take every opportunity to show just how un-scary Linux and other F/LOSS are), the question of F/LOSS reference management software came up. Not being a user of such software, I didn't have any good suggestions about an alternative to the dominant applications like Refworks and Endnote. However, in an example of proper esprit d'escalier, I now have such a suggestion.

Yesterday, in an attempt to avoid writing an abstract while still pretending to get things done, I spent some time fiddling around with JabRef. And it's quite nice. It imports from a variety of sources (JStor, Endnote and annotated PDFs, to name a few) and exports a variety of suitable formats (including BibTeXML, HTML, plain text, RTF and a few different flavours of OpenOffice formatting). And, the quite nice thing, it's painless and organized. Adding a source (with any number of different fields) is simple. Searching those sources is simple, making subsets of the database is simple. I'll be the first to admit that I have no idea how it stacks up against the competition, but on its own merits, I quite like it. In fact, I think I'll be fiddling with it quite a bit in the next few months, as I try to keep my giant reference list better organized.


JabRef v. my current non-system system. It's tidy, it's centralized and it works beautifully, not to mention easily. Score one for JabRef. Added bonus: no install needed. It can be run just by clicking the "Run JabRef" button on the JabRef website. 

While meditating on the idea of standards and how they make our worlds work (prepare to be inundated in coming months by more on this topic), something occurred to me. It occurred that while similar knowledge makes groups cohesive and feel like clubs, it also serves to make them homogeneous and boring. Maybe I don't know everything other F/LOSS geeks know, maybe I'm not actually very good at partitioning hard drives myself, but I know a hell of a lot about intermodal transport. Different skill and knowledge sets are important. I know how to mould plastic of many different kinds. I know what the numbers on the bottoms of bottles mean. I know about wood working and welding. Who gives a damn if I need a step by step guide to partitioning a hard drive? There are loads of other people who know how to do that, and when I need to, I can ask them for help. Having different skills gives both of us value. And when they need something built, or want to know what the difference between a raglan and an inset sleeve are, or how to work a vacuum forming machine, I can help right back. Homogeneity bites. The point of having other people around is learning from them. Maybe my credibility gets a little shot when I don't know something that others perceive to be basic, but hell, there's loads of stuff I consider basic that they don't even approach knowing. Of course variety is the spice of life. It's a cliche for a reason.

Non-Standard Bodies, a mechanical dress/art thing/critical making experiment that I've mentioned before (without wires, and in prototype form) is progressing nicely. My most excellent and talented colleague, Mike, has attached some servos, arduinos and servo control boards to the frame that I built last week. We're using small yo-yos as winding mechanisms, as seen in the second and fourth pictures. Picture three shows the servo control board.

Below: An illustration of two boxers, boxing. The old-school moustaches were part of the brief. I'm still torn about them. Below that, a different kind of boxer. The cute kind,

Below, progress shots of a rebuild of a mechanical dress. The dress, called Non-Standard Bodies, used to have structural elements made of chicken wire, which was causing shorts. Today, I built a new frame for it, out of Sintra. Built using only a utility knife, heat gun and plastic that softens at a low temperature. The electronics are getting added back in later, once some smaller elements are added to the frame.