Liz Lawley

Liz Lawley

Liz is a professor of interactive games & media at RIT, as well as the founder and director of RIT's Lab for Social Computing. As the producer for Just Press Play, her primary role is herding cats and running meetings, with a generous helping of writing and content development on the side.

Aug 312012

Update: Registration is going up and down. We’re working on it. Be patient :)

You can register from ANY computer, so you don’t need to camp the IGM office if you’d like to explore or enjoy some of the lovely afternoon sun!

We had a brief hiccup in the registration system a few minutes ago, but we’ve corrected it and new registrations are working again. Sorry for the inconvenience!

Aug 182012

The summer has flown by, and we’re now only two weeks away from launching version 2 of the game. And, remarkably, nobody’s panicking! We’re very much on track for our launch date, and that’s due in large part to our learning from our mistakes.

This year, we took on the task of fully redesigning the technology, content, and interface of the game in a single summer–that’s nine weeks to encompass planning, development, and testing. Given that very small time frame, we spent what might have seemed to some people to have been an inordinate amount of time on planning before we ever wrote a line of code. As we come into the final stretch, that emphasis on front-loading the design and architecture (of both the back-end technology and the front-end user experience) is really paying off, as we watch pieces click nicely into place with no last-minute realizations that we missed something critical. So this post is devoted to the topic of what tools and processes we used for that design process, and how and why we used them.

We began the old-fashioned way, by locking all the key faculty and staff from last year’s game in a room for two days and doing an in-depth breakdown of what worked and what didn’t from a game design perspective. What pieces did we want to keep? What pieces were clearly broken, either technically or from a user standpoint? Were our core ideas of what we wanted the game to be still solid? Were our core mechanic for delivering that experience solid? During that retreat, we sketched out the basic structure of how the game could change this year, retaining our core goals and objectives but retooling the presentation and mechanics. Without those two days of intensive thought and planning, we wouldn’t have been able to move forward. That kind of deep-dive design work requires sustained attention, not a meeting here and another there squeezed between other obligations. This was not a high-tech process, either–we relied on whiteboards, notebooks, and piles of index cards (for card-sort exercises). The one technology tool that was valuable during that process was Evernote, since it allowed me to take photos of our white board diagrams and be able later to search for them based on the automatic text recognition.

Once we had a clear sense of direction, the next step was to write detailed functional specifications for the new system. Who were our users, what were our use cases, what content would we have, how would it be presented, and what functionality needed to be supported? This document was primarily my responsibility, because writing specs is not something that typically works well by committee. However, it was an iterative process that required regular input from other members of our team. I wrote the specs in Google Docs, granting read and comment permissions to the rest of the team, and encouraging them to add comment in areas where things were unclear. At the same time, our technical architect (Chris Egert) began creating a data model for the new site, taking into account both what I was drafting in the specs and the need to better record data for ongoing analytics.

As the specs took shape, I worked with Elouise Oyzon, our design lead, to mock up the pages of the site in wireframe form, focusing on functionality rather than aesthetics. We chose to use Mockingbird, an excellent web-based tool for creating application mockups, both because the tool itself worked well for our purposes and because as a cloud-based app it allowed for us to work collaboratively. We paid for the $20/month version, so that we could maintain separate wireframes for the public version of the site, the logged-in version of the site, and the administrative interface. All members of the development team had access to the wireframes, which helped enormously in clarifying the functionality in the specs. As we mocked up pages, I updated and clarified the functional spec to match what we’d determined. Eventually, the mockups became the definitive design document for the whole team, since the visual representation of the functionality was very effective for communicating requirements. Here’s an example from the administrative interface wireframes:

Mockingbird - Admin Wireframe

