Articles on Digital Photography

Tagging has become one of the themes of so-called Web 2.0 sites. Really nothing more than free-form keywording, tagging has proven useful in many contexts. Eschewing hierarchies and controlled vocabularies, tagging reduces keywording to its essence. For many of my uses, though, I’ve been finding it it just a bit too simple.

Tag clouds

Seven years ago, the startup I led (Fotiva) built one of the first photo organizers to use tags, which Adobe brought to market as Photoshop Album. Since then, tags have become a popular organizing method on the web, not only for photos (most notably at Flickr) but also for web bookmarks (such as at del.icio.us) and for blog posts (encouraged in large part by Technorati). Rather than offering any tag hierarchy, typical usage on the web is for all tags on a site (or within a user’s account, for private tags) to simply exist in one big namespace, sorted for display either alphabetically or by popularity. A hybrid listing, sorted alphabetically with type size denoting popularity, has become known as a “tag cloud”.

Hierarchical tags

For me, this approach doesn’t scale well. With more than a few dozen tags, the organization cries out for some further structure. This is true for tags describing web pages as well as tags describing photos or blog posts, but the sheer number of photos I take, and the diversity of their tags, first made the problem acute in that context. I have tags for a dozen different types of boats, for example, and for several dozen places, and for more than 30 people; mixing those together in an alphabetical sequence is counterproductive, yet that is what sites such as Flickr force you to do. In the Photoshop Elements organizer (which is where the Fotiva/Photoshop Album code base ended up), you can have hierarchical tag categories, so I have Places > USA > California > San Francisco Bay > Angel Island, and Boats > Sailboats > Schooners. I have hundreds of tags, and without these categories they would be much harder to use.

A proposal for tag clusters

To use the tag hierarchy in this way, you have to create tags within the hierarchy. Once tags are created, you can apply them in Photoshop Elements using drag-and-drop from the tree-structured tag list.

Simply entering tags as free-text, whether they are new tags or ones you’ve used before, is widely used on the web, and it is the ultimate in simplicity. But it doesn’t provide any clear way to support a tag hierarchy. With a few dozen tags, it’s fine, but as time progresses and you have more tagged material, it becomes less effective.

For blog authors, the problem is similar but has some different twists. For this blog, I have sections and tags, but they have no relationship to one another; they are two orthogonal organizing schemes. Sections are more static than tags; they must be created independently of creating a post. Tags, on the other hand, can be freely created just by entering them when creating a post. Since blog search engines such as Technorati, as well as some photo sites like Flickr, search on the tags, it is important to have reasonably specific tags, especially if you want to associate blog posts or photos with a particular event.

So what I end up with is tags that are very specific, and sections that are very general, but no connection between them. If tags knew what sections they belonged in, then I could dispense with assigning posts to sections as well as giving them tags. I could also list the appropriate tags as an index for a given section, to provide an easier way to navigate it.

Ideally, sections should be created by clusters of tags. For example, posts tagged as ruby-on-rails or php or css should all appear in the Web Development category. The question then becomes how tags get associated with sections. Any time a new tag is used, the blog engine could prompt the user for the section to which it belongs. Potentially, sections could be inferred automatically, using an existing lexicon for reference.

I think a similar approach could work for tagging photos. It could make sites like Flickr more capable organizers, or make programs like Photoshop Elements easier to use for tagging.

I’m planning to explore a Mephisto extension along these lines. I’d love to hear about any experiences you’ve had with organizing tags into clusters or hierarchies to make them more useful.

Photo sharing has proven to be one of the Internet’s most common applications. Indeed, the ability to easily share photos electronically is a key driver behind the success of digital cameras. In the past five years, dozens of photo sharing web sites and other sharing services have come and, in many cases, gone. Yet I still don’t find any service that I’ve used entirely satisfying.

