Blog This!   Lee Geistlinger's Web Log

Blog Home
Blog Archives
LittleGhost Home

E-mail: geistlinger AT gmail.com

Everyone loves lists Books, Movies and so on

My Online Aggregator

Tools for Tools

WATCHING: Chicago This film - a cross between All That Jazz (another Fosse creation) and Moulin Rouge - was highly entertaining but, ultimately, not memorable. As a modern musical, with rapid, MTV-style edits and a blur between thought and reality, it is extremely well done and fun, but the story itself is weak. But, hey, it's a musical, no War and Peace, right? All movies

As I have mentioned more than once, I've been concentrating more on tools than, say, full applications recently (both in a Web-centric manner).

The difference? Well, let's use the example of a photo gallery.

• Application: The actual set of pages, databases and so on that allow an admin to post pictures with captions, edit same and so on and the front end that allows a user to view the posted images.


• Tools: Tools either support the application (usually the back end) or provide some additional functionality that is not part of the original application's scope or part of the application at all.

A back-end support tool, for the gallery example, would be a tool (process) that auto-resizes photos, so the admin doesn't have to open Photoshop before uploading pic - the tool, embedded in the app, does all the work silently. While technically part of the app, it's really a separate process that is not a necessary feature of the application (storing data in a database for later retrieval is necessary, so that process is actually part of the app).

Another back-end tool example would be a spell checker: This is not necessary to post a caption; it's a helper app to get the correct spelling that caption text. It's a helper tool.

The line between tools and applications is fuzzy in back-end processes, because a back-end app is, essentially, a collection of tools. In large part, the difference between a tool and the application proper is just a matter of project scope: Anything out of scope added later that's not really required to meet the earlier scope can be considered a tool, but that's semantics.

An example of additional functionality would be a "random picture" process: A process that displays either a random picture on each page load or a "Picture of the Day." This type of functionality is not really part of the application, because - once initial params are set - they don't require any admin intervention. Another such tool would be a referrer log processor/listing.

Again, this is fuzzy, because a random pic display is often part of an application scope for a gallery. I guess a good rule of thumb would be to say that a tool is something that has little to no impact on the user experience, but helps the admin: While auto-resized (to fixed thumbnail and full sizes) pics will create a more uniform experience to the user, it has little overall impact. Does the user care that the images were auto-resized? No. Does the admin? Yes.

And that's the crux: Tools just mechanize what can be done in an automatic manner, to free up admin time for more human-centric tasks, such as picking out the images to add/taking new pics and so on.

Tools, to me, have been interesting lately for the following reasons:

• I've built hundreds of applications, for fun and profit. It's not as challenging to build apps now.


• I've done a lot of tool work, but mainly support for apps - usually, as part of an application scope. Tools for tools' sake is newer to me than app work: Thus, it's harder and I can learn more. I like both parts of that last sentence.


• Tools, for the most part, come down to scripting. And while my Web scripting skills (HTML, PHP, ColdFusion etc) are high, my tool scripting skills are not honed as well: Shell scripts, Perl scripts, PHP for FTP processes and so on. Again, I can learn and have fun doing so.

And - ultimately - you start to get a different picture of user/computer interaction when you have a deeper understanding of both apps and tools. I'm just beginning to see that now, and it's interesting.

Much like the difference between looking at a Web scripting vs. database architecture and looking at at the same time.

Frustrating at times, but interesting. And brings up some interesting dilemmas and questions.

More on that as I begin to understand the questions, much less the answers...