bgror

Design Forces in Ekawada, Part 5 »

Created at: 09.11.2010 20:37, source: the { buckblogs :here } - Home, tagged: Projects Under the Hood design ekawada forces ios string figures

In making Ekawada a free app, one of my hopes is that people with little or no experience with string figures might be tempted to download it and give it a try. But a list of string figures and some cryptic instructions are not going to be particularly encouraging to these newcomers; I needed to make sure that Ekawada was suitably welcoming to them, without getting in the way of more experienced users.

The three screenshots below illustrate the approach I took:

The first screenshot is the home screen, which is the first thing a user will see when they open Ekawada. It includes a limited set of options, and the very first one the user will see is labeled “New to string figures?”. If they tap that option, they’ll be shown the second of these three screenshots: the tutorial list.

Ekawada will ship with 9 tutorials initially. These range from selecting your first string, to basic string maneuvers like the Navaho and loop exchanges. These tutorials are intended for rank beginners, and are focused on teaching things like how to read the notation used in the instructions. The tutorials also include links to some of the included figures, to encourage people to apply what they’ve learned.

If, however, you’re not a complete neophyte, you might not identify as “new to string figures”, but you may still have questions about Ekawada itself. If so, the second option in the list is intended to attract your attention: “Got a question?” Tapping on that option will take you to the third screenshot: “Common Questions”.

There aren’t a lot of questions here right now: just six things that I expect people might want to know. As I get feedback from people using Ekawada “in the wild”, I’ll grow that list.

I’m sure that as the app gets used, deficiencies in my approach here will surface. In the end, the best anyone can do is guess until the app gets put in front of real people, but I’ve tried to anticipate some of the common concerns.

Ekawada is currently “in review”, according to iTunes Connect, and has been since Monday morning. I’ll post as soon as I have more news. You can bet I’m refreshing iTunes Connect some few times per day!

I’ll be heading to New Orleans tomorrow for RubyConf, but if I’ve got some time while I’m there, I’ll try and do another post this week focusing on the Ekawada store, and the process I went through deciding how to organize the initial offering of figure sets.

Design Forces in Ekawada, Part 4 »

Created at: 03.11.2010 16:17, source: the { buckblogs :here } - Home, tagged: Projects Under the Hood design ekawada forces ios string figures

For many people, string figures are games that they learned as children, and haven’t touched since. The years are rarely kind to memory, so what this means is there are a lot of people who remember doing figures, but can’t remember what they were called, or how they were done.

I knew, back in April, that Ekawada needed to address this somehow.

The solution I came up with is based on filtering figures by their attributes. For example, suppose you remember, way back when, doing a figure that had a bunch of diamond shapes in it. You don’t remember what it was called, or how it went, just vaguely what it looked like.

You’d go to Ekawada’s index list, and tap the magnifying glass icon, which would take you to the filter criteria selection page (pictured on right). From here you could drill down further into the specific criteria you want to filter on.

In our case, we’d choose “appearance” (since we only remember that the figure looked like diamond shapes), which would take us to the list of appearance criteria.

(Note that with an initial set of only eight figures, most people won’t see much to select here. Then again, they wouldn’t really need to use the filters, either, since eight figures are trivial to scan. But with the other 98 figures installed from the five available packs, the available filter criteria are pretty extensive.)

There’s “diamond”. We’d select it (and any other criteria we want to filter on), and return to the index view.

The resulting list is still longish (diamonds are a very common theme in string figures), but it’s much better than trying to scan all 100+ rows.

Now, I’m not 100% pleased with this filtering system. It’s functional, but the flow isn’t quite right. I intend to revisit this in later versions, possibly ripping out the current incarnation and replacing it with something more flexible. I’d like to add the ability to search by name, for one thing, as well as the ability to combine filters together. (Currently, selecting more than one filter returns all figures that match any of them: an “or” condition, rather than an “and”.)

In spite of that, the system works as it is and it does let you answer the question, “what was that figure I used to know?”