The first-generation photo sites, such as Zing and PhotoPoint, had a simple model: upload photos and invite people to view them. Kodak, Shutterfly, Snapfish, Smugmug, and many others continue with this approach. They have survived, while Zing and PhotoPoint did not, by having better monetization strategies: either they are really printing services, with electronic sharing being incidental, or they have become paid subscription services.

But for me, and I believe for many consumers, all of these Web-centric solutions suffer from a clumsiness that makes them unsatisfying and causes me to share much less than I would like. At the heart of the problem is the complete disconnect between the way I manage my photos on my PC, and how I manage them online. The only way to achieve an elegant, simple solution is to eliminate this dichotomy.

There’s three ways one might approach this:

• Make the web central. Upload all your photos, do all your organizing online, and access photos on the web whenever you want to do anything with them.

• Make the PC central, and use peer-to-peer access to enable sharing directly from the PC.

• Make the PC central, with the web being an automatic, partial mirror of what is on the PC.

Pure Web-Centric Solutions Need Much More Bandwidth

I believe the first approach will not succeed, at least in the near term, because it simply takes too long to move significant numbers of photos up to the web. There are other challenges as well, such as the difficulty of achieving a high-quality user experience in a web-based application involving large files, but the upload bandwidth is the most fundamental limitation.

Broadband is becoming widespread, but the vast majority of broadband connections have relatively modest upload speeds. There’s just no way I’m going to put up with the latency of uploading photos to the web before I can do things with them.

Peer-to-Peer is Not the Answer

Some companies have advocated peer-to-peer sharing as the answer. This has its attractions. I don’t have to spend time uploading, I don’t have to choose in advance which subset to share, and, at least if I organize using the file system, the organizing work I do on the PC is visible over the web. There are some P2P photo sharing services that have seen some success, such as Google/Picasa’s Hello and H2ST’s Pixpo.

However, I don’t believe that P2P is the way to go for most photo sharing, for several reasons:

• I don’t want to depend on my home PC being on and connected all the time.

• I don’t want my PC spending cycles and using bandwidth for photo sharing when I’m performing other tasks.

• I don’t want the recipient’s viewing experience to be limited by the upstream bandwidth of my internet connection.

There’s a reason I host my web sites at a hosting company, and not on a computer in my home or office: I want someone who is in the business of doing so to keep the server always running and supplied with ample bandwidth. For the same reason, I want photos I’m sharing to be hosted elsewhere.

Having a server “in the cloud” provides many advantages. Not only does it offer faster, more reliable connectivity, it can also act as an offsite backup. It can create photo renditions at various resolutions, providing each viewer a size optimized for their needs. It can provide a link to photo printing services. And it can serve as a collaboration hub when many people take photos of one event. (All of these things are possible in a P2P arrangement but more practical with a hosted solution.)

P2P has been a great success for sharing commercial content, but there’s two factors behind this success that don’t apply to most photo sharing. First, with commercial content, there’s thousands of copies of every file, so you aren’t dependent on any one computer being online. And the real reason P2P has seen such spectacular success is that it is a superb way to illegally share copyrighted content while obscuring who is responsible.

My Pick: PC-Centric, Mirrored Online

So I want my primary photo repository to be local, and the web to be a selective mirror. I don’t want to explicitly upload photos, I don’t want to organize on the web separately from the organization work I do locally, and I want all the metadata (such as captions) that I enter locally to be visible on the web. I want all the pictures I care about to appear magically in my web repository, for my use, but I want them kept private unless I’ve explicitly enabled them to be shared.

For most photos, the full resolution doesn’t need to be online, but in some cases I do want the original online, either for archiving or so others can make large prints. When I’ve enabled it, I want an easy way for others to order prints, and I want them to be able to download high-resolution files to print at home.

When I create a slideshow or photo book on my PC, I want it to be available online without additional work.

I some cases, I want others to be able to add photos to my collection. For my kids’ school events, for example, what I want is not just my pictures online, but on online location for everyone’s pictures. I want to be able to make photo books, and enable others to make photos books, and anyone involved to in the group to be able to order them. SnapJot is one service that does this, but it lacks some of the other critical features for my needs.