Once the mockups and the data model were largely complete, our dynamic developer duo of Chris Cascioli and Ben Snyder began work on the actual application engine, which was built using the .NET MVC framework. (We looked at a few other web application frameworks, including Django and CakePHP, but ended up going with .NET because our development team had strong C# coding skills.) Because that part of the project was outside of my expertise, I’ll leave it for our devs to talk about that side of the project. While they toiled in the code mines, though, Elouise and I went back to work on design issues.

To manage the many aspects of the content and visual design production process, we chose to use Trello, a free web-based project management tool made by Joel Spolsky’s company Fog Creek Development. Trello provides a flexible and very visual framework for representing tasks as “cards” that can be moved between lists. Here’s what our “front-end” Trello board looks like today, as we near the end of the process:

(2) JPP Front End | Trello

Trello is wonderful for tracking to-dos, and for maintaining an at-a-glance sense of what’s happening and needs to happen in a project, but I found when we tried to use it for organizing achievements and quests in the game that its limited search and sort capability made it less effective for large amounts of structured content than a spreadsheet or database. I finally ended up moving all of the achievements and quests into a single Excel spreadsheet, which I’ll eventually move into Google Docs.

Our final go-to tool for the design and production was Dropbox, which I have a love-hate relationship with. I love the ease of being able to share documents with a group, particularly for things where there’s little confusion about who can modify the documents–like the folders of icons we need for both print and online representation of achievements. The inability to restrict access in any way in Dropbox is consistently frustrating, however. Any person with access to the file can move or delete it, making it unavailable to other users. There’s no way to make a file “read only.” I’ve begun investigating Microsoft’s SkyDrive as an alternative, but the challenge is getting a large group of people to all be willing to shift their tools and workflow, and that wasn’t a challenge I wanted to take on with this project.

While this particular project was a game, the process and tools I’ve described are applicable to any complex web-based application (and probably non-web-based applications, although I’ve got less experience in that domain). I get asked often enough what’s involved in building a complex website that it seemed worth outlining our workflow in details for others to learn from. If you know of other tools or resources that are helpful in collaborative design and production processes, I’d love to hear about them!

Jul 252012

As Weez said in her last post, we’re changing the look and feel of Just Press Play for the new academic year. But that’s not all that’s changing, not by a long shot. Some of the changes are technical, and we’ll devote a post later to the nuts-and-bolts of the infrastructure. This post is about how things will be changing for the players.

The most obvious change in the mechanics of the game will be around the collectible cards and awarding of achievements. There will still be cards associated with achievements, but there will now be cards for *every* achievement, even the ones awarded automatically or based on materials you submit online. Once you get an achievement, you can stop by the IGM office to pick up the associated card. The cards will be professionally printed playing-card format, and later this year we’ll be developing some card games that you can play with them.

The cards won’t have those impossible-to-enter codes on them anymore, either. We know that lots more people participated and got cards than ever entered them into the system. That meant the mechanic was broken, so we spent a lot of time thinking about how to improve that aspect of the system. What we decided on was to equip anyone who can award an achievement (professors, staff members, etc) with a mobile app that can scan a QR code. Students will still get a keyfob for the game, but instead of RFID transmitters (which we were never able to integrate properly with our game engine) the keyfobs will hold a unique QR code linked to your game ID. When you qualify for an achievement, the person who can award it will scan your code, instantly giving you credit for the assignment. Sometimes they’ll have the collectible with them, other times you’ll need to pick the card up at the office. Either way, you won’t have to enter anything online to redeem the achievement. (For faculty and staff who don’t have mobile devices, we’ll provide a web interface they can use to assign the achievement.)

Another big change is in the core mechanic of achievements, quadrants, and “leveling.” We’ve changed the quadrants to four distinct categories–Create, Learn, Socialize, and Explore. Every achievement is worth 4 points in the system, and the points can be all in one quadrant, or distributed across 2 or more. There won’t be levels in the same sense that we had them in the past, either. All achievements and quests will be available to all players. We’ll reward players with achievements for reaching certain milestones (for instance, 25 points in each quadrant), but the levels will simply be progression markers, not restrictive barriers.

We’ve also added repeatable achievements into the game, which we’ll use for things like the “Flocking to Hockey” achievement. Go to one hockey game and find the JPP rep and you’ll get the base achievement. Go to 5, and you’ll get the next achievement in the series. Go to 25, and you get yet another achievement. We’ll use that mechanic for a variety of repeating events.

For every achievement you earn, you’ll be able to upload an optional text narrative and/or photo to help remember the activity. We hope this will allow people to build a nice record of the activities they engaged in to get the achievement.

And finally, you’ll now be able to make your achievements public if you’d like. By default, your achievements will be visible only to your friends in the JPP system. But you can opt to make them visible to the outside world, and even share them on Facebook if you’d like.

We’re excited about these changes, because we think they’ll make JPP more accessible and enjoyable for our players. What do you think?

Aug 232011

Has it really been two months since we posted anything here? Apparently so. Once we got our funding, all our energy got channeled into the developing, rather than the talking about the developing! We’re making a lot of progress, though, and today at the Games in Education conference I gave a talk about the system and what we have planned.

The presentation is available on Slideshare ( I could embed it here, but the slides are mostly images that won’t make a lot of sense without the speaker notes–if you go to the Slideshare site, you can toggle the speaker notes on to get that context.

Jun 152011

We are delighted to announce a major gift from Microsoft Research Connections in support of the Just Press Play project. Their generosity will enable us to move forward with rolling out the game to our students this fall, and to work with partners at other institutions to extend our work into other educational environments!

You can read more about the project and the gift from Microsoft on the RIT School of Interactive Games & Media site and the Microsoft Research “Gameful Research” site.

If you want to know when we launch, you can sign up for updates on the game on the new Just Press Play site (

Mar 272011

We’ve been thinking a lot lately about motivation. How do we get students to begin playing the game in the fall? How do we keep them engaged over the long term? There’s been a lot of excellent research and writing on motivation over the past few years, from Deci & Ryan’s groundbreaking work on self-determination theory to Daniel Pink’s engaging and accessible book Drive: The Surprising Truth About What Motivates Us — and most of it tells us that in both work and education we’re doing it wrong. We tend to focus on extrinsic rewards (like money and grades) rather than intrinsic rewards (a sense of accomplishment and pleasure in our work).

A recent Harvard Business Review study by Teresa Amabile and Steven Kramer provides more evidence for the importance of intrinsic rather than extrinsic rewards. Most of the original article is behind a paywall, but this newspaper article summarizes the findings:

“On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak,” they wrote in the Harvard Business Review early last year.

“On days when they feel they are spinning their wheels or encountering roadblocks to meaningful accomplishment, their moods and motivation are lowest.”

Those findings are highly relevant to what we’re trying to do with “Just Press Play”–providing our students with that tangible sense of progress in their educational process, and giving them support to help them overcome obstacles. It’s nice to see more support for the basic premise of the project, though there’s still a lot of work to be done in determining exactly how to provide them with that evidence of progress and support for their endeavors.