Project Assignment 5

Online Battlemat
Michael Guthmann | Jordan Hofker | David Kim | Kurt Larson
5/2/2008
Introduction
Dungeons & Dragons (D&D) is a popular pastime enjoyed by many people of all age groups. Many
friends get together on evenings or weekends to play Dungeons & Dragons (D&D), but young adults find
themselves separated from friends as people move to different states for college or jobs. These friends
already communicate with existing instant messaging or voice chat software and even play multiplayer
computer games over the internet, but there is no software that supports the freeform and imaginative
play of pencil and paper D&D.

Bringing D&D, a traditionally “pencil and paper” game played with specific tools like the battlemat—a
large grid that represents an environment in a fantasy world—and miniatures, into the digital realm is
the goal of the team’s project, Online Battlemat. Online Battlemat will connect the players and fill the
void of a much needed digital D&D experience.

Based on feedback received from users during interface design stages, the team has created a fairly
complete prototype as an early version of the proposed final system. This electronic prototype will allow
the team to further revise the interface based on users’ comments and to strive to create a more usable
and functional system.

To access the Online Battlemat site, navigate to http://hci.hofker.org/. There are links to both the
source code and to the hosted system on that page. To directly access the system, enter
http://hci.hofker.org/wp-content/uploads/2008/03/Default.html into your browser’s address bar.

Design
The design of the online battlemat system started with deciding the tasks that users would need to be
able to perform. After that, a paper prototype was created based on a good design idea. Over time, the
initial paper prototype had small changes contribute to its evolution. In this section, those tasks and the
related design decisions are
described, along with screenshots
showing the changes along the way.

Tasks
Early in the project, a significant
amount of time was spent thinking
of user scenarios. It was important
that these scenarios appropriately
represented the actions a common
user would perform while playing
through a D&D session in real life,
with a real battlemat. These
scenarios brought to light four main
tasks that users would be wanting
to perform:

 Drawing on the battlemat

 Uploading a new token
 Moving a token
 Moving the viewing area

What follows is a snippet of the scenario that brought each of these tasks up.

Drawing on the battlemat

Before Tobias begins his D&D session, he would like to place few environmental objects such as
buildings, trees, wells, etc. onto the battlemat. This task should be simply accomplished by Tobias as he
selects the Pen button and draws objects on the battlemat. This is analogous to Microsoft Paint's pen
drawing on its canvas.

Uploading a token
Justin just joined his very first D&D session using the battlemat with Tobias. Before Justin can do
anything else, he is kindly reminded by Tobias that he needs to upload his character token. Finding the
"upload token" button on the top menu bar, Justin selects it to find a pop up of a file browser.
Navigating to the token image he wants, he selects the image and clicks "OK." Now the image path is
displayed on the file dialog and Justin can enter the description of the image. Upon submission of the
token upload, Justin sees his newly-uploaded token placed on the battlemat for him.

Moving a token
Justin is quite happily playing D&D with Tobias who is the dungeon master for this session. Tobias hints
that there may be some treasure and magic items inside of a house near Justin's character. Justin
excitedly wants to move his token into the house so that he can search for treasure and magic items.
Justin clicks and holds down the mouse on his token and drags the token across the online battlemat
until it is inside of the house. Then, he releases the left mouse button. Justin is happy because it was
simple and easy to move his character.

Moving the viewing area

The majority of the house that he just moved his token into is hidden from view outside of the main
viewing area. Justin desperately wants to view the rest of the house so that he may continue exploring
in pursuit of the treasure and magic items that Tobias told him about. To view the rest of the house,
Justin simply clicks on the battlemat with the Hand tool and drags just like he would an online map,
revealing the rest of the house and his newfound treasure.

Early Interface Design

Early versions of the Online Battlemat are very similar to the final layout. Shown in a screenshot on the
next page, the system is designed to give the user a very open feeling. As users create their map of the
current game setting in the system on the battlemat, we believed the system should behave similar to
familiar online mapping solutions. The main priority in the design is allowing for maximum screen real-
estate to be used by the actual mapping portion, rather than buttons, dialogs, and options.