I’m not aware of any solution available today that meets my needs. As a result, I share fewer photos than I would like, and for those that I do share I endure a process that is more cumbersome than I want.

There are some interesting options appearing from companies such as Sharpcast. I think the problems are entirely solvable, but it requires a company that can craft a solution that unifies the desktop and web experience, and that can attract a large enough customer base to justify the investment. Photo sharing companies have generally been web-centric with little desktop software capability. Desktop software companies tend to be weak on the web side. And startups have a big challenge reaching enough customers. But the opportunity remains for a much better solution than exists today.

So Why Don’t I Do It?

I do believe I know what the right solution looks like. I’ve spent seven years in the digital photo domain looking deeply at all these issues. And I am looking at opportunities to start new web-based companies. But I’m not planning to chase this opportunity.

Why not? There’s just too much competition, too much noise, and it’s too hard to attract significant numbers of customers to a new offering in this space, no matter how cool it may be. One thing the Fotiva experience taught me is that a superior product idea is insufficient to create a good business.

I believe the company that wins in this space will be one that already has a great brand and lots of customers. It could be a well-funded startup with incredible marketing talent, but I think it is more likely to be an existing player. Adobe is an obvious candidate, if only it could get out of its own way. Microsoft is certainly a possibility. Apple is as well, if it put more focus on cross-platform software. Google and Yahoo have the web infrastructure, to be sure, but they tend to undervalue the desktop client piece.

Do you use a service that solves these problems? I’d love to hear about it.

It is often said that failures are more instructive than successes. In this spirit, I’ve done a lot of reflection on what went wrong at Fotiva, my previous startup that we sold to Adobe at the end of 2001.

In many respects, Fotiva was a success. We succeeded in building a great team, funding the product development, creating a breakthrough photo-management experience, selling the company to Adobe, and delivering this experience in the context of the Adobe product line. So there’s a lot to feel good about.

From the perspective of building a sustainable company, however, or delivering the returns venture investors look for, it must be admitted that Fotiva failed.

Our focus on was on providing a complete solution that would enable consumers to move from film to digital photography without adding lots of complexity. There were several environmental factors that were in our favor:

• We believed that consumers were about to make a massive transition from film to digital cameras. This indeed happened. A transition of this magnitude seemed like a great opportunity to build a new business.

• People already were accustomed to spending time and money on their photos, and the transition to digital, which was driven by the appeal of the cameras themselves, required consumers to adopt new tools and methods. So we didn’t have to convince people to take on an entirely new activity, and we didn’t have to be the driving force in causing them to make a change.

• Existing imaging software was largely focused on editing, whereas the major need of consumers was to collect, find, and share their photos, which is where we focused.

Sounds like a great setup, right?

The immediate problem, which led to the sale of the company at a modest price, was that completing a second round of financing in the fall of 2001 was impossible, despite having a nearly completed product and a great executive and engineering team. In a less hunkered-down investment climate, I believe we would have been able to complete this financing round. The venture community was licking its wounds and trying to salvage companies in which it had large investments, which made it almost impossible for young ventures to raise money.

There were, however, deeper and more enduring challenges that would likely have limited the company’s potential even if it had been funded. These issues also constrained the future of Fotiva’s software within Adobe.

The most fundamental issue was this: given an even marginally usable solution for free, most consumers will never look for a better one.

When Fotiva’s software was released, in evolved form, as Photoshop Album, Adobe was able to make only a moderate success of it, despite the huge draw of the Adobe name. There’s a lot that I think Adobe could have done to make it more successful, but the biggest problem was inherent in the market.

Once someone reached the point of considering purchase of a piece of photo software, many (if not most) would purchase Photoshop Album. The product won the category, such as it was. But the overwhelming winner in the category was nothing—at least nothing that wasn’t free. The vast majority of people simply used the capabilities built in to Windows XP (or iPhoto on the Mac), or the software that came with their camera, or other free solutions (most notably Picasa). While annual sales of digital cameras skyrocketed, sales of digital imaging software remained relatively stagnant.

