Simple IF interfaces

Simple IF interfaces 06/23/2010

Recently Emily Short [twice], David Cornelson, Nick Montfort, and others have written about the command line/parser in traditional IF, and whether we can improve or eliminate it. Understandably, when a player tries IF for the first time, they are usually confused by the command line and the many conventions that go with it. They end up with more error messages than story, and are unlikely to persist.

The command line will live on as long as authors and readers keep enjoying fiction made with it. But many have pointed out there is a huge market of readers (print and digital) and casual gamers who ought to love all this free IF, but sadly, they aren't exactly flocking to it.

One reason must be the interface. Another might be the lack of "packaging," both in a marketing sense (few attention-grabbing covers, promotional materials, or sites), and a convenience sense (first download an interpreter, then a file, then find a FAQ or guide). A third for some is that playing IF can feel like using DOS or an early BBS, not reading a book. And if a reader gets past all of these things, they're likely to find most IF is about "you," trapped in an area, examining everything and picking up random things to get to the next area. Obviously, there are exceptions to all of these, but a beginner can't count on finding them before giving up.

I tried to address some of these barriers, and below are mock-ups of my ideas. They fit an iPhone screen, and could be programmed in Javascript to work on mobile devices and browsers. The images are a sequence: the result of each click is shown on the next screen.

Click on images to see a larger version in another window/tab. Firefox and others may shrink the image to fit that window, you should be able to click it for full size.

Verb icons. Click the verb icon you want to perform, then the word in the text you want to perform it on. The main description and story carry on in the top bar (reflecting any changes you make to them), and immediate responses to your actions show at the bottom. For a working example, see my unfinished story Red.

