Apr
06Development Discussion - Feature Theory
Tagged Under : Feature Development, Software
There has been an interesting discussion floating around work recently that I thought would be very interesting to share here. I am excited to hear feedback and discussion on this topic as it is not only fascinating, but very relevant to my work.
Scenario: You have built a fantastic application to build widgets. Your application is a great v1 at building widgets and you have much room for improvement, but the foundation of widget building is solid.
Feature Ask 1: Customer A has been using Widget Builder Plus for a few months and has found that it’s very easy to build thingies with it. If you use a few parameters for different purposes, it builds very slick thingies. Can we put in a thingie generator to keep from having to use widgets to build thingies?
Feature Ask 2: Customer B has been using Widget Builder Plus to build Thingamabobs. By hacking the XML files generated by Widget Builder Plus, you can generate a basic thingamabob that only needs modest modification to be a full fledged thingamajiggy.
Of course this is totally laced in humor and mildly facetious, but you get my point. In the world of software development, it’s very important to be scenario minded so you are sure that your building features for your users, not a Swiss army knife that can do anything but is difficult to navigate.
So the question I pose is this. If you develop an application, and find a large portion of your users are using the application for a different purpose entirely, do you:
A) Add more features from the alternative usage to the application to satisfy the users that are using your program incorrectly?
B) Retrain your users to use your application more effectively for it’s intended purpose.
It’s really a difficult problem, you surely do not want to lose users of your application by removing the abilities that they are finding so useful, but at the same time, if you are looking at the evolution of your product 2, 3 or more versions down the line and comparing it to your product’s vision, do you risk feature bloat and confusion to keep functionality you never intended to provide?
Thoughts?
It’s the nature of the beast It’s cool that I can not only embed an image in Application A, but I can also crop it from the same spot. Now if I knew a way to hack some xml file so that I could also change its white balance, make selections, toss it, turn it, and apply filters, I’d never have to leave Application A! As much as the idea appeals to me, its certainly not possible to have one application that does everything, but I can\’t blame users for trying. Power users will always try to do things easier, faster, and most importantly their own way with any given application. Even the most pointed and directed training will not stop up us from thinking “Hey this is cool, I can use this application for this other totally unrelated task!”
I guess theres no use in trying to keep our tinkering in the boundaries of your project. Instead, it’s up to you to decide if your app has hard or soft boundaries to begin with, and then where those boundaries are in the scope of the software.
Good Luck!
I agree with Dawn that power users will always find a way to do something quicker, better, more than designed, etc.
Answering your questions, I think my solution would be to trim down the features of the program to what 80% of the users need. Make those as intuitive and easy as possible then have extra addons/plugins that the users that want it can install that will make it so the program can build the thingies. Of course this can cause a couple additional issues:
1) Support, having to support different configurations of the software could make the scripted responses no longer valid.
2) Who is allowed to develop the extensions?
There are good arguments for both. If the application isn’t free, (I am guessing by this post that it is….) then allowing 3rd party plugins will increase sales of the product. This potentially cannibalizes sales from different products, but gives power users more control. If the application is free, and your company also offers a non-free program that can build thingies, then it is undesirable to have the competition.
As a developer I prefer the open option. I am rarely asked to develop something that fits into a cookie cutter template and like to have as many options as possible in whatever tools I am given.
I would really love to throw out some product names to discuss this in less abstract terms but this article was intentionally vague so I will respect that. Hopefully my response didn’t give too much of what I think they are away.