``Serving authors' needs'' is an ambiguous metric. There are two parts:
These goals are sometimes in conflict. What authors want vs. what authors need are two entirely different things. Any particular multimedia tool authors decide to use usually lacks important features authors want to reify their paper designs.
However, these wants have two parts: a need and a suggested solution. The need is some domain issue they have--for example, authors might have some critiquing situation that isn't covered by conditions as they currently appear in the tool. The suggested solution may or may not be the best way to solve the problem, where best is defined as either provide the most leverage on such difficulties and/or be the cleanest to implement in code. Often in these situations, INDIE developers would act as mentors and suggest different solutions to authors' problems.
Even with INDIE developers meddling in the design process, the INDIE developers' approach to requests for new features was conservative--if it could be done without adding new features with ``INDIE engineering'' (in other words, clever uses of the model, triggers, or other pieces), we would urge authors to do that instead of adding new features.
But even with ``INDIE feature conservatism,'' to truly see if a given tool is successful, one must see both what parts of the tool were used and what new parts needed to be added that developers failed to anticipate. If there is a large number of changes or the changes are very fundamental (such as those between INDIE 1.0 and INDIE 2.0), the tool's structure is flawed. In this section, we will examine different features of INDIE 2.0 and see which ones were used frequently, and which features needed serious revising. This will provide us an overview of INDIE's ability to serve authors' needs.