Justification for tumbledry version 15 design decisions
Computers are most useful when they get out of our way. I recently realized that when I say I work with computers, people automatically peg me as that computer geek who loves hardware, spec sheets, and processors. Thing is, I only know about them in order to get these blasted machines to do what I want to do. I spend an inordinate amount of time shoehorning machines into working the way I think, so (pardoxically) I can stop worrying about shoehorning the machines into working the way I think. I’ve always seen Windows as a respectable software tool to deal with, but I must liken the experience to taming a wild stallion (without any of the glamorous trappings inherent in the animal analogy). Windows has to be poked, prodded, altered, trimmed, augmented, and examined from the top to the bottom and up again, to get it to do what you want it to do … when you want it to do it.
I want to process words, I don’t want to find the formatting bar, close the tutorial #41 dialog wizard, or discern the subtleties of tables and headers by trial and error. I want keyboard shortcuts, a big chunk of white space, and a program that makes it impossible for me to lose what I’ve been writing. I’ve learned the esoteric underpinnings of many-a-program simply because I wanted to do something that, on the surface, seemed exceedingly simple. Case in point: the other day, Kim asked me if I could help her burn the music on her computer to a CD. I said I could try, but I suspected it to be impossible - the music industry, motivated by a desire to stop music from spreading via the technological pathways set down for that specific purpose, have not only successfully tied down a lot of music (see this fantastic and entertaining illustration thereof) but have done so largely without the end user’s knowledge or even consent. I do my best to fill in the gap between what people want their computers to do, and what they are observing them doing. Frankly, I really enjoy helping people get these darn machines to do what they want, and maybe even help them better understand their computers in the process.
And no, this is not where, despite a small urge on my part, I trumpet the fact that I like Apple and wish to buy a computer from them. But, ok … a quick take on Apple (anyone who thought I outlined these blog posts is silly indeed). Unlike Windows, things are much more “ready to go” out of the box on a Mac. By default, things are set up with an average user in mind - and from what I’ve seen, it’s a pretty dang good default. However, if there’s One Little Thing (say … OS X windows don’t maximize) that bothers you, your chances of there being an option to fix it can be abysmally low. However, I do consider the excellent shell access, combined with AppleScript and Automator a sort of panacea for any odd customization problem you may have. Translation: I’d rather deal with strange customizations on a Mac than on a Windows box. Could be simply because I’ve been dealing with the latter for so long.
Still with me? If not, a quick recap: while powerful, computers frequenly arbitrarily limit our actions, or (even worse) are not quite intuitive enough to predict how we would like to accomplish our goals on the machine. For example, I’ve seen “Clippy” directly interfere with my Biochem prof’s lectures 4 separate times. Who the heck needs an animated paperclip during a lecture on protein kinetics? Anyways, the midpoint between a static machine and an entirely task driven interactivity between user and computer is what we have now: customization. And it stinks. A lot. So we are stuck taming our wild animal machines to be tame and docile (with the ever-present risk of them running feral again) or to suffer at the mercy of default settings, obscure warnings, and incomprehensibly weird oddities of digital media protection.
All that said, I must veer once again as the above is intended to only be a sort of zeitgeist of my current computing attitude. It leads rather naturally to an introductory outline of my design decisions for the next version of tumbledry. This version you are reading now was developed in large part as a collaboration with Mykala, who helped keep me grounded and avoid the unnecessary. The current tumbledry focusses on simplicity of design (especially when compared to the previous designs of tumbledry). Unfortunately, we still have, to a large part, features that are only present for the “wow I could do that” factor. The drop-down menus at the top of the page are not particularly useful because there is not that wide of a variety of content that people wish to access on tumbledry. At the mile-high level, I’m either writing a journal entry or posting a picture. There is nothing more. So, the newest version of tumbledry is being assembled with the intent to present what is required by the user and nothing more. This aligns with my current philosophy towards computers: I’m not going to bombard you with useless cruft. I’m working on showing you what’s new, hiding that “what’s new area” when nothing is new, making commenting exceedingly easy, and giving you a kickin’ search tool to find what you have seen in the past. Tags will play a more central role, allowing a navigation driven by keywords. Don’t worry, navigation by date will also be available (and a whole heckuva lot easier to use than before) in the archives.
I’ve already squashed some major bugs, made a lot of headway into the search mechanism, and formulated some possible color schemes. If you have any feature you’d like to see on tumbledry, do let me know … because this is the very last redesign I will have time to do for an indefinite period of time. In the meantime, thanks for visiting.