Ekawada itself is nearly done; I’m wondering if I could possibly have it available to download by RubyConf, though the bottleneck is going to be the App-Store review process. I also still need to flesh out the website and help pages (and a few other marketing-related things), but I’m almost there! It feels like I’ve run a marathon.

I’ll do a few more posts before Ekawada launches; the next one will talk about how Ekawada answers the question: “I’m new to all this—where do I start?”

Design Forces in Ekawada, Part 3 »

Created at: 01.11.2010 16:41, source: the { buckblogs :here } - Home, tagged: Projects Under the Hood design ekawada forces ios string figures

String figure books are great resources, but they can be incredibly frustrating, too. Even if you’ve never tried to use one, it’s not hard to imagine having a string looped around your fingers, trying to hold the book open with your knee, and then discovering that the next step wraps onto the next page. You somehow need to turn the page without dropping any strings, and without closing or dropping the book.

It is no surprise, then, that this became one of the design forces that drove Ekawada’s construction.

Now, given the constraints on the size of an iPhone screen, it isn’t feasible (in general) to display all of the steps for a figure in one screen, so there still needs to be some kind of “next page” operation. However, the touchscreen makes this much easier to do than with a physical book.

This screenshot shows the “figure detail” view. It gives you a nice big picture of what the final pattern will be, and then a sequential list of the steps to accomplish it. As you can see, the number of steps for “Osage Diamonds” (a.k.a. “Jacob’s Ladder”) exceeds the available screen real-estate, and so bleeds off the bottom. But that’s no problem on an iOS device, because you can simply swipe to scroll, and a swipe is much easier to do with strings on your fingers than trying to turn the page of a physical book.

Further, if you tap any row in the instructions, you’ll be taken to a “zoomed” view. Here, each instruction is displayed full-screen, including any illustration or clarification for that step. (Not all steps have illustrations or clarifications, but for those that do, you’ll find them in this view.) You’ll also get an indicator of how much further you have to go to the end of the figure, and icons for going to the next (or previous) step.

Why icons? I considered doing a “swipe” gesture to go to the next page, but really, a tap is easier to do with strings on your hands than a swipe. (The less motion involved, the better.) I tried to strike a balance between size of the icons (a larger target is easier to hit) and maximizing the viewable area for the step (the less often you have to swipe to scroll a step instruction, the better). The size as it is now seemed best, empirically, but later versions may adjust the balance further.

This zoomed view also answers another one of the design forces behind Ekawada: “I don’t understand what this step is telling me to do.” You don’t want to just add verbosity to the instructions, because more verbosity can actually hurt readabilty. (Just try reading these instructions for the “Apache Door” figure, if you want a concrete example of what I mean.)

Thus, for steps where the instruction itself may be too terse, or ambiguous, I can use the zoomed view to add an illustration, or extra clarification, without bloating the instruction list. When you need more information, you can get at it easily, but for the common case, you can just scan the instruction list.

Tune in next time, when I’ll address another design force behind Ekawada: “I remember learning this one figure as a kid, but can’t remember how to do it now.”

Design Forces in Ekawada, Part 2 »

Created at: 29.10.2010 07:34, source: the { buckblogs :here } - Home, tagged: Projects Under the Hood design ekawada forces ios string figures

In my previous post, I talked a bit about one of the “forces” that influenced the design of Ekawada, my as-yet-unreleased string figure catalog app for iOS. In this post, I want to talk about another of the forces that affected the app: “What are some easy figures to do?”

It’s not hard to imagine someone with little-to-no string figure experience being curious about the app, especially since it is free, and downloading it just to see what it’s all about. They might want to start with the easiest figure, just to see if it is something they could really learn. How should the application show this to them?

From the UI point of view, I took the easy way out: in the upper-left corner of the index is a toggle that lets you switch between “ABC” (alphabetical) and “123” (difficulty) orderings. I’m not best pleased with that solution, though: it’s not very self-explanatory. Expect that to change in a future version of Ekawada, after I have more opportunity to think about how best to present that.

