Conversation manners for geeks

Ranting today about a behavior pattern that shares a lot in common with mansplaining: interrupting someone whom you’ve just asked a question.

I just came back from Thanksgiving with my blood-family, and it explained to me a bit more why my parents can make me so crazy: they interrupt each other, constantly, over everything. It’d be sort of adorable if it didn’t generate so much frustration between them, when it could be easily solved by shutting the fuck up and practicing good conversation manners. I got it from them — I used to interrupt people constantly. I think I stopped a few years ago when I learned to unclench my butt, stop trying to top one story with another, and listen to what was actually being said. I’m now a lot better at letting people say their piece.

So I’m working away, and someone asks me a question about a MySQL thing. I was just about to give him the critical bit of the answer when he interrupted to repeat his base assumption, and the nice little train of thought happening in my brain hit a buffalo.

I paused and said “Please let me finish” and steamrollered on through, but then with a twinge in my gut like “was I just shockingly rude?”, which I’m not sure most folks experience.

Assorted style thoughts, marginally more coherent than STFU:

  • Interrupting is saying to someone that you’re not actually interested. Don’t do it when you’re the one asking for their time.
  • Read the docs.
  • Speak in sentences that have endings. Use natural conversational pauses.
  • Technical conversations are hard. Listen.
Posted in Rants | Leave a comment

Maintaining your own code

In continuing my mobile OTR work, I’m confronting a lot of the same issues that every dev team faces. This time, though, I am an army of one. Keeping my own work straight has brought me to a couple of best practices:

  • Commit early and often. Git was made for this. When I first started out as a developer, I was using SVN, and commits to even a working branch were considered a big deal — committing a work-in-progress that didn’t even necessarily run without barfing errors was unacceptable. With Github and Bitbucket on the table, and git and Mercurial both allowing local commits against a personal working copy with the option to push later, you can make as many mistakes as you need to without damaging your trunk.
  • Diagram dependencies as simply as possible. The dependency chain to build this app looks something like this, from highest-level to lowest:
    • JavaScript UI (jQuery, jQMobile, or maybe xUI)
    • JS class that connects to OTR library
    • JS class that connects to XMPP library
      (I’m using Strophe as the world’s simplest XMPP connection library for JS. Works fine in a dev context. For XMPP running on the device, it seems wiser to connect to a native library that correctly positions the phone as its own origin server. So eventually, I get to write wrappers for Smack and xmppframework.)
    • Phonegap JS
    • Java plugin for OTR library
    • Java plugin for XMPP library
    • Obj-C wrappers for OTR and XMPP on the iOS side! (Lest we forget…)
    • Phonegap compile-time includes, to make it all run.
  • Distribute your non-code reference material. Delicious is a good link repository for the many, many Stack Overflow results and Phonegap tutorials that I’ve googled in the last two weeks. I also have a /ref directory in my code base that contains some searchable text files with things like sample XMPP stanzas. Beats re-running a simulator or re-searching for the same result, or littering comments with examples.
  • Find out the distribution terms of any libraries you plan to include. This might be painfully obvious, but I spent a good hour facepalming after a conversation like this:
    Someone on IRC: You should really use libpurple as a connection manager to support multiple accounts.
    Me: Great idea! I’ll get right on that. *download read design design*
    Someone else: Apple doesn’t allow apps with the GPL license in the App Store, and libpurple is GPL’d, so using it would disqualify you from distribution by Apple.
    Me: Well, then I guess this will only support exactly one XMPP account, because I have far too much else to do to reinvent a multisession manager.
    — fin —

    There’s a tangent conversation to be had here about why, exactly, having the option to accept virally-open source code is an ideological problem for Apple. They do permit open-source apps under less aggressive licenses, and the GPL doesn’t prohibit charging money for one’s app as long as it’s also distributed for free, so no problem there. I can think of two possible explanations: they want to insulate themselves from any possible interpretation that the App Store itself would be included in a GPL’d package, and, more likely, FLOSS sentiment doesn’t jibe well with their models for profit and control. And we want to develop for the App Store nonetheless because that’s where the user base actually is. Well played, but a frustrating barrier to the self-same dev community that’s so enthusiastic to contribute to the market.

  • Know the limitations of your toolchain. Phonegap has a pretty great API for phone events. It does not have an XMPP library — many people on various Google Groups have requested one. Personally, I think it makes sense that it doesn’t, since sending and receiving IMs isn’t a common device feature in the same context as a tilt sensor or a received-call event. It’s just necessary to find out from API docs and READMEs whether your new tool can actually solve the problem at hand.
