Back in college, one of my favorite games was Star Control for the Amiga. I spent many hours in my sophomore year playing Star Control melee with my roommate Chad and our friend Doug, in my dorm room (on the third floor of Hong-Lim House, Oakes College, UC Santa Cruz).

That year, I had also met Valentin Pepelea at a meeting of BADGE, The Bay Area Amiga Developers’ Group. BADGE was a users’ group (or in modern parlance, a meetup) for software developers who developed for the Commodore Amiga. Valentin worked for Accolade, the publisher of Star Control.

At some point, Valentin learned of my love for Star Control, told me that Accolade was working on a sequel, and asked me if I had any ideas for new ships.

I thought about it, wrote up a few ideas, and sent them off. And to my delight, some of my ideas made it into Star Control II.

In the years that followed, I never game it much thought, but I’ve recently come to realize that the Star Control series had a much larger fanbase than I realized. So for the sake of history, below is the email I sent Valentin. I don’t know exactly when it was sent (I don’t have the actual email archive, just the text I prepared), but it probably would have been Spring, 1991. Following the email is my analysis of what ships seemed to use what ideas.

---

Valentin,
     You asked for some ship ideas at the last BADGE meeting; I've come up
with four.

(Official notice)
I hearby waive all my copyright rights in regards to these four ship ideas.
They may be used in the original and/or modified form without any
obligation to their designer (although I wouldn't mind a mention in the
manual if you do use them; I'm not requiring it, though).

-----cut here------

Ship A:
-------
Shaped something like this (I'm only doing a diagram for the first ship,
since it's the only one whose shape really matters):
                           |     |
                           |     |
                           |     |
                            \ n /
                             [ ]
                             [_]
     This ship's primary weapon is the pair of prongs sticking out of the
front. These are electrical conductors; electricity builds up in one
prong, then jumps across the space inbetween the prongs. If there's a ship
inbetween the prongs when this happens, it gets damaged.

     The 'n' in the diagram is a tractor-beam generator. When the pilot
pulls back on the joystick, a tractor beam comes out of the 'n' and pulls
whatever it can lock onto (such as a ship) toward the ship's prongs, so
that when the enemy ship comes between the prongs, they can be damaged with
the ship's primary weapon.

Ship B:
-------

     This ship's primary weapon is a weak gun-type weapon, sort of like the
Shofixti's gun. It's secondary (defensive?) weapon is a omnidirectional
energy pulse. Basically, when the pilot pulls back on the joystick, a
circle of energy radiates out from the ship, getting weaker the farther it
travels (think of it as the sort of wave you get if you drop something into
a large amount of water). Ships, etc. get damaged/destroyed when the run
into the expanding energy wavefront.

Ship C:
-------

     Primary weapon: some gun of moderate strength (perhaps like the
Syreen's). The defensive 'weapon' is the more interesting of the ship's
capabilities: when the pilot pulls back, the ship is made 'transparent' to
surrounding matter. This means that it can pass through asteriods and
planets; enemy weapons won't have any effect on it, etc.

Ship D:
-------

     Again, the primary weapon can be whatever you want, as the secondary
weapon is the interesting bit of this ship. When the pilot pulls back, the
ship launches of a 'circle of confusion', which homes in on the enemy ship.
When it reaches the enemy ship, it surrounds it and causes the pilot of the
enemy ship to loose control of that ship for a period of time (10
seconds?); picture a ship turning and thrusting randomly.

-----cut here-------

Well, that's all I can think of for the time being. I'll let you know
if I have any more ideas.
-Dave Schreiber

---

It’s been many years since I played Star Control II, so I’ve had to use online Wikis and YouTube videos to refresh my memory as to what ideas appeared where. Let me know if there’s anything I’ve missed.

Ship A proposes a ship with a tractor beam, which the Chmmr Avatar has. The primary weapon idea wasn’t used, though the Avatar has dual “prongs” on the front of the ship (in a much reduced form).

Ship B proposes a ship with an expanding ring of destructive energy, which is the secondary weapon (the “Flame Corona”) on the Kohr-Ah Marauder.

Accolade didn’t seem to use any of the ideas with Ship C.

Ship D proposed a ship with a secondary weapon that disables the other ship. The Melnorme Trader has a weapon, the “stunner”, which seems to be based on this idea.

As I said at the beginning, Star Control was one of my favorite games. Though I never got my mention in the manual, that’s not important. I’m just delighted to have contributed to the series, and hope that Star Control fans had a lot of fun fighting with the Avatar, Marauder, and Trader.

I ran into an interesting bug with Ingerchat recently.  A friend was visiting his family in Denmark, and reported that Ingerchat wasn’t working for him.

I ran through a number of scenarios. Ingerchat didn’t work from overseas? I got a free VyprVPN account, connected my phone to it, and routed the VPN through an Denmark IP. But that worked.

Maybe using the Denmark region or language caused the problem? I set my phone to both, but again, Ingerchat was fine.

I looked in my server logs and noticed that a call to fetch conversations was failing. That call fetches all conversations with unread material after a specific date and time.  It looked like the date was invalid, but my logs didn’t tell me what was going wrong. I put in more logging, and asked my friend to retry.

The next day (this is nine time zones away), he did, and I got another look at the log. The date being sent was similar to “2016-03-02T14:15:28.010 0100”. That looked correct, but I fired up the Node REPL to check, and discovered that that is not, in fact, a valid date string, due to the space before the time zone. Instead of:

2016-03-02T14:15:28.010 0100

it should be

2016-03-02T14:15:28.010+0100

Oops.

So now I had a cause. Since this date comes from the app and doing a release of an iPhone app takes 4-5 days, I couldn’t fix it on the app. I had to work around it on the server. So I did a hack to replace that space with a “+”.

Problem fixed. For my friend. But now the question: why was the date being sent in an invalid format?

I fired up the debugger on the app, set the time zone to Denmark, and found that the “+” was, in fact, being generated. So why wasn’t it making it to the server?

Turns out than in a URL, a “+” is a special character that is used as a substitute for a space. so “2016-03-02T14:15:28.010+0100” is interpreted by the server as “2016-03-02T14:15:28.010 0100”. I was encoding the URL using

 NSString.stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding

But it turns out that’s not good enough! That call does not escape the “+” symbol. So to fix this I needed to add an additional call to escape the “+”. My URL encoder now looks like this (in what is one of the few bits of Ingerchat still written in Objective-C):

return [[string stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding] stringByReplacingOccurrencesOfString:@"+" withString:@"%2B"];

Problem fixed.

 

In Part 1, I discussed setting up a Mechanical Turk (MTurk) survey as the first stage of a two-stage process of getting feedback on a proposed UX change to Ingerchat.

At the end of the first stage, I had a list of 10 people in our target segment. To reach them for the second stage, I used two features on Mechanical Turk: messages and bonuses.

The identities of MTurk workers are anonymized, but consistent. It’s possible to message individual workers who have completed your task, and to pay them a bonus. So I created a followup survey on SurveyMonkey, messaged each worker in my segment, and offered a $1 bonus for them to complete the survey.

An aside: social science researchers often use MTurk to do surveys, but use software such as Qualtrics that provides a “reward code” at the end. This integrates more easily into the MTurk system, but Qualtrics was too expensive for my budget.

For each worker, I game them an individualized “access code” (the last few characters of their Amazon worker ID), which they entered at the beginning of the survey. In addition, as a backup, each participant got a separate web link to the survey (Survey Monkey lets you create multiple web links, and track which ones have been used), though that proved to be unnecessary.

The survey itself consisted of a number of images. Each image was a combination of two screenshots side-by-side, with an “A” above the left and a “B” above the right.  The question was “Which screen do you prefer?”, with the choice of “A” or “B”.

In the world of MTurk, $1 is a fairly high price for a survey. Of the 10 invitations I sent out, 7 responded, and quickly.  In the message I sent, I said they would be paid within 12 hours, but once I saw that an individual had filled out a survey, I used the bonus mechanism to pay them their $1 promptly.

The result? Remember that the question was: should Ingerchat use icons instead of text for the drawing panel? My instinct was that icons would be the preferred choice, but in fact 6 out of 7 respondents preferred the text buttons! So the text buttons stayed. It’s true that 7 responses is not a lot relatively speaking, but with that strong a signal, I decided that was good enough.

My conclusion is that MTurk can be a good research tool for doing some simple A/B testing. The advantage is that you get direct responses from real people, quickly, without coding or shipping a new product (this is especially important with the iPhone environment, where shipping new versions is a heavyweight process). And it’s relatively inexpensive.

The disadvantage is that the MTurk system is cumbersome to set up. MTurk out of the box is not designed to take demographics into account. And while there is some support for dual-level surveys, that support assumes the use of expensive third-party survey software. There’s probably a startup opportunity in using MTurk’s API to automate this process for UX researchers.

Recently I was trying to decide on a UI change for Ingerchat: whether to replace the text buttons in the draw area (“Done”, “Cancel”, etc) with icons. I felt like this would be a good choice, as icons seem to be more fun than text, but I wanted to validate this hypothesis by showing it to some people before implementing it.

The problem is: where could I find people in my target segment (18-24 y/o college students) to validate this change? My solution was Mechanical Turk.

Mechanical Turk (aka MTurk) pays people do small tasks for small amounts of money. Say five cents to determine if a website is spam or not. Though I haven’t heard of UX/UI designers using it for research, many social science researchers use Mechanical Turk to perform inexpensive surveys. So doing a UX survey seemed like a reasonable (and inexpensive) task.

The first problem was that MTurk doesn’t provide fine-grained demographic control. Basically the only choice I had was country where the workers were located. But I wanted to restrict my survey to 18-24 year-olds.

The solution for this was a two-stage survey. A first stage where I ask demographic information, and then a second stage where I perform the actual survey.

You have a number of choices when creating a project in MTurk: “categorization”, “writing”, “survey”, etc. I chose “Survey”. In the survey, I asked a number of questions, such as age, gender, education, app usage, though I was only interested in age and whether or not the person was in college. I asked the other questions to ensure that it wasn’t obvious what I was looking for, to prevent people from gaming the survey. The instructions were generic, and indicated only that I was looking for information on mobile app usage.

But then it got challenging. The tools MTurk provides to put together a survey are, frankly, crude. MTurk has an API, and I get the impression that most people use the API to construct surveys. Without using the API, it’s not obvious at first glance even how to force survey takers to answer all the questions in the survey! After much investigation, I found that by editing the survey HTML and putting a “required” tag on the first choice in a radio field, the question became mandatory:

<label><input name=”Gender” required=”” type=”radio” value=”Male” />Male </label>

For this reason, any question in the survey that needed exactly one answer, I made into a radio button.

Once the survey was done, I put it out for 20 people for 15 cents each, and found it finished in just a few minutes! Of the 20 people who answered, 5 were in my target segment. (Edit: I then did a second stage for 12 cents each, and got another 5 in the target segment). So now it was time to move on to the second stage of the survey.

Continued in Part 2…

In my search for iOS freelance work, I’ve been pleasantly surprised by how many potential clients have been asking for Swift experience. I would have guessed that most clients would have been more conservative: that most would want Objective-C, and a small handful would be bold enough to ask me to develop in Swift.

The reality is that it’s been almost exactly the opposite. Most clients ask for Swift, with a small handful asking for Objective-C.

When I started Ingerchat last November, choosing Swift instead of Objective-C felt like a bold choice. And the tooling was definitely a struggle. But now it looks like it was the correct choice. Not only is Ingerchat well positioned for the future, in a language I like much more than Objective-C, but now I’ve also got a lot of practical experience in a technology that clients need.

Well, time to give this blogging thing a try again. I’ve been reading Keith Ferrazzi’s Never Eat Alone, and as a result have decided to be a bit more visible in the world.

Also, after a couple frustrating Twitter discussions, I’d like a space where I can talk about what interests me and not be limited to 140 characters at a time.

What interests me? Computers. Programming. Startups. Entrepreneurship. LGBT issues. Silicon Valley, including its history. Also theater, politics, cooking, and, of course, cats.