Worst. Form. Ever. · 294 words posted 05/09/2006 06:55 PM

Brian Eno and David Byrne released My Life in the Bush With Ghosts twenty-five years ago. A newly packaged and remixed CD is now in the stores, along with a promotional website.

As befits a nostalgia project, the registration form is a throwback to bad-old-days of the late 90s, when designers often put flash gimmickry ahead of helping the user accomplish the task at hand. This form isn’t just awkward; it’s actively hostile.

That’s a shame. Once registered you can apparently download tracks from the album to remix under a Creative Commons license. But I couldn’t get past the form.

Seriously, who builds junk like this anymore?

Comment

* * *

Adobe: The Phone Number field does not match the pattern ^[0-9 \.,/\-\(\)\+]*$. · 203 words posted 04/05/2006 07:13 AM

While trying to update my customer account at Adobe I got the following error message:

The Phone Number field does not match the pattern ^[0-9 \.,/\-\(\)\+]*$.

I’m pretty handy with Regular Expressions and I still couldn’t get Adobe to accept my phone number. It’s a textbook example of bad error handling: written by programmers for programmers.

What’s more, there are several form fields for phone numbers and the error message is nowhere close to the offending field. Good error handling on the web follows two guidelines:

Error handling runs with a company’s culture. Some companies get it, others don’t. Macromedia got it: ColdFusion makes it easy to write form validation routines that help people recover from mistakes. Validation in Flash forms couldn’t be better: here’s an example from the Macromedia account login page. The field in question is highlighted, the error message is close to the error, and the language in the message isn’t technical.

Here’s hoping some of Macromedia’s best practices rub off on Adobe.

For more on error handling on the web, see Defensive Design for the Web from 37signals.

Comment [2]

* * *

180: That Patent Application Doesn't Say What You Think It Says · 1023 words posted 02/23/2006 07:10 PM

You’ve heard about it by now: the US Patent and Trademark Office issued Patent 7,000,180 (hereinafter “180”) on Valentine’s Day, granting some wicked licensing mojo on internet moving thingies to a previously obscure web design shop named Balthaser.

I say “wicked licensing mojo” and “internet moving thingies” because no one seems to have accurately described what the patent actually covers. Here’s Information Week’s take:

A patent has been granted to a relatively unknown California Web-design firm for an invention its creator says covers the design and creation of most rich-media applications used over the Internet. The patent holder, Balthaser Online Inc., says it could license nearly any rich-media Internet application across a broad range of devices and networks.

Potentially tens of thousands of businesses—not only software makers employing its business processes but companies offering rich-media on their Websites—could be subject to licensing fees when they use rich-media technology over the Internet.

The patent—issued on Valentine’s Day—covers all rich-media technology implementations, including Flash, Flex, Java, Ajax, and XAML, when the rich-media application is accessed on any device over the Internet, including desktops, mobile devices, set-top boxes, and video game consoles, says inventor Neil Balthaser, CEO of Balthaser Online, which he owns with his father Ken. “You can consider it a pioneering or umbrella patent. The broader claim is one that basically says that if you got a rich Internet application, it is covered by this patent.”

Zeldman simply calls it a patent on AJAX.

In other words, two groups would have to pay licensing fees to Balthaser under the alarmist reading of 180: anyone who distributes rich media1 over the internet (example: Basecamp, Gmail, etc. etc.), and anyone who sells a tool to create RIAs (example: Adobe/Macromedia, Microsoft).

But I’m pretty sure that’s an overly broad reading of what 180 actually claims. As with most patent applications, 180’s language is turgid and obfuscatory. That’s not really the fault of Balthaser and its legal team; it’s just how the game is played. But if you can wade through the muck, you’ll find a detailed description of how the “invention” is actually intended to be used.

Background: when an enterprising young man files a patent in hopes of bottling the magic2 he must include at least one example of a specific embodiment of his invention. The specific embodiment requirement forces the junior achiever to articulate how his abstract concepts will actually be put into practice.

Here are the specific embodiments contemplated by 180:

In a specific embodiment, the ability to create rich-media applications may be purchased by the user. Specifically, the user may purchase the right to use rich-media applications created on the host website, the right to design and create rich-media applications on the host website, or both. The user may also purchase the right to use more services by paying a different fee.

In a specific embodiment, the user may construct a rich-media application by using rich-media components including navigation elements, backgrounds, images, headings, sound files, text, windows, animations, e-mail clients, calculators, stock tickers, clocks, menus, movie files, and production types. Production types are customizable rich-media templates for performing specific operations such as presentations, resumes, catalogs, reports, user manuals, magazines, newspapers, photo albums, cartoons, websites, shows, movies, and invitations. The user may also upload components from other Internet locations for use in rich-media applications by listing the location of the component and the file type of the component. Applicable file types may include JPEG, MPEG, GIF, animated GIF, TIFF, EPS, PNG, SWF, MP3, and WAV. The user may be limited to a subset of all possible file types that may be uploaded depending on the level of service for which the user has paid.

In a specific embodiment, the user may create and access a customer account for the purpose of creating or modifying a rich-media application. Specifically, the user may access account and project information or save, close, delete, publish, or preview a project. The user may also create, insert, delete, save, or modify a scene of a rich-media application or add, access, edit, copy, paste, or delete components.

That’s just a sampling, but what becomes clear upon reading the specific embodiments in their entirety is that the patent is intended to cover a web interface for creating, editing, and hosting rich internet applications. The patent does not contemplate a desktop GUI, nor does it cover rich media created by a desktop GUI and hosted on your own server. The images accompanying the patent application seem to support this reading: by and large they’re site flows or database diagrams for setting up accounts and creating/saving/serving your rich app from a database to the web.

In other words, if you’re Microsoft and you hope to move a future version of Visual Studio onto the web so designers can use a web interface to create a web application, this patent may give you pause. Also, 180 might cover a web WYSIWYG app like Google’s new page creator.

I could be reading the patent incorrectly: remember, the language is defined to befuddle, not enlighten. And I’m not your lawyer. But if you’re Adobe/Macromedia and you sell Flash Professional 8 (a desktop GUI for creating rich media)—or if you’re a designer who creates rich media with a GUI and uploads it to the web—or if you write and host apps like Basecamp or Gmail—this patent says nothing to you about your life.

1 The patent specifically covers Flash, Java, MPEG movie files, and several other rich media formats. Curiously, the patent omits SVG. Even more notable, the patent doesn’t mention XMLHttpRequest, the foundation for “AJAX,” which dates back to the release of Internet Explorer in 1998, three years before patent 180 was filed in 2001.

2 I’m not making this part up. Here’s what Neil Balthaser said in the Information Week article: “My mom saw me struggling, and one day said, ‘Why don’t you figure out a way to bottle up that Balthaser magic and let people purchase the bottle and do it themselves?’ It was one of those whacks on the side of the head. ... I started to work on an early prototype.” That scamp!

Comment

* * *

Review: Creating a Web Page with HTML, Visual QuickProject Guide · 349 words posted 10/07/2004 06:10 PM

Elizabeth Castro Book Cover When Elizabeth Castro’s Creating a Web Page with HTML, Visual QuickProject Guide showed up in my mail recently, I wasn’t immediately inclined to review it. What could I say about a slender introduction to writing HTML? Then I came across Jeffrey Zeldman’s favorable review from several weeks ago:

With simple language and clear illustrations, Castro teaches budding web producers the basics of HTML and CSS in the context of a simple, hands-on project.

This is not a book for the world’s Dunstan Orchards; it is strictly for beginners (but not for dummies). If friends, colleagues, or family members with a desire to learn web design basics and no prior experience ask how to begin, you can safely recommend this book to them.

So I decided to give the book a second look.

And what a look. Mr. Zeldman has already covered the book’s substance; I want to praise the book’s style (disclosure: I co-authored a Visual QuickStart Guide for the same publisher two years ago).

When you review computer books regularly, you see a lot of crap. Many, maybe most, computer books are lazily written, poorly edited rehashes of instruction manuals that aren’t worth the industry standard price of $40+. I don’t write about the bad books because it’s more fun to bring the good ones to your attention—but the stinkers are legion.

Hoping to be first to market, publishers often require their authors to write titles while software is in beta, thus ensuring that the book won’t reflect a mature understanding of the software and will likely have a lengthy errata. Even assuming an author tries to write something fresh, her work is still at the mercy of publishers who increasingly cut costs at the printers. In otherwise favorable reviews this year, I’ve complained about low contrast gray-scale printing in books that would have benefited from color.

So it’s an uncommon treat when everything comes together as it does in Creating a Web Page with HTML. Clear writing. Useful appendices. No typos. And color on every single page for only $12.99. Bravo!

Why can’t more computer books be this professional?

Comment

* * *

Folksy, non-specific error messages on Gmail · 192 words posted 07/15/2004 07:28 AM

I got this error message when I couldn’t log in to Gmail this morning:

Sorry, something didn’t work correctly.

If we knew exactly what the problem was, we would tell you instead of giving you this useless error message. Actually, if we knew, we would most likely have fixed it already.

Rest assured. As you read this, alarm bells are ringing at the Googleplex, signifying something has gone horribly wrong in this quadrant. A report will soon be in the hands of our engineering team, detailing the bad thing that happened here. This team will work without rest to address the problem you have brought to their attention.

If, after a decent interval (about 24 hours), you encounter this problem again, please email us at accounts-support@google.com . The more specifics you include, the better (e.g., what kind of computer and browser you were using, what page you looked at last, what you clicked on, etc.). Sometimes, even our engineers need a little help.

Thanks for using Google.

So folksy, you’d almost think Gmail’s been hacked. (They haven’t: googling "this useless error message" turns up AdWord error messages at least 2 years old).

Comment

* * *

Review: More Eric Meyer on CSS · 280 words posted 05/27/2004 04:10 PM

Eric A. Meyer’s fifth book, More Eric Meyer on CSS, consists of 10 projects designed to help you separate your site’s appearance from its content. Each project explores many of the layout challenges you’re likely to encounter when building a site.

Wait a minute, says the reader, why are YOU writing a review of a CSS book? You use a default MovableType template, and you’ve publicly admitted that you don’t even have a firm grasp of the box model hack!

Fair enough.

But here’s why you should study a book of CSS projects even if you’re a programmer who cares not a whit for design: Assume that you need to display a gallery of images, with src attributes generated from database content. This requirement often means writing code to generate a table that displays rows and columns of images. It also means that when your client changes her mind about the page’s appearance—“we want x columns instead of y”—you have to change your code.

Or, as Mr. Meyer demonstrates in one of the book’s projects, you can simply generate an unordered list of images, each enclosed in a div, and then use CSS to create a columnar layout that automatically changes when the page is resized.

Although the book is not targeted toward programmers (and contains no server-side code), it contains enough great ideas for layouts that you can forget about struggling with tables and JavaScript menu hacks, and concentrate your programming time on serving up semantically meaningful markup.

The next time a client requests an interface change, buy this book for your designer and send Mr. Meyer a box of chocolates. They’ll both thank you.

~~~

Buy this book from Amazon.

* * *

Review: Defensive Design for the Web · 700 words posted 03/26/2004 05:14 PM

Defensive Design Cover Basecamp, a web-based project management tool, is one of the most elegant, affordable, and easy-to-use pieces of software I’ve encountered on or off the web. When I browse a site this good, I often think “I wish I could pick that guy’s brain.”

In this case, I could: Matthew Linderman and Jason Fried of 37signals, the web design and usability specialists, have distilled their knowledge of user interaction into Defensive Design for the Web: How to Improve Error Messages, Help, Forms, and Other Crisis Points (New Riders, 2004). As the authors describe:

No one’s perfect. Let’s admit it: Things will go wrong online. No matter how carefully you design a site, no matter how much testing you do, customers will still encounter problems. Sites must plan for these inevitable breakdowns with defensive design… By improving defensive design, online businesses can help customers recover from mishaps—increasing conversion rates and customer loyalty in the process.

37signals provides 40 guidelines for helping your users manage crisis points, including:

Each guideline is supported by multiple online examples. Simply listing the guidelines doesn’t do the book justice: you might be tempted to respond, “Well, that’s just common sense.” But many sites violate even the simplest of the guidelines.

Defensive Design gets right what so many other computer books do not: it is brief, free from jargon, and doesn’t attempt to browbeat you with a list of inflexible rules. The author’s tone of humble, informed guidance brings to mind Steve Krug’s Don’t Make Me Think, and Defensive Design clearly belongs on the same shelf as Mr. Krug’s usability classic. As good as the book is, though, it has two real flaws.

First, the book relies on “As if analogy” sidebars to compare online contingency design to offline situations. Too often, the sidebars are distractors, and simply highlight the differences between online and offline transactions. For example, Guideline 28 is “Don’t force registration.” In other words, web sites shouldn’t force customers to uniquely identify themselves before receiving assistance. Here’s the “As if” analogy:

Why is this bad? It’s as if I call the phone company to report a problem with my service. To receive assistance, however, I must first sign up for their customer mailing list.

But that’s not a precise comparison—in fact, there already is a real-world analogy: you won’t get support service from a phone company without providing your uniquely identifying information. Increasingly, you can’t even get pre-sales information from a phone company without providing uniquely identifying information. That may be a nuisance, but it’s common offline practice, and the inexact analogy simply muddies the otherwise reasonable online guideline: don’t force registration.

Defensive Design Screenshot

Second, and worse, the book is printed in black and white: the screenshots are small, low contrast, and difficult to read. This wouldn’t be such a nuisance if the screenshots were on the periphery of the authors’ message, but they’re not! Instead, the screenshots are central to each of the guidelines. Here’s a sample Yahoo! form used to support Guideline 11, “Explicitly state limits to characters.” (The screenshot was taken from a PDF at the book’s companion web site, but the paper version is almost as murky).

You might think color doesn’t matter to a book like this, but consider the authors’ second guideline: “Use color, icons, and text to clearly highlight and explain the problem area.”

Don't Make Me Think Screenshot

In defense of Linderman and Fried, the decision to publish a book in black and white is made by the publisher, New Riders, not the authors. Four years ago, the same publisher released Don’t Make Me Think—a book of similar length, scope, and goals—in glorious color on thick paper stock for $35 (sample screenshot, above, taken from the author’s site). Perhaps times are different, with publishers and purchasers poorer alike, but I would happily pay $35 for a full color version of Defensive Design. You should too: write to Jennifer Eberhardt, New Riders Senior Development Editor, and ask her to publish a second edition in color.

The bottom line: Defensive Design is a bargain at $25. But a book this good deserves to be better.

~~~

Buy this book from Amazon.

* * *

Al Sparber Interview · 1614 words posted 03/11/2004 04:54 PM

Al Sparber 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:

  1. Programming the extension and its Dreamweaver interface(s)
  2. Writing the User Guide
  3. 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:

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.

* * *

Nick Bradbury Interview · 1503 words posted 01/15/2004 04:58 PM

Nick Bradbury, handsome devil One-man software company Nick Bradbury is the creator of the popular web authoring tools HomeSite and TopStyle, and recently released the RSS newsfeed reader FeedDemon. Nick started his career as a cartoonist, but switched to programming after discovering that he liked to eat regularly and have a roof over his head.

Nick’s company, the aptly-named Bradbury Software, can be found at www.bradsoft.com.

since1968: Your previous programs, HomeSite and TopStyle, have become industry-leading tools for writing, respectively, HTML and CSS. How do you compete with the large software houses?

Nick Bradbury: Being a small player means that I can get something to market much faster than a larger company, even if they already have plans for a similar tool. But primarily I serve markets that are initially too small for larger companies to target, yet which I believe will grow substantially. Or I simply look at markets that are being ignored by the larger companies for political reasons.

For example, when I created HomeSite, companies such as Microsoft were focusing on being the first to create WYSIWYG authoring tools, and they hoped to use them to persuade developers to support their platform over a competitor’s. The market for a code-based HTML editor was being ignored not because it was too small, but because it didn’t serve the needs of the larger players. Ironically, in the last couple of years we’ve seen tools such as FrontPage and Dreamweaver develop a much more code-centric approach.

When I developed TopStyle, no one was really serving the demand for help with creating style sheets. The use of CSS was certainly growing in leaps and bounds, yet even existing HTML editors weren’t offering CSS tools. After TopStyle took off, it became obvious that another need wasn’t being served: the need to create standards-compliant web sites. So, I took TopStyle to the next level and made it a full-blown HTML editor that focused on standards-compliance.

The market for an RSS reader is a little different in that it’s already quite sizeable and some larger companies are showing an interest (albeit a limited one). I initially conceived of FeedDemon a long time ago, but left it on the drawing board since I was nervous about supporting two popular applications. Now, of course, I wish I was sooner to market with FeedDemon, but I think I’m still getting in on the ground floor with RSS.

since1968: Every year we hear about the imminent death of packaged desktop software. Still, you appear to be gainfully employed. Will we be reading blogs in desktop apps three years from now?

NB: Rumors of the death of desktop applications are greatly exaggerated :) The line between the desktop and the web will continue to blur, but for the moment desktop apps simply provide more of what customers want.

There are some distinct advantages to web-based apps (the ease of synchronizing data between different computers being the biggest, IMO), but the web as a platform for UI-rich apps is still too limited to compete with the desktop.

since1968: Why not consume RSS with Flash or Java instead of with a desktop app?

NB: So far, neither Java nor Flash have proved themselves to be competitive on the desktop. Macromedia has been making some interesting moves with Flash lately, such as Central, but they’ve still got a long way to go to compete with native desktop development tools.

That’s not to say a Flash or Java RSS reader wouldn’t be good, though. More often than not, it’s the design rather than the development tool that kills a program. A well-designed Java RSS reader could certainly be competitive.

since1968: Why don’t you develop for Mac?

NB: Simply because the first company I worked for used PCs, so the PC is what I learned. Once I started developing shareware, supporting more than one platform didn’t make sense – it would take too much time for too little payoff.

I have to admit, though, that after looking at OS X, I now wish I had the time to develop for the Mac.

since1968: During the FeedDemon beta, I recall requesting arrows that expand or collapse the various grids with a single click – and then being blown away when you added them in the following revision. How do you decide which features get included in new versions of your software?

NB: With TopStyle, I’ve had a "feature vote" before each major version. Basically, I collect the most popular feature requests, then create a web form where customers can rank each one. The outcome determines which features go in.

Of course, in some cases a feature request is such a no-brainer that I’ll implement it as soon as it’s suggested. In other cases, I’ll add a feature that nobody has suggested simply because I believe it will be popular. And I have to confess that I’ve added a couple features just because I needed them (it’s good to be the king!).

since1968: You sold HomeSite to Macromedia several years ago, and it hasn’t changed much since. What sense of ownership do you still feel over it? Do you still use HomeSite?

NB: HomeSite is like an old girlfriend that you no longer keep in touch with. I haven’t been involved with HomeSite for several years, and I stopped using it after adding HTML editing to TopStyle.

since1968: Both you and Brent Simmons, creator of NetNewsWire, plan to require that Atom feeds are well-formed XML. In other words, FeedDemon will generate an error instead of attempting to parse malformed XML. I understand your reason for taking this position, but if a non-technical end user encounters an error message in FeedDemon or NetNewsWire, whom does he contact or blame: the aggregator? The content author?

NB: Just to provide some background, the issue is whether aggregators such as FeedDemon should accept Atom feeds that aren’t well-formed XML. Most aggregators – including FeedDemon – have already been forgiving of invalid RSS feeds in order to be backwards-compatible. The end result is that we’re faced with a similar problem that plagued HTML: different tools interpret coding errors differently, resulting in a bad feed looking right in one aggregator but like a ransom note in another. This forces everyone – not just developers, but also blog authors and their readers – to be aware of the problem. I address this situation more fully in my blog at:

http://nick.typepad.com/blog/2004/01/feeddemon_and_w_1.html

Atom is a new format, so there’s some hope that we can get it right this time, resulting in far fewer invalid feeds. The problem of how to handle invalid Atom feeds when we come across them is something I’m still thinking about. I obviously can’t just throw up a cryptic XML error, since that would be meaningless to all but a handful of end users. But if I accept a bad feed without any indication that there’s a problem, we risk getting back in the same boat we’ve been in with HTML and RSS. Stay tuned on this one.

since1968: I use MovableType for blogging. When I remember to do so, I provide a summary of each entry in the "Excerpt" field. This means that my <description> tag in the RSS feed says exactly what I want it to instead of lopping the blog entry after the first x characters. On the other hand, some bloggers like Anil Dash include the entire blog entry in the <description> tag, which has the advantage of showing the entry in the FeedDemon newspaper pane without sending the user to the browser to read the text of the blog entry. What’s best practice?

NB: The best practice is what serves your needs and your visitors’ needs. If you generate revenue from ads on your site, you obviously want to get people to visit your site so you don’t want to put everything in your feed. The trick is putting sufficient content in your feed to get people interested enough to click on to your site to read the rest of what you have to say. If you do this, it’s a good idea to use a link such as "[Read More]" at the end of your excerpt, so readers can continue reading with a single click.

since1968: You’ve posted about your problems with software piracy: there are more pirated copies of TopStyle in circulation than licensed copies. Were you surprised by the number of responses that told to, in essence, to get over it?

NB: No, I’ve been doing this long enough that it didn’t surprise me. There will always be a large number of people who will justify their copyright infringement and treat developers who wish to get paid for their work as though they’re whiny robber barrens.

It is ironic, though, that so many of those who have popularized the Internet seem so ill-prepared to deal with the concept of bits as property.

since1968: Thank you for your time.

NB: No problem, Marc. Thanks for the interesting questions!

* * *

Cockpit Commonality and RIAs · 333 words posted 12/19/2003 01:13 PM

An NPR commentator recently reported that Airbus sales have surpassed Boeing sales because, among other reasons, Airbus supports “cockpit commonality”: once you know how to fly one Airbus plane, you pretty much know how to fly them all. I’m not a pilot, so I have no idea if this is true, but it sounds reasonable.

Rich Internet Application development is in its infancy, but whether the concept achieves its potential depends on developers embracing “cockpit commonality.” Users should expect a consistent set of experiences from RIAs: once they’ve learned how to operate one, they should pretty much know how to operate them all. With some exceptions, this goal has largely become true of HTML interfaces: most users know that typing a few words in a text input box and then clicking the adjacent search button will generate a list of search results. This hasn’t always been the case, however.

Recall the early days of HTML application development; in 1998 I had a client request that each time a checkbox was checked, the user’s computer should play a snippet of Mozart. Even worse, I wasted precious development hours trying to accomodate the wish!

Think about it: if you’re frustrated when Macromedia changes an API call (and you should be), how can you expect users to feel any differently, especially when the time they have to learn a new interface is substiantially less than the time a developer has to learn a new API?

RIAs are in a fertile but precarious state: it’s easy to find clients who want to reinvent the wheel with each app; it’s hard to find a client who understands that their app is made useful by being more like all the other apps out there, not less. As more and more database and application developers like myself enter the RIA field—who know their way around stored procedures and query caching but for whom interaction design is a tertiary skill at best—it’s incumbent on them to remember the concept of cockpit commonality.

Comment

* * *