Blue Sky On Mars

I haven’t been there yet (it just opened today), but Borders has just opened their first new “concept” store right around the corner from my house. Eighteen months in development, this store is out to change Borders’ future prospects and help stop the losses.

At this point, it’s unclear to me what bookstores will look like in 10 years. The Kindle, while certainly not perfect, is a glimpse of a more paperless future that I think will come to pass at some point. In the meantime, though, something like this new Borders sounds like the right idea. They’re looking to blend their traditional book and music selling business with how people are actually making use of the content. They’ve got kiosks where you can buy prints of photos or custom burned CDs. You can also load up your MP3 player… except…

The only glitch so far: The digital services don’t work with Apple’s iPod, something Borders says it’s working on. [From Borders offers preview of new concept store - Latest from the Ann Arbor News - MLive.com]

It’s hard to say who’s at fault for this, be it the record labels or Apple, but Borders’ inability to sell music that can be loaded directly onto iPods eliminates 70% of the digital music players out there. Just as online sellers have been battling these past 10 years to sell content in convenient electronic forms online, brick and mortar stores like Borders are going to have a challenge creating interesting and useful physical destinations in an age of electronic content.

Guy Kawasaki’s blog is fantasic. Really great reading (and only a month old!) One recent entry: The Art of Rainmaking stresses some great points about selling your product. His writing here is focused on selling some goods and getting some cash, but many of his points are applicable to selling anything: ideas, open source tools, etc.

Over the years, I’ve done a variety of reviews. I’ve also consumed a lot more books, music, movies and websites than I’ve managed to review or mention here. I’ve decided that I’d really like to highlight some of the great things that I’ve found along the way.

(more…)

In product management, the things you choose not to do are at least as important as the things you choose to do. Though it might seem like adding features is always a good thing, there are actually tradeoffs being made with each feature added. Consider my cell phone (a Nokia Series 60): this thing can do many different things. It keeps my contacts, has games, takes pictures and can wake me up via its alarm clock. Because it has so many features, I have to do *a lot* of clicking around to set an alarm on the alarm clock. If the phone had fewer features, the user experience could be optimized better for setting alarms.

In an open source project, having an idea of what your product truly is becomes critical. Many people will have patches or apparently complementary projects that are ready and free for the taking. But, should you take them?

Numerous times along the way, people have asked about using “template package X” or “database thingy Y” with TurboGears. There have been thoughts of making TurboGears abstract away some of the underlying pieces so that they can be swapped out. (My responses have been that TurboGears shouldn’t stand in the way of using those other packages, but TurboGears itself will not directly support them.)

If what you want is to pick and choose every piece of the application stack, then the web framework you want is CherryPy or, I guess, one of the other controller frameworks. If one tried to support everything in order to become the web framework “to rule them all”, you’d eventually end up with just Python (or some hideous layer on top of Python) and the current collection of fine components available for Python.

TurboGears is not going to go that route. Here are the overarching thoughts that go in to TurboGears’ evolution:

1. best-of-breed
2. one way to do it

I want to start with and maintain use of the “best-of-breed” components for each part of the stack. If you use great quality ingredients, you’ll get a great tasting cake.

Of course, “best” is in the eye of the beholder. Often, two components may be equally capable, but have a different feel. That’s when you get into a more subjective area which makes the second rule that much more important: rather than punting when faced with two nearly equal choices, pick one and run with it.

I can’t overstate the importance of TurboGears providing “one obvious way to do it” (at least when it comes to the big picture items). Let’s say that TurboGears specifically supported several templating packages (and there are certainly several to choose from in Python). The documentation would balloon, because it would have to cover both. The users would somehow have to have a basis for choice and the mailing list will get frequent questions of “which one should I use?”. Email traffic related to template issues would likely double. Features like internationalization would need to account for both. And, the path to adding more features that integrate multiple components would be a lot less clear. The new TurboGears widgets package uses Kid to power the appearance of the widgets. The Toolbox makes full use of all of TurboGears’ components.

Am I saying it’s always wrong to provide a choice? No. But, if there is going to be a choice, there has to be a good reason for it. If it’s a specific use case that one tool handles tremendously better than another, document that use case and encourage people to use the right tool for the job. If it’s a case where one component is far better overall, but is just missing a feature that another has, maybe it’s better to try to build that feature into the component of choice.