(Ignore for now the blue button at the bottom—that’s there because the view is being filtered to show only the “starter set” of figures. Tapping that button would return the view to the default of showing all installed figures.)

At any rate, toggling the view to “123” gives you the figure list, sorted by difficulty (actually complexity—more on that shortly). The first figure in the list is the least complex, and the one at the bottom is the most complex.

Here’s where things get sticky, though. There is no formal, standardized way to evaluate a string figure and say how difficult it is. If you look at the various string figure web sites that try to categorize figures by difficulty, they all do it in a very subjective way. Sure, you may agree that the “easy” ones are easier than the “hard” ones, but you may also disagree with specific categorizations.

Anyway.

I wanted a way in Ekawada for people to order figures by difficulty, and thus I needed a way to objectively rate figures. After a bit of experimentation and observation, I came up with a system that considers what types of maneuvers are used in each step, and assigns a number to each type of maneuver. Then, the various maneuvers used in a figure are summed, and the figure is given a rating. “Opening A”, for instance, is rated a 10, “An Apache Door” is a 61, and “Cat’s Cradle” is a whopping 196 42. (edit: I updated the system to handle figure sequences better, so Cat’s Cradle has a much more sane complexity rating.)

This gets to the point of “complexity” versus “difficulty”. Cat’s Cradle is rated at 196, but that’s because it is a complex figure (actually, series of figures), and is not actually very difficult. Thus, the rating still doesn’t necessarily tell you what is easy and what is hard, only what is simple and what is complicated.

Often, that’s good enough. I do plan to tweak the algorithm for computing the complexity after Ekawada is released, based on feedback from users. However, I think it’s good enough for version one as it is.

Next week, I’ll talk about how Ekawada balances another of the design forces on my list: “I can’t hold a figure on my hands and turn pages at the same time.”

A look inside Ekawada's design »

Created at: 27.10.2010 17:35, source: the { buckblogs :here } - Home, tagged: Projects Under the Hood design ekawada forces ios string figures

Around the time I was thinking of doing a native iOS app for cataloging string figures, my co-worker (and master designer) Ryan Singer posted this article and video about “designing with forces”. My take-away from it was that you don’t design with a list of desired features in mind, but instead with a list of focused scenarios that describe barriers that you want your application to overcome. These barriers are “forces” that are acting on the space your solution ought to fit into.

Taking one concrete example in Ekawada, I could imagine someone downloading the app and thinking, “I want to learn a figure that looks cool.” I wanted Ekawada to be able to address that user’s goal, and so this goal became one of the “forces” that the app needed to interact with.

My next step was to consider ways that Ekawada could “balance” that force, pushing back usefully on the “what looks cool” question. It was obvious that in order for a user to know if a figure looked cool, they had to be able to see it, so I knew right away that I needed the illustrations of each figure to feature prominantly in the figure list.

The result is the index screen. The thumbnails are small, but I’ve found that they are sufficiently large to give a good impression of what the final figure will look like. I originally had a second view, with images that were 4x as large, which was intended to let you browse the figures by their illustrations. I took a couple of weeks to build it out, and learned a bunch about subclassing and customizing UITableView. Alas, it was a darling I had to kill, though I may bring it back eventually (once in git, always in git, eh?). It turned out that the view was not really much more useful than the index itself, and removing it helped to simplify the UI a bit.

All told, my original list of “forces” included nine different questions and scenarios that I wanted Ekawada to be able to answer, and for this first version I believe I’ve been able to address at least eight of them. I may do some more posts about those other design forces and how I tackled them, so watch this space.

Ekawada approaches—last night I was able to knock off a few more items from my to-do list (and, well, add one or two more items to it), and I’m really excited about how it is coming. I don’t want to give a release date or anything yet, but my list of remaining issues is only about seven items long, none of which should take more than 30-60 minutes to complete. Almost done!