Posted in Projects, Software | 5 Comments

Mobile, encrypted, and… cross-platform?!

That mobile chat application I was contemplating a few weeks ago has officially taken over my brain. I’ve continued playing around with Gibberbot source, but I just can’t get past the sense that this tool should be unavailable to the iPhone crowd just because no one has time to develop it specifically for iOS.

Furthermore, the issues I’ve taken on in Gibberbot are things where I’m not sure what’s the best way to suggest patches, like the XMPP library. If you see an issue in an included library, is it best to switch to that project and make a patch for the include rather than fork it within your main project? Seems right, but that rabbit hole runs deep.

I’m currently trying on a Phonegap-based approach. I know how to write an interface in jQuery, and including the Java port of OTR as a plugin for Android no longer seems so scary. The Java port contains an interface called OTRCallback that offers to make the OTR functions available to whatever you choose to use for XMPP (I’ve got an installation of JSJaC semi-working), and that looks pretty awesome.

The scarier parts are these. One: redeveloping plugins for the other operating system(s) you choose to support with Phonegap (after all, the whole point is to spend less time becoming an iOS developer!) Two: figuring out whether the security features of any XMPP library for JS are appropriate for what is, at heart, a better-secured-communications platform.

Currently I’m stepping through an issue where XMPP from JS needs a source URL. Internet lore holds that Phonegap may be able to simulate a self-originating request (but don’t hold me to that; that’s just what I got from a couple of hours with Google Groups!) but I’d rather save hours of reloading the Android emulator and develop in a desktop, where request origin matters, and where I’m using a Mac running Apache. I’m unable to lock down a cogent description of whether Phonegap emulates its own server. This may kill the whole project, but it’s certainly taught me a whole lot about XMPP and Apache along the way.

Onward!

Posted in Projects, Software | Leave a comment

Encrypted mobile chat?

I’ve been longing for a usable mobile chat service that lets you send encrypted messages to folks using OTR with a desktop IM client like Adium. The Guardian Project is a (NYC-based?) group that produced Gibberbot to solve this for Android users.

I do use an Android phone, for the moment, but I’ve been having a lot of trouble running Gibberbot. Those of you in the iPhone camp are out of luck — it’s cleartext all the way down. Platform-dependence really bothers me, as a Web developer — and I’ve given the ol’ college try to dropping everything and learning a bit of iOS development, but honestly, it would take me several years and rather a lot of career-redirection to gain those chops.

So, what about media that runs on all devices?

The mobile web might be able to save you here, though the approach lacks the one-touch appeal of a real app. There are real security problems to solve, and you’d be better off starting from a proxied connection via Tor. Marco has done interesting work packaging Tor for iOS, and the Guardian Project takes care of providing Tor for Android.

I’m taking a stab at a web app that’s just as pleasant to use as a native app solution and runs on any platform. App lockdown is a serious problem on Android, and we need it before the platform wars end.

Posted in Projects, Software | Leave a comment

Is AirTrain Broken?

When Audrey last came to visit, AirTrain service from JFK was down. We decided there needed to be a one-shot website that would make more sense than the airport “transit alerts.”

Here’s Is AirTrain Broken?, a simple scraper for NY/NJ Port Authority alerts. I wrote it in Python using Beautiful Soup to handle their HTML and web.py as a (remarkably elegant) web framework.

It’s on Github, if you like.

Posted in Projects, Python, Software | Leave a comment

Bract

Bract is a lacemaker, finding geometric forms in the interiors of shapes.

I’m using Processing to define a vector shape and then find a graph of polygons that exactly fills the shape. These polygons can be used to define paths for laser cutting, CNC cutting, or any other form of vector-controlled creation.

A bract, in botany, is the beginning of a new branch — the leaflet that diverges from a stem. Bract is designed to follow the player’s touch, adding new polygons to the graph as they draw.

Github repository for the project is here.

Posted in Processing, Projects, Software | Leave a comment

Gamification vs. Play

Last night, I went to a panel discussion that a co-worker at Etsy was kind enough to tell me about, called “Can Gamification Advance to the Next Level?” This was at the Game Design Lab at NYU Polytechnic.

Couple of well-known game designers on the panel: Frank Lantz, the creative director at Zynga; Nick Fortugno of Playmatics; Greg Trefry of Gigantic Mechanic. Wade Tinney of Large Animal moderated.