Wouldn’t some people be turned away if you don’t support the exact component they want to use? Sure. But, expending the effort to support that rather than truly enhancing the user experience will cost far more users than simply not supporting one group’s preference. An example of this is alternative database technologies. Python has quite a few interesting non-relational databases available. There are certainly applications for which those databases make life easier. And, you can even use those technologies with TurboGears, just without special tool support. But, for the vast majority of people writing web applications today, relational databases are the primary storage option and which means that providing optimum support for relational databases is key. Providing support in TurboGears for non-relational databases would muddy the waters considerably. (Would CatWalk have to support those other tools? How about the tg-admin command line tool?) You could end up with half-baked support for a whole bunch of things rather than robust support for the “best-of-breed” toolset.

Note that I’m not saying that TurboGears won’t have plugin support to allow people to mix in other components. The balance being struck here is that TurboGears provides a distinct way to get things done. If you agree in general with the TurboGears approach, but have some specific unusual needs you want to meet, TurboGears should at least try provide a reasonable way to meet those needs while you use the rest of the framework. The “reasonable way” to meet those other needs cannot conflict with the primary tools being used, however.

One more point about when to say “no”: Good ideas come along all the time. At some point, you’ve just gotta ship it. Particularly with software, “good enough” today is worth a lot more than “perfect” at some distant point in the future. 1.0 is not the end, but just the beginning.

TurboGears as envisioned and implemented can meet a wide variety of web app needs in a way that many people find fun to use. It’s impossible to make a framework that makes everyone happy, and to try would mean creating a framework that ultimately makes no one truly happy.

Because I’m behind on my reading, I hadn’t heard about the Kinkless GTD system for OmniOutliner. I had already been organizing myself via OmniOutliner, but Kinkless looks much slicker than the route I was taking. If you’re into GTD and OmniOutliner, this is something you should really see!

Every time a prospective customer needs to make a choice, you open up the possibility that the choice will be to head somewhere else.

A couple months ago, Apple offered: the iPod Shuffle, iPod mini, iPod and iPod Photo. I’m not going to count the U2 iPod, because that’s more of a niche gimmick sort of thing. Since then, Apple has introduced two new models, but reduced the number of choices: iPod Shuffle, iPod nano and iPod. These models come in at nicely spaced price points, and it should be pretty clear to a potential customer which one they should buy.

Contrast that with Creative’s lineup. Desparate to win some market share, these guys seem to want to throw a ton of products at the wall to see which stick. At first I thought they had 9 models, but then I noticed the little arrows. They 9 Zen models, 11 Muvo models and something called the “FX200″.

From some reviews I’ve read, some of these models are actually quite good. Of course, it’s impossible for me to remember which of the 21 models those are. Do stores really have shelf space for 21 models, some of which come in 10 colors? How can they profitably produce so many models?

Apple appears to understand market segmentation. They offer an entry level device, an ultra portable skip-proof device and a full-size model with good storage capacity. It’s crystal clear how Apple has segmented their market, which means the choice of product will be crystal clear to the people who are prospective Apple customers. Apple’s 75% share of the market proves that their segmentation isn’t leaving many users out.

I challenge someone to explain Creative’s market segmentation. From the photos, it would appear that the Zen is for businessmen who thought it was a cell phone. The Zen Micro is for stylish women who bought the player to show off that they’re in the 21st century. The Zen Neeon is for women who can’t make up their mind and will buy all 10 colors. The Zen Nano Plus is for the trendy (but not rugged) outdoors types.

With a product lineup like that, it’s no wonder that Creative will need to resort to lawyers to make a buck.

There are lots of wiki programs out there. I mean lots. It seems like everyone has written one, in just about every language there is.

Wikis are used a lot for software project documentation, because they’re just so easy. The barriers to jumping into a wiki and adding a page where one seems needed are so low that people dive right in with gusto. You’d think that my issue with wikis is that you end up with a huge mass of disorganized pages. That’s not it, though… with some judicious care, that mass can be turned into something useful readily enough.

My issue with wikis for software development is a problem of unknown obsolescence. The best example of this I can highlight right now is the CherryPy wiki. There’s quite a bit of potentially useful material there, but almost all of it won’t work as written in CherryPy 2.1. You go to the wiki looking for info, and you have no idea when you see a given page whether it’s applicable for the version of the software you’re using.

TurboGears documentation is all in Subversion because of this. This allows the documentation to naturally be tied to the version of the software. This also has the advantage that I can use my favorite editor and take full advantage of HTML when I’m doing docs.

