Guyub – Konsultan F/OSS

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.

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.?

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.

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.?

My closing presentation at the dedicated MySQL track at ODTUG Kaleidoscope 2010 discussed various techniques and best practices for improving the ROI of developer resources using MySQL. Included in the sections on Design, Security, Development, Testing, Implementation, Instrumentation and Support were also a number of horror stories of not what to do, combined with practical examples of improving productivity.
Increasing MySQL Productivity
View more presentations from Ronald Bradford.