In addition, we found that convincing people of the superiority of our approach was tough. Changing entrenched habits is very hard. Once users became accustomed to working with their photos as native elements in the file system, it was challenging to convince people of the merits of the database-oriented approach. To be sure, there are downsides as well, and there were some problems in execution, but nevertheless I believe far more people would benefit from this approach than were willing to adopt it.

I took from this experience these lessons, among others:

• Providing a superior solution to a real problem at an affordable price isn’t enough to capture a market, even with a great brand on your side. If there are adequate free solutions, it is very hard to sell a superior solution in large quantity.

• Even if users have a real problem, if they don’t perceive that it is a problem that better software could solve for them, there isn’t much of a market. Having the best user interface means nothing to people who never give it a try.

• A great piece of software doesn’t necessarily create a great business. In most cases, consumers simply don’t consider buying software. And service revenues, while attractive in theory, can take a long time to develop to substantial levels.

One of the projects I led at Adobe during the past year was the development of a new generation of web photo galleries to replace the clunky old HTML galleries that have been in Photoshop and Photoshop Elements for years. We built what I think is a pretty cool Flash application, which has some really nice features compared to typical web galleries. Most notably, it:

• Scales to fill the browser window
• Uses multiple image renditions (sizes) and uses the one most appropriate to the window size
• Performs intelligent prefetching of images
• Can be extensively styled via an XMLfile
• Supports video clips (FLV format) in addition to still images

This gallery is used in Photoshop Elements 5.0 and in Photoshop Lightroom, with different styling.

Now, for the news: Adobe has released the source code for the gallery as open source. This is a pretty large ActionScript program, which was written for Adobe by Bluefire Productions. You can get the code now from the Adobe Open Source site.

If you’re a Flash developer, you can modify the gallery program, or learn from it to produce your own design, and then distribute it to users of Photoshop Elements or Lightroom. They can install your design in either application and create galleries using it just like they can with Adobe’s standard version. You can even specify, using XML, what customization controls you want presented in the application. There’s a tutorial on how it works on the Flash Developer Center (coauthored by yours truly).

Here’s some examples of what the gallery can do:

• Thumbnail grid plus preview image
• Vertical thumbnail strip plus preview image
• Horizontal scrolling thumbnail strip plus preview image
• Slideshow with background image
• Lots of slideshows produced by users of Lighroom beta

I’ve just reached the end of a seven-year adventure into software for digital photography. The adventure began with my first digital camera, a Nikon 950, in July 1999. My frustrations with the difficulties of working with digital photos on the PC led me to conceive of a digital photo appliance, a “photo tablet,” during the Thanksgiving weekend that year. In February 2000, my cofounders Ken Rothmuller and Bernard Peuto had signed on, and PhotoTablet was incorporated. A couple months later, we closed on $2 million in seed funding from the venture capital firm New Enterprise Associates, thanks to the vision of general partner Stewart Alsop.

During the next six months, we realized that our tablet appliance concept was ahead of its time. Our product plan evolved by September 2000 to be based on a PC application, and by early 2001 we had built a great executive team, including CEO Jim Heeger and VP Marketing Tanya Roberts (both now at PayCycle). We renamed the company Fotiva, and set out to raise a second round of financing to bring the product to market. Alas, the fall of 2001 was the worst of times for raising money, especially for a consumer-focused digital photography company. We ended up selling the company to Adobe Systems in December 2001. The software that we built at Fotiva turned into Photoshop Album, and then into the organizer mode of Photoshop Elements.

Along the way, I learned a great deal about the photo industry, the shrink-wrapped software business, and life in a big company. It was a grand adventure, but I’m thrilled to now be returning to the world of building a small business.

View the Fotiva web site, captured for posterity as a PDF file before it was taken offline. (Keep in mind that this is more than five years old now, so many of the external links and email addresses no longer work.)