Web developer personas (are you in there?)

User personas are a useful tool for when you want to discuss needs that users¬† have and, ultimately, features that meet those needs. Personas help keep you talking about real people versus some random “user”.

I’d like to build up a collection of web developer personas that we can use in our product and feature planning. The idea is that each persona will represent a (largely)[1] distinct collection of web developers.¬† We can use these personas when we’re crafting product requirements, though we will likely need to customize them to properly describe specific kinds of problems we’re trying to solve.

Are you a web developer? If so, please take a quick look at the initial set of personas I’ve created and let me know if none of these would be able to reflect the workflows and tools you use regularly.

Footnotes    (↵ returns to text)

  1. There’s actually quite a bit of overlap in terms of tools that different web developers regularly use, but there is also a wide range of workflows and a wide variety of tools at the edges. For example, almost everyone uses browser-based styling tools for making tweaks to their styles. But, for editing their CSS files, people use all kinds of different editors. Some people might use the ReCSS bookmarklet to reload their CSS automatically. Others use LESS or SASS with some kind of build step before they preview their pages. This variety is part of the reason it’s helpful to have some representative personas and talk in terms of what they’re trying to accomplish, rather than how they do it.

Thinking About the Developer Experience for the Web

I’ve been working on developer tools for a while now, and I’m really proud of what we are shipping in Firefox today and the new features that are right around the corner. Browser tools are one of the most important parts of a web developer’s toolbox.

But, there’s a lot more that goes into web development than the browser tools. The video above and the text that follows are some thoughts on the whole of the web developer’s experience.

Web development is great because the platform is so high level and dynamic. That makes it easy to get started. There’s a massive collection of libraries, tools, books, tutorials and more to help web developers get things done once they’ve moved beyond the first steps. In fact, there’s so much out there that it can be hard for someone getting going to decide how to go from idea to done. The riches of the web ecosystem are both a blessing and a curse. It’s more blessing than curse, but that doesn’t make it any easier for newcomers and, in some instances, for experienced developers that are moving into a new area or applying a new technology.

Mozilla’s non-profit mission is to protect openness and innovation on the web. We want to make the web better for everyone, and I think we’re in a good position to help guide developers from idea to published app. Doing so is especially critical for our Apps initiative.

To that end, Daniel Buchner and I will be looking beyond developer tools in our product plans to include the whole of the developer experience. This will first show up in an Apps context, but we’re going to look for ways to apply what we do more broadly.

The Point of Diminishing Features

Making software products is a great business. You release version 1 and start selling, followed by new major versions from time to time that generate further upgrade revenue. A good product can give you a nice ongoing business.

It seems like a lot of products, and not just software products, are really exciting when they first come out. People go gaga over the product and buy it by the truckload. Then comes the next version, and it’s got some huge improvements and people happily snap it up. The next version really puts the polish on, and again is a hit. In fact, I think I’ve seen it said that Microsoft products don’t really hit their stride until 3.0.
But I think that’s precisely where the “point of diminishing features” is reached. The product went from intriguing to great to “use all the time”. The improvements made after that might entice some new customers but no longer really shine for the existing customers.
Let me make that more concrete: Microsoft Office hit that point a long time ago. Or, more specifically, Word, PowerPoint and Excel. The only useful features Microsoft could add were features that were useful and exciting to a very small subset of their audience. Upgrades to those products simply wouldn’t be exciting enough for most people. And, major UI reshufflings just annoy people, rather than making them want to upgrade.
In the case of Office, since almost everyone buys it as a bundle, Microsoft had the option of creating entirely new products like OneNote and then making it seem like a no-brainer to just buy the upgraded suite.
Watching the Apple “Back to the Mac” keynote, it really felt like iLife had hit the point of diminishing features. Watching Steve Jobs, I didn’t get the impression that even he was truly excited about iLife ’11. He seemed most excited when he introduced the new MacBook Air.
I wanted to be excited by iLife ’11. There were features there that were “kinda neat”, but nothing that made me want to grab the credit card and head out to the store.
What’s the cure? “Think different”. Try to come up with fundamentally new ways for the customer to do things and use that type of product, or create features that take something that you frequently want to do and turn it into a quick, fun task. Making trailers looks like fun in iLife ’11, but I don’t actually want to make trailers. I’ll be curious to see how many of those things show up on YouTube.
Mac OS Lion seems like it will be way more interesting than iLife ’11, because Apple is bringing a bunch of unusual new ways to work with a full computer in from the iOS world. And, you can bet that we’ve only seen a piece of Lion.
I think iWork has the potential to be exciting, just because so many features are still missing from Numbers and Pages. iWork doesn’t feel like it has reached “3.0” yet.
I’ll end this line of thinking with a product that ran for a good number of years before hitting the point of diminishing features: the iPod. The iPod had a good run of big new features because Apple was willing to take major moves like drop the best-selling mini in favor of the new and untried nano.
If you’re working on a product and find yourself unable to be truly excited by the features coming in the next rev, maybe it’s time to go back to the drawing board and rethink some fundamental aspects of it.

