Skip to main content

What features don't you need in your application?

10 days ago, Scoble asked What will Steve Jobs kill next?



Perhaps more importantly, he asked "How about you, which feature are you getting rid of to make your product/service/store/business simpler?"



I think application developers have a real tendency to thrown in "everything but the kitchen sink". It's not because we want to - but more because after years of experience, we want to be ready "just in case" someone asks for a feature.



Yet the end result is overloaded apps with not just too much functionality, but also a need for complicated user manuals and training.



But after users have used the application for years, it's really hard to take away a function or feature because there may still be a group of users who want to use it.



I've been going through this recently and have found myself turning off or hiding features in one of my applications. But I still can't take myself to take away the feature - instead, I've just hidden it (using GENMENUX to ensure it doesn't even appear on the menu). I've added a flag in my application to show the hidden functionality (in case, there's an uproar) - but my goal is to encourage users to use other features that offers similar functionality. (I even have a dialog when they try to use an older function that says "why not use this one instead?")



(why would you have two features that offer similar functionality? Blame it on application bloat - consider FoxPro's LTRIM and TRIM functions.)



I tried doing this with a Search screen recently and the results were interesting. I was inspired by Yag's post on new ways of developing. So I built a screen with a single box and a dropdown and told the customers that they could search for anything they wanted, simply by putting it in the search box.



Their response? "I want to see separate boxes for all of my search options."



Argh! It's tough to be a developer offering new features in an older application when you've got users who are used to older approaches.



Maybe I should just create a new application entirely - but then you have to retrain everyone.



What do you do when you want to introduce new approaches in your applications?  (or maybe more importantly, how do you fix bad habits?)





Powered by ScribeFire.

Comments

davidfung said…
Great to read your post. I employ a similar approach when moving end users from one way of doing a task to another. In this case, it is moving users from using a character-based app to perform a task to is windows-based app equivalent.

In the first stage, I just put up a nagged screen asking the users to use the new app for that task and warn them that the old app is soon going to expire, but still allow them to use the old app. This is to manage their expectation. And at the same time, assuming only a small number of users actually use the new app initially, take advantage of that as a small pilot to make sure the new app is bugfree.

In the next stage, I disable the feature in the old app altogether and changed the nagged screen into a "Stop" dialog, telling the users that they have to use the new app to carry out that task.

I also liberately log the usage, so that I know how many users are converting and how many are not, and if appropriate, I can choose to talk to those not willing to convert to find out why. Perhaps they have a valid reason that I haven't thought of.

Also like you, whenever I change the behavior of an existing "mission-critical" feature, I will add an ini flag to turn that change on and off, just in case of uproar as you said, or a showstopping bug showing itself.

Popular posts from this blog

Merry Christmas

Whether you celebrate now, have already celebrated your past holiday, are planning to, or not, I hope you find yourself surrounded by family and those you love during this holiday season and are able to remember fondly those who are not with you. We often find ourselves buried in work, or too distracted by other problems, to share and remember a few moments with those closest to us. So many of us are separated by huge distances, we often find it easier to focus on those who are out of arm's reach yet so easy to connect with online, instead of those who are right beside us. So do yourself a favour, put down the keyboard (stylus, mouse, etc) and spend that time. I know I will. Merry Christmas. Powered by ScribeFire .

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...

From Writing to AI: the pattern repeats itself

When I was ten years old, my dad bought a computer and, thanks to an advertising supplement in a Superman comic I read, it was a TRS-80. A month later, he dragged the entire family (my mom and brother were not the most enthusiastic) to a class at Radio Shack teaching how to use microcomputers. At the time, I understood why my mom wasn’t that excited: the computer was yet another gadget in the house. But today I find it fascinating. My mother went to Vassar in the 50s. She learned how to type — not a common skill at the time — but it opened doors. Her ability to communicate effectively led her to a career in adult education and later communications work with the CBC (Canadian Broadcasting Corporation). This isn’t a nostalgia post. Today, the ability to use artificial intelligence, be it through Copilot or simply writing the right prompt, is becoming a critical skill. But is it really that novel? In the 1500s and 1600s, the printing press gradually made reading accessible beyond cler...