- Although the interface was uncomplicated, technical problems
made the program hard to use. Most notable in this respect were the
large memory requirements (which made using it in parallel with
spreadsheets and word processing programs nearly impossible) and the
slow startup, which meant rapid testing was very difficult--it could
take up to 15 minutes for the tool to start.
Also, authors needed to see the data from different directions
than just looking directly at the template--for instance, there was
no way to get a summary of questions and answers, or jump to a
particular piece of art that needed changing. Instead, authors had
to click the navigation buttons, which moved the ``content insertion
point'' forward or backwards one spot.
- GBSB was not very flexible, with many built-in limitations at an
interface level. If the program were to be expanded in any way (more
tests, different sorts of interactions for tests, more questions,
etc.), there is really no way to fit new ideas into GBSB's
template--the internal data structures and the interface template are
very brittle.
- There were some technical problems with getting GBSB to build a
full application, but more importantly the template didn't specify a
complete application. With the full complement of four samples and
four tests, there are 16 different facts that can be ascertained from
the information provided. Students should be able to obtain these
facts in any order. Thus we have 216 possible
combinations of facts with which students can approach the clients.
Since there is no critiquing model in GBSB, the template needs to have
a case for every possible combination and order of facts. 216 is
an untenable number (65,536) to enumerate, and GBSB designers
instead restricted critiquing to only work for whether or not each
test is done and thus the client responds to the student as if the
student ran each test on every sample. This leaves only 16 possible
combinations of evidence, and thus the number becomes less
combinatoric, but 16 is still a lot of cases to explicitly
author.13.1
- Authors in GBSB face many restrictions to easily expanding their
GBS, especially on the level of changing the domain or knowledge
model. For instance, while running an experiment such as the one
shown in Figure 7.1, there are three questions available in
the Just-In-Time help. Each of those questions could have one answer
and one followup. There could be no more than six total questions for
each phase of the GBS, and no less--there were always exactly six.
This problem was very difficult to work around if authors had more or
less content, and the facilities for very deep exploration of a topic
was very restricted by the six-question limit.
- Analysis of the deployment of Sickle Cell
Counselor implied that it was entertaining and useful as part of a
museum display. One can easily believe that the good design of
SCC was carried over into other projects built in GBSB, since they
shared nearly identical interfaces and model.
With an inflexible and unscalable GBS tool, however, projects
suffered. Although a handful of projects worked well inside the GBSB
template, this was not the case for most. Many projects needed more
sophisticated critiquing, had irritating and needless interface
elements and guide videos (since GBSB didn't allow authors to remove
elements they didn't want), and lacked depth. However, full analysis
of the quality of GBSB's products is largely impossible as none of
these SCC-like GBSes were deployed on a large scale.