In order to duplicate the "feel" of an

online mapping system, a small
header bar at the top of the screen
was placed that would display
pertinent information to the users,
such as the session name. Just below
that and to the left, are the map
controls and tools. Through use of
mapping software like Microsoft's
Live Maps and Google Maps, this
seemed like it would be the most
familiar and useful to users. On the
right, a hidable list of other users
and their representative tokens is
displayed. It was decided that this
list should be collapsible because once a session has started and the users are all connected, most users
would have a good idea of what token represented what user and would no longer need a constant
reminder.

Design Iteration
Based on the observations made during an in-class usability study exercise with the paper prototype,
necessary changes were discussed before having three more people perform the tasks from before. The
observations made during the initial session provided a good opportunity to discuss details of how
things should work in the system and how the interface should flow. Additionally, it allowed the scope
of the prototype to be reconsidered and cut as necessary.

Before observing three more users, the following changes were made to solve the issues we identified
and discussed earlier. These changes were later reflected in the actual prototype where applicable:

 Changed the script to mention system metaphors (like a real battlemat, like a computer painting
program, like an online game).
 Larger, colored buttons.
 Showing the thumbnail of a token when the user browsed to it.
 Changing the in-hand tool of the user immediately after uploading the token.
 Removing the Paint Bucket tool button and putting an Eraser tool button in its place.
 Displaying a help dialog when the user first selected the Template tool.
Design Revisions
The paper prototype revealed many problems with the risky aspects of the Online Battlemat System. In
particular, frequently-used buttons did not have clear icons, leaving users lost as they approached their
tasks. After improving the buttons for the second iteration, all common tasks showed significant
improvement in ease of use. Tooltips were added later to more advanced prototypes as a limited Help
function.

Another very risky area was the spell templates. As

both novel and complex functionality tied to what
is already an advanced task, users were often left
confused about how to use spell templates in the
system. Initially, the solution seemed to be to
simply present the user with Help dialogs and let
them figure out what to do from there. However,
through continuous discussion, the idea came up
that the issue could be solved by reworking how
templates worked. Instead making a complicated
click and drag in a direction to display a template
kind of system, a more usable system was designed
that mirrored the use of the token system. This
allows users to use a concept that's already familiar
and apply it to other actions in the system,
requiring less learning.

One area that always worked very well was joining

a game session. The simplicity of the dialog along
with a predefined notion of joining game sessions
made this task trivial to accomplish for all involved.
The metaphor of the battlemat surface and its
manipulation was also highly intuitive, as soon as
users got past unclear tool buttons.

Current Prototype
Through making revisions to the system by
constantly reviewing user feedback, the system has
slowly changed over the course of the semester. The above diagram shows the three main states of the
prototype as it has evolved over time.

Implementation
The final version of the system implements more functionality both horizontally and vertically - that is,
more features were implemented and existing features were made more complete. User feedback was
taken into account to increase the usability and clarity of interface elements. Like the previous iteration
of the system, the final version was created using Microsoft Silverlight 2 Beta 1. As before, the system
can be run from http://hci.hofker.org/wp-content/uploads/2008/03/Default.html. As it stands, the
prototype can run fully without crashing, and all user tasks can be completed in this prototype.

As a beta technology, Silverlight 2 is not yet fully complete. There were a few areas where Silverlight
limited the functionality we intended to implement. In particular, it was difficult to get uploaded images
added to the list of available tokens. Tokens at least appear on the battlemat surface after being
uploaded, but the system would be more usable if users could keep adding the same token to the
battlemat without uploading it every time.

Another feature impacted by the newness of Silverlight was zooming in and out. This feature is currently
somewhat functional, but it has many strange bugs that we did not have time to find and eliminate.
Zooming is surely something that will be easier to code in future versions of Silverlight, but for now it
was too difficult to get working properly. Fortunately, this feature is one of the least critical to
performing tasks in the system.

