Category — Usability and Web

From a very high level, Hitchery is a game/app that lives on your mobile device. Each player owns a bus (their device) and several autonomous “hitchers” who travel from place to place in the world via other player’s busses. Think Flat Stanley or a Travel Gnome + Foursquare. The device serves as a tool (bus) to check-in (pull over) to real locations. Once at a location, a player can “pick up” and “drop off” hitchers owned by other players of the game.

What becomes difficult is explaining the concept that the phone represents a bus that is attuned to real locations and that each user has autonomous characters that are out in the world in real locations (but not real characters). Users who are familiar with digital games or a certain type of lateral thinking have no trouble understanding the nature of having independent and dependent representatives in real life locations. The difficulty is trying to explain this to new users to whom this concept is completely foreign.

We are currently trying a tutorial approach for new users (with some hand-holding) to walk them through the game the first time through. Tweaking copy here and there (to account for the fact that users simply skim over instructions) has had mixed results. Our next approach is to try it with graphical overlays over the interface to explain how things work without so many of those pesky words.

At the end of the day, I don’t think anything could beat a great info graphic that simplifies the experience even more. Time will tell.

I’m open to suggestions.

 Some of you know I am working for a startup called Hitchery creating a social/spatial/mobile game. I am tasked with creating a simple and engaging user experience. As a UX Designer during my day job, I have ample experience with creating easy to use interfaces, interactions, what-have-you’s. Hitchery presents me with a new kind of challenge that I have no experience building, yet am increasingly fascinated by.

Is it fun?

It has been a guess and check process since I became involved in the project. That’s not to say that it isn’t progressing, because it most certainly is. The trouble is that it is difficult to measure fun. The methodology isn’t all that much different than it would be on a standard project.

• Speak to users;
• Come up with some wild idea which we presume would add to the fun-factor of those users;
• Implement;
• Conduct usability test (and fun testing?);
• Fix pitfalls, bugs, usability issues;
• Then do it all over again.

The problem comes in between the fixes and the iteration. Did we actually add any value to the game or just add complexity? It’s hard to tell on a small scale.

Maybe engagement is somehow correlated to fun. This was a hypothesis that I quickly learned would not work. My thinking was this: What is it that would make a user open thn app during their idle time? What would make the user go out of their way to stop their lives to open the app and engage? What would engage users enough to transcend their mobile experience, and explore the game through their browser through the web interface?

Solution for measurement: Notifications. We could test the quality of key events in the game by measuring the engagement based on notifications that are sent out about game occurrences that affect the user. Notifications of passive events that occur in the game while they are not using it will possibly increase the chance that they will be reminded of its existence. This is no measure of engagement or even desirability, but rather succumbing to an alert that demand attention. This type approach has two sides:

• Either the user opens the app upon receiving a notification and enjoys what they see;
• Or they become increasingly annoyed at the notifications because the experience tied to it is predictable and not satisfying.

Once again. It doesn’t solve the problem or measure the solution accurately until the app is truly fun.

Iterations and time will tell. Until then, it’s a race to iterate quickly with a guess and check philosophy where the guess is incredibly subjective to a small sample size. Once my experience in this domain grows, I will hopefully be able to make better educated guesses and ultimately come to solutions more effectively and efficiently.

This guide will walk you through creating a mega drop down that is visible on hover similar to the way sub menus work with the default Menu Widget… Only you’ll have more control over how and what is displayed. The assumed interaction is to show the menu on hover, hide it on mouse out, and have a clickable top level item.

For this guide I will be using Axure RP 6. This technique should work in previous versions to some extent since it uses basic interactions. Download a free trial if you don’t already have it.

Step 1: Make a primary navigation bar (as a master) using the Menu Item, table, or arranged static text.

Step 2: Place a Dynamic Panel the width of the page that generously extends across the navigation in every direction. Name it something meaningful like “MegaDrop”. Make sure it is layered on top of the navigation.

Step 3: Add a state to the Dynamic Panel for each primary navigation item and name them appropriately for easy reference.

Step 4: Enter the edit mode for the first state. Place an Image Map Region that fills the Dynamic Panel region. This Image Map Region will act as a sort of negative space since it will close the dropdown when the user moves their mouse away from the navigation area. With the Image Map Region selected, and the widget properties visible, go to the Interactions Tab (Ctrl + 2). Select OnMouseEnter and click Add Case… Select Hide Panel(s) under Dynamic Panels. Then select “MegaDrop” (or whatever you called it in Step 2) and hit OK. You can add an animation to make it flashy, but I’ve found it can be a little buggy if the user is mousing over and out of the navigation items too fast.

Copy and paste this Image Map Region onto every navigation state.

Step 5: Make a box in the first state that will hold the dropdown content. The top of the box should away from the edges of the Image Map and in front of it. Populate the mega dropdown with whatever it needs for the navigation item it’s associated with. The tricky part is getting it to align with the top level navigation. You can try moving it to the top of the state list with the dynamic panel set to visible. Then it’s just a question of going back and forth between the state edit tab and the primary navigation view to get it right.

Repeat this for every state and navigation item.

Step 6: Go back to the primary navigation view and add an Image Map Region on top of each navigation item. It helps if they extend between each item to touch to make a solid area of separate Image Maps. Make sure that all of these Image Maps are in front of the “MegaDrop” dynamic panel with the dynamic panel extending in every direction outside of the Image Maps. We want to make sure that if the user moves their mouse above the primary navigation, they will hit the negative space.

Step 7: Get to the interactions view for one of the Image Maps you just created (similar to how you did it in step 4). Add a case for OnClick. Select Hide Panel(s) and then “MegaDrop” under the Dynamic Panels heading. Also, select Open Link in Current Window under the Links heading and find the top level navigation page the navigation item is associated with. Click Ok

Add a case for OnMouseEnter. Under the Dynamic Panels heading, select Show Panel(s) and then “MegaDrop”. Under Dynamic the Dynamic Panels heading, select Set Panel state(s) to State(s) and select MegaDrop. Then in the dropdown (at the bottom) select the state associated with the top level navigation item. Click Ok

Repeat this for each Image Map Region on the primary navigation bar.

Final Step: Generate a prototype and test it out!