
Imagemixer Label Maker User Manual
- 1 -
Welcome
This section is more or less a philosophical overview of the ImageMixer Label Maker. If you’re
leaning forward in your chair right now, pupils dilated, mouse in a deathgrip, all because of
something you haven’t been able to figure out how to do –see the . If you’re reclining peacefully,
with a comforting beverage beside you and perhaps one hand thoughtfully stroking your chin –
read on.
Our Goals
The ImageMixer LabelMaker’s mission is to be fun, quality, easy to use software. We want to be
a program that never makes you want to swear at your computer or throw your monitor out the
window. We want to help you get your labels made quickly and enjoy doing it. And we want to
help you bring out your creative side, even if you don’t think you have one.
One of the first things we realized is that if you want to be able to get where you need to go and
try all the things you want to try, you need to have your tools handy. You don’t want to have to
weed through menus and nested subdialogs and hieroglyphic-laden, randomly arranged
toolbars to get at the image or tool you’re looking for. When you were four years old and you set
out to color a picture, you set your paper in front of you and dumped all your crayons out beside
it. Everything you needed was in easy reach. You didn’t put all your red crayons in one of the
kitchen drawers, your blue crayons in a box in the attic, and your green crayons under the bed
at your friend’s house across town. That would have been stupid. That would have been the sort
of thing –and I blush to say so, because I belong to this category –that a programmer would do.
We’ve tried to avoid the programmer’s way and, instead, keep all your tools just a click away so
the program doesn’t get in the way when you’re in a creative trance (you’re in those all the time,
right?). For more details on our approach to tools and general program layout, see Getting
Around in the CD Label Maker.
Our Process
“The best way to have a good idea is to have lots of ideas.”
--Linus Pauling
My colleagues loved it when I brought in a new version of the program with some important new
feature. They seemed to think it was one of those carnival booths where you throw darts at the
rows of balloons until you pop the one with the prize behind it. “I don’t think this is clear,”one of
them might say. (Pop!) “It’s too hard to find this button,”might say another. (Pop!) “You need to
be a techie to figure this out,”a third might add. (Pop! Pop! Pop!) Eventually, having reduced the
program to rubble, we’d agree on what seemed to be the clearest, simplest way to access
whatever feature we were adding, and I’d head back to my code editor. I soon figured that I
could shorten this process by making us all argue over how to add a feature before I wrote a
version to try. This would be like having my Acousticohorts help set up the booth, so that they
knew beforehand which balloon hid the prize. Surely this would reduce the carnage. But you
know what? It didn’t change a thing. The same people who swore oaths over the best way to
arrange the tabs in the print dialog would violently disagree as soon as they saw it in action.
Some things, it would seem, like program interfaces and living room paint colors, just have to be
tried out before you know what works.