Also limited by the technology was the capabilities of our eraser tool. With Silverlight's implementation
of the Stroke class that we had to use for drawing lines on the battlemat, it quickly became apparent
that there is no way to erase certain pixels of a line at a time - the whole line must be erased at once.
User testing showed that this was not the expected response, though once learned it would indeed save
time over "pixel hunting" to erase entire lines at once.

Silverlight also introduced limitations in the proper affordance of the system's buttons. Many users were
hoping for more feedback on which buttons would cause drop-downs to appear when clicked, yet we
had to find a work-around of simply changing our custom button icons to include such feedback rather
than being able to modify the buttons themselves. Lacking any built in tool to easily indicate which tool
the user currently had selected, the team found it easiest to rig a non-clickable button to display the
current tool.

The final feature not yet implemented is the networking of sessions between separate people. This
would require a working knowledge of WCF, and the team was simply not ready to add more
technologies to the system at this point. Furthermore, networking does not directly impact any interface
elements, that is, it's all back end work rather than anything user facing. This was simply another
tradeoff between those features which were feasible to implement for this deliverable.

Silverlight did make most of the features in the final deliverable easy to create. For example, buttons
were easy to add, their icons were easy to replace, and their tooltips were easy to rewrite. A simple
version of spell templates was easy to add by taking advantage of the token functionality already in
place -templates merely use the character token class with some changes in visual styles and size
restrictions, as well as always being placed behind real character tokens. Erasing drawings, tokens, and
templates was also easy functionality to implement by making use of mouse events that were already in
use by other features. Finally, the team also found a variety of cursors already built in to Silverlight,
making the addition of new tool feedback quite simple.

Lastly, the team was able to correct many bugs that impacted the usability and correct feedback of the
interface elements, simply by taking the time to more deeply explore the classes and their properties
within Silverlight. An example of this is the now-correct response of tokens being dragged across the
battlemat surface. This previously behaved in an unexpected manner where a token's corner would
snap to the mouse, but it was easily rectified upon finding certain mouse event properties already
existing in Silverlight.

Evaluation
Test users were gathered from among the residents of Kauffman. Specifically, the researchers asked
friends and acquaintances with D&D experience to participate in the Online Battlemat study. Those that
showed initial interest in the system were then briefed. The researchers described the purpose and
goals of the study, specifically stating that the system was designed to assist in the playing of D&D by
remote players. Also, the researchers indicated that providing a free online playing tool would make
D&D more accessible to the average player who may be prohibited by the cost of miniatures, a
battlemat, and other playing devices.

Once the researchers described the purpose and goals of the study, users chose whether or not to
participate. Those that did choose to participate first signed a consent form and then completed the
tasks the researchers set before them. A copy of the consent form is reproduced in the appendix.

During the final evaluation, Kurt Larson acted as the facilitator. He described the purpose of the system
to test users and verbally provided the tasks that users needed to complete. Whenever a user had a
question or issue, Kurt was the primary point of contact. Michael Guthmann acted as the note taker.
Michael documented the actions that the user took to complete tasks and also recorded user
comments. The notes that were taken during these sessions are reproduced in the appendix.

Usability Problems and Proposed Changes

A few usability problems were uncovered by this final evaluation. They are described in the following
subsections. Also, proposed changes are suggested for each of the usability problems.

Erase functionality was unclear

When the erase functionality was added to the current prototype, a user was required to click on each
individual line or element with the upper left corner of the eraser icon in order to erase it. This proved
to be difficult for users who were forced to exercise great care with their clicks in order to erase
elements. Typically they were simply trying to hastily erase and then move on to the next task.
To improve this functionality, the prototype was revised so that a user could simply hold down the left
mouse button and then drag over the lines that were to be erased. This was well-received by other test
users.

Image upload had no feedback

The image upload window has a small square which acts as a preview of the image that was uploaded.
This proved to be a successful feedback mechanism for indicating that the image was loaded properly.
However, the window also had a text field where a user was required to enter a title for the image. If the
user did not enter a title, the system did not accept the image when the Upload button was clicked.