The discussion quickly got heated, but they brought up some really neat points for anyone thinking of new features or tools (toys?) to boost interaction. I’m thinking and writing here in a web/mobile context, but interested in applying it to in-person and site-specific game structures.

  • First of all, imposing a credit or goal system on a product does not make it a game. Lots of companies right now are trying to imitate Foursquare’s success by adding checkins/badge-based rewards to their product. It’s not working, because the “game” aspect of the product is not giving the players enough control over their actions to find it worthwhile.
  • People play as an escape, not a simulacrum. Wish I could remember who said this: “People play Farmville because they don’t have to farm actual crops.” There have been various efforts to gamify “boring” tasks, like a task-manager called Epic Win that’s a Zelda-like take on household chores. The reason why this kind of app is not completely endemic, Nick pointed out, is that this structuring of “not fun” tasks with “fun” concepts actually strips the real-world task of any enjoyable qualities it once had. At an extreme, it actually robs you of your “real” life experiences, forcing you to see an activity like doing the dishes as inherently needful of reward. So you might play the game for a little while to see how it affects your productivity, but you’ll probably tire rather quickly of caring about the game’s artificial reward structure and go back to plain old-fashioned procrastination.
  • Incentive programs such as frequent-flyer mile schemes and Groupon are also not exactly games (using the panel’s collective understanding of what a game is; more on that later), but they take advantage of cognitive-psych principles and economic reward schemas to be somewhat gamelike; they can be successful as long as the rewards are material and meaningful to the players.
  • From this I conclude: People get bored when they decide there’s nothing new to discover. I encountered this idea years ago, probably in a piece of Douglas Hofstadter’s writing on then-current AIs: humans get bored, not when they have exhausted a parameter space, but when they think they understand the ruleset and there are no new rules to discover. I don’t know if that holds up in the face of addictive point-accumulation or gold farming or Farmville, since it doesn’t account for the perverse reward psychology of gaming as procrastination behavior.
  • People can form significant parts of their identity around playing certain types of games: console games, SF Zero, World of Warcraft… the panelists didn’t really go into this, but I believe what these games have in common is a relatively loose narrative plus a really strong social component.
  • Activities which are unexpected and delightful become personally meaningful. Wade showed the famous video of Volkswagen’s piano staircase experiment to kick off this point. It says a lot for their marketing that I remember this as a Volkswagen effort, though it was actually co-produced by The Fun Theory.
  • Arbitrary incentives become antagonistic, the opposite of personally meaningful. People, especially within organizations, can see instantly when they’re being talked down to and fed incentives that they don’t care about. (I can’t come close to covering the literature of motivational psych here.)
  • Finally, an unresolved question: what makes something a game, as opposed to an incentive framework? Is narrative necessary? What about rules? I didn’t hear a strong definition from the panel, though I walked in a bit late. I’m still thinking about it, but I’ll try this on for size: “A game is a fantasy participatory experience constructed to be different from the player’s normal activities.” That kernel of “realness” in “ordinary activities” is what provides the delight in the staircase experiment, and the existential panic in a plotline like The Truman Show or The Matrix, wherein you discover that what you took for granted as real is actually a simulation by someone bigger than you.

My takeaway from all this? Designers of games, and companies whose products use game principles, will be best rewarded if the game invites experimentation, novelty, and emergent behavior.

Build in flexibility so that the game becomes personal.

The views here are mine, not necessarily those of my employer.

Posted in Blog, Game Design, Talks | Tagged | Leave a comment

Jared Tarbell’s living objects

I saw Jared Tarbell speak tonight at Geeky By Nature in NYC. His topic was “The Computational Landscape”, which I thought would imply the present state-of-the-art in HTML5 vs. Flash, <canvas>, SVG, and Processing — every technology we have for making vector drawings in a browser.

Not so. Jared was talking about the literal (notional) landscape, the blank slate placed before anyone who sits down to write some code.

Most strikingly, he spoke about objects — in the sense of object-oriented programming — having lives. Along with life, they have age, and death. A dying node will attenuate from the image and stop drawing itself, while surviving threads almost but do not quite take its place.

As someone who invests macro-scale physical objects with personalities and anthropomorphic habits, I was prepared to think of physical inanimate objects as having lives, but the thought of constructs themselves having lives and trajectories was new and startling. I’d love to play with this idea in my work.

Jared’s one of the original forces behind Etsy, and a brilliant computational graphic artist. Check him out here.

Posted in Blog, Generative Design | Leave a comment