Feature Creep
One of the issues I tend to clash with a lot of programmers on is the issue of tossing in options/toggles/etc on programs I work on, be they scripts, MUF, engines, servers, etc. When I maintained code on MUCKs in the past, and someone came to me with a problem they had with how a program worked for them, or how it didn't work like they were used to on another game, or just had a random feature request, I would usually add another option to give them exactly what they wanted as long as it wouldn't take too much adjusting.
I love being asked if I can add a way for someone to do something with an engine/program/script and being able to answer that the ability is already in place. And when I ask other programmers if they could add something that would make my life easier, it's great when they can answer that the option exists. Now ideally, the exchange of questioning and answering shouldn't even need to take place, but that's more an issue of documentation and the fact that either the docs about the options don't exist, or they're not where the user expects. That's a whole other matter though and I can discuss documentation another time.
But I find that isn't often the answer I see coming from other programmers that have to deal with various users with different expectations, habits, and wants. Often the requests for alternative forms of command syntax or GUI interfaces are met with 'I don't want to add a bunch of options', or 'No, I want to keep it simple, so there won't be any options or toggles.' or as I saw more recently expressed, 'We want to keep the number of knobs on this place to a minimum.'
I can imagine why that's sometimes the answer. Adding options to programs increases their complexity, from a user's stand point as well as a programmer's position as having to maintain the code. Having way too many options can confuse users not familiar with the system you're supporting. Having a lot of options can make it so that every time a change has to be made to the code, you have to test for dozens of variable configurations, which can make QAing your own code more and more difficult.
Still, at least for me, those have been acceptable trade offs for giving users the power to customize as much as is reasonably possible with the programs I write. I think part of it comes down to picking what you put in as options or features in a program and how you got about it.
High priority options for me are ones that let someone customize how they get information from a program, how the program's interface looks, or how they use the program themselves. The nice thing about these kinds of features is that they don't affect anyone besides the user that wants to be able to set them. This means that even if you think the user's request is the worst way possible of using the program, as long as the feature doesn't impact anyone else, why not give the user the power to change it to what they want?
Take for example the big page program debate over at MotM last week. I heard excuse after excuse of why the 'p =' syntax for paging a message to the same people you just paged wasn't supported. They basically boiled down to 'It's adding too many features to a program that's deliberately kept simple' or 'It increases the chance of paging someone you didn't intend to.' The first excuse is irrelevant. Why should a program be kept deliberately simple if it means that the program is also less convenient? I can get on board with the idea of having simple interfaces, but not when maintaining the simplicity requires stripping out convenience. Especially if the convenience people are expecting is what has already been a standard for over a decade.
The second excuse, about being too easy to page the wrong people, actually IS an excuse I would agree with. That creates a situation where an option would make a lot of sense.
One of the most important questions to consider when putting in an option is figuring out what the default behavior should be. If the user doesn't specify, how should the program act? My strong preference here is that the program should act like how it did before the option went in, whenever possible. Options should be something that users opt in on if they want to. There are exceptions here though.
Kobun at MotM rewrote page this weekend and all the complaints from last week have been completely dealt with. The page = syntax was added, and defaulted ON, with the option to opt OUT of it if you don't want to accept the risks associated with the shortcut. I haven't decided if I would have defaulted it on or off, as I can see an argument made either way. Defaulting off would make the new option there for people who wanted it, while leaving those who disliked the option not having to worry about dealing with the change. Defaulting it to on would make the MotM page program behave like just about every other page program I've ever used, and would cut down on the infinite number of times it would be brought up by some future users as a complaint about how page doesn't support the page = syntax. My gut feeling is that defaulting that change to ON was the right choice. All the same, I'm just glad to not be stuck with last week's version of Page any more, so thanks to Kobun for that one. :)
One of my personal favorite options in Proto is the custom color support. For all the grief we like to give Moose, this really was one of his most powerful contributions to Proto, for me anyway. Making it easy to toss in color tags that could be adjusted to be whatever color a user wanted was huge. I don't think it actually got taken advantage of much, outside of things I wrote. But it was nice, because it made it possible for me to support color in programs, because *I* wanted color, but not force my color schemes on everyone.
A lot of times I find programmers resort to a 'Well, the interface, color, syntax, etc, is the way it is because that's how I want it, and that's all that matters.' response when asked why they aren't open to adding options to let users set their own preferences. This is probably the attitude that sets me off the most, because the programmer is also the one with the power to offer people the flexibility to change it to whatever they want. The 'My way is better because it's my way.' reduces the discussion to a opinion war with no one really being right and no one really being wrong. With the right options, toggles, features, and flexibility, everyone gets to be right at the same time.
Above, I mentioned that one of the big questions about adding an option is determining the default behavior. Another big question is 'Will this option affect other people, and if so, have I made it possible to opt out?' Custom page formats drove me up the wall for a long time after I got into MUCKing.
'From the deepest depths of the murkiest, darkest cave comes the whispers of the long dead souls trapped beneath the nether. Their essences congeal and produce a shimmering mirror of black crystal. In the mirror you see: Takrin waves.'
Thanks, but no thanks. It made my day when I found out I could opt out of seeing other people's custom page formats by telling page that I wanted to stick to a standard format, AND that I was able to specify the standard format that I wanted it to follow, since it allowed me to add a timestamp to the format as an added bonus. The custom page formats used for sending pages, like the example above, is an example of an option that impacts /other/ users. It's important to provide ANOTHER option to let someone opt out of having to put up with that kind of crap if they don't want to. That way, Takrin gets a kick out of thinking his pages are being sent wrapped in the most creative custom format I will ever bear witness to, while I get the peace of mind of not having to see any of it. ;)
Similarly, one of my biggest problems of each new iteration of Microsoft Word is that all of the new stuff is ON by default, and I have to go out of my way to turn it all off. I've been using Word since it was small enough to fit on a floppy. And each time a new version of Word comes out, I feel like a novice all over again, because I can't figure out where anything is, or why the program is acting the way it does when I perform certain actions. I really wish they would release each version with stuff turned off, and provide a wizard for enabling the new junk. That way you could get a quick tutorial on what is new, and be given a choice as to whether or not you wanted to have the new feature available.
I think WoW hit on a really good approach, and they're often mentioned within the game industry as being a great example of how to handle interfaces for multiplayer games. They have a pretty simple, intuitive base interface. But they provide the power for people who WANT to to go in and change that interface around in every way imaginable. Having someone customize their interface doesn't hurt anyone else, and it lets the individual play the game with the interface that they want. I won't belabor the point further, but that in short is what I think a lot of programs should try to emulate. Simple to use 'out of the box', but powerful enough to let people adjust them to their own preferences.
Anyway, those are just some of my thoughts. To date, after years of maintaining code on MU*'s, within the server core itself, and on other projects, I've actually never received a SINGLE complaint about something being too flexible or having too many options from someone who wasn't a programmer. The only grief I've gotten, be it actual annoyance, or just teasing about having too many options, has been from other coders. Just something to think on.
-Akari
I love being asked if I can add a way for someone to do something with an engine/program/script and being able to answer that the ability is already in place. And when I ask other programmers if they could add something that would make my life easier, it's great when they can answer that the option exists. Now ideally, the exchange of questioning and answering shouldn't even need to take place, but that's more an issue of documentation and the fact that either the docs about the options don't exist, or they're not where the user expects. That's a whole other matter though and I can discuss documentation another time.
But I find that isn't often the answer I see coming from other programmers that have to deal with various users with different expectations, habits, and wants. Often the requests for alternative forms of command syntax or GUI interfaces are met with 'I don't want to add a bunch of options', or 'No, I want to keep it simple, so there won't be any options or toggles.' or as I saw more recently expressed, 'We want to keep the number of knobs on this place to a minimum.'
I can imagine why that's sometimes the answer. Adding options to programs increases their complexity, from a user's stand point as well as a programmer's position as having to maintain the code. Having way too many options can confuse users not familiar with the system you're supporting. Having a lot of options can make it so that every time a change has to be made to the code, you have to test for dozens of variable configurations, which can make QAing your own code more and more difficult.
Still, at least for me, those have been acceptable trade offs for giving users the power to customize as much as is reasonably possible with the programs I write. I think part of it comes down to picking what you put in as options or features in a program and how you got about it.
High priority options for me are ones that let someone customize how they get information from a program, how the program's interface looks, or how they use the program themselves. The nice thing about these kinds of features is that they don't affect anyone besides the user that wants to be able to set them. This means that even if you think the user's request is the worst way possible of using the program, as long as the feature doesn't impact anyone else, why not give the user the power to change it to what they want?
Take for example the big page program debate over at MotM last week. I heard excuse after excuse of why the 'p =' syntax for paging a message to the same people you just paged wasn't supported. They basically boiled down to 'It's adding too many features to a program that's deliberately kept simple' or 'It increases the chance of paging someone you didn't intend to.' The first excuse is irrelevant. Why should a program be kept deliberately simple if it means that the program is also less convenient? I can get on board with the idea of having simple interfaces, but not when maintaining the simplicity requires stripping out convenience. Especially if the convenience people are expecting is what has already been a standard for over a decade.
The second excuse, about being too easy to page the wrong people, actually IS an excuse I would agree with. That creates a situation where an option would make a lot of sense.
One of the most important questions to consider when putting in an option is figuring out what the default behavior should be. If the user doesn't specify, how should the program act? My strong preference here is that the program should act like how it did before the option went in, whenever possible. Options should be something that users opt in on if they want to. There are exceptions here though.
Kobun at MotM rewrote page this weekend and all the complaints from last week have been completely dealt with. The page = syntax was added, and defaulted ON, with the option to opt OUT of it if you don't want to accept the risks associated with the shortcut. I haven't decided if I would have defaulted it on or off, as I can see an argument made either way. Defaulting off would make the new option there for people who wanted it, while leaving those who disliked the option not having to worry about dealing with the change. Defaulting it to on would make the MotM page program behave like just about every other page program I've ever used, and would cut down on the infinite number of times it would be brought up by some future users as a complaint about how page doesn't support the page = syntax. My gut feeling is that defaulting that change to ON was the right choice. All the same, I'm just glad to not be stuck with last week's version of Page any more, so thanks to Kobun for that one. :)
One of my personal favorite options in Proto is the custom color support. For all the grief we like to give Moose, this really was one of his most powerful contributions to Proto, for me anyway. Making it easy to toss in color tags that could be adjusted to be whatever color a user wanted was huge. I don't think it actually got taken advantage of much, outside of things I wrote. But it was nice, because it made it possible for me to support color in programs, because *I* wanted color, but not force my color schemes on everyone.
A lot of times I find programmers resort to a 'Well, the interface, color, syntax, etc, is the way it is because that's how I want it, and that's all that matters.' response when asked why they aren't open to adding options to let users set their own preferences. This is probably the attitude that sets me off the most, because the programmer is also the one with the power to offer people the flexibility to change it to whatever they want. The 'My way is better because it's my way.' reduces the discussion to a opinion war with no one really being right and no one really being wrong. With the right options, toggles, features, and flexibility, everyone gets to be right at the same time.
Above, I mentioned that one of the big questions about adding an option is determining the default behavior. Another big question is 'Will this option affect other people, and if so, have I made it possible to opt out?' Custom page formats drove me up the wall for a long time after I got into MUCKing.
'From the deepest depths of the murkiest, darkest cave comes the whispers of the long dead souls trapped beneath the nether. Their essences congeal and produce a shimmering mirror of black crystal. In the mirror you see: Takrin waves.'
Thanks, but no thanks. It made my day when I found out I could opt out of seeing other people's custom page formats by telling page that I wanted to stick to a standard format, AND that I was able to specify the standard format that I wanted it to follow, since it allowed me to add a timestamp to the format as an added bonus. The custom page formats used for sending pages, like the example above, is an example of an option that impacts /other/ users. It's important to provide ANOTHER option to let someone opt out of having to put up with that kind of crap if they don't want to. That way, Takrin gets a kick out of thinking his pages are being sent wrapped in the most creative custom format I will ever bear witness to, while I get the peace of mind of not having to see any of it. ;)
Similarly, one of my biggest problems of each new iteration of Microsoft Word is that all of the new stuff is ON by default, and I have to go out of my way to turn it all off. I've been using Word since it was small enough to fit on a floppy. And each time a new version of Word comes out, I feel like a novice all over again, because I can't figure out where anything is, or why the program is acting the way it does when I perform certain actions. I really wish they would release each version with stuff turned off, and provide a wizard for enabling the new junk. That way you could get a quick tutorial on what is new, and be given a choice as to whether or not you wanted to have the new feature available.
I think WoW hit on a really good approach, and they're often mentioned within the game industry as being a great example of how to handle interfaces for multiplayer games. They have a pretty simple, intuitive base interface. But they provide the power for people who WANT to to go in and change that interface around in every way imaginable. Having someone customize their interface doesn't hurt anyone else, and it lets the individual play the game with the interface that they want. I won't belabor the point further, but that in short is what I think a lot of programs should try to emulate. Simple to use 'out of the box', but powerful enough to let people adjust them to their own preferences.
Anyway, those are just some of my thoughts. To date, after years of maintaining code on MU*'s, within the server core itself, and on other projects, I've actually never received a SINGLE complaint about something being too flexible or having too many options from someone who wasn't a programmer. The only grief I've gotten, be it actual annoyance, or just teasing about having too many options, has been from other coders. Just something to think on.
-Akari