Users were confused because they assumed that there would be a default file name placed in the title.
However, no default title is supplied; instead, when a user tries to upload an image without a title a
subtle message appears in the upper right portion of the window stating “Invalid Title”. Most users still
missed this message. It proposed that it would be best to have the title default to the name of the file.

Lack of keyboard shortcuts

Another user mentioned that it would be nice to have keyboard shortcuts. The team had not really
considered the usefulness of keyboard shortcuts since we felt that most users would be inclined to
interact with the system with a mouse. This was not implemented in the prototype but would be an
excellent way to expand the interface to give more options to those users that prefer keyboard
interactions.
Lack of undo and redo
The same user who mentioned that keyboard shortcuts would be a welcome addition also suggested
adding undo and redo functionality. This could be implemented with buttons and/or keyboard shortcuts
in a manner similar to other applications like Microsoft Word or Adobe Photoshop. From a code
perspective, this would require the implementation of a stack based command system that is recorded
in memory. This functionality has not yet been added to Online Battlemat.

Reflection
All in all, we believe the project fit in very nicely with the course's iterative design process. It was a
simple project in concept, yet it solves a problem that is prevalent in the current D&D world. Also, the
project mechanics mandated that we implement it with dynamic web technologies such as Silverlight
which in turn challenged us into building a wholly new application in a new context. Our audience knew
what to expect and the tasks could not have been more clearly defined or understood by them. In
addition, the project required very little learning on the users' part as it involved much of the same
functionality as the familiar Microsoft Paint program, yet those core functionalities were richly
presented in a new format for D&D players. The system we built and presented is simple yet powerful,
clean yet intricate. We are overall very content with our project choice.

With this project, we learned many things about integrating better usability into a product. We learned
many valuable lessons to close the gap between what we believe to be important and what users find to
be important. For example, the single most important piece of feedback we received throughout the
entire project was that the icons were not clear. Therefore, the team revised and re-revised the icons to
improve clarity. Users were quite pleased with the final version of buttons.

For each milestone, we made the following steps/changes:

Project Milestone 1: The system was conceived.

Project Milestone 2: The researchers analyzed the problem, the potential users, and considered a
contextual inquiry.

Project Milestone 3: With paper prototypes, we had feedback that the icons were not clear. Also, we
had feedback that the zoom feature and the scroll screen feature were not
clearly presented; the "paint" bucket icon which was present in the paper
prototype was identified as an unnecessary feature that just confused the users.
With this feedback, we decided to take out the "paint" bucket icon but
elaborate on the zoom and scroll features by making the icons more legible.

Project Milestone 4: This iteration has been the most helpful. Users identified the following issues
with the electronic prototype:

 Users said they had expected to be able to use the uploaded token immediately, instead of
being forced to find it in the system's menus.
  Users noted that the system lacked a way for them to erase things that they drew on the
Battlemat.
 Users were confused by the Spell Template tool and using it to place different shapes.
 Users were hoping for some Help functionality.
 Users were confused by having no feedback on which drawing tool was selected.

These identified issues have been truly helpful. We incorporated the feedback into the final prototype
by:

 Changing the in-hand tool of the user immediately after uploading the token.
 Removing the Paint Bucket tool and putting an Eraser tool in its place.
 Displaying a help dialog when the user first selected the Spell Template tool.
 Displaying tool tips for each tool.
 Showing the thumbnail of a token when the user browsed to it.

While making the above necessary changes, we incorporated many design principles and heuristics into
the system. Affordance on the buttons, consistency on the look and feel, constrained minimalist design,
visibility on buttons, and feedback on system status were all integrated into the system from the
foundation on up. We ensured that the system status is clearly displayed along with simple dialogs
which carried only relevant messages.

After making revisions based on our users’ feedback, we are very happy to present the final prototype of
our system. We had design and technology in mind, and we were able to fuse them together to deliver
something very simple yet rich and pleasant to use.

