Posts Tagged ‘user experience’

Emily Short just wrote a nice summary of some of the issues surrounding IF user experience, although she missed mentioning Zifmia.

Zifmia is a plan to implement IF games in a web client/server architecture, leaving the UI of the game entirely in CSS/HTML/JavaScript. The game file, the save files, and the virtual machine would all reside on the host side of the equation.

Anyway, I see the accessibility from a different angle, having looked at this for a long time and in the last three plus years from a commercial perspective.

First of all, I’m really excited that everyone is taking this seriously. I remember not many years ago when I would bring up the interpreter/game-file issue and people would simply shut the conversation down. They would say, “This is the way we do it because we want to be cross-platform. This is the best model.” and I would end up on a channel on ifMUD arguing with myself. I think the casual gaming implementations have shown that any installation complexity is a barrier few are interested in crossing. We still have that barrier and need to knock it down.

The parser and interface aspect has also been something I’ve discussed, but only through Textfyre have I really tried to push the envelope. Even I’ll admit that before Textfyre, I was mostly a traditionalist, favoring a white fixed font on a blue screen. That quickly changed when I started thinking about how I was going to present IF to new players.

My initial thoughts were to implement a book interface. I developed the concept with an art director and Thomas Lynge implemented the complex code to allow for paging. This can be seen in the deluxe version of Secret Letter.

This looks great, but most people thought it was “over done” and possibly detracts from game play. With a mixed response, this implementation is likely to be abandoned until further testing is done.

I’ve since started focusing less on the look and more on the functional side of the user experience. This is why I started talking about simple buttons for common UI actions as well as implementing a “Try” button that might list commands that would work at the current moment in the game. iFrotz has also come up with a few neat tricks that I think are great. You can tap words and watch them slide down to the command prompt. I think more touchscreen and multi-gesture input concepts could be introduced into the user experience increasing usability and accessibility.

But I believe there is a flaw in Emily’s article as well as in my own implementations and ideas. In order to determine what works and what doesn’t work, I believe we need lab rats, guinea pigs, and hyperactive mice to try out our ideas on a relatively large scale, get feedback, improve our ideas, get more feedback, and at some point make a cut that we think can reach as many people as possible. In talking to partners via Textfyre, we probably need several hundred people of varying ages, experiences, genders, and backgrounds to truly determine what works and what doesn’t. And then you have to decide what subset you want to target. Where do we get hundreds of people to use as guinea pigs? When we find them, how do we track their usage? Who will organize/facilitate sessions? How do we implement the results? Who implements the results? Which platform do we choose first? Z-Code? Glulx? TADS 3? (Knowing that the results will be portable to other platforms).

Do you want anyone from 8 to 80 playing your game?

Do you want non-computer users playing your game?

Will your game be on a PC/Mac?
Mobile device?
Does it have a full keyboard?
iPad or multi-touch tablet?

Are you willing to develop content for a deep help/hint system in conjunction with the lab-rat determined user experience?

Are your users avid readers?

Have your users played video games?

These questions are just as important as where to put buttons, what font to use, and how you make games accessible.

* * * *

As much as I struggle with this problem, it’s my number one priority both for Textfyre and for the community at large.

We’re in our third year at Textfyre and nearing the completion of our third game, Empath’s Gift. Empath is now in a state where the game can be played through to several of its conclusions. There’s a bit more paint to dry before it goes into beta-testing, but that should happen in the next few weeks. I can’t offer a firm release date yet, but it’s looking like sometime in late June, early July.

Meanwhile, our fourth series is beginning its design phase and we have a series and episode title. The series, designed and written by Sarah Morayati (Broken Legs), will be called Anna Chronicle. The first episode in this historical fiction adventure is Poets in Peril. It’s great to see the fourth series underway.

You may have noticed that Sarah is doing both the game design and the writing. In this case, She’s very passionate about the subject matter and knows it well. She’s also planning to use internal resources for puzzles and interactivity, but the project is hers to manage. The programming will still be done separately. The designers and writers (except for Gentry) all seem to love not having to do any programming.

* * *

In other news…

The Apple platform versions of FyreVM (now an open source project on sourceforge.net) are cruising along. I look forward to announcing the first releases of Textfyre games on the iPhone and iPad.

In lieu of a professional user experience consultant, I am adopting some of my own ideas into a Windows version of Shadow in the Cathedral and then having those ideas ported to the demonstration Silverlight version that can be played online. Some of the ideas include hyperlinked exits, a “Try This” context menu, and voice over help. When ready, we will share the new ideas with everyone.

Andrew Pontious started working on an Apple implementation of FyreVM and he’s moving his work from a private source control repository to the new SourceForge.Net FyreVM repository soon. This will also be released under the MIT license, which means anyone can use it for personal or commercial purposes.