Unfortunately, though, I don’t think anyone is going to check out the project just to write up some new docs. People are a lot more likely to add documentation if it’s as easy to do as updating a wiki.

We could try to give wikis branching and merging capabilities like you find in source control systems. We could also require users to go through a root canal to view our docs and see how well that goes over. Even though tools have gotten better than they were, branching and merging still seems to be a black art for many.

Perhaps there’s a simplified user interface that will do the trick. Something like this:

• By default, a user will be browsing at the latest released version (something that is marked by an admin). Links at the top of the page will let the user choose a different version to browse.
• Only major versions would get their own version of the wiki. In most software projects, the difference between 2.0 and 2.0.1 doesn’t involve a whole bunch of potentially breaking changes.
• When a new version is created, the wiki starts out empty. This is important, because it needs to be very clear to someone when they may be viewing a page that is out of date.
• If a wiki word is referenced that exists in a previous version of the software but not the current, the user can choose to start with the previous version and work from there. This way, there is a manual review step for each page.
• The history for the “2.0″ versions of a page is a separate line than the history of the “2.1″ versions of a page. Usually, the documentation for an older version is just going to languish anyhow.

To me, this seems easy to use for a browser of the wiki, editor of the wiki and even for the creator of the wiki software. Sure, a big wiki with lots of pages will have a bit of pain for a major new release, but you’re only talking about a couple clicks per page for pages that don’t require any changes. It seems like a major release is a good time to review the docs.

A decent wiki with a feature like this would definitely make me move my docs out of Subversion. Let me know if one exists.

I’ve been meaning to write up a review of Call To Action by Bryan Eisenberg and Jeffrey Eisenberg for some time. Meanwhile, in between the time that I read Call To Action and today, Seth Godin has released his KnockKnock ebook for free. I decided to review the two at the same time, because there is a lot of overlap.

I discovered Call To Action through Seth Godin’s blog, and wrote an early opinion of it back in June. At 70 pages in, I was underwhelmed. Thankfully, the book picked up after that point and I really started to get into it. I even sent a note to Ian Landsman toward the end of June saying that the book was a must read.

Call To Action is all about conversion: getting the somewhat random people that show up at your site to do whatever it is you want them to do (buy something, read something, download something). They use many real life examples to talk about good strategies for doing this. One big takeaway I got was that relying on a site search engine is a bad idea. If someone resorts to the search engine, your primary navigation has failed them. And, once they’re at the search engine, there’s a good chance they’re going to end up leaving your site.

The Eisenbergs also stress the testing of your ideas to see what actually works. This is something that comes up in many areas (including software development). If it’s fairly easy to test, why just go on a hunch about what the problem is?

Call To Action is a fine book with important ideas, but you can get the same important ideas in the free and far more succinct Knock Knock.

Godin’s ebook weighs in a 41 pages, including unobtrusive ads, colorful screenshots and pleasantly easy-on-the-eyes text.

By the time you’ve hit page 300 of Call To Action, you’re starting to think “all right, all right, I get it. Now leave me to work.” Many business books seem to have a problem with repetition. It’s like they need to fill pages so that you feel like you’re getting your money’s worth.

Sure, Knock Knock doesn’t go into some of the detail that Call To Action does. There are no references to stats and studies, for example. But, in my opinion, the most important thing from both of these books is the idea that you’ve got to get the people that come to your website to do something, and all of your efforts in site building should be focused on that.

Now that I’ve given the idea away, you don’t have to read either book. I’d still recommend reading Knock Knock, however. Being told something is not the same as seeing it for yourself. Godin’s text and examples do a good job in making the point, and Knock Knock is easy to read over lunch (that’s what I did).

In case it’s not clear by now, unless you’ve got a website that’s already converting 90% of visitors, I highly recommend reading Knock Knock by Seth Godin.

John Jantsch has a great tip for getting quality testimonials for your product. The key is rather than asking for a testimonial directly, have a prospective customer ask a current customer for an opinion. You’ll end up with a better-written testimonial than if you had asked for one directly. I’ve never tried this myself, but I do believe this would work wonders.

As promised when he released it, Seth Godin’s ebook KnockKnock is now available for free.

It’s a short take on how to use the new online marketing tools to make any website work more effectively.

I haven’t read it yet, but I’ve enjoyed Seth’s work in the past. All of his books have at least one powerful idea that makes the read worthwhile.