The way this mock-up turned out, it seems like it would be good to have both a TALK TO and a TALK ABOUT (with whomever you're currently speaking to) icon. And maybe a GO TO icon.

Inventory. This version leaves its transcript available as grayed text, and only disables links that would break the game (e.g. players can't pick up the same object twice). You can see an example of this method by I.D. Millington at undum.com.

My mock-up also has an inventory, and works somewhat like point-and-click Flash games: clicking on an object in the text either interacts with it or adds it to your inventory, and objects in your inventory can be examined and combined, or used on yourself or things in the description text. As my simple example tries to show, this would allow for some lateral thinking puzzles.

One cumbersome part of the transcript method is having to scroll back for keywords you need, hitting the eye icon to look at the room again, and re-clicking objects for description keywords

Popup menus. The links look just like the rest of the text, and the reader just clicks on nouns or significant phrases to view and choose from interaction options. This would keep the text "clean" and require no extra panels, but almost everything in the text would need a menu to come up when clicked.

I've shown two styles, the first more of a choose-your-own-adventure flavor, the second more IF puzzle solving. Either would allow you to examine objects and their details, but also manipulate them or make choices that moved the story.

I showed only verbs that served my examples, but the menus could be more consistent, offering the same limited set of verbs minus inapplicable ones based on context (e.g. no TASTE option for the moon). The menus could also use verb icons instead of words.

Inventory + verbs. No mock-up for this one, but it would work as a combination of the first two examples, like a LucasArts graphical adventure such as The Secret of Monkey Island. The player chooses from a list of verbs, and performs them on links in the text or items in the inventory list. Add directional buttons, and you could have most of the interactions of IF or graphical adventures.

Granted, it's fairly easy to create short mock-ups that serve my purposes. These may look like glorified CYOA games to some. The proof will be to create a working story that provides an enjoyable experience. I believe that with some extra work (programming all by hand, without the benefit of a robust environment like Inform or TADS), one could create a fiction system that allows free travel, object manipulation, and puzzles, while still being intuitive and book-like to new readers.

Comments

IF newbie

06/22/2010 9:31pm

I think you all are right on - having to guess an exact phrase each time I want to proceed takes away from the thrill of the story/game. It loses something when I know what I want to do, but can't guess the specialized vocabulary that will make it happen. Horace's ideas do solve this problem. Even having to scroll back to find a term I want to click is far less disruptive than having to guess at and type in a phrase until I get it right.

David Cornelson link

06/23/2010 1:53pm

Finally someone with UX skills takes up the IF challenge. Of course the only way to really follow through on your thoughts are to implement them in a prototype and try them out on unsuspecting newbies.

This should provide incentive on my part to further implement a working Zifmia server and then skin a game as you've shown here.

In all of your mockups, I like the last one the best. It has that "thumb" interaction model that I think is critical for any mobile/non-keyboard implementation.

I would love to see you continue developing mockups based on the community's feedback.

the one thing I had not thought of in my designs was the single click exposes button panel concept, just like in the photo viewer on the iPhone. That's an excellent way to keep the screen clean (text only). And then the button panel should have a standard implementation.

I think an important button for newbies would be a "Try this" button, but I don't know what the icon for that would be. Clicking the "Try this" button would display a list of obvious commands relative to the current location and state of the game.

Other buttons for Help, Hint, Map, Save, Restore, and Undo are important. We could also add social networking updates. When the player solves something or discovers a treasure, we could send a note to Facebook or Twitter.

I could go on forever....

RealNC

06/23/2010 10:08pm

These are not better interfaces for IF. They are better interfaces for CYOA games. Also, they are too complicated. The simplest and most powerful interface is a CLI.

george

06/24/2010 2:15am

I think highlighting keywords in the running text is useful up to a point similar to the second example, where you have so many highlighted words that it's just too visually distracting to make reading interesting. For that reason I like the third example, but the pop-up menus seem clunky in how they're overlaid -- I'd like to see this combined with the verb-button from the first example instead.

One possible enhancement here would be to highlight keywords when you mouse over them, which could avoid frustrated clicking on non-significant words.

David Cornelson link

06/24/2010 10:55am

@RealNC - the first statement is an unsubstantiated opinion. Why do you think the mockups are "not better"? Why do you think they suit only CYOA? What makes them complicated?

The current discussion in the IF community is not about replacing the command line, but enhancing the overall user experience so it has a softer entry for new users. Although there has been some discussion of removing the command line, most of us I think believe that would be a step away from true IF (including myself).

Scatman Dan link

06/25/2010 3:09am

@george: In a world of touch-screen devices, "mouse-over" is fast becoming a dying concept! Better to have a subtle highlight at all times than one conditional upon something that mobile users might not be able to do!

Horace Torys link

06/25/2010 11:07am

@george: I agree the keywords are too dense, but that might be softened by the fact that it's essentially the "room description," which you read once, and then only refer to as you are looking for keywords. In "action" passages, keywords would not run that densely.

@Scatman: I had thought of an interface where a half-second mouseover gave the description, a click interacted/travelled, and a double click picked up the item. Obviously, this wouldn't work on a mobile device, though perhaps a swipe or other gesture could work.

@David: Thanks for the kind words. These mock-ups were actually created without a command line in mind, but hopefully with the world modeling of traditional IF still present. Obviously, the command line could still be included, but I think that would be even more confusing to beginners, never mind that the keyboard takes one third of the screen on an iPhone.

In your opinion, what does the command line represent that is indispensable? I know several answers to that question, but think they can actually be achieved with different interfaces. Maybe I'm too optimistic.

Dennis G. Jerz link

06/29/2010 12:46am

One way to solve the keyword density problem is to start with plain text, and several layers of hyperlinks that are visible at different times. By that I mean perhaps the player touches a compass direction, and all the other exit words are highlighted (but not quite as boldly as the word you touched). Likewise, touching the name of an NPC might cause a secondary highlight to appear on words representing topics to ask the NPC about.

The iPhone/iPad has a gesture vocabulary that includes touch, long touch, tap, pinch closed (could map to take") and pinch open (could be "drop," but could also open a verb palette, inventory list, or some other context-sensitive tool).

While it's tempting to imagine a new interface that lets you play existing games without typing, a new interface will generate a new kind of artwork, just as the introduction of the chorus, the proscenium arch, spotlights, and microphones each changed the medium of theater because playwrights and production designers fed off of each other's innovations.

At any rate, if you plan to use the new interface to play existing IF games, because IF authors have made no attempt to make visible on the screen all the words the player needs to type, and because a list of all words that the game recognizes would be full of spoilers, I can't really see any way of banishing the CLI for existing games. So the challenge is to write new works, native to the new interface -- using its constraints to help tell the story.

Perhaps in a new interface, you could drag a word to an "i" icon to add it to your inventory, and drag one word to another word to indicate "use word 1 on word 2". This is far more simpler than CLI, but far more interactive than simply clicking a link, as in literary hypertext. If you exclude the possibility of using the CLI, then part of the gameplay involves figuring out how to get the screen to display the two words you want at the same time, so that you can drag one word onto the other.

Just as the best IF authors somehow manage to write variations of "You can't do that" in creative ways that preserve the aesthetic experience, the best drag-and-drop IF authors would be inspired by the constraints inherent in the interface.

I agree with David... at some point, the next step will be to implement a mock-up (maybe of "Cloak of Darkness") and see what happens.

Horace Torys link

06/29/2010 11:34am

@Dennis: the idea of clicking a word and having related words light up is very cool, as is dragging words to other words directly in the text.

You are right (and perhaps I wasn't very clear). This would have to be IF in the broadest sense, i.e. new works. I don't see any way to adapt existing works to play without a CLI, at least without a huge amount of work, in which case, why not make a completely new work that takes advantage of the new interface? Well, except that an existing work has most of the writing done already...

I'm really bad at finishing projects, but am sketching out a short story that would demonstrate how some of these ideas might work, and hopefully have interesting characters and plot and a smooth reading experience for the player.

Mike Roberts

06/29/2010 6:36pm

I experimented with some similar ideas a few years ago, with some actual live implementation and user testing. My (reluctant) conclusion was that hybridizing text IF with GUI controls doesn't work.

Of course, I can only say for sure that the specific things I tested didn't work. But I tested a set of ideas pretty close to what you've laid out, and from what I saw, I started to think there's a general principle that keeps these things from working.

The basic problem as I see it is that the text IF interface works because it the same kind of serial flow as reading static text. In contrast, graphical UIs are spatially oriented. My subjective experience, and what I inferred from watching others, is that those are two distinct cognitive modes, and that the two modes are incompatible. Continually switching back and forth between them seems to be distracting and fatiguing. The really bad part is that the GUI/spatial mode seems to dominate when offered, which really seems to pull players out of the story world cognitively.

(People do go back and re-read passages of text, so even static reading isn't strictly serial. But I think that's much more limited, and I also think it's a qualitatively different mode than looking for active UI elements with a mouse. If you watch people play regular IF, they tend to repeatedly type LOOK, EXAMINE, etc., even when they could go back and re-read a passage - somehow it's more natural to the player to get a fresh copy than to scan back up the screen. I think this is the serial mode at work.)

The traditional IF interface - text, command input, text, command input - has the advantage of keeping you in that serial mode. I think that's what makes it work, to the extent it does work. Clearly it doesn't for most people, but I think that's got more to do with all the usual complaints about parser limitations and world model depth. Another surprising thing I found in my testing was that the GUI input approaches were still vulnerable to the world model depth issues - you could still have situations where the player would conceptualize some reasonable action and then fight with the UI to figure out how to accomplish it (oftentimes because the action simply wasn't representable in the world model).

Anyway, I could easily be overgeneralizing my experiences with this. Maybe I just missed the one crucial ingredient that would make it work. So don't let me discourage you from experimenting - the more of that the better, certainly. But I think it's worth considering how the serial and spatial cognition modes interact in this kind of UI, since it seems like that's going to be there in any kind of IF GUI. The trick, if there is one, is probably to find some impedence matcher to make the mode-shifting as effortless as possible.

Horace Torys link

06/30/2010 12:12pm

@Mike: I had not considered the difference between reading something continuously vs. breaking out of that mode to go back and search for keywords spatially. Off the top of my head, I would say while playing IF I still do a decent amount of re-reading descriptions for things to interact with, but I also know I'll retype LOOK or EXAMINE rather than scroll up.

Have you seen C.E.J. Pacian's Walker & Silhouette and played the link-enabled version? http://gamesforcrows.blogspot.com/2009/12/walker-silhouette-download.html How similar is it to what you were testing? I found myself typing LOOK in quite a bit, despite wanting to get thru it only clicking keywords, because the room descriptions contained the keywords needed for interaction.

Mike Roberts

07/04/2010 3:50pm

I took a look at Walker & Silhouette. The approach I tried out was similar, with the elaboration that you could also get a relevant verb menu per object by right-clicking it. I think the straight keyword approach as in W&S can work, but it makes for a rather different playing experience from traditional command-line IF, and I wanted to see if I could find a middle ground closer to that.

As you noted, this UI has the practical problem that keywords scroll off the screen, so you have to keep LOOKing to get fresh keyword lists. It also suffers from the linear/spatial mode switching I was talking about. I think that's more pronounced when the keywords are hyperlinks and less of a problem when you're typing, since you can type a remembered keyword without having to recall exactly where you saw it on the screen.

One thing to try might be a hybrid of this and something like Blue Lacuna's conversation system, where the currently active keywords appear in a separate little keyword list adjacent to the command line. (Ideally this would be a temporary display that disappears after you make a selection, so the keyword lists don't clutter the scrollback transcript.) That would fix the scroll-off problem, and might help with the linear/spatial mode switching by isolating the input controls in one consistent place rather than making you hunt around the whole window for them. The difficulty would probably be finding a balance between showing enough keywords that all of the interesting (to the player) options are present, but not so many that it's overwhelming.

Amy

09/02/2010 4:44am

The approach I've been toying with mentally for some time is to maintain a list of available keywords separate from the highlights in the text. If the 'current' block of text does not contain all available keywords, then above the keywords associated with the player's possessions could be listed 'out of frame' keywords, so that you wouldn't need to type look/examine to re-obtain them.

Amy

09/03/2010 1:06pm

And then I see that Mike Roberts' last post covered that exact suggestion anyway. Whoops, reading comprehension fail.

I'd instead like to comment on my own experiences watching typical people working with applications, playing games, and my (woefully unsuccessful) attempts at getting others to try Interactive Fiction.

... many users constantly LOOK for things. Each time they go to make a decision, be it in a productivity suite or a game, they search the interface for options, in case they've forgotten something. I actually suspect that the serial/spatial shifting Roberts describes happens automatically for more people than you might think.

This could actually be advantageous.

Horace Torys link

09/04/2010 9:22am

@Amy: That is interesting. I personally do not LOOK or search menus often, and I suspect most IF players don't either, but you may be right that the average reader/user does, and something like these interfaces could suit them.

Comments are closed.

Comments

Archives

Categories

Cool IF People