Features come with price
Adding features is not a good idea all the time...
In the past few weeks we were having a discussion about what you'd like to see in activeCollab – from small things like minor interface improvements and tweaks to major features such is time tracking or invoicing. What most users don't think about (and don't need to thing about) is the price of every added feature.
In Apple Human Interface Guideline there is a section that covers adding features to software products. Here is the most interesting part of that section:
When making design decisions regarding features in your application, it’s important to weigh the costs, not all of which are financial, against the potential benefits. Every time you add a feature to your application, the following things can happen:Choosing appropriate features and devoting the needed resources to implement them correctly can save you time and effort later. Choosing poor feature sets or failing to assign appropriate design, engineering, testing, and documentation resources often incurs heavier costs later when critical bugs appear or users can’t figure out how to use your product.
- Your application gets larger.
- Your application gets slower.
- Your application’s human interface becomes more complex.
- You spend time developing new features rather than refining existing features.
- Your application’s documentation and help become more extensive.
- You run the risk of introducing changes that could adversely affect existing features.
- You increase the time required to validate the behavior of your application.
I couldn't agree more. Every new or existing feature that does not benefit 80% of users should be thrown out.
Some will tell that good plugin architecture is an answer to this problem, but that solution is not a silver bullet. It creates support nightmare, quality and consistency across application can not be controlled any more and so on. Even plugin support should be approached the same way as any other features - does it provide benefits that justify introduced complexity. If not - skip that and concentrate on things that do matter.
Posted on: 2007-02-03 9:12
Comments:
Good stuff. I’d rather you concentrated on getting the basics perfect than trying to implement everything that’s been asked for. Perhaps after a stable version 1.0 has been released, you could look at some of the other requests as official – and optional – add-on modules.
This is an interesting evolution of your two previous posts. Seeing the features list grow out of hand, it is clear that some choices are needed.
Here are my two cents on the subject :
Ilija, I don’t know if you could set up a survey on this website, but to let each user select a few (say 4-5) features in the list and give a priority to each one would allow you to see really fast what are the features most requested – especially if you display the overall results only after the survey period, so that people will really vote for features they are interested in, not just for features everyone seems to be voting for.
If there’s a clear majority of requests for just a few features, then it could probably lead to their integration in the “core” app.
But if the feature requests don’t show a overwhelming majority, and you can’t really pick a group of common requests, then I believe that implementing a good and solid plugin system would be the best way to go. I agree that it can be challenging to do it right, but it would then allow features to be added by 3rd party and that would allow answering to most requests.
Here are my two cents on the subject :
Ilija, I don’t know if you could set up a survey on this website, but to let each user select a few (say 4-5) features in the list and give a priority to each one would allow you to see really fast what are the features most requested – especially if you display the overall results only after the survey period, so that people will really vote for features they are interested in, not just for features everyone seems to be voting for.
If there’s a clear majority of requests for just a few features, then it could probably lead to their integration in the “core” app.
But if the feature requests don’t show a overwhelming majority, and you can’t really pick a group of common requests, then I believe that implementing a good and solid plugin system would be the best way to go. I agree that it can be challenging to do it right, but it would then allow features to be added by 3rd party and that would allow answering to most requests.
Elija: Can I suggest something almost the exact opposite of jtreglos… do not vote. Focus and clarified software are not going to come from a democratic vote. Why don’t you setup several model use scenarios and align upcoming features with those, so that you are working toward an experience (or set of experiences). Joomla has done this and it does a great job of defining what types of uses Joomla will be targeted towards in the near future.
There is no need for voting. In past few weeks there was more than enough feedback from community to see what needs to be done. Also, a small set of use cases will point out most of the problem in current (and future) design.
I’d definitely go with the use scenarios and not only keep in mind what you’re aiming for but also what you’re trying to avoid.
The problems I’ve had with other tools was getting people to use them and use them correctly. The reason I finally opted for AC was the simplicity of use, if I needed something along the lines of MSProject or PHProjekt I wouldn’t have come here in the first place.
What makes AC so attractive ? Don’t lose that.
Oh… and keep up the great work. :-)
Chris
Paris – France
The problems I’ve had with other tools was getting people to use them and use them correctly. The reason I finally opted for AC was the simplicity of use, if I needed something along the lines of MSProject or PHProjekt I wouldn’t have come here in the first place.
What makes AC so attractive ? Don’t lose that.
Oh… and keep up the great work. :-)
Chris
Paris – France
To Colin : I’m not talking about democracy, I’m talking about collecting user feedback… Joomla was able to set up realistic use cases because they had enough input from their user base.
Use case are a good tool, at least if they are done right. From my dev experience, I know that most use cases made up by the dev team or the marketing crowd are not representative of what the majority of users are needing. Use cases must come from user feedback. I’ve seen too many projects being bloated by features that no one ever used, because the use cases where build without asking real users. And as Ilija pointed out in his previous post, adding unnecessary features costs time, energy and complexity to the project.
But if you have enough user input from all the comments you collected in the last few weeks, then I totally agree, there’s no need for voting.
Use case are a good tool, at least if they are done right. From my dev experience, I know that most use cases made up by the dev team or the marketing crowd are not representative of what the majority of users are needing. Use cases must come from user feedback. I’ve seen too many projects being bloated by features that no one ever used, because the use cases where build without asking real users. And as Ilija pointed out in his previous post, adding unnecessary features costs time, energy and complexity to the project.
But if you have enough user input from all the comments you collected in the last few weeks, then I totally agree, there’s no need for voting.
I agree with toferyu. I use aC for its simplicity and ease of use. I dont think aC should be bloated with features that people arent going to use, instead, just make them plugins. It seems like to me, the most important things are improving current features, and adding plugin support, in that order.
so you propose making a new blog post “one simple question: what do you typically use aC for ??”
I totally agree with seventoes. Improving current features and adding plugin support.
Two things need to be defined, 1) What is AC? 2) If it is this, what basic features should it have.
E.g if it is a project management application of some kind then there are some very basic features that are critical. There are also things it could do but doesn’t necessarily have to do in order to function.
So for example you have to be able to assign a milestone to someone, but you don’t have to have a plugin that allows for AC to work with an SMS server and notify that engineer by SMS..
Once you defined what are the basics needed for AC to work, you can divide the rest in to risk vs reward etc.
E.g if it is a project management application of some kind then there are some very basic features that are critical. There are also things it could do but doesn’t necessarily have to do in order to function.
So for example you have to be able to assign a milestone to someone, but you don’t have to have a plugin that allows for AC to work with an SMS server and notify that engineer by SMS..
Once you defined what are the basics needed for AC to work, you can divide the rest in to risk vs reward etc.
All I care about is a calendar added to it. AC is awesome.
This makes sense. I’d like to echo what adamld has said, and see a clear, specific definition of what ActiveCollab is supposed to be or become. As it exists now, it does not solve my needs entirely as a “collaborative project management system” as I am using a combination of different things to accomplish that due to a lack of some functions that I would consider essential. I may, however, not be within the majority in what I consider “essential”. I’d be in favor of a survey of some kind on this subject, just to find out if this is going to go in a direction that will prove useful to me.
I love AC and do not want to see tons of features polluting the core sufficiency and simplicity of the application. It works really well, as it is, for most of my (and my clients) project management needs
I said this in another comment, but I think it is worth reiterating: a plugin structure is critical. Wordpress is a nice example of a project that does well this way. The plugin architecture, whatever the quality (and it was really stinky at first), has allowed Wordpress to be a very pure blogging tool at its core, but have enough additional features that I can deploy it in a wide variety of different scenarios where a blogging tool or very basic CMS is needed. And the developers have shown some wisdom in which user contributions to push back into the core. There is some griping in the WP community about the slow pace of change, but as a developer on several platforms (WP, Django, Drupal, and a custom data-analysis-and-stats platform) I think it’s pretty nice to not wake up one day and see that a new point version came out, and life’s going to be “interesting” until I can line up my customizations with API changes and the like.
I understand that the UI issues and data structures in a project management tool are richer and more complicated than a simple CRUD-esque CMS, and so building a plugin architecture is also more complex. But it would be worth it—you get to see what ideas people have, how popular they are, and slowly push them into the core application.
I said this in another comment, but I think it is worth reiterating: a plugin structure is critical. Wordpress is a nice example of a project that does well this way. The plugin architecture, whatever the quality (and it was really stinky at first), has allowed Wordpress to be a very pure blogging tool at its core, but have enough additional features that I can deploy it in a wide variety of different scenarios where a blogging tool or very basic CMS is needed. And the developers have shown some wisdom in which user contributions to push back into the core. There is some griping in the WP community about the slow pace of change, but as a developer on several platforms (WP, Django, Drupal, and a custom data-analysis-and-stats platform) I think it’s pretty nice to not wake up one day and see that a new point version came out, and life’s going to be “interesting” until I can line up my customizations with API changes and the like.
I understand that the UI issues and data structures in a project management tool are richer and more complicated than a simple CRUD-esque CMS, and so building a plugin architecture is also more complex. But it would be worth it—you get to see what ideas people have, how popular they are, and slowly push them into the core application.
Right on! To many features in the core app release will … over time … doom it to failure. The key, IMHO, is to build a simple, rock solid, core feature set that uses can extend for their own purposes. I agree that all core features should be applicable to 80+ percent of all users.
Although a plugin sysem complicates the core abit… it allows the community to easily write extensions to the core and share them with other users. Issues like time tracking, Gantts etc are things that I feel should be contributed by us; the community. THe core dev team should work to harden current features, extend core apis for the community to leverage, and evaluate community contributions for inclusion into the core (and clean them up if needed). This really opens 2 doors and possibilities for action….
1. The core dev team is more concerned with the architeture of the project and the CORE feature set (I would place BASIC Calendering here and inclusion of Jquery here). Stability and managed growth are the keys here.
2. The community contributes. New features are released, shared, and co maintained by the users that need them without clogging up the core install with stuff that a small percentage of users actually need. I would assess that this is the true spirit of open source. (time tracking, Gantts, Drag and drop reordering (for tasks), Chat module would be handeled and created here by us)
Side note… Inclusion of JQuery … or some other stable JS library is something I will continue to push, and possiblely dedicate some time to. As this project grows and we begin working on the UI, as a community, we need a clear narrative and standard before uses begin submitting work with different library … which in my mind wastes effecientcly in the final product (loading too many libraries) and in some cases time in debugging JS conflicts etc.
I look forward to hearing all of your thoughts.
Although a plugin sysem complicates the core abit… it allows the community to easily write extensions to the core and share them with other users. Issues like time tracking, Gantts etc are things that I feel should be contributed by us; the community. THe core dev team should work to harden current features, extend core apis for the community to leverage, and evaluate community contributions for inclusion into the core (and clean them up if needed). This really opens 2 doors and possibilities for action….
1. The core dev team is more concerned with the architeture of the project and the CORE feature set (I would place BASIC Calendering here and inclusion of Jquery here). Stability and managed growth are the keys here.
2. The community contributes. New features are released, shared, and co maintained by the users that need them without clogging up the core install with stuff that a small percentage of users actually need. I would assess that this is the true spirit of open source. (time tracking, Gantts, Drag and drop reordering (for tasks), Chat module would be handeled and created here by us)
Side note… Inclusion of JQuery … or some other stable JS library is something I will continue to push, and possiblely dedicate some time to. As this project grows and we begin working on the UI, as a community, we need a clear narrative and standard before uses begin submitting work with different library … which in my mind wastes effecientcly in the final product (loading too many libraries) and in some cases time in debugging JS conflicts etc.
I look forward to hearing all of your thoughts.
I agree completely. Usability is the most important feature.
Great apps have it and it is obvious.
Apps that succumb to feature bloat are far less attractive to most
for all of the reasons stated here.
Great apps have it and it is obvious.
Apps that succumb to feature bloat are far less attractive to most
for all of the reasons stated here.
Plug-ins are great in theory but usually horrible in practice.
In my experience, using several web-systems, plug-ins do not complement the consistency of quality that exists in the core system. They’re often times a pain to install, investigate whether they will work, back-up your core system before you try, set up a dev version to test rather than interfere with your work-flow, etc. Then, they are usually not compatible with core updates. So, you then have to update your plug-ins every time the core is updated or just risk using a possibly less secure old version of the core. Additionally, one-click updates offered by web hosts are complicated by a bunch of plug-ins. Plug-ins have their place for obscure, unusual features. But, they shouldn’t be relied on for features that follow the logical use of the software (in this case timetracking, writeboard, etc).
Perhaps the problem here is taking 37signals theories a little too far. Maybe do as they do, not as they say.
It is possible to listen to the users too much. Perhaps the problem here is that too much of a production is being made of discussing every feature that gets thrown out there. From what I’ve read, the project has already had a sensible road-map of features to add. I don’t see why everything should be shortened just because an overwhelming amount of new input shows up. I say stick to the plan and stop taking requests until the next solid version is ready.
If Basecamp is still a model to be considered, they offer a time-tracker and write-board for a reason.
In my experience, using several web-systems, plug-ins do not complement the consistency of quality that exists in the core system. They’re often times a pain to install, investigate whether they will work, back-up your core system before you try, set up a dev version to test rather than interfere with your work-flow, etc. Then, they are usually not compatible with core updates. So, you then have to update your plug-ins every time the core is updated or just risk using a possibly less secure old version of the core. Additionally, one-click updates offered by web hosts are complicated by a bunch of plug-ins. Plug-ins have their place for obscure, unusual features. But, they shouldn’t be relied on for features that follow the logical use of the software (in this case timetracking, writeboard, etc).
Perhaps the problem here is taking 37signals theories a little too far. Maybe do as they do, not as they say.
It is possible to listen to the users too much. Perhaps the problem here is that too much of a production is being made of discussing every feature that gets thrown out there. From what I’ve read, the project has already had a sensible road-map of features to add. I don’t see why everything should be shortened just because an overwhelming amount of new input shows up. I say stick to the plan and stop taking requests until the next solid version is ready.
If Basecamp is still a model to be considered, they offer a time-tracker and write-board for a reason.
who cares about 37signals theory? don’t YOU know, what kind of software you want ?
i do know what kind of software i want. but, its impractical to think of a project in purely selfish terms. i cant expect them to tailor aC just for my needs.
the point about 37signals is that they suggest getting a version out there quickly and listening to user response to tailor future development. my point is that that concept has been taken too far here. “too many chiefs and not enough indians” is another much older and time-tested theory. at some point, you have close the flood-gates of suggestion and just develop. let the product grow horns if they sometimes need to be trimmed later.
ultimately, listening and theorizing have a cost just like features do. imo, the former is more expensive in this case.
the point about 37signals is that they suggest getting a version out there quickly and listening to user response to tailor future development. my point is that that concept has been taken too far here. “too many chiefs and not enough indians” is another much older and time-tested theory. at some point, you have close the flood-gates of suggestion and just develop. let the product grow horns if they sometimes need to be trimmed later.
ultimately, listening and theorizing have a cost just like features do. imo, the former is more expensive in this case.
I also agree. As often, the answer should be compromise. The right spot is between “listening and discussing too much and doing nothing” and “doing it all without discussing or listening”... Now finding that sweet spot could also be source of endless disccussion ;)
For me a plugin system is a good step, it will bring in many more programmers to make light work of some of the more niche functions people want.
There are clever people out there just gagging to add features and help improve AC, its almost rude not to let them :P. If your worried about quality, you still keep control of the core and let people who use plugins worry about instabilities it may introduce.
If they end up getting used by 80% + then you can put them into the core (and re-write them if needed).
I agree with CorpX on JQuery and flashlackey on basecamp’s time-tracker and write-board implementation.
The time tracker is the killer app for me.
There are clever people out there just gagging to add features and help improve AC, its almost rude not to let them :P. If your worried about quality, you still keep control of the core and let people who use plugins worry about instabilities it may introduce.
If they end up getting used by 80% + then you can put them into the core (and re-write them if needed).
I agree with CorpX on JQuery and flashlackey on basecamp’s time-tracker and write-board implementation.
The time tracker is the killer app for me.
I would like to see where active collab goes in its next release. Ilija has made references to a templating system, and plugin system and I would like to know what decisions he makes before I dig into app. Regardless… I am here to stay and contribute! ... But how I spend my time will depend on where Ilija decides to go. i.e. I don’t want to do a great deal of work on the UI if there’s a templating system in the work and presentation logic is being pull out of the core. Will wait until that’s complete : )
Drayen… “There are clever people out there just gagging to add features and help improve AC, its almost rude not to let them :P….... If they end up getting used by 80% + then you can put them into the core (and re-write them if needed).” Perfect! I agree 100%.
Drayen… “There are clever people out there just gagging to add features and help improve AC, its almost rude not to let them :P….... If they end up getting used by 80% + then you can put them into the core (and re-write them if needed).” Perfect! I agree 100%.
I love ActiveCollab. I have experimented with Basecamp. I have a request- I’m not sure if it meets the 80% rule but here it is. I have a marketing system that has the same projects and tasks process for every new client to go through. Could there be a “Project/Task Template” that could be selected for new clients to save manually having to create the same Task Lists and Tasks. I have 7 projects/Tasklists with a dozen tasks to key in for every new client.
Perhaps it should be a “Client Template”- create it once- then select it for clients using the system. I’m not a coder, but you guys rock!
Perhaps it should be a “Client Template”- create it once- then select it for clients using the system. I’m not a coder, but you guys rock!
Gary,
I believe that I read something to the effect that (By Ilija)... Project templates is a regular feature requests and will most likely be incorporated sometime in the future.
I believe that I read something to the effect that (By Ilija)... Project templates is a regular feature requests and will most likely be incorporated sometime in the future.
PLEASE KEEP it simple Ilija
Rather then build a time tracking feature, why don’t you consider using an existing awesome application like Slimtimer and its API: http://www.height1percent.com/articles/2006/10/17/slimtimer-api-released
Keep up the great work!
Keep up the great work!
My web design team recently switched to activeCollab from phpCollab and really enjoy the clean and simple interface. We have come from various backgrounds and project management systems, and the one thing we all agree that we miss on activeCollab is the ability to make comments on Tasks.
Secondly, but much less than the comments on Tasks feature, is the ability to have a Support Ticket system for each project that could have tracking and commenting history, ability to assign and mark as complete, etc.
Thanks so much for your awesome system! Our team is looking forward to what your team has to offer.
Secondly, but much less than the comments on Tasks feature, is the ability to have a Support Ticket system for each project that could have tracking and commenting history, ability to assign and mark as complete, etc.
Thanks so much for your awesome system! Our team is looking forward to what your team has to offer.
I am all for plugins and a clean core.
It works great in WordPress.
The niche folks will get what they want. Other programmers can contribute. The project can develop.
Plugins are the way to go. Should be a top priority.
In terms of control of the project, you can warn off plugin developers of features you plan to bring into the core app in the near future.
It works great in WordPress.
The niche folks will get what they want. Other programmers can contribute. The project can develop.
Plugins are the way to go. Should be a top priority.
In terms of control of the project, you can warn off plugin developers of features you plan to bring into the core app in the near future.
As an aside, how about a bounty system for these new features?
As well as there being lots of clever people wanting to contribute – i’m pretty sure there are some rich ones too. If Ilija could see there was a total of $5000 bounty of interested on getting the time tracking working, it may make it worth his while to do so.
Nothing like some cash to speed things along – right?
I myself am holding off using AC, full scale, until time tracking is done – its a killer app i just cant live without.
As well as there being lots of clever people wanting to contribute – i’m pretty sure there are some rich ones too. If Ilija could see there was a total of $5000 bounty of interested on getting the time tracking working, it may make it worth his while to do so.
Nothing like some cash to speed things along – right?
I myself am holding off using AC, full scale, until time tracking is done – its a killer app i just cant live without.
have a look at the forum. iRadeon posted $1500 worth of bounties during the last week…
Hey i was just wondering has anyone else noticed that you can’t make sub folders in the files section like i have documents and i want the folder “from Marry Jane” to be in documents.
There is no support for subfolders in Files section (intentionally). You can still tag your file with “Marry Jane”.
I think being able to post comments on tasks would be a sweet addition.
Plugins would make Active Collab a very popular choice. I can’t wait.
Has this project been abandoned?
nope, it has not been abandoned. it is on pause. expect a new blog post in the remainder of the week, or check the forum for news.
I would rather the software be bugless than to focus on new features. Currently, you can’t make changes to most items in your profile, like password changes. Being able to make edits is more important than new features. Thanks for a great software. Will make a donation when you put a donation form on your site. But please fix those important bugs. :)
I take back my previous comment. We’ve reinstalled the software in the root of a subdomain on dreamhost and the software’s working like a dream. Great work! It may not have all the features but it has the most important ones and it makes the software very easy to use even for non-technical folks.
Comments are locked. If you have something important to say about the issues discussed in this post please write at hi@a51dev.com.
Subscribe
Lou
2007-02-03 11:08