The harder part is the user interface. Andrew will likely have a very basic UI implemented for testing FyreVM, but it will be up to the community to help bring about something more visually appealing and usable.

I’ve found a user experience consultant to work with the community, but the quote is rougly $4,000. This would include 5 weeks of iterative user experience work. Andrew is partially committed to helping out with mocks and Chris Cavanagh, a Silverlight developer, is also open to doing mocks.

The result of this work wouldn’t be the actual UI. It would be the general look and feel. We’d have to then work with someone with graphic arts experience to take the usability designs and make them pretty as well as having a programmer implement any of the active components of the experience (rollovers, transitional animations, etc).

I’m committed to finding a way to fund this effort. I’ve started a Kickstarter campaign, but haven’t launched it yet. I want to put a video together that tries to explain to potential contributors how important this is to the IF community.

Remember, the user experience isn’t just about Apple products. The results could be implemented in Parchment, on Windows, in Silverlight…or in any other interpreter.

I’ve started the search for a consultant to help develop a new user experience for general IF consumption. I’m flirting with the idea of trying to develop a general guide and leaving it open to the community to use and add onto. To use it for free and commercial works. I’m beginning to lean towards the idea of spending money and time on hobbyist outreach activities and letting the results of that flow into Textfyre organically.

I think I’ve found the right person to help too. Here is her very first take on playing IF:

Hi David,

So I’ve done some reading and tested out a few games–the online demonstration of The Shadow in the Cathedral and two others.

Being a newcomer to IF myself, I can see two barriers to its adoption. One is the hurdle of getting started (and it’s actually not that big of a hurdle) and the other is meaningful progression through a game. To get started, users have to download the correct interpreters or, in Textfyre’s case, Silverlight. These are not difficult steps at all but they add the perception of difficulty to first-time users. So, if this step could be eliminated at all (if users could play directly on the website?), I think that would help.

The help text and text formatting are key to getting someone started, and I think even more could be done with text formatting to help delineate the progress of the game vs. the help/hints. As an example “Remember, you can type “help” if you need assistance” might be put in italics so the user can easily scan a page and see what’s part of the game and what’s technical assistance. Some other suggestions are indenting help text or keeping the actual story in a different color or font.

Once a user gets started, the meaningful progression through the game depends on knowing what to input. In one of the games, Earl Grey, I was given keywords to use. However, it was hard to keep all those in my head. At least for beginners it would be helpful to have the keywords always onscreen (not scrolling off as the users progress) to refer to. It was also difficult to remember my past actions and my progression. Something like the idea of a breadcrumb (although a true breadcrumb isn’t possible since users will be jumping around) would help. Users need to know where they’ve been, where they are and where it’s possible to go. Documenting their past actions on part of the screen (again, instead of keeping it all in one scrolling page) would remind users what avenues they’ve already taken, and what it’s led them to. Combined with the keywords onscreen (the ‘where it’s possible to go’ part), that would cover all three states.

One last suggestion I might have would be short how-to videos for both getting started and what to do when one gets stuck.

One thing I wondered about was whether users and writers preferred the text part of IF, and whether they would resist graphics such as buttons, props or pictures of the scene. Is the point that the user gets to imagine what something looks like? Does showing too much ruin the creative experience of the game?

I think Laura is on the right track and if we go through several iterations on paper, we should have something reasonable on the back end. I’m also considering putting together a sort of usability panel. If anyone is interested, drop me an e-mail.

Updated: 11pm

Inspired by the outreach panel at PAX, I came up with the following design idea.

There would be a very sparse color-border container for the main window. We would eliminate the status line and possible move that information to the right side or somewhere else. Commands would be entered on the right. Help text, command lists, and other items could be retrieved by clicking one of the friendly color buttons. When clicked, the UI would transition smoothly to one of the new views (help, map, about, or ?).

The entered commands would still be embedded in the transcript, but I haven’t nailed down if I would highlight them or add them in with the standard “> open mailbox” reference.

Previous layouts can be seen here and here.

I moved things around for a second pass. Buttons on the right or in between the input bar and main window. Help screens would slide in and out like the iPod Touch/iPhone.

New thoughts?

Since we have had such a difficult time finding resources to work on WPF, I’m making the big decision to dump it in favor of a Flash implementation. We still need to determine the right mix of .NET and Flash to make it function well on Windows, OS X, and Linux, but I don’t see this as a huge technical hurdle.

So the UX job description has been updated. We’re now looking for a very strong Flash developer with C# experience. My preference is to hire someone in the Chicago area, but I’m open to other suggestions.