Appendix

User Evaluation Notes

User 1

Join the game

- Enters 1234 with password foo.

- Didn’t know what name to enter – could be your sign in name or your character’s name.

Upload a picture

- Hovered over the correct button and read the tool tip.
- It didn’t put in the title of the image. User 1 expected that the file name would be populated by
default.
- Didn’t give any feedback so User 1 doesn’t know if it works properly.

Place a token
 - Read the tool tip before clicking the button.
- Selected a character and clicked it.

Move character

- User 1 had no troubles with this. User 1 said “Awesome! It’s easy.”
- Move character inside of temple

Draw some lines

- Noticed that the cursor changed to a dot for a pen.

- Clicked the hand icon to go back to the normal selection state.

Select a spell template

- Looked to the tool tip for confirmation.

- Dragged the spell template over the enemy cultists.

Erasing

- Kind of difficult because you have to click on the line with the upper left part of the eraser icon.
- Tried to drag the eraser over the pixels. Assumed a pixel erase

Played with the zoom and center functionality. Liked those features a lot.

“Seemed pretty smooth overall.” “Made pretty good sense.”

User 2

Join the game

- Joined game with no difficulty.

- Put full name in the name textbox.

Upload a picture

- Tried to drag the picture around the

- Invalid title – tried to reupload the picture instead of entering a title.
- Thought the title was the path to his file
- Invalid title was not very helpful.

Place a token

- No problems

Move character

- No problems

Draw a temple and sacrificial altar

- Carefully sketched the outline of the temple.

- Drew the altar and jewels.
- Thought the cursor might change color with the selected color.
- Drew a wall of fire without difficulty.

Select a spell template

- Selected the spell template without difficulty

Erasing

- Easily erased the board.

User 2 tried to erase an item using delete. Expected keyboard shortcuts. “I like the system.” “I liked that
I could erase things.” “I wish there was an undo for erasing.” Keyboard shortcuts for undo, redo, cloning,
etc. would be nice. Mouse gestures would be nice.
User 3

Join the game

- Typed in password and session without difficulty.

- Player name or character name. User 3 thought player name.

Upload a picture

- Hovered over the buttons. Read through the tool tips.

Place a token

- Size is confusing. Maybe should just say medium, large, huge.

- Entered a title when the invalid title string appeared.

Move character

- No problem

Draw a temple and sacrificial altar

- Drew blue fire. Then erased it. Then redrew it.

Select a spell template

- “You guys have spell templates. That’s awesome!”

- Can’t draw on the template. Expected to draw behind the template when he clicked on the spell
template.

Erasing

- Pretty easy.

Grabbing hand animation would be helpful. Click the pen to have a default color without having to select
a color.

A menu could come up and you could select delete (right-click menu).
Usability study participant informed consent form
The Online Battlemat System application is being produced as part of the coursework for
Computer Science course CSCE 396 at the University of Nebraska-Lincoln. Participants in
experimental evaluation of the application provide data that is used to evaluate the interface of
the Online Battlemat System. Data will be collected by interview and observation.

Participation in this experiment is voluntary. Participants may withdraw themselves and their
data at any time without fear of consequences. Concerns about the experiment may be
discussed with the researchers (Kurt Larson, Jordan Hofker, Michael Guthmann, David Kim) or
with Professor Lorin Hochstein, the instructor of CSCE 396:

Lorin Hochstein
Department of Computer Science & Engineering
University of Nebraska-Lincoln
404-472-3525
lorin@cse.unl.edu

Participant anonymity will be provided by the separate storage of names from data. Data will
only be identified by participant number. No identifying information about the participants will be
available to anyone except the researchers and their supervisors.

I hereby acknowledge that I have been given an opportunity to ask questions about the nature
of the experiment and my participation in it. I give my consent to have data collected on my
behavior and opinions in relation to the Online Battlemat System experiment. I understand I
may withdraw my permission at any time.

Name ______________________________________________

Date _______________________________________________

Signature____________________________________________