French Wall Art Photos by Me.

Man, have I blown a lot of time on this: French Wall Art photos I took this last spring. Just the tip of the iceberg of stuff I never posted last year, especially the ones from Paris which I quite liked, for once.

If you like the Misstic graffiti pics I've posted before, there is more here. And some other phenomenal street artists.

Ice Photos and Photo Blogging Wishlist

My referrer logs suggest I'm not keeping up with the needs of depressed teens on Xanga and MSN Spaces for bleak winter photos to illustrate their poetry. So here's a few recent ones of ice in Massachusetts.

In the photo blogging software update, I have none and am increasingly frustrated. I'm one step closer to just using Flickr, but I am reluctant to send people there when they click on my pics. I am not cool, I guess, in that I am not a fan of their UI for viewing, at least not till they let me customize the page experience a bit better. In case anyone has any other recent suggestions, what I need is this: tagging, auto thumbnailing and image reduction on upload, option of date or tag viewing, display of optional captions. Ideally CSS etc. for the pages themselves. Help, anyone? (I don't want to install and fix up Movable Type just for a photo blog, life is too short.)

Illusion of Explanatory Depth

Fantastic post here: Mixing Memory: The Intellectual Teeth of the Mind. Chris is writing about the Illusion of Explanatory Depth, a cognitive science observation that people often think they know how things work when in fact they don't know.

The old-time reader who knows me will automatically connect this to one of my favorite findings of recent years, that I seem to repost every six months: Incompetent People Really Have No Clue that they're incompetent (that was the popular press reportage, here's the scientific article).

Back to Explanatory Depth:

The idea behind the illusion of explanatory depth (and it may be a dangerous one) is simply that there are many cases in which we think we know what's going on, but we don't. There are many great examples in cognitive psychology (e.g., psychological essentialism, in which we believe that our concepts have definitions, but when pressed, learn that either they do not have definitions, or we don't have conscious access to those definitions), but you don't have to look to scientific research to find them. If you ask 100 people on the street if they know how a toilet's flushing mechanism works, many, if not most will tell you "Of course I do!" But if you then ask them to explain it, you will quickly find that they really have no idea how a toilet's flushing mechanism works. This is the illusion of explanatory depth. They know that when they push down on the flusher, the water leaves the bowl, and then fills back up, but they don't know how this happens, they only think they do.

In experiments, it was shown that participants' ratings of their own knowledge of a subject decreased over time, upon being asked to explain device functioning and having problems doing so, and upon receiving explanations that clarified their issues. They realized what they didn't know, by being forced to explore it and being "corrected," essentially.

Chris recaps 3 factors that influence the phenomenon:

• Confusing environmental support with representation: People may rely on visible parts to build their (shallow) theories about how things work. For me this relates -- very tangentially-- to the notion of "affordances" in UI theory, where roughly speaking analogies to physical world behavior are sometimes leveragable for indicating functionality of controls. I have to think about the implications a bit more.
• Levels of analysis confusion: Multiple causation means you can stop at any level you want, and usually stop early. For me this raises the question of when a level is sufficient, and whether it always matters to go further? In UI design, we want to work with and understand existing mental models of application behavior, but also educate our users with feedback in the UI about necessary differences between their "naive" expectations and how things really work. We don't need to explain object models and for-loops in our code (hopefully) but we sometimes need to indicate relationships that aren't obvious to our users from their current world knowledge.
• Indeterminate end state: People have a hard time knowing when they know enough, partly because of the above point. Stories about how things work help clarify this, because of their determinate beginnings and endings -- assuming they're well-structured and not ultra-postmodern and intended to confuse! (This reminds me, again tangentially, of Harvey Sacks' proto-story told by a small child: "The baby cried. The mommy picked it up." Causation is represented, there's a problem and a solution, a beginning and an end. But it's also a story of the most simple analytic level possible!)

Chris says: To sum up, then, the [Illusion of Explanatory Depth] exists for explanations that involve multiple relations between parts, particularly causal relations, but not for more surface knowledge (e.g., facts, stories, and simple procedures), and it shows up fairly early in childhood. The concern it raises for doing science is that increasing specialization -- depth in branches of science -- means shallower understanding on the part of practioners of mechanisms outside their immediate field.

Now see the article noting that geniuses built their work on the work of other geniuses. Although not all examples are cross-disciplinary, it's clear that cross-disciplinary work is a huge opportunity and an increasing challenge.

More Adobe: After Effects Tour

