The AR Workbench: A Complete Co-located Reach-in Mirror-Based ...

Marlon Richert, Master’s Thesis, Friday, 23 February, 2007
attached to the user. Even in this case, however, the user will still enjoy great
freedom of movement and it will not significantly encumber them.
Is the system intuitive to the user? This of course largely depends on the kind of
application developed with the system. In general, however, the kind of direct
manipulation that the system provides to the user should be very intuitive to use
because it largely corresponds with interaction situations in the real world. In
addition, the system has an actual physical component that the user can grasp and
control—the tool handle—whose real position and orientation translate to the virtual
world in the most direct way possible. Thus, when manipulating objects in the virtual
world, the user can apply much of the expertise they have with manipulating objects
in the real world, thereby enabling positive transfer between the two.
Does the system require only limited domain knowledge from the application
programmer? That is, will a developer with only very limited prior knowledge and
experience with IPF be able to use the system to successfully and easily create AR
applications? This is a difficult question to answer, as the topic matter is very
complex. We can glean a great deal of information, however, from the sample code
presented in chapter 6. What is immediately clear is that the developer is still
required to know how to be able to create objects in IPF. This is, however,
straightforward and does not require that much time to learn. The real crux, though,
lies in implementing the act(…) method in subclasses of Role. This will still require a
great deal of knowledge of IPF. The real merit of the roles module, however, lies
in allowing the developer to think of and create interaction structure on a much
higher level of abstraction that is normally possible in IPF. If you take a close look at
the implementation of the Interaction constructor, it is immediately clear that it
takes a tremendous amount of tedious, low-level work out of the hands of the
application programmer. In addition, if one constructs such interaction structures
manually in IPF, they can quickly become unmanageable because of their opacity
and the sheer numbers of objects necessary, whose relationships often quickly
become quite obscure to the casual observer. The roles module effectively allows
the application programmer to take a step back and work at the big picture instead
of having to tinker with the niggling little details. In that respect, perhaps the
software does not have such a significant impact on the amount of knowledge of IPF
required to create applications, but rather benefits the programmer by significantly
streamlining and speeding up the development process, as well as making the code
more human-readable and maintainable.
Is the system not tied to a particular development platform? Although the design
tries to put plenty of abstraction between the application programmer and the
underlying platform, many aspects of IPF still shine through in many different
places. This turned out to be unavoidable for all practical purposes. First, IPF is
simply too large a system that it would be completely unfeasible to fully hide it from
the application programmer. It is also not completely desirable to do so, because the
graphical user interface of IPF is rich with features that hiding would make
inaccessible. Second, being able to create virtual objects in a visual such as allowed
by the user interface of IPF is simply too convenient a feature to discard, but this of
course means that we need some way of dealing with the primitives that result from
this process. The system, however, is by no means completely stuck with IPF.
Changing from IPF to another system will obviously require modification of the links
that Actors and Targets have with Items in IPF and reimplementation of the act(…)
methods of subclasses of Role because these will likely interact directly with IPF. The
main structures created with Actors, Roles, Targets and Interactions, however, will
be able to persist, as the contracts of their interfaces will remain unchanged. Only
44