Interview: Dave Hoff and Anthony Webb of IMified · 571 words posted 02/28/2007 05:29 PM
Dave Hoff and Anthony Webb recently launched IMified, “an instant messenger buddy that works across all major IM networks and offers access to a growing number of web applications.” While I’ve worked with the ColdFusion Event Gateway to build automated bots in the past, I’ve never seen the Event Gateway used so well for such broad purposes under a heavy load: IMified provides a single chat interface to Basecamp, Remember the Milk, Google Calendar, and more. I asked Dave and Anthony to talk about their service. And if you haven’t checked out IMified yet, it’s worth your time.
since1968: IMified is one of those great ideas that seem obvious only in hindsight: an IM content aggregator. How did you come up with the idea?
IMified: The idea for IMified came about when I was looking for an easier way to post todo’s to my Basecamp account. I found myself neglecting to add stuff to my projects because the process to do so was too cumbersome. Basecamp is a service I use a lot but doesn’t really warrant me leaving it open in my browser all day. I use IM throughout the day for staying in touch with colleagues and family. It’s always open and available, yet unobtrusive and was a logical interface to “fire and forget” simple data entry tasks.
since1968: Rails gets most of the “Web 2.0” attention. How did you decide to use ColdFusion?
IMified: Choosing anything other than CF as platform wasn’t really an option. Anthony and I are CF developers. When the concept for IMified was finally laid out, ColdFusion became the logical option due in most part to the excellent Event Gateways that are offered out of the box in the enterprise edition. The event gateways allow us to tightly integrate with the IM networks we connect to.
since1968: You say on your blog that your initial growth was almost accidental. For all we know you guys may be running a higher load on the CF Event Gateway than anyone else. What is your load?
IMified: Before launching IMified we did some research and tried to find others out there making use of CF’s Event Gateways under a heavy load. We didn’t find much information to go off of and were really surprised to see that the event gateways were so under utilized. We are handling a very heavy load and CF has handled this load like a champ! Our down time to date has been due to problems with some of the IM networks we run on and one out of control log file that grew to 30gb. In just 3 weeks of operation, our users have completed over 60,000 tasks through IMified!
since1968: What pitfalls did you encounter with the Event Gateways?
IMified: Honestly, none. There haven’t been any surprises as of yet and we don’t expect to see any soon. We’re really impressed with their performance, stability, and ease of use.
since1968: Do you have plans to monetize IMified?
IMified: Yes, we most certainly do. Someones got to pay for all this bandwidth! In the next few weeks we’ll be launching the next phase of IMified that we feel will really change the way people think of IM. We want IMified to be your go-to buddy when you need to get something done at your desk or on your mobile. Somewhere in there will be a business model. Hint hint… API.
since1968: Thanks for your time.
Comment [5]
* * *
Mark Hamburg Interview: Adobe Photoshop Lightroom Part 2 of 2 · 1691 words posted 02/15/2007 08:57 PM
Last month I spoke to Mark Hamburg, Adobe Fellow, former Photoshop architect, and founder of the Adobe Photoshop Lightroom project. In the first half of our interview we discussed Lightroom’s lengthy gestation and innovative UI. Here’s the second part of our talk.
since1968: Lightroom’s first beta was Mac only. Thanks for the Mac love—but why did you choose Mac first?
Mark Hamburg: I’m primarily a Mac user, and as it happens a lot of people on the initial team were primarily Mac people. We’ve now got some hardcore Windows users on the team for balance. We started out doing what was much more a research project, though, and it seemed sensible to only focus on doing one platform first.
We actually spent a while at one point starting to get things running cross-platform and that managed to sidetrack most of the project. The lesson there was that when you are still figuring out what to build, you don’t want to let yourself be distracted with coming up with cross-platform architectures too early. You want to keep cross-platform in the back of your mind, but the most wonderful cross-platform strategy without a product to build on it doesn’t really get one anywhere.
Another thing that influenced us in this regard is that Photoshop started its current code base in the early 90s. Though it has evolved over time there are certain assumptions built in very deeply that reflect the state of the art at that time and the Photoshop team is having to do a lot of work to move beyond them. When we started what would become the Lightroom project we wanted to focus on building for “modern” operating systems. Mac OS X by that point had been out for a while and was more or less settled. On the other hand Microsoft was busy still just talking about Longhorn, so Mac OS X was in a better position for us to start on when looking for a modern OS.
The irony here is that Lightroom 1.0 ended up being built for XP rather than Vista, and we’ve already felt some development pain from that.
Finally, we knew that in reaching photographers it was really important to get to the influencer market and that market was largely a Mac market. If you go through and look at how the market breaks down among photographers, the influencers tend to be heavily Mac—not entirely, but heavily. The mainstream working photographers frequently are on Windows. In the “prosumer” market Windows still dominates but there’s a mixture. Knowing that we wanted to start with the influencers, we needed to be on the platform they were going to be on.
since1968: Lightroom is 40% Lua. How did you select Lua? Which parts of the program are handled by Lua?
MH: I foisted Lua on the rest of the team which actually at that point was very small. But I had discovered it just in reading some of the mailing lists I was on—I think it was actually a garbage collection mailing list that led me to it.
I wanted to build an app that was heavily scriptable and was looking for a good scripting language to build in and got the pointer to Lua. I’d actually read one of the first papers on Lua several years earlier but hadn’t pursued it because it hadn’t been relevant to what I was doing. At that point Lua was also much more primitive than it was when we picked it up.
Lua has an appealing balance of simplicity and power. It’s small, fast, and easy to embed. It also has a very straightforward license associated with it. It’s very much like Scheme language I like—but without a syntax likely to make people go running for the hills. So there were a lot of things.
I looked at some other things. I looked at JavaScript: Adobe had an internal implementation of JavaScript but it wasn’t as easy to do drop-ins and all the things we wanted to do in the Lightroom project. I looked at Python, I looked at Ruby. Some things were going to be bigger, slower, and had licenses that were harder to figure out. Lua just happened to fit really well.
So what we do with Lua is essentially all of the application logic from running the UI to managing what we actually do in the database. Pretty much every piece of code in the app that could be described as making decisions or implementing features is in Lua until you get down to the raw processing, which is in C++. The database engine is in C; the interface to the OS is in C++ and Objective C as appropriate to platform. But most of the actually interesting material in the app beyond the core database code (which is SQLite) and the raw processing code (which is essentially Adobe Camera Raw) is all in Lua.
since1968: What development environment do you use to write Lua? LuaEclipse?
MH: We have our own development environment. On the Mac side we have a fairly sophisticated IDE that was developed internally as one engineer’s first project when he started on the team. We have a Windows IDE as well. It isn’t as sophisticated as the Mac IDE. I think the people who are doing their primary development on Windows are generally either using the Windows IDE or they’re editing the source code in Visual Studio.
since1968: Whoa—Adobe is known for building or acquiring some famous IDEs: HomeSite, Flex Builder, Dreamweaver. Did you look at your stable before building your own? Any change the Mac IDE will evolve into a future public project?
MH: Tim Gogolin, the engineer who built the IDE, gave a demo at the Lua Workshop in 2005 and had lots of people drooling. We’ve contemplated on occasion whether there was a good way to release it to the public, but it’s pretty tightly coupled to the rest of the Lightroom implementation. It will, however, definitely be included when we do a serious SDK for Lightroom.
since1968: Lua’s not such a common scripting language. Apart from a legion of World of Warcraft modders, do you have to grow your own Lua talent?
MH: Yes, we have to teach people Lua. The benefit is that it’s fairly easy to learn. One of the people who joined the team was an avid scripter anyway, but his comment coming in was that Lua was easier to learn than JavaScript.
since1968: On the Mac, did you use LuaObjCBridge or write your own bridge to Cocoa?
MH: We wrote our own bridge.
since1968: Let’s talk about extensibility. Adobe will release an SDK sometime after 1.0. Data from C is directly accessible in Lua’s userdata type, so presumably Adobe could really open up Lightroom to be extended as far as a developer can take it. Will developers be able to write extensions in Lua?
MH: [Laughing] Developers will have to write their extensions in Lua. At one point—and it probably complicates the app a little—there was probably some notion that we’d provide ways to let people write things in purely native code as well. But I think at this point you will have to write at least part of your logic in Lua for knitting into the rest of the system.
When people ask “What do I do for Lightroom development?” I tell them “Go out and learn Lua. Hack World of Warcraft until we’ve released an SDK.”
Any APIs we publish we’d like to commit to supporting long term. In getting a 1.0 out as we’re sorting through some of the feature set there’s a fair amount of churn on the APIs that we have. Putting out an SDK means we need to start freezing those a lot more, so that’s essentially the delaying factor. After version 1 we get to go through and sort through and say “Yes we can commit to this. We can publish it and put it in the SDK.”
since1968: What’s the coolest Lightroom feature that people haven’t noticed or hasn’t been mentioned in the blogs?
MH: One of the things people haven’t entirely gotten is some of Phil Clevenger’s working from the “inside out” behavior. It takes time to really grasp how to tune your workspace, but once you do, you can get a lot of stuff out of the way.
One of the really surprising features for me in Lightroom came out of the Print module. It starts with doing the basic grid work, but combining extreme grids with the “zoom to fill” options start to push you toward discovering new way of looking at your images and new layouts that wouldn’t have been expected on our part. The grid goes in as “OK we’re dealing with contact sheets and so forth” but what comes out of it is that it actually becomes a viable creative tool as well. That’s somewhat reflected in the 4 Wide templates, but I don’t know that people have really picked up on the fact that if you start pushing the settings in the Print module you can get fairly creative effects out of what otherwise people might have thought of as a contact sheet generator.
The Split Toning controls in Develop actually are fun to use on color images as well as gray scale. They were created for creating duotone-like effects but they actually can be used in interesting ways to enhance color images as well. They’re not particularly good for correcting images. I’ve had people try to push them to correct color casts in the shadows and they’re not really built for that. If you want to put a color cast into your shadow they’re a great tool for that. Not so good if you want to take one out.
Finally, something that applies only to 1.0 and not Beta 4. I’ve been doing more dust spotting work on my images lately, I have to point people to the benefits of zooming to 1:1 (or higher), starting at the top left corner, and then just repeatedly pressing page down. Watch what happens when you get to the bottom of the column.
since1968: Mark, thanks for your time.
MH: You’re welcome.
Comment [3]
* * *
Mark Hamburg Interview: Adobe Photoshop Lightroom Part 1 of 2 · 1855 words posted 01/23/2007 03:35 PM
Adobe Photoshop Lightroom, currently in beta, is Adobe’s newest tool for importing, managing, developing, and printing digital images. On January 19 I spoke with Mark Hamburg, Adobe Fellow, former Photoshop architect, and founder of the Lightroom project. Mark has been working on digital imaging at Adobe Systems Incorporated since 1990 and is currently driving the development of Adobe Photoshop Lightroom.
since1968: You started work on Lightroom partly based on your frustration at working with several gigs of images—but the project has had almost a five year gestation.
Mark Hamburg: Well, Lightroom as a multi-image editor probably hasn’t been going for five years. I left the Photoshop team in spring of 2002, so I’ve been looking at post-PS stuff for about five years. The general direction and focus on how you deal with lots and lots of images in photography workflow grew probably a year plus after that.
I started out worrying about alternative paradigms for image editing, but then my manager at the time, Greg Gilley, who was an avid photographer, started to push toward: “Well, we just have all this stuff, and how do we deal with lots of images and what can we get out of pushing ACR further.” Actually the way he got me to deal with that was he pushed me to go get a camera and start shooting more. I very rapidly determined that as interesting as it was to do image editing there was clearly just a general problem that comes from shooting far more than the tools are really built to deal with. At this stage it’s focused on “I’m shooting gigs of images and I need a tool to deal with that.”
The volume problem really hit home in fall of 2003 when I did my first shoot of nearly 500 images in one day. The things we’d been experimenting with like light table simulations just fell apart in the face of that sort of volume.
Even after that, we kept resisting getting into hard core image management for quite a while because it would pretty obviously eat up everything else we wanted to do and we felt that Adobe had already explored image management with Photoshop Album. We capitulated eventually and it did indeed consume vast amounts of attention and resources and probably could have taken even more if they’d been available.
So that’s my partial defense for why it’s taken so long.
since1968: Is it fair to say that but for Aperture, Lightroom might never have been released? In the podcast it sounded as if LR might not see the light of day. Is that a fair assessment?
MH: Certainly there were a lot of doubts. Adobe has been very successful with Photoshop. From Adobe’s perspective and market surveys every photographer out there has Photoshop. Working through that mindset, it’s sort of a classic thing that happens when you have a product that’s strongly successful: seeing the things that are different from the product is difficult for people whose job it is to spend most of their time thinking about Photoshop. And so we would go through discussions internally about “Well how many people are there like this? How big is this market? Maybe what we want to do is just add something on to Photoshop.” A variety of things like that.
And as we’ve seen in the public beta program, this isn’t just an internal issue. Photographers generally get the program and understand the problems it is trying to solve. People more focused on Photoshop, however, have a harder time seeing where Lightroom fits in.
The benefit for us of Aperture is that it clarified the market for people who had doubts that you could actually launch a product into that space. It certainly raised the pressure to ship Lightroom. As long as there were people with doubts about the existence of the market we could spend lots of time internally just trying to clarify what the market was and how big it was. Aperture’s entry showed that there is a market and we should be pursuing it. It’s pretty obvious that it does match up almost identically with the market we had identified though Apple’s approach to that market is also pretty different from ours when you drop down from the high-level overview.
since1968: One of my favorite Lightroom features is the way the Print module options are integrated directly into panels, instead of opening a new dialog box. Who thought of that?
MH: The notion about doing more without going into external dialogs goes back to an idea that was introduced early on in the project—before we were working with lots of images—taking ideas that had started to evolve in Photoshop with things like Liquify and “Save for Web”: a number of these things were getting to be mini-applications in a dialog. We had these giant plug-ins (we refer to them as “mondo plug-ins”) and the notion got to be “What if you could build an application where everything was essentially these modules that sat on top of the core, and instead of going into a monster dialog and going back—what if you just went from one environment to the next and never went back to a core?”
So the diagram that I would draw for this: Photoshop with a big circle in the middle, and you go out to various things; you go out and come back, you go out and come back. The model for Lightroom was to say “We still have a core but the user never actually goes into it. The user just goes and bounces around the things that are on the outside of the circle.”
So the Print module then becomes a full peer to all of the other tasks. The idea is to take what you would put into an elaborate print dialog and instead bring it up as a user interface for the print environment. And what actually happens inside that environment is the result of lots and lots of iterations. As I joke, the print environment works as well as it does in Lightroom because we made Kevin Tieskoetter iterate on it until his eyes bled.
since1968: In one of your recent podcasts, Phil Clevenger says he demos Lightroom from the “inside out,” with most of the interface hidden. It took me a long time to discover just how image-centric Lightroom’s interface can be. Why not install Lightroom with its panels hidden? Most programs I explore by adding pieces to the interface, but with Lightroom I explore by taking pieces away.
MH: Ideally we would ship it in the ideal configuration to work in; of course that will vary from person to person. If you have all the panels open, unless you’re on a really large screen and it’s far off to the sides—mostly in your peripheral vision—it gets to be a lot of stuff and that’s not ideal.
The notion was to have an interface where we could make things go away. The problem is from the standpoint of users discovering things: if we were to ship it with the panels hidden off to the side users would have to learn “Oh, if I move over and I click this thing on the side and then I pop this panel open it has a bunch of settings that I want.” It seems easier to have them see the settings and then have them learn that they can make things go away and can adapt this in a way that’s ideal for whatever my workflow is. Certainly it does have the downside that it means that the initial launch experience is not reflective of how good the app can be if you allow the interface to get out of the way.
There are people who will run with the top module picker bar hidden. If you ran with that hidden—if that’s how we came up initially—people would have a hard time knowing “oh I can go to these other modules.” They could discover it in the menus but the menus have lots of stuff in them and you have to find and dig through and find stuff.
I think we’re also seeing that web pages have been to some extent undermining the value of the menu bar. People see more things in browsers; the menu bar in the browser is pretty much completely useless in terms of what it contains. People don’t go looking in the menu bar by default as much.
since1968: I’m one of those people who run with the module picker hidden.
MH: Yeah. That’s just it. Ideally Lightroom is designed to run in full screen mode with the menu bar hidden. That was one of our focuses throughout the evolution of the product. Heavy Photoshop users frequently ran in full screen mode and we wanted to build a UI that was really optimized for full screen. At the same time it would be considered pretty rude if when we first launched Lightroom the first thing it does is blanks out everything else on your screen.
since1968: I understand that you want to differentiate Lightroom from Photoshop and the older version of Camera RAW, but sometimes I’ve found the language changes confusing. “Smooth” seems to work like Camera RAW’s “Luminance Smoothing.”
MH: Yes, it does. The noise reduction is same as Camera RAW’s; we’ve had a few terminology differences but those are now getting sorted out with the next version of Camera RAW. The issue for Lightroom was because of the user interface design we tend to favor shorter labels.
If you look at Camera RAW, it stacks the name on top of the slider and so has a fair amount of horizontal space. Because we were trying to make more of the controls available at once, stacking them up vertically, we ended up putting the label off the the left-hand side of the slider. That then means you don’t want to spend a lot of space on the label. So there was a certain amount of “well can we pick a shorter name than this?”
since1968: But at some point Adobe will map the names for various functions and algorithms across its various image management tools? If I perform an action in Camera RAW will it render the same result as Lightroom?
MH: Yes, there will eventually be a version of Camera RAW which will be synched up with Lightroom because we’re building off identical code. This also means all of those cool new development features in Lightroom are making their way into Camera RAW. Not all of the UI functionality is coming over, but all of the processing is showing up in Camera RAW.
since1968: The Sydney Morning Herald has reported that Lightroom will be released on February 28.
MH: That would not be accurate, nor is CNet’s report of January 29 accurate as a release date. The release date is not announced at this time.
since1968: And we shouldn’t expect any more beta point releases?
MH: That is correct. There will not be a beta 5, nor beta 4.2
In Part 2 of the interview to be posted later this week, Mark discusses Lua’s place in Lightroom.
Comment [8]
* * *
From the Archives: Joshua Davis Interview · 52 words posted 02/24/2006 09:07 AM
This month’s Wired Magazine profiles Joshua Davis, a designer who creates beautiful, randomized works of art with ActionScript.
The Wired profile will be posted March 2. In the meantime, you can read the since1968 interview from August, 2002, in which Mr. Davis discusses creativity and commerce, sharing code, and his artistic response to September 11.
* * *
Love and Yearning Interview, Part 2 · 1287 words posted 10/15/2004 12:33 PM
In the fall of 2003, the Freer Gallery of Art and Arthur M. Sackler Gallery exhibited Love & Yearning, a collection of illustrated Persian manuscripts. John Gordy, Head of Digital Media, and Jacqueline Bullock, Web Producer, designed a kiosk and website around one of the manuscripts, “Haft Awrang,” (or “Seven Thrones”).
Last summer they gave me a tour of the galleries and talked about their production processes. In the first part of the interview, we discussed the planning, storytelling, and goals of the exhibit. In the second part, below, we talk about the choice of technologies. Many thanks to John, Jacqueline, and the rest of the staff at the Freer and Sackler for their time.
Databases
The Freer and Sackler galleries use The Museum System (TMS) database to track their collections. I asked John about using a database for the Love & Yearning exhibit.
John Gordy: We didn’t use a database for Love & Yearning; it’s only 28 pages. For some online collections, we do an extract from TMS, which has 50,000 to 60,000 records. We only want the few of those that have been approved for public access. We’ll do an extract that pulls a few thousand records and puts everything in a flat Access table. That way, when I have the Access table I can work with it on my desktop. We may bump it up to SQL Server, but it still will be one flat table.
Our museum tends to be more about interpretation rather than presenting mass quantities of information. So in the same way it just wouldn’t make any sense to invite a visitor in and let them roam around the collection storage—they wouldn’t have any idea of what they were really looking at—we want to encapsulate the stuff we’ve got and put it in groups. It’s thematic, it’s got narrative text with it, and that contextualizes it. So that leads us away from doing large scale database projects.
Working with Flash
Love & Yearning uses Zoomify to magnify Flash images at a very high resolution. I asked John and Jacqueline how they selected their technogies.
John Gordy: We originally started looking at Zoomify when it was using Java. It was a nice idea, but it wasn’t giving us imaging gratification, so it wasn’t something we wanted to use. But the first Flash version was interesting, and the second Flash version was up to speed and really worked. When I saw the first demo at a FlashForward in San Francisco, at the same time I was thinking about what Massumeh [Dr. Massumeh Farhad, Chief Curator and Curator of Islamic Art], had said: “I really want to get into the details.” It was a perfect fit, and perfect timing.
So the choice of technology changes depending on the exhibit. Each curator will present me with a challenge, depending on what they’re interested in, and I will look in the bag of tools and come up with whatever I think might work.
since1968: Stepping back from Zoomify for the moment, let’s talk about the choices of Flash, Java, or—let’s be crazy—SVG, it’s an option. David Rumsey does Japanese maps for UC Berkeley that are breathtaking. He uses a proprietary Java applet called “insight” that lets you zoom in on the images. There’s another viewer called MrSID from LizardTech that many libraries use to show Fire Insurance Maps in great detail. How did you choose Flash?
John Gordy: Part of the reason for using Flash is I’ve been using it for so long that I feel comfortable with it. It’s also nice to have so many developers out there working in something. The reason I didn’t use those other two products is I’d just never heard of them, whereas Zoomify, everybody uses it.
The nice thing about so many people using a tool is there’s always code out there, and so when I wanted to create custom buttons and tools, it was pretty easy. ActionScript is easy to read in a way that Java is not, and the code behind Zoomify is very easy to use. 
And also, I have to say, the guy who runs it, David Urbanic, he’s just so nice. I would email him, and the first time I emailed him I had been banging my head against the wall trying to do something. He said “try this,” and sent me code. He’s just super friendly, and ever since then, when I’m working on a project I’ll show him things as I develop it and he’ll suggest ways to do it.
So that’s the reason for Flash. I’m sure other tools have their own communities.
I’m very conscious of the fact that we’re part of the Smithsonian, and I want to make sure a good number of people can see what we’re showing. In fact, we talk about using Flash all the time, but 99% of our site is HTML: straight HTML, very accessible using CSS, making sure it’s easy for people to read it with any sort of reader they may have. I wouldn’t put vital information like dates, times, and directions in Flash.
A few years ago there was a lot of QuickTime on the site. There’s less and less now. But now, if you want to present video it makes more sense if you want to do it in Flash.
since1968: You used the same code base for both the kiosk and the web site, but did you have to use a different wrapper for each?
Jacqueline Bullock: Most of it was redesign because we lost physical space on the web.
John Gordy: Yeah, we had to design the layout a bit differently. We had put in scroll bars to accommodate the text, which of course you don’t really want to do on a touch screen. But the time it took for the webification was a week or less.
We started out with the kiosk version. The code already worked, the zoomify was already written. I did have to go in and slightly tweak each coordinate for the web.
Jacqueline Bullock: The kiosk resolution was 1600×1200. It was so nice designing for that.
since1968: Is there a Smithsonian design standard? Every site under the Smithsonian banner must follow a certain set of design guidelines?
John Gordy: Think of it as a garden of wildflowers. You want them all to have their own personality.
Jacqueline Bullock: Air and Space is not going to have the same flowers as we are. There aren’t too many restrictions: you have to have the privacy act; you must link to the main Smithsonian site; and there are restrictions on how you can use the logo.
John Gordy: These are not big restrictions. That being said, if I were to redo our entire site in Flash 7 player that would be a problem. But before it would ever cause an issue on an institutional level, there would be an issue in house.
since1968: Will you be able to use code from this interactive in future projects?
Jacqueline Bullock: The hope is that this would be a prototype for other manuscripts. We really wanted to see if this is a model that we could then put in other manuscripts and use, to have a library in our own format.
since1968: So the hope is you’ll have a website and kiosk already built, and drop in a different set of graphics and text. Is it that level of templating?
Jacqueline Bullock: It never really is for us; we’re always trying to reach a higher level of quality. More than templates, this project added another tool to our repertoire.
We want the Flash interactives to be able to stand beyond the exhibition. When the exhibition goes offline, we want to make sure the interactives are still pertinent and interesting.
* * *
Hugh E. Williams Interview · 2081 words posted 10/05/2004 12:38 PM
Hugh E. Williams is the Associate Professor in Information Retrieval in the School of Computer Science and IT at RMIT University in Melbourne, Australia. With David Lane, he is co-author of Web Database Applications with PHP and MySQL, 2nd Edition. This interview was conducted via email.
since1968: You wrote the book as an omnibus: with chapters on Entity Relationship modeling and creating PDFs, the book is one of the most useful on my shelf. Who is your target audience? Do HTML designers making the transition to MySQL need to know all this stuff?
Williams: I’m glad you’re finding it useful, that’s great news. Writing books is a solitary experience: you just hope when it’s launched that readers get something from it.
To answer your first question: when I wrote the new edition, the target audience I had in mind was broad. At one extreme, I thought about the reader who knew something about the Web and its standards (such as HTML) and could program a little. At the other extreme, I thought about someone who knew much more: they might have programmed PHP and used MySQL, and might want to know more about OO, PDF production, writing an error handler, more about MySQL, or just see how others thought about issues in in web development. The book would probably be difficult going with no Web or programming experience, and unsatisfying to the experts.
Do HTML designers need to know it all? Probably not, or at least not right away, and I guess that comes back to the broad audience I had in mind when writing it. I tell beginners to read chapters 1 to 3, and 5 and 6. They get you through PHP basics, MySQL basics, and introduce putting the two together. That’s enough to build simple applications and do it reasonably securely. From there, I encourage beginners to read the book as the issues arise: it makes more sense to read about sessions when you’ve banged your head against the wall trying to pass values from one page to the next and on again. A designer might never read about advanced MySQL or OO concepts.
since1968: The ColdFusion community went through a lot of growing pains two years ago when Macromedia added object-oriented features to a procedural language. With the move to PHP 5, it seems like the designers of PHP are saying the same thing: eat your dog food and learn OO. Won’t this scare off HTML designers—the very people originally targeted by PHP? If you really need to work with OO, why not use a scripting environment that’s OO from the ground up, like Ruby?
Williams: I’m with you on this: it’s moving PHP away from its original purpose and towards being an environment where large-scale software engineering seems possible. I’m not convinced that’s a great idea. I’m especially not convinced because there’s very little evidence that OO does anything for software development: I remember investigating the issue a couple of years ago and finding only one published study that compared C with C++. It showed that C++ projects have more bugs, took longer to develop, and were generally less successful. Sure, OO is neat when you finally “get it”, but most people don’t. I certainly don’t find it a comfortable way to program, but then I’ve been a procedural programmer for almost 30 years.
In the book, we’ve strived to walk the line between non-OO and OO. Outside of Chapters 4 [Introduction to OO with PHP 5] and 14 [Advanced Features of OO in PHP 5], you’ll find very little OO, but the OO in those chapters should be enough for readers to understand and use OO concepts. The winestore application very much walks the line between the two: it does OO when it has to (mostly when using PEAR) and otherwise doesn’t.
I actually wrote an OO-only winestore when I was drafting the 2nd edition of the book. It was neat: you could create an HTML form widget, and it knew how to validate itself and deal with errors. The problem came when I wanted to explain it: it’s hard enough writing about large slabs of code, but when you throw OO in the mix, it’s impossible. So, the end result is a winestore that matches how I program: OO when you need it, and procedural otherwise.
It’ll be interesting to see what developers do with PHP 5, but I bet most never use the features that are being trumpeted.
since1968: PEAR DB: to use or not to use? I’ve worked in various scripting environments for about 7 years and I’ve had precisely two projects move from one application server/database configuration to another. Every other project I’ve worked on has stayed with the same database for years at a time—I just can’t see much value in database abstraction. Still, a lot of the popular libraries use PEAR DB. For instance, if I want to use patUser to avoid writing authorization routines from scratch, I’m forced to use PEAR DB. Can you give some advice to beginners who need to weigh the advantages and disadvantages of database abstraction in PHP?
Williams: In my view, you shouldn’t use PEAR DB unless you’re seriously considering migrating your application from one database server to another in the future. Using the native libraries, you get direct access to the tools and features of the database server, and those tools are often richer than the vanilla, generic PEAR DB interfaces. What’s more, direct use of library functions is faster. In my applications, I almost always use MySQL and the libraries directly.
As an aside, even if you use PEAR DB and are thinking about migration, you’ll have other problems when you do. SQL varies between database servers, and so you’ll end up rewriting database code anyway. Just moving our winestore database from the book to Oracle took me half an afternoon, despite using PEAR DB in the application; there were clashes between column names and reserved words, column types that weren’t available, key problems, and all sorts of other changes needed.
since1968: It’s a great time for what I think of as “littleware”: small PHP programs that interact with client-side command line interfaces like curl to produce mini-applications. One of my favorite examples on the Mac is iTunes Watcher, which tracks your iTunes playlists and posts them to your site via PHP and MySQL. Do you have any favorites? Is littleware going to lead to something useful, or is it just some fun noodling around?
Williams: I’ve seen some great little PHP snippets for all sorts of tasks, and I’ll admit to writing many myself. I’ve written a web interface to some footy tipping software recently—I’m not sure how universal footy tipping is, but this allows a group of people to pick winners in our football competition and it produces a ladder each week and there are prizes for the most correct picks in the year. I’ve also fiddled a lot with displaying the weather, simple web cam galleries, page visit counters, and so on. Fun, simple stuff.
It’s noodling around for sure, but that’s not a bad thing. Putting tools on the web makes them accessible and there’s a place for making the web more entertaining. I enjoy that kind of PHP development.
since1968: While I have a large educational client making the transition from IIS to LAMP, I haven’t yet been able to interest a commercial client in PHP and MySQL. Here in the United States, when I say “no vendor lock-in” a business hears “no proper support.” When I say “open source” a business hears “built by geeks, for geeks.” What’s the situation in Australia? Are commercial concerns adopting PHP?
Williams: Being an academic, my overview of what’s happening in the commercial sector is largely formed from the stories I hear from students, ex-students, other staff, and contact with industry. Lately, those stories have been positive for PHP and MySQL. For example, I recently did some training for a development house who’ve taken the decision to do only PHP and MySQL and I hear they’ve landed some great SMEs as clients lately. In the same week, a graphic designer approached me to recommend someone who could build PHP and MySQL backends for her company. I’m sure there’s intense resistance in larger corporations, but when guys like Yahoo! adopt the technology it does help bring it into the mainstream; indeed, “geek” companies like Google and Yahoo! have done a lot to legitimise LAMP (Linux, Apache, Mysql, and PHP).
since1968: Let’s return to PEAR for a moment. I’ve tinkered with PHP for a couple years, but only recently started using it to build medium-sized sites. It’s hard to know when to use various PEAR packages or just write my own routines, especially when so many packages rely on PEAR DB, which you’ve advised against using. What are your thoughts on PEAR generally? Are there any packages you especially like, or any that you would specifically avoid?
Williams: Perhaps I’m contradicting myself, but I wouldn’t necessarily avoid PEAR DB or other database abstraction layers. What I do think is that developers need to to consider carefully why they’d want to use it, rather than blindly make the choice because they’ve heard database abstraction makes for better code or solves problems. It’s useful if you’re planning to migrate database backends, particularly if you’re able to keep your SQL fairly generic. Other than that, stick to the native libraries.
But back to your question. I’m a fan of PEAR, because it saves development time building components that everyone needs. It’s also got that Open Source safety feeling: you know there’s thousands of other developers out there using it, pulling it apart, and pushing it to its limits. That means if there’s a bug, it’s probably been found and fixed.
The downside of PEAR, like much other Open Source software, is that it’s often too new to have been documented properly and the developers don’t necessarily find time to write down what they did. However, that’s no big deal: you usually choose a package because it does what you want, which means you’ve thought about it and are ready to look at the code and understand it.
My favourite PEAR packages include:
- Date for manipulating times and dates, because it’s more reliable and flexible than the PHP library
- PHPDoc, for documenting PHP code. It’s a great way to produce documentation after adding a few structured comments to your code
- Mail, for sending emails, because it’s more flexible and reliable than the PHP library function mail()
- Net_DNS, for resolving domain names to IP addresses, which is useful in email validation and so on. In fact, most of the Net_* packages are very useful.
There are also a range of other useful packages for meta tasks, such as online payment processing and web services. For specific applications, these can come in very handy.
since1968: Let’s talk about Rich Internet Applications and PHP. Microsoft, one of these years, will roll out Avalon and XAML, which will go a long way toward making web applications feel more like desktop applications. Macromedia has already introduced Flex, a presentation server that, when coupled with a J2EE server for business logic and data access, uses Flash to produce rich interfaces. PHP doesn’t really have anything to compare: you can experiment with “PEAR XML_XUL”:http://pear.php.net/package/XML_XUL; you can work on the desktop with PHP-GTK; or you can hook up PHP to a Flash front end via AMFPHP, but these technologies are either experimental or not central to PHP, which was originally envisioned as a “hypertext processor.” Are there plans to add a rendering engine to the core of PHP? Is is that just extraneous to what PHP is trying to accomplish?
Williams: I’m not sure a rendering engine is where I’d like to see PHP go. PHP’s in danger feature bloat—perhaps it’s already past the point of no return?—and that’d pull it in another, bigger direction. I’d like to see if focus on the core: a hypertext preprocessor that’s fast and scalable under load, and has features that make building applications on the web easier. Indeed, I’ve never really played with PHP-GTK or PHP on the command line: I reckon PHP is great for what it’s designed for, and there are better tools to do other tasks. For example, Perl, awk, and sed do most of the things on the command line I’d want to do.
since1968: Thank you for your time.
Williams: Cheers.
* * *
Love and Yearning Interview, Part 1 · 1531 words posted 08/04/2004 01:11 PM
Last fall, the Freer Gallery of Art and Arthur M. Sackler Gallery exhibited Love & Yearning, a collection of illustrated Persian manuscripts exploring epic love stories and mystical themes. Among the featured manuscripts was “Haft Awrang,” (or “Seven Thrones”), around which the gallery designed a Flash interactive in order to draw visitors more deeply into the texts. The interactive was displayed on kiosks at the gallery, as well as on the web, and won a 2004 Muse Award Honorable Mention.
The “Love & Yearning” exhibit is one of my favorite uses of Flash: it’s like having the beautiful words and pictures directly at hand, only better. The visitor can view the pages as a whole or zoom into details too small for the naked eye, and the designers have created a playful flow from story to story with very little of the gimmickry that often mars interactive works.
The web team responsible for building the interactive—John Gordy, Head of Digital Media, and Jacqueline Bullock, Web Producer—walked me through the process from start to finish. The interviews were conducted at the Freer and Sackler galleries in July 2004. This week, I’ll examine the cultural decisions that go into designing exhibits, as well as the process of storytelling. Next, I’ll look at the steps needed to translate a manuscript into an interactive kiosk.
If you haven’t had the chance to see the Haft Awrang interactive, take a few minutes to explore it before reading this interview.
Planning the Exhibition
Dr. Massumeh Farhad is the Chief Curator and Curator of Islamic Art. Dr. Farhad curated the exhibit, and narrates portions of the web interactive.
MASSUMEH FARHAD: We have this outstanding manuscript in the Freer from the 16th century: the Haft Awrang, or Seven Thrones. We were going to show four paintings, but the frustrating part of it is you can’t see the whole manuscript, you can only see so many pages. We started talking about ways we could make the whole manuscript available to the visitors, short of actually having it there and having people flip through it. I had first seen this web site where you could actually flip pages, but that became too complicated, and it didn’t really allow us to focus in on the details; it became more of a gimmick and a distraction of turning the pages.
One of the challenges, not only having more than one page available to the public but also, with Persian or Indian painting, is to really make people look at the detail. We’re all so used to looking at Western art, a large picture hanging on the wall: you walk into a room and you can sort of “get it.”
With Persian painting especially the images are so tiny you have to work at it, you have to look closely. A lot of people don’t have the time or inclination, and we needed to find ways to draw them into the painting. If people came and looked at the interactive, we hoped that they would then look for the details in the actual paintings.
These were some of the ideas that led us to creating the program: to make all the paintings available and to make visitors focus on the details.
since1968: You thought that the electronic version might drive you deeper into the physical version.
MASSUMEH FARHAD: Right. The interactive is just a way of teaching you how to look. I mean you can stand there and say as many times as you want “you need to look closely,” but people say “oh yeah” and they can’t be bothered. When you have the ability to really focus on the details and create this interaction between you and the work, it’s learning a new way of seeing things or looking at things. It’s an experience you can take with you and use. We also have magnifying glasses, which help, but not as much as when you can zoom in and see some of the detail.
since1968: One of the things that intrigues me when I see a Persian exhibition: there’s a willingness to show images of the Prophets, and a lot of Sunni Muslims disapprove of that. As a Muslim working for the Smithsonian, but also as a custodian for the Smithsonian institutionally, how do you take the decision to show those images?
MASSUMEH FARHAD: Well, you can’t deny history or tradition; it’s censorship. Whatever my background, whatever my beliefs, I am here as a custodian of this collection. Clearly, there are different attitudes toward imagery, but at the same time when you look at the number of images of the Prophet that do exist, even though there are a lot of people who believe it’s not right there are just as many people who created representations of the Prophet, and it clearly seemed OK; they have survived.
One thing that’s important to remember is that these works were made for a private, secular sphere. For instance, the painting of the Prophet and the Seven Thrones is part of a poem. It’s still the Prophet, but he’s not used for a religious purpose, or he’s not shown in a religious context. You don’t have images of the Prophet in a mosque.
There isn’t a single rule; the whole issue of imagery is so layered. Part of my responsibility here is to show part of the complexity, not only of the cultures but also of the art. There isn’t just one view, and that’s one of the reasons Islam is so misunderstood. The belief is that there’s one Islam and one Muslim, but we know you can go to different villages in one single country and it’s different in each village.
since1968: When you’re deciding which images you’re going to show in a walk-in exhibition, where the group of people are more self-selecting, vs. when you choose images for the web, do you show identical images? Is there any consideration that we’ll show a larger set of images in person vs. a smaller set on the web?
MASSUMEH FARHAD: No. We’re a public institution and everything we have is available and accessible to the public.
JOHN GORDY: If the question is how many images you have, and what you put up on the web vs. what you put up in the exhibition, there are always choices—we want to have a narrative and to keep the web presence focused.
MASSUMEH FARHAD: In many ways my role as a curator of Islamic art is really not that different from a curator dealing with Indian art or Japanese art: we’re all here to show the complexity and breadth in the artistic culture of these different geographic regions.
JOHN GORDY: Another thing, we’re presenting this in the form of visual art. Most of the people who come to the museum are looking at it as visual art; religion is very important to the creation of the art. But people aren’t coming in and looking for a mosque or a temple. Haft Awrang was a love story.
Storytelling
Howard Kaplan is a museum writer for the Freer and Sackler, and wrote much of the text that accompanies the exhibit with the assistance of Carol Huh, Assistant to the Chief Curator and Curator of Islamic Art. I asked him how he translated a set of complex images and scholarly essays into something accessible to the general public.
HOWARD KAPLAN: In putting together the interactive, the storytelling aspect really had to be there. When you’re writing for the web you need to tell a story, and the design flows from one story to the next. You can go to any one of the seven stories, but once you’re in you can easily go to the others. That sort of hands-on activity level made you want to learn more. So many times you can go to a site, it’s like “here’s the text,” and you’re just going to scan and move on. Here you don’t. Some of the writings covered scholarly subjects like Islamic architecture… and then there were things that were not scholarly, like food preparation, making milk or yogurt.
As we went through the manuscript, we would go through the pages of the catalog and identify what would make a good hotspot, something to Zoomify, a detail.
We were able to locate things that you really couldn’t see in the manuscript with just your eye.
since1968: Such as?
HOWARD KAPLAN: There’s a signature of the calligrapher on one of the pages—you can’t see this with the naked eye (left). The signature was only discovered after magnifying one of the tiles. 
I think it’s a model, and I hope there are other manuscripts down the road that use these same tools, in the way you can zoom in and create text that is informative and lively and appeals to different audiences.
~~~
The images used on this page are taken from the Love and Yearning exhibit. They are owned by, and used with permission of, the Freer and Sackler galleries and are not part of the Creative Commons license that covers the rest of this site’s content. Next: In part 2 of the interview, John Gordy and Jacqueline Bullock discuss translating the images from Haft Awrang into Flash.
* * *
Mahabir Pun Nepal Wireless Interview · 2111 words posted 07/05/2004 02:55 AM
After receiving his Master’s Degree in Education at the University of Nebraska at Kearney, Mahabir Pun returned to his native village, Nangi, and founded the Himanchal Education Foundation. Mr. Pun is currently at work establishing wireless networks in rural Nepal.
I conducted this interview with Mr. Pun over a series of email exchanges. Thanks to Sabeel Rahman for helping me formulate the questions, and to BoingBoing.net for bringing the original BBC story to my attention.
since1968: You’ve set up wireless networks in five villages. Can you talk about the physical process of setting up the networks? How are they powered?
Mahabir Pun: The network has been set up in five villages, located in different ridges of the mountain ranges through two relay stations. The elevation of Relay Station 1 is 10,800 ft and that of the Relay Station 2 is 12,000 ft. The villages that are networked are lying between 6,000 ft and 7,500 ft. Relay Station 1 is connected to the nearest ISP through dial-up networking, which is about 22 air miles away.
The relay tower at Relay Station 1 is actually a tall tree. We have tied antennas on the top of the tree pointing to different directions. The radios, laptops, and other accessories at Relay Station 1 and Relay Station 2 are powered by a 75w photo voltaic panel and a 400w wind generator.
Even with the two sources of power, it has been very difficult to run the radios all day at relay stations because of the lack of power. It is because this is monsoon time and there is almost no sunshine and no wind. The power problem will be for three months. Right now we are running the radios at the relay stations about four hours a day.
since1968: Why now? When did you start the project?
Mahabir Pun: We tested 802.11b wireless equipment in 2002 between two villages with the help of a Belgian and a Finnish volunteer. They decided to come to our village after they read about us in the BBC news in 2001. Before that I did not know anything about 802.11b wireless technology. After the testing, we were quite hopeful that the technology would work to network the villages. Therefore we tried to find financial support to install the network. A student at the University of California at Los Angeles got a grant from the Donald Strauss Foundation, which made the project come into a reality. We bought the equipment needed from the grant money.
since1968: Most of my readers are in the United States or Western Europe, and the news we get about Nepal usually relates only to the political situation. Can you talk a bit about day-to-day life?
Mahabir Pun: Whatever you hear about the Maoists fighting and power struggle in Nepal from the media should be mostly true. I live in the mountain and I don’t get to read any news from the newspapers. Perhaps you hear more news about Nepal than the people in the mountains hear.
The Maoists don’t shoot people randomly. As long as they think that there is no threat from an individual or group, one can stay in the villages and work. It is very true that the life has been very difficult to live with the Maoists because they force people to support them. They vitually have control in the rural areas. They are free to move almost everywhere in the mountains because the security forces can’t patrol all the villages. The only way one can survive in the mountain villages is that one should not speak and act anything against them. Even if people don’t agree with or support the Maoists, they have to shut their mouth up to keep themselves alive.
Take my example: I am working in the mountains trying to set up wireless network and trying to bring better educational opportunities for the children living there. The reason I am alive in the mountain and the Maoists have let me stay there is because I have shut my mouth up. Keeping my mouth shut has been the hardest thing for me to do.
since1968: How do the villagers use the networks?
Mahabir Pun: Mostly for communication purposes, since the network is the only means of communication available. The distance from one village to another village is from 8 to 15 miles. The distance to a yak farm from our village is two days walk. The communication between the villages and with the yak hearders has been so easy now. It has saved so much of the villagers’ time.
Although there is a shortage of power at the schools, relay stations, and proxy server station, the villagers still can send and receive their messages through [Microsoft] NetMeeting or through e-mails using our POP server. The POP server is run by Jonni Lehitranta in Finland. We have provided NepalWireless.net accounts to seventy eight people so far and will provide more. Students from two high schools are using the network to write e-mails to each other and to their pen-pals abroad.
Paudwar and Nangi villages are using the network to run their income-producing projects such as yak farming and camping grounds located in the high mountains. Now the management committee of the projects are using the network to communicate with each other and with the yak herders through NetMeeting or email. For that we have given laptops to the camping ground and Yak farming staff. The interesting thing is that the yak herders and the camping ground staff have almost no formal education, and they had never touched the computers before last September.
since1968: As part of a similar project for connecting rural villages in Laos, the developers localized Linux for Laotian users. What operating system do you use? Do you localize for Nepal? If not, why not?
Mahabir Pun: Right now we are using Windows server. Therefore we have not been able to localize the server for Nepal. I know that we can do that with Linux server, but I don’t know much about Linux. One of the volunteers from the US (Philip Mucci) has promised to come to Nepal this year and help us to localize the server, but he is a busy person and he has not decided yet as when he could come.
since1968: I’d like to return briefly to villagers using the computers. Who is in charge of the program in each village? Who controls access to the computers? In one program used to track soy prices in Indian villages, the person put in charge of the computer had marginal social standing. The program found that being able to use the Internet was another avenue of social mobility. Do you see similar patterns of social mobility with your program in Nepal? Is that one of the goals of your program?
Mahabir Pun: Right now the school has been the center for the connection in each village. Therefore one teacher at each school has been working as the “incharge” of the connection. However, our plan is to build a communication center in each village and give the village committee full responsibility to run the center. The committee will choose a person as an “incharge” of the center.
There aren’t much social levels in our society in the mountain villages because most of the people come from the same tribe. All the villagers are farmers and have about the same level of economic status. Therefore I don’t think that the people in our villages will think about moving one step upward in their social status.
since1968: That might surprise a lot of western readers—I think we assume that one of the big reasons for introducing computers to developing countries is for social mobility. You went to college in the US, correct? Can you compare your observations on social mobility here and in Nepal? If social mobility isn’t a goal of introducing wireless networks, isn’t there a risk it will be one of the unintended consequences?
Mahabir Pun: The community in the villages in our region belong to mostly one tribe – Pun Magar. Over 98% of the population in a village come from this tribe. In some of the villages there area few people from other tribe too.
We don’t have any written history of our tribe. Based on the folk tales and oral history our people were originally nomads and used to travel in the mountains hunting wild animals for food. Later they settled in villages and started farming because there were not many wild animals available for hunting. Our people mostly rely on sustainable farming to these days too. Each family have their own land. They raise cattle, goat, and chicken. They grow corn, potato, vegetables, beans, etc, for food. Other than rice, they don’t have to buy food from outside.
Military service is the only source of cash income for the villages. During the First World War and Second World War, the British had recruited young people from our tribe in their army. Since then joining the army has been the main occupation of our people to bring cash income. In the past few years, people have also started going to Gulf countries for work. Other than that there is no source of cash income for the people.
In this way there is not much social levels in term of economic possession in the villages. Moreover, they have the same level socially because they come from the same tribe. They have enough food to eat and they somehow make some money needed to buy clothes and other stuffs for their living. Most of them so far are satisfied with what they have with them.
Therefore most of the people had not thought seriously about sending their children to schools for higher education until two decades back. However, the situation is changing very fast with the coming of new information technologies and building of highways. People in the villages are also learning about different ways of living from different media. Now they are getting more interested about sending their children for higher education so that they can have “better life” other than farming. So far they are not haunted much to make a lots of money and get to higher social status. In this way I can say that our people have just started to think about moving up in social status in term of economic gain.
In this context, my goal of introducing the computers and wireless technology in the rural schools is to provide opportunities for the students to learn about the new technologies and to provide better formal education using the wireless networking technology. That will help to prepare them to compete in the materialistic world to find better jobs. I know how important it is to have better education in order to get better jobs because I have been to school in the US and I have seen it there.
Another goal to bring the technology is to use it for communication purpose. So far the only means of communication that exists is post office. However, not all the villages have post office. The existing rural post offices are not functioning well because of the Maoists rebels. There are no telephones in the mountain villages and it is hard for us to communicate with each other and with the outside world. The reason I am working very hard to network the villages is because I believe that better communication system is important for the overall development of a community and a nation.
However, the fact is that it will take several years for people to seriously think and work hard to adopt the new technologies and get full benefit from them. Even if it is going slow, I would keep working on the project.
since1968: Aside from funding, what were some of your obstacles in launching the program?
Mahabir Pun: Right now there is no main obstacle aside from funding. The Maoists and security forces have let us use the wireless network so far. However, they might come any day and ask us to bring down the connection citing the security reason. If they ask, we have to bring the network down.
The reason we have this fear is that both the security forces and the Maoists have shut down the rural telephone centers if they think that there is danger from the centers for them. There are virtually no rural telephone centers in Nepal now. Some places the maoists have bombed the telephone towers and centers and some places the army has ordered to shut down the centers.
since1968: Good luck with your project and thank you for your time.
Mahabir Pun: Thank you. Please visit our school and village at http://www.himanchal.org.
Comment [3]
* * *
Lance Ledbetter, Dust to Digital Interview · 1374 words posted 06/09/2004 11:55 AM
Goodbye, Babylon, a boxed set of over 150 gospel songs and sermons from the first half of the 20th century, was compiled by Lance Ledbetter and published by Dust to Digital. Lance lives in Atlanta, GA and answered the interview questions via email.
since1968: I’ll be honest. I grew up on on Black Flag and R.E.M. If I hadn’t been lucky enough to go to law school in a city where the local NPR affiliate played bluegrass, I’d probably think American roots music meant George Clooney lip-synching “Man of Constant Sorrow.” How did you get exposed to old time gospel?
Lance Ledbetter: As a kid I was taken to a couple of different Methodist churches near my home in northwest Georgia. It wasn’t until I was older that the songs would begin to resonate with me. I was at a radio station called Album 88, which is broadcast from the campus of Georgia State University in Atlanta. I took over a show called 20th Century Archives armed only with the American Anthology of Folk Music. So I started to try to track down as much music that was recorded in the 1920s and 30s as I could. It was then when I started to really get into old gospel music. Some of the songs I remembered from going to church with my folks. A lot of them were completely new to me. But it was the performances which really grabbed me. Songs about sin and death were delivered so straight forward. I knew I would have to find more.
since1968: Most white performers and black performers today sing right past each other, about different subjects, to different audiences. One of the striking things about Goodbye, Babylon is the overlap between white and black artists; society may have been more segregated when this music was recorded, but the music itself certainly seemed less fractured.
LL: I had a few people tell me that it would never work having both black and white music in one collection. The common excuse was that from a marketing standpoint, it would negate both audiences – the black people wouldn’t want to pay a lot of money for only half of which was performances by blacks and vice versa. I thought that was a bad way to think about it. I leaned toward the standpoint derived from the Christian belief – that we are all the same color in God’s eyes.
since1968: My favorite disc is the collection of sermons, many of which have as much rhythm and force as any of the songs. Where on earth did you find the sermons?
LL: Most of the recordings used for Goodbye, Babylon come from the collection of Joe Bussard. He’s collected records since the 1940s and has amassed 25,000 of the best from the early 1900s. It took me a year and a half just to go through just his gospel material, and when I got into the sermons I was just as amazed as you. I was hearing the roots of soul, hip hop, and even modern stand-up comedy. I knew I’d include a lot of them, but I had a hard time trimming the list down to just twenty-five.
Editor’s note: You can listen to two selections from Goodbye, Babylon on since1968.com: the Black Diamond Express to Hell, a train where “Sin is the engineer and Pleasure is the headlight”; and The Prodigal’s Return (The Things I Usta Do I Don’t Do No More), a sermon about renouncing worldly pleasures . Both links are in mp3 format; you can listen to the songs in iTunes, QuickTime, Windows Media Player, and most other music players. The recordings are provided with the permission of Dust to Digital.
since1968: As I understand it, Alan Lomax recorded music that hadn’t previously been put on tape. Your job was a bit different here: you preserved and digitized music that was already commercial in its time. Did the songs in this collection serve a similar cultural function to those recorded by Alan Lomax?
LL: One thing I set out to do was to create an entrance into the world of old gospel music. Everyone knows old gospel music is out there and if you look hard enough you can find it. But where does one start? That’s why I thought it was so important to include lengthy annotations and introductory essays by some of the most knowledgeable researchers and writers from each subgenre.
since1968: Goodbye, Babylon is packaged as beautifully as any CD box I’ve ever seen: the cedar box includes raw cotton and the CD sleeves form a cotton plant in the shape of a cross. Where did you get your ideas for the packaging?
LL: I developed quite a love for the artists that appear on Goodbye, Babylon. Sure, there are some artists on it that everyone has heard of. But there are others that remained in obscurity from the time they were alive until today. So I wanted each artist/song to have its own page in the book. I wanted Sister OM Terrell to appear beside Mahalia Jackson. And I wanted it to be presented in a way that would make them proud.
As for the cotton, I worked with a very talented graphics designer named Susan Archie. In working on the layout for the book, she had told me that it would be nice to have a motif. I had drawn up the design for the wood box and had the prototype built. When I was trying to figure out what to do with the empty spaces on each side of the CDs, I suggested stuffing them with cotton. She was excited because she had a motif she could incorporate.
As for the CD sleeves making the cross, I wanted to show that all of these songs together form a sum greater than their parts, in a similar way that the Father, the Son, and the Holy Ghost form the Trinity in Christianity.
since1968: Curt Cloninger has written about the problems of digital preservation: not only does the archivist have to worry about “bit integrity” (i.e., fidelity to the actual source), but also the “equally troublesome task of preserving the technology used to read the media.” This may sound silly, but a compact disc doesn’t strike me as the most obvious media for preserving music. Isn’t there a better chance that the LPs pressed fifty years ago will play fifty years from now than a CD burned today will play twenty years from now? How did you choose CD as your format?
LL: I believe you are correct when you talk about the limitations of the compact disc. Initially, I spoke to Joe Bussard about putting the collection out on LP. He told me that by far the best sounding medium for reissues of 78s is CD. He said the sound comes closest to the actual 78.
Another thing to remember is that the CD player is the most common audio playing device throughout the world. I feel like if a newer medium comes along we can always issue Goodbye, Babylon in that format. Also, if CDs begin going bad in 50 years we can back up the old discs to new ones. I just feel that today the CD is the best way to go.
since1968: Why not distribute the music of Goodbye, Babylon over the internet instead of on CD?
LL: Because CDs are the most common format. I do not think the internet could be an “instead” situation. I do think that it could be used as an accompaniment to the CDs.
since1968: I searched kazaa for the music from Goodbye, Babylon but didn’t turn up anything. What are your thoughts on peer to peer and the music industry? Can a technology like kazaa actually help spread the word about collections outside the commercial mainstream?
LL: The pro with peer to peer is that more people can hear the music because money is not a restriction. The con is that the music becomes more disposable and does not get the attention it would get if people paid for it. Also, the 200 page book could be downloadable, but I’ve yet to see a downloadable cedar box.
since1968: Thank you for your time.
Comment [2]
* * *
Al Sparber Interview · 1614 words posted 03/11/2004 04:54 PM
Al Sparber is a founding partner of Project Seven Development (PVII). Sparber and co-founder Gerry Jacobsen produce Dreamweaver extensions, books, learning materials, and operate an extremely popular web site and newsgroup community for Dreamweaver users. Al lives in the picturesque town of Hudson, Ohio, with his wife Carol and their two children, Melanie and Ryan.
since 1968: PVII’s Tree Menu Magic extension is truly amazing. For readers who haven’t seen it, the extension is an add-on to Dreamweaver that creates the sort of tree control menu people previously might have preferred to build in Flash or an applet. How long did it take to develop?
Al Sparber: Tree Menu Magic took several months from concept to finished product. Our development process always starts with a raw idea and a series of conversations between Gerry and me that lead to working prototypes of the html structure, the CSS, and any necessary images. Once we’re satisfied with the structure and the look, Gerry goes to work weaving the scripts that bring it all to life, while I begin the task of optimizing the style sheets and the markup (I can sometimes be found in the basement chanting aloud in Sanskrit as I read the CSS1 and CSS2 specs). After deciding how the structure, the CSS, and the scripts will work together, we complete all optimization processes. We then call in our customer support specialists to test and evaluate an advanced prototype. Our support team tends to see things more as a real-world user would.
When we’re confident that the product will work and be stable cross-browser and cross-platform, the most demanding parts of the process begin:
- Programming the extension and its Dreamweaver interface(s)
- Writing the User Guide
- Beta testing
Our beta group is comprised of a good mix of folks representing diverse backgrounds and levels of expertise. All in all, it’s a team effort from start to finish.
So PVII products have a rather long gestation period and we think it shows in the quality of each finished product.
since1968: When you sell an extension like Tree Menu Magic, does the value come from the code itself, or the automated creation of the code?
Al Sparber: Both. Naturally, what goes in the actual web pages our customers make is the proverbial bottom line. But there’s more to our products than that. The user interface (UI) allows Dreamweaver users to save substantial development time. It allows them to deploy a scripted solution with the speed and efficiency that only a graphical user interface can provide (and some of the things Gerry has done with the extension UI border on the miraculous). Documentation and customer support also fit into the overall equation. Our User Guides are thicker than most of the manuals currently shipping with major desktop applications and customer support is always free.
Stir all of the above ingredients together and that’s what makes PVII products so tasty and special.
since1968: Nick Bradbury recently noted that there are more unlicensed copies of his software in circulation than licensed copies. Is piracy a problem for PVII? How do you address it?
Al Sparber: We once considered the establishment of a ballistic missile program but we couldn’t swing the financing. Then we tried to raise an army, but no one would enlist. Then it dawned on us that we really have no way to measure piracy. So we don’t really know what effect it’s having on us.
since1968: Aside from people illegally distributing actual copies of PVII extensions or design packs, do you lose sales from people downloading your source?
Al Sparber: I really don’t know. But if someone does download our source code they are missing the extension UI and the product User Guide – two very key components that serve to make our products so darn good.
since1968: My internal blog pages validate as XHTML as long as they don’t have Flash (and when I get around to implementing the JavaScript fix for Flash, they’ll validate as well). But my home page is a mess: 41 XHTML validation errors, generated mostly by MovableType template code. Should that bother me?
Al Sparber: I think you should call a lawyer immediately. No, don’t. That would make it worse. Seriously, I consider validation a measuring device, a reference, and a gauge rather than a certification of competency. I’m an advocate of clean code and I just adore CSS – but there is a time when practicality must win out. So I wouldn’t lose sleep over it. Perhaps the W3C Validator should have a better name. I kind of like MovableTargets. Catchy name if I do say so myself.
since1968: Over the last eighteen months, Macromedia has made a real push for Flash to replace DHTML for most interaction in web pages. Still, the new Dreamweaver MX 2004 updater has restored the timeline (a feature used to animate layers). Should we read that as a concession that users aren’t ready for Flash to entirely replace DHTML? Or is Macromedia just restoring a tool that designers have become accustomed to using for several releases?
Al Sparber: I think Macromedia is merely restoring a tool whose removal caused a very loud stir on its public forums. It seems to be a relatively easy way for them to show that the company is listening to its customers. As for why it was removed in the first place, I can only speculate. My business sense tells me that it should not have been removed until a viable substitute was in place. That does not mean I am endorsing Dreamweaver Timelines. By today’s scripting standards they are dinosaurs.
I see Flash more as a replacement for HTML than for DHTML. I also see it as an attempt to put a prettier face on web-based applications. But most of all, I see Macromedia doing its darndest to do exactly what it should be doing: cultivating its core technologies. I think the jury will be deliberating for quite some time.
As I see it, the news of JavaScript’s demise has been greatly exagerated. After all, it is a language native to all modern browsers. There is a certain purity and harmony when one marries well-formed markup, good CSS, and good JavaScript. Flash doesn’t do it for me yet. Flash is almost ubiquitous, somewhat accessible, but often untenable over still-prevalent dialup connections.
Flash and JavaScript have some common problems, too. In the hands of tasteful people who know what they are doing, either technology can enhance a web site. But in the wrong hands, either can be used to shake and rattle browser windows, make navigation all but impossible, or do silly things that annoy anyone over the age of twelve.
While Macromedia is constantly improving Flash and shoring up its holes – PVII is doing the same with JavaScript, the DOM, and CSS. Fire up a Tree Menu Magic page in a browser with JavaScript disabled and you’ll get an idea of what I mean. Load a Tree Menu Magic page in a real copy of Lynx, or listen to it in an assistive reader, and things really start to crystalize.
My feeling is that there’s room for both in the winner’s circle now – and for years to come. Oh, and wait until you see what’s next on our menu of magical tools!
since1968: How much does your business depend on sales of Dreamweaver? When Dreamweaver MX 2004 didn’t take off as quickly as Macromedia expected, did your sales suffer?
Al Sparber: Dreamweaver has a very large installed base, which means we do too. The success of a new Dreamweaver version seems to have no measurable impact on our product sales. That’s probably due to the fact that each of our extensions, whether commercial or free, works as well in Dreamweaver 4.01 as it does in MX2004.
since1968: When I look at the download numbers for your commercial extensions on the Macromedia Exchange, I get a little dizzy. For instance, Menu Magic 1, an extension that costs nearly $90, has been downloaded 55,000 times. Does each download represent a sale?
Al Sparber: Gee, that would be nice! Actually, all it means is that Macromedia’s link to our Menu Magic I product page has been clicked through 55,000 times. It does keep people guessing, ha!
since1968: While browsing one of your design packs I came across the following quote:
This will fundamentally cause a morphing into a well designed and actionable information infrastructure whose semantic content is downright null. To more fully clarify the current concept, a few aggregate issues will require addressing to facilitate a distributed communication venue.
I spent a minute puzzling out what you meant before I realized it was a clever update on lorem ipsum. You seem like a guy with a solid B.S. detector. How do you cut through all of the information effluvia?
Al Sparber: I use a cleaver. There is so much effluvia wafting around web development channels that you have to be quick. There is no time to think. Split decisions must be made. When reading articles or postings, I completely shut down all sensory receptors when the author:
- Uses the word “semantic” more than twice on a page
- Uses biblical-era language (thou shalt cast thine links in lists that hath no order)
- Sounds more like a preacher than a teacher
- Bashes Microsoft, Mozilla, Opera, Apple, or Jennifer Anniston
- Gets way too personal in his/her/its blog (describing underwear preferences, for example)
- Uses profanity
- Says we must all embrace xhtml
- Says we must all stick with HTML 4.01
- Doesn’t like chocolate truffles
- Can’t take a joke
Beyond that, I’m cool with most everything else.
since1968: Thank you for your time, Al.
Al Sparber: Thank you, Marc. It was a pleasure.
* * *