Whilst avoiding blogging about irritation-provoking topics (e.g. the science article claiming men like women who laugh at their jokes but don't care if women are funny-- thanks, steve!), I happened on some good news: A video demo showing off some new features in the new release of Adobe After Effects.

Quite possibly the healthiest team at Adobe when I was there, AE had good UI design, good team process, famously good project management, good tools for tracking workflow internally and customer issues (actually integrating the two, good grief!), and a user-centered modified agile development philosophy that actually worked. Someone on their team should be writing articles about their processes, hint hint.

The new product shows some nice UI improvements in palette and window management, as well as 2 tools of great usefulness to me and many people I know: precision time fx, and smart blur fx. The graph UI controls make the chart geek in me salivate, too.

Note the increasing number of product integration features. I keep hearing about AE and Flash, so it's continuing even with Macromedia in the corporate mix now.

Printing with Photoshop

When I was working on UI design for color management at Adobe (for CS2), one of the things that made our cut for "must fixes" was the print options in Photoshop. They looked like this, if you recall:

The goal of this original design was to provide enormous flexibility in how printing is accomplished with respect to color handling. Color "management" is a hard science topic that is not for everyone, and barely understood even by most creative professionals in the print industry. The average Jane trying to print her photos in Photoshop (or even the average consumer pro photographer) was tripped up by this dialog all the time. What does it mean, "same as source?" When should I choose something different? What combinations are good and which are bad, and for what??

The short story of color handling is that there are conversions going on all over the place -- an image viewed on the screen looks one way, because it has been interpreted by your OS and screen settings to be seen as you see it. It may not be seen the same on anyone else's screen. A common complaint from the common user of Photoshop is "I printed and it looked different." It will always look different, because you are now converting to what your printer can print, not what your screen can display.

"Profiles" are descriptions of how the colors in a file should be handled in conversion, more or less. One of the strengths of Photoshop is that it lets you simulate ("proof") how something will look on another device. You can even use your printer to simulate another printer. But you have to pick all the right combinations of profiles, and have good ones so you get accurate previews.

Photoshop has an excellent conversion engine. Some printers do too, and some consumer printers do, but you can't be sure. Every device will differ a little, and consumer profiles are batch produced. I grew up in my understanding of color handling at Adobe concluding that I'd never use my printer's color management because these consumer devices just won't be reliably good; I'd rather trust Adobe's world class color scientists, with whom I was then working!

Now, here's the shipping (CS2) version of the design I helped to produce to clarify your choices in Photoshop, showing the two crucial options for home printers:

We couldn't do much about the consumer printer drivers and in particular couldn't override their own color handling, so we relied on rollover help that I think ended up a little vague about what you need to do next. In my Canon printer dialog, the necessary place for enabling or disabling color management in the printer is buried in this "ICM" language:

But now that I have the new Photoshop CS2 UI to experiment with, I've discovered (to my chagrin) that a color management problem I hadn't been able to diagnose is Photoshop's conversion's fault. At least, I get the best results from enabling color in my printer, instead. The preview my printer driver gives me before it prints is quite accurate, it turns out:

There's obviously a lot more to say about color management in printing (entire books have been written on it), but my reason for posting is to say: I hope we made the world of the Photoshop user a little simpler, at least as far as debugging their printing issues goes. I haven't heard any customer feedback on this myself, but it sure has helped me! (And I was privileged to have been able to work on this with the color management team at Adobe, including Lars Borg, Chris Cox, Russell Williams, and Matt Philips.)

Map Things of Interest

Not the post I was intending to make tonight, but I've just freed myself from an accidental click on the Canadian Cartographers web blog that somehow ended up in my Bloglines reading list. A bunch of it was fun stuff, if you like maps.

First, this amusing item that I blogged right away, before editing the post to add the rest: The Prejudice Map shows a map of the world with callouts identifying stereotypes gathered by Googling "X is known for" where X is a nationality or cultural group.

Some hilarious juxtapositions appear, like Turkey's tags: "Hospitality. Using weapons." It's unscientific, but as a travel map it isn't completely useless. For instance, it makes me want to go to Cuba: "relaxed, humor, sophisticated jazz." On the other hand, you have to admit that the UK sounds pretty bad unless you like dirty but posh restaurants with nice management: "fair play, aristocratic kitchens, extemely unclean, rarely complaining."

Then, there's the now ubiquitously blogged Starbucks Center of Gravity in Manhattan map, which I include just in case anyone living in Manhattan cares to know where all the neighborhood coffee shops went in their neck of the woods. Apparently there was also once a Starbucks Avoidance map, but the link is broken.

Try the Avenza Publisher Map Awards, which are all maps produced in Adobe Illustrator using GIS support. Winners available in PDF and jpg. Good news for any Seattle readers, the Grand Prize winner is a geologic map of WA state, and a runner up is a hiking map of King county. How they were made is described, which is very cool. As is this quote from Van Gogh they stuck on top: "Great things are not done by impulse, but by a series of small things brought together." But in the "you've got to be kidding me" category, there's the interactive map of Bethesda, MD. I grew up near there, Bethesda is not interactive.

A map of the world showing dots corresponding to newspapers, from newseum, and when you roll over the dot, you get a thumbnail of the front page. It expands to mostly readable. Quite useful, actually.

Seemyroad is filming towns, and has Zurich down pat. Zoomable overhead map, plus. You can get ride-throughs of locales, reminiscent of the Paris ferrari's bumper video, except not so illegal. (They stop for pedestrians and red lights.) You can also get a tramline fly-over from the sky. I'd really enjoy this for London and Paris.

Fair Isle Travel Tales

Despite what it looks like from these pictures, everything on Fair Isle is not blue and red. Some of it is green, but there are red birds. There might be blue birds too, but I didn't see any. There are definitely a lot of cliffs and weather and some very nice people with telescopes.

Read about my 2002 trip to Fair Isle in the North Sea, in my newly polished old essay, "Twitchers and Tweeters of Fair Isle". It includes many photos, and it took all day (there's just got to be a faster way to do this web stuff....).

Donner Party, pigs, maps, mayans...

Apparently, the Donner Party cannibalism legends remain unproven.

Do we really need glow-in-the-dark green pigs? Apparently we do, and these ones are better because they are entirely green, not just patchy green like the previous attempts.

Mayan writing is older than we thought. (How old did you think it was?)

And there is a debate going on over whether a 1418 map shows that the Chinese discovered Rhode Island before Columbus found America. The fact that the admiral was a eunuch seems to merit reporting in the TimesOnline.

Fred Brooks and Late Projects

Scott Berkun, rapidly becoming one of my favorite reads in the internet for his sagacity about software projects, points to an interview with the legendary Fred Brooks in Fortune magazine.Fred is of course famous for The Mythical Man Month, in which he argues Brooks's Law: "Adding people to a late software project makes it later."

The article itself has some stellar bits of quotage in it, including these:

Brooks' law depends heavily on the amount of information that has to be communicated. So the argument is that if you add people to a project that you already know is late, which means you're at least in the middle of the project, you have to repartition the work.... Sometimes that can be done by subdividing the existing units, but sometimes you have to move boundaries. That's a lot of work. The next thing is, you have to train the new people.

...Peter Fagg, a really wise System/360 engineering manager, gave very sound advice: "Take no small slips." That is, if you're going to take a slip, get everybody onboard, get organized, and take a six-month slip, even though you may at the moment feel as if you're only four months late.

...The other was when I was a new IBM employee and heard Vin Learson, a VP at the time, later CEO. He said, "The problem is not to make the right decision; it's to make the decision right." ...I came to understand that he was talking from an executive-level point of view. ... Either way can be made to work, but it's very important to pick one and then go whole hog. A counter-example is IBM's PL/I language. They adopted it, they backed it, and then there was a spell when they decided maybe it wasn't going to be the language. And then they decided maybe it was going to be. As a consequence, most customers didn't stick with it. The wishy-washiness killed it, I think. Whatever you're doing, you'd better go do it.

Visibly wishy-washy corporate "positions" can be fatal or at least very damaging to a business. But it's unfortunately pretty common to hear one's customers say, "We're not sure what you're telling us to do" or "What are you recommending here, you have us confused." Brooks has some comments on open source that are interesting too.

Scott notes that there are caveats or objections to the original Brooks Law linking project lateness and adding manpower (item summary here, he says more about each): It depends who the manpower is. Some teams can absorb more change than others. There are worse things than being later. (Producing better quality work might justify being later, if you've identified a role or expertise that's required.)It depends on why the project was late to begin with. Adding people can be combined with other management action (...such as cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc.).

Smart stuff.

Shadowland in Beta

A day late and an OS short... Adobe's first new (internal, from scratch) product in yonks is finally out in early beta: Lightroom. Only for Mac, alas. No, it's not a response to Aperture, as everyone thinks on first hearing about it; it's been in development forever, even when I was there.

This is a lengthy story of the dev. history, a bit too starry-eyed, People-magazine-style for me: Photoshop News » The Shadowland/Lightroom Development Story. Pretty much my take on this whole thing is "Don't try this at home," and better yet, "If we try this at the office, can't we all do better?" Is it that hard to innovate, incubate, and manage the release of a new product?

Maybe one of the lessons here is "Make sure you've got a good UI designer on staff during the whole process." But I'm definitely biased on that reading.

"Popping In On PopCap" Games.

I got this nice article off Amy Jo Kim's blog. Gamasutra on PopCap: "James Gwertzman On Casual Growth" describes the process of game development of "casual games" like Bejeweled, which is one of my favorite Palm Pilot games.

"Our path of development is extremely prototype-heavy," said Gwertzman. "We'll make half a dozen prototypes, and pick just one of those to be a hit casual game. And once we develop that one, it's a very iterative process. It's a sandbox model. We try different things out, and find out what's fun. Only when we find out that the core mechanic is fun do we worry about the art, content, and all the other little details."

"We really obsess over the core game mechanics. In a game like Bejeweled, hardcore developers look at that and might think it's kind of...it's very easy to kind of dismiss it, but we literally spent weeks on just the right way for the gems to fall when you make a match. In a game like that, it's little details like that. How does it feel? Getting those little details right is what we prioritize. So when we're designing a new game, we'll spend months and months prototyping core mechanics."

As Amy Jo noted, they're iterative; and interesting to me is that they still work hard after identifying the good gameplay principles. The design details really matter! As Gwertzman says, "We compete in a try-before-you-buy market, and we believe competing successfully there is a fundamentally different kind of design." And fun is an incredibly demanding business to be in-- no one has to use your application for their paycheck, after all.

Their game engine is available for free, I was interested to see.

Usability Research References

Human Factors International (a well-known consulting firm) does end-of-year summaries of important usability research findings in bite-size bullet pieces. The items are useful for designers and researchers working on any UI topic, but there's a definite focus on web design (for obvious reasons). The review is titled Yeah but can you give me a reference?

The 2005 list includes:

• What users think/ say they will do in focus groups and what they actually do in usability tests often differs. (Eysenbach and Kohler, 2002) [This is a truism often repeated, but now there's a reference you can cite!]
• Tolerable wait time is about 2 seconds. Users will wait somewhat longer if there is feedback that something is happening. (Nah, 2004)
• Use of whitespace between paragraphs and in the left and right margins increased comprehension by almost 20%. (Lin, 2004)

They did the same in 2004 and 2003. Interesting cites from those years include:

• Less than half of users take advantage of breadcrumbs (even when most report having noticed them). (Lida, Hull and Pilcher, 2002)
• Under click-stream analysis, breadcrumbs are not more efficient than other approaches to navigation. (Lida, Hull and Pilcher, 2002)
• Color similarity has a stronger perceptual influence than common region, proximity, or grouping. (Beck and Palmer, 2002)
• Photographs do not increase the trustworthiness of already credible sites. They do, however, improve the credibility of sites that are not generally perceived as trustworthy. (Riegelsberger , Sasse & McCarthy, 2003)
• Heuristic review tends to uncover usability issues related to presentation (skills- and rules-based user performance). (Fu, Salvendy and Turley, 2002)
• Usability testing tends to uncover issues related to domain-specific knowledge and interaction (knowledge-based user performance). (Fu, Salvendy and Turley, 2002)

On the final subject, another issue of the HFI newsletter features an article on Pitting Usability Testing Against Expert Evaluation. This is an excellent piece, summarizing well the things that expert evaluation can do for you and what to realistically expect from usability testing -- including where they overlap.

The Office 12 Blog

If you're wanting to catch up on the hullabaloo about the Office 12 redesign, Jensen Harris has just reorganized his links and provided good access to summary articles on his blog. See An Office User Interface Blog.

Also, I've been finding the Excel redesign posts interesting over here; I especially like the highlight-and-get-instant-math, and the little color bars indicating relative value differences at a glance in the spreadsheet. Lots of good stuff going on.

My Site Traffic (an Unscientific Report)

In the last year, I've browsed my traffic logs on and off, and noticed a bunch of things get visited a lot. I haven't tracked it carefully or with real numbers, but it looks like these guys are winners:

• Crop Circle Montage
• My Siberian Vacation Essay, which gets read quite regularly (although I never get any email about it, sadly).
• My Temporary Wallpaper posting. It gets hit by search terms, surprisingly. There's big business in this, for someone.
• The sadly defunct photo blog pages. My New Year's resolution is to fix these.

Search terms that hit me a lot include "girls on boats" (no idea why!), my name, Siberia, Windhouse, and for a while the Caspian sea merman sighting brought me some occasional traffic.

In honor of the Windhouse traffickers, I have finally cleaned up my old post about the folklore of the Shetland haunted house and put it up off the essays page: The Haunting of Windhouse.

Sand Game

Steve didn't really do this sand game justice when he rec'd it. It's beautiful and surprising. Tips: fire eats plants, water feeds plants, and it's all pretty. Try mixing the sand colors.