MacSpeech fails the version number test

MacSpeech Dictate 1.5 has just been released. In the process, they made a major product management blunder: they chose the wrong version number. How can you mess up with a version number? Simple: you misalign your own expectations with those of your customers.

MacSpeech Dictate is really the only viable speech recognition software for the Mac today. Their original iListen project wasn’t so hot. So, they licensed the Dragon NaturallySpeaking engine and put a Mac UI on top to produce Dictate. The first version that came out was somewhat incomplete, in that there was no way to train the program and improve its accuracy. In October 2008, they released Dictate 1.2 as a free upgrade, adding the training features. In February 2009, Dictate 1.3 added features to make dictation work better with other apps and add some other features. Dictate 1.3 was also a free upgrade.

Now, three months later, they have released Dictate 1.5 as a $55 upgrade. Two of the major features listed are “better accuracy” and “faster performance”, which I think to many people come across as fixes more than features. Just take a look at the comments on the forum thread. The Vocabulary Editor is a true new feature, and the “New Commands” bit sounds like a minor thing they tossed in.

Based on the feature list they presented, “1.5” sounds like the right version number. It doesn’t seem any greater in scope than 1.2 or 1.3. And yet, for the MacSpeech folks themselves, it probably seems like a long time since 1.0 came out and perhaps they’re feeling the pinch of the current economy. Certainly, the amount of work they’ve done on the product between 1.0 and 1.5 is significant. I’m sure they feel entitled to an additional $55.

Release early, release often is a phrase used a lot in the open source world. For commercial software, however, if you want to offer a paid upgrade, you can’t follow that rule. By doing relatively quick releases of similar scope, MacSpeech inadvertently set the expectation that 1.5 should be a free upgrade. Had they spent 3-6 more months adding new features and then released it as “2.0”, I’m certain they would have had fewer complaints about the upgrade being a paid upgrade.

As far as I know, MacSpeech Dictate doesn’t have any strong competition. From that perspective, they could have waited a few months more. It is possible that they’ve been hit by the economy, though, and couldn’t wait several more months for the additional revenue. If so, that’s a tough spot, and I wish them luck. Regardless, I doubt they were expecting this kind of reaction to a new release, and they may not get the kind of revenue they’re hoping for. HarvidMD in the forum thread:

With upgrade policies like this, I think that I’ll save my pennies and wait for MacSpeech Dictate 3.0 in about five years so that I’ll be able to get a voice recognition package that actually performs as advertised.

Product Activation sucks.

The music industry has figured out that DRM doesn’t work and does more to annoy real customers than it does to stop thieves. If they had paid attention to history, they would have found that in the 80s and early 90s, the software industry had already learned that lesson.

Recently, I moved from an older Mac laptop to a new one. I used the Migration Assistant and everything came across just fine and appeared to be working just fine. Then, last night I recorded a video using ScreenFlow at the MichiPUG meeting. Much to my surprise, it said that it was an unregistered copy. Entering my license key didn’t help, because it said the number was “expired”.

I also had a suspicion about another product I own, Kinemac, and sure enough it had gone into an unregistered state.

Before wiping my old computer, I did think to deauthorize iTunes. But, is someone seriously going to remember to deauthorize every random program that uses that technique? What a waste of time!

So, shame on you Vara Software (ScreenFlow) and Kinemac for not learning from history. I have no doubt that they’ll take care of getting me up and running again… that’s not the point. The point is that every other commercial program I use has continued to work just fine (Apple’s software, Things, Pixelmator MenuCalendarClock, TextMate, Leap and everything else I’ve tried that I’m forgetting).

Update: It looks like the issue with ScreenFlow may not have
been a bad product activation system. Vara Software was acquired by
Telestream last year, and I think their product licensing system
switched over to Telestream’s in the process. So, my old Vara Software
style serial number was no longer valid. Their tech support people had
me “repurchase” the software with a coupon code that made it free, thus
giving me a valid, up-to-date serial number.

Can Borders’ new concept store push toward a brick-and-mortar future?

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.

Let the Good Times Roll–by Guy Kawasaki: The Art of Rainmaking

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.

What is TurboGears not?

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.