Thus, INDIE shows improvements and expansions over GBSB in terms of being complete, scalable, usable (including technical design of the tool), and effective. At ILS, INDIE has completely supplanted GBSB's role in student and staff work in building investigate-and-decide applications for the Macintosh.
One of the arguments raised in support of the restrictive nature of GBSB is the audience issue (that authors will be novices, such as schoolteachers armed with video cameras), but in hindsight it appears that high levels of restriction in structure for a GBS do not guarantee a good GBS. In [Bell 1996, Chapter 6], the author looks at 9 different projects built in GBSB and finds that only a small portion of them fit the definition of a GBS found in [Schank et al. 1993].
Like GBSB, INDIE is aimed at non-programmers. But INDIE's users are familiar with computers, familiar with basic GBS concepts like ASK systems, and can be trusted not to use the tool to build something that isn't a GBS. From the results discussed in the end of the last chapter relating to the time it takes authors to build GBSes, it appears that novice authors will need large amounts of training anyway, making it unlikely that there will be many completely novice GBS builders.
Thus, tool developers come down to a question of what they wish to focus on: Should a tool stop authors from building bad GBSes? Or make it possible for authors to build good GBSes? The second is the approach we have taken in INDIE, and it seems to have paid off with good GBSes. However, a few of the prototypes floated in INDIE were poor products, but it isn't clear that what was wrong with them (badly-focused ideas, poor art and video, no clear pedagogical goal) would be fixed if they had been using GBSB.