 |
« | Week of Jul 6 | < | Individual Entries | > | Week of Jul 20 | » |  |
 |
 |
Photography as a Communication Medium
aesthetics, design, writing & communication
July 17, 2003, 11:29 PM
I've been learning lots of interesting things in CDF recently; sadly, since I moved last weekend and lost my broadband internet access at home for a couple weeks, I haven't had time to post about all of them. So this is my best shot at trying to play catch up.
By the end of last week, we'd finished up the photography section of the class that Charlee was teaching. Our final assignment was to combine a photograph with text to create some communication piece (Charlee likes wide-open assignments). I did a public service announcement poster type message, which I thought turned out okay, although several other people in the class put together some things that were much better, in my opinion. It was amazing to see how good everyone's was after only a week of practice and critiques.
For mine, I actually started the project intending to communicate a different message. I wanted to take a picture of an interesting but run-down street and compare it with a quote from the philosopher of art Jerome Stolnitz about the aesthetic attitude that inspired me to write Aesthetic Mornings a few years ago. But I couldn't find the right subject or the full quote, so I wound up wandering around East Liberty (a relatively poor neighborhood here in northeastern Pittsburgh) for a couple hours taking pictures of various subjects, including this bottle. At first, I wasn't too fond of any of them, but after returning home and looking at it on my screen, I decided the bottle picture wasn't too shabby, especially in black and white. But I had no idea what text to put with it. I tried a number of semi-depressing captions (I was in that kind of mood at the time) but none seemed to fit. Then I hit on "Just Another Broken Window" (a reference, possibly too obscure, to the "zero tolerance" program adopted by New Jersey in the 70s), which I thought was neat especially since the visual presentation allows you to read it as "Just Broken Another Window" as well. And so it became a public service announcement, although I couldn't quite bring myself to turn it into a just a "pick up litter" message (it seemed too trivial for the weight of the photo), so I tried to work in a larger social message as well.
I guess the point of all this rambling is that the design process is messy. Sometimes it's hard to know ahead of time exactly what you're going to wind up with, and walking into it with too precise of an idea may just end up wasting you time or (even worse) leading you away from good alternative ideas.
On a bit of a tangent, while we were doing the crit (design critique session where everyone comments on everyone else's work and suggests improvements) for this assignment we got into a discussion of how photography can be used to evoke emotions and suggest certain responses to subjects, especially when combined with text. Andy remarked that it was amazing how easy it was to misrepresent a situation you are photographing, even though you're supposedly taking a completely accurate image of the real world. There are many design variables available to the photographer, the greatest of which is the shutter itself, the box around the world through which the viewer must look. Photographers can decide what portions of the truth to show their viewers and (sometimes quite literally) what light to present them in. Thus, it is just as possible for the photographer to introduce his interpretation of reality into his work as it is for a writer or a painter to introduce theirs. But in a way this is obvious to anyone who knows anything about journalism. The interesting (sometimes dangerous) fact about photography is that it seems so real; it looks as though it is a completely accurate, objective presentation of the world. I have a suspicion that most people don't think through all this when they see a photograph; they don't ask what "spin" the photographer was trying to put on his subject as they might ask about a prose article or a painting. This makes photography a powerful medium for communication and persuasion, both of true propositions and untrue ones. It's worth thinking about the next time you're reading the morning paper.
Usable Architectures and Designing for Change
software development, usability
July 16, 2003, 08:32 PM
Recently, I've been thinking a lot about architectures for software systems as well as systems in general, specifically about those aspects of system design that make future changes easy or hard. A while back I wrote up an outline for a post on this subject, so I wanted to flesh it out to frame the discussion.
First, a brief discussion of what I mean by architecture
. For software systems, the architecture is the part of the system's internal design that determines what aspects of the system are easy and quick to change and what aspects are difficult and time-consuming (and therefore costly and unlikely to happen). They are commonly compared to the support walls in a building. If you want to knock out a wall to make a room larger, for instance, this may be relatively easy if the wall in question isn't supporting the roof. If it is, however, you can't get rid of it without bringing down a good portion of the house. Software also has support walls
in the form of the major components, patterns, and idioms that crop up all over the code. Changing these components generally requires rewriting (and retesting, reintegrating, redeploying, etc) large portions of the system. Since most industry software development teams are under a tight schedule, this generally means that modifications to the system (new features, more usable interfaces, faster performing algorithms, etc) that require making these changes don't get implemented in most circumstances.
Ultimately, the goal of any software system is to be usable (in the broad, "useful to humans" sense). Since the architecture is hard to change later, we'd ideally like it to instantiate the high-level usage of the system and related system concerns. In other words, it should support the users' main tasks and provide a framework into which newly discovered subtasks can fit in. For example, for Newsable, the architecture should support the main gathering, sorting and cataloging, and skimming and reading tasks that the user studies identified as the most critical user tasks. This would be a usable
architecture.
The problem with all this is the use of any system, even at its highest levels, evolves over time. Users' needs change, business processes change, the environment in which the system must operate changes, even the introduction of the system changes the work processes of its users in ways that may in turn suggest changes to the system itself. This means that the architectures of these systems must change as well. Even the SEI, the big proponents of "get it right the first time" software design, recognize this fact. In Software Architecture in Practice, Bass et al describe the Architecture Business Cycle (ABC)
, which describes how system architectures evolve through changing conditions. But if architectures necessarily define what is hard to change, how can we expect this evolution to take place?
We must embrace a simple truth: we will never be able to design architectures that are entirely timeless.
Extreme Programming (XP) doesn't talk about architectures; XP practitioners use the term metaphor
instead. They confound metaphors of usage (designing systems based on metaphors to real-world concepts is a common best practice in usability, for example, most appointment managers' interfaces are based on paper planners and calendars) with metaphors of system structure (the core patterns and idioms; basically, the software architecture). But this may not be an entirely bad thing. The high-level usage metaphors (the desktop metaphor of most personal computer operating systems, the conversational metaphor, direct manipulation, etc) need to be well supported by the architecture of the system. Although these metaphors do change, they tend to change less frequently, and thus they fit the rigid parts of the software structure (the support walls) better. The architecture, then, should ideally be the system view of the primary usage metaphor.
The other point XP makes about the software design is that it must change over time (remember that XP's motto is "Embrace Change"). XP emphasizes refactoring all portions of the software design (architectural or not) as new needs become available. Given that the architecture must evolve along with the system usage, this constant attention to refactoring begins to make sense. Sure, the architecture is likely to change slowly, but at least we recognize up front that this change will happen and we must be constantly steering it in the proper direction. It's much easier to make many small changes over a long period of time than to make huge sweeping changes all at once (during which you'll be hard pressed to get anything else done, like adding new functionality).
But it's rather unsatisfying to think that the best answer we can come up with to the software change problem is Well, you just gotta constantly keep your eyes open and do the best you can to adapt the system to new needs.
We'd prefer to find more perfect metaphors that change less often, so we can spend less time refactoring and more time adding new features, improving the interface, etc. Is this even possible? I would answer yes, but only through close examination of the very thing that defines the software architecture to begin with; the ways users work with the system, especially the ways this work changes over time. Getting at this data is difficult, but once found, the metaphors and architectures developed through these studies can be reused through product lines. Organizations that achieve this capability will possess a huge competitive advantage.
Unfortunately, few organizations (if any) currently possess such capabilities. In general, hoping for timeless architectures is unrealistic. To a Taoist, everything that lives must change, and those that refuse to change, die. Architectures that are healthy, that are being used by real people doing real work, will need to adapt to remain healthy and continue to do good work. Those that stay static, like everything else in this world, will soon die.
Posted by angie.s born on August 18, 2003 at 06:51 AM
i am working on my diploma project about 'adapting intranets to changing user behaviour' and need some reference (studies, etc.) to evidence (or substantiate) that user behaviour changes over time. you mention the SEI - do you have further references proving what you say (and I believe)? thanks for your help
Posted by Rob on August 19, 2003 at 05:57 PM
I posted a new entry today that lists a number of different sources that make the argument that usability and software architecture are interrelated. Unfortunately I don't know of any studies that prove user _behavior_ changes over time (it seems to me to be pretty obvious to anyone whose worked with software that work changes when you introduce new technology). There may be studies that prove something similiar though. I'd suggest checking the CHI proceedings or one of the ACM's SIGCHI journals. If anyone's done work of that nature, it would likely at least be referenced in one of the major HCI journals or conferences.
Email Rob:
Email Rob: