Slugline

Simple, elegant screenwriting.

Needables
  • Panasonic LUMIX DMC-GH4KBODY 16.05MP Digital Single Lens Mirrorless Camera with 4K Cinematic Video (Body Only)
    Panasonic LUMIX DMC-GH4KBODY 16.05MP Digital Single Lens Mirrorless Camera with 4K Cinematic Video (Body Only)
    Panasonic
  • TASCAM DR-100mkII 2-Channel Portable Digital Recorder
    TASCAM DR-100mkII 2-Channel Portable Digital Recorder
    TASCAM
  • The DV Rebel's Guide: An All-Digital Approach to Making Killer Action Movies on the Cheap (Peachpit)
    The DV Rebel's Guide: An All-Digital Approach to Making Killer Action Movies on the Cheap (Peachpit)
    by Stu Maschwitz
Thursday
Jun162011

Feature Requests

Response to my previous post has been wonderful. Ben Zotto, the creator of Penultimate, blogged about it yesterday, and Daring Fireball picked it up as well, highlighting the bit about generalizing my specific need (storyboarding templates) into a general suggestion (user-customizable papers that are easy to share). “Good way to think about feature requests” comprised Gruber’s customary dense morsel of commentary.

Which commentary inspired Ben to craft a must-read post on how a good developer listens to customer feedback, and how a user can best make their case for new features. Hint: It’s not about feature requests.

I’ll give you an example from Penultimate. Early versions of the app had the eraser function, but the eraser was a fixed circular size (about the size of a fingertip). I got lots of feedback asking for selectable eraser sizes (small, medium, large). That was the feature request: “add other eraser sizes.” But more eraser options, as such, was not what these users were really asking for, which was usually a way to do detailed erasing in small areas. Instead of complying with the letter of the request, I like to think I did one better, which was to make the eraser size dynamic. There’s still just one eraser, but if you’re working in a detailed area, it’s tiny. If you make huge swipes, it’s large.

That’s the difference between an elegant app that just works and a Homer Car of faithfully implemented features reflecting no singular vision. Read Ben’s entire post here, and think about it the next time you get inspired to make a “feature request.” I know I will.

Reader Comments (3)

That's good advice for any designer or engineer or IT geek or filmmaker brief: tell the designer what problem you want to solve, not what solution you want them to implement.

If you are going to tell them the solution, you might as well include: we've decided we want you to do something stupid and expensive.

June 16, 2011 | Registered Commenterbradbell.tv

Exactly — this advice is salient for any client/service interaction. Don't tell your editor to slip the shot six frames, tell her what feeling you think is missing. Don't tell your VFX company to make the monster brighter, tell them which story point you want to emphasize. The list goes on and on.

June 16, 2011 | Registered CommenterStu

"If I had asked people what they wanted, they would have asked for a better horse." --Henry Ford

This is also excellent advice for screen writers dealing with script notes from executives.

June 17, 2011 | Registered CommenterCasey Stone
Member Account Required
You must have a free and harmless member account in order to post comments. Log in to your account to enable posting. I don't use your information for anything, I just want you to be who you are.
« Final Cut Pro X Is Here | Main | What I Do With My iPad Part 1: Storyboarding »