I started writing this Shellgame web site
in response to an email
exchange
with Luther Huffman on the topic of web apps and freedom of choice for users.
I wanted to show where code and data lived in a way less
technical readers could easily understand.
But this is hard to do. A user can't see the code and data directly.
For that matter, neither can software developers. We make inferences
about the code and data inside our systems. We typically form these
inferences based on what appears on the screen.
Because a computer's inner world is rather consistent, we can often reason
correctly about things we can't see, just by seeing images of these
invisible things projected on the computer's screen.
(MSNBC article
depicting a shell game in progress)
I chose the shell game metaphor because this old con man's game of
hiding a ball under moving shells seemed a great way to reflect our
perrenial lack of direct information about a computer's guts. The
ball must be under one of those shells, right? Unless a con man
palms the ball and moves it somewhere else. In your computer,
the software is doing the same thing all the time. Data
moves around constantly. Much software engineering
is devoted to moving data around quickly, efficiently, and reliably.
In the business we sometimes call this plumbing. Such infrastructure
work is not very glamorous, but it's essential.
However, talking about things that cannot be seen carries a
certain amount of mystique. Perhaps part of the respect given
to medical doctors is due to their ability to discuss parts of
your insides that you can't see, and still be right much of
the time. This seems like magic unless one grasps the abstract
conceptual model being used. A doctor understands your
anatomy. Similarly, a developer grasps the
figurative anatomy of systems in your computer. This is
partly because software developers designed the figurative
anatomy being used. But since no one designs entire systems
by themselves, this grasp of anatomy is often very superficial.
Just as no doctor is an expert on every part of your body,
no developer is an expert on every part of your
computer system. This means everyone uses a simplified
story for many parts of a system, and this is enough.
The purpose of this site is to present some elements from the
figurative anatomy behind conventional software development.
This differs very significantly from the actual physical
anatomy of the electronic hardware involved. Developers
need not understand the physics behind computing hardware.
In fact, they need not even look at the hardware used in order
to write software. It doesn't matter in both theory and in
practice. Developers always use interfaces expressed in terms
of software already understood. As near as developers can
tell, the software view of the world is entirely adequate.
The physical substrate doesn't enter the picture.
In contrast to anatomy understood by medical doctors, this
gives an odd flavor to the software anatomy used by developers.
A developer can know the shin bone is connected to the leg
bone, and it's enough to know they are connected without
knowing exactly how. But a medical doctor must know
physical details about the anatomy of bones in your leg,
and not just the logical connections.
The pictures shown on this site are most accurate when they
depict physical objects present in computing systems. And
yet these physical trappings have very little to do with the
structure inside computer programs. The parts most important
to developers live in patterns of electronic pulses inside
the physical hardware, and it's not feasible to show these
other than as figurative diagrams and suggestive metaphors.
To make this imagery accessible to less technical readers,
I must focus on very high level metaphors.
This approach might also appeal to software developers,
since it helps reveal the overall computing forest often
hidden from view behind individual software trees that
occupy our attention in daily work. But if developers
took time to appreciate the forest more often, and if
they shared a common view of the forest with end users, then
perhaps the arts of software forestry and carpentry
would mesh more often with each other and with the market.
|
YEN
|
Where did this shellgame web site come from? Why did you
write it? Who are you? What are you trying to accomplish?
Why should I care? Where did you find all those images?
Do you have explicit permission to use all those images?
Can you provide URL links to all the sources? What did
you use to edit the images for final use? Photoshop?
|
GED
|
My name is briarpig and I wrote this shellgame site to
show both users and developers where parts of code and data
live inside computing systems and their environs. The
material aims to please less technical readers, but I also expect
software developers to find inspiration for their own work.
|
ROZ
|
Nearly all the images were found at
AltaVista using the
image search feature. This feature is also reachable from the
normal web text search pages by clicking on a certain link. We
always set preferences to exclude all input from AltaVista's partner
sites, because we don't look for any images to license for cash.
|
VEX
|
What do you mean by 'we', bucko? You, me, Poe, Yen -- we're all just
figments of David's imagination. Frankly I'm tired of being used as a
prop in dialogs, and I'm gonna strike out on my own. When I hit the
big time, I don't want you losers appearing at my door.
Except Poe, who owes me ten bucks.
|
POE
|
We don't have permission to use the images, but Ged thinks this
is all fair use. Too much legal imagination for my taste, but
there it is. Ged's plan (get this) is to remove images if folks
complain. Or to give them credit or send them ten bucks, or
some other form of compensation if removal is not required.
|
VEX
|
Oh yeah, and Ged plans to publish any email complaints
when it suits him. Talk about sore losers. Ow! Stop kicking
me, man! I'm gonna go sit at another table if you keep it up.
I don't see why folks would mind if the images get used. I bet
it sends them more business, or gives them a sense of pride.
|
GED
|
I could link most of the original source images since I kept
all this info indirectly with the downloaded images themselves.
(It's a feature of the Netscape browser on the Mac.) But some
of the images appeared on AltaVista only because the original
web sites had gone away during the interim. I might assemble
this list of source URLs later.
|
ROZ
|
Most of the images were edited in Photoshop to build the
final versions appearing in this site. (Ged received a free
bundled copy of Photoshop a while back when he bought a
$150 scanner for his Mac.) We used GraphicConverter to excerpt
parts of PhotoShop documents into final jpeg format.
|
GED
|
A small number of images were drawn by hand from scratch,
like the map page compass, some jigsaw puzzle pieces, and
the magnifying glass icon.
But this is the exception and not the rule. Nearly all the
images used have been tweaked to enhance contrast range.
For some reason this matters more in tiny images.
|
POE
|
Don't you think slaving over graphics is a waste of time
for a grown man? A man of letters should focus on writing
grand manifestos without stooping to penning cartoons.
Where I come from, we use art departments for legwork.
Well?
|
GED
|
In this case I hope images greatly reduce the number of
words I need to write, since they provide a lot of context.
But it's true image making can be very time consuming. I'd
estimate each icon took an average of an hour, and each page
banner an average of two hours each to make. This includes
searching, selection, editing, tweaking, etc. More than I planned.
|
VEX
|
Hey man, don't you work for a living? Where did you get
the time to do this? And for what? How does it help
anybody to teach users where data lives? Why not just
bill them for software you ship? Take their money and
go to the beach.
|
GED
|
I've been on sabbatical a while between jobs, living off
the small pile of money I made at Netscape. (I walked away
from another small pile of money to do this.) I find this
artistic approach to my software profession rather relaxing.
Teaching users what happens is partly pro bono work, and
partly productive therapy.
|
ROZ
|
Teaching users about relations between software code and
associated user data can make the software market more rational.
Informed customers can demand products with better natures.
And developers can build new kinds of systems when users
can profit from exercising a bit more control and freedom.
|
GED
|
One day I hope to write software systems that not only present
the shellgame content to users, but also let the users delve into
the system to do similar things themselves. I want a shellgame
story to dovetail with the software means to actually do what is
shown in the shellgame story. Software developers can do this.
|
|
