privatesquare

I’ve been working on, and testing out, a new thing for the last couple of weeks. It is called privatesquare. It is a pretty simple web application that manages a private database of foursquare check-ins. It uses foursquare itself as a login service and also queries foursquare for nearby locations. The application uses the built-in geolocation hooks in the web browser to figure out what “nearby” means (which sometimes brings the weird but we’ll get to that later). On some levels it’s nothing more than a glorified check-in application. Except for two things:

First, when you do check in the data is stored in a local database you control. Check-ins can be sent on to foursquare (and again re-broadcast to Twitter, etc. or to your followers or just “off the grid”) but the important part is: They don’t have to be. As much as this screenshot of my activity on foursquare cracks me up it’s not actually representative of my life and suggests a particular kind of self-censorship. I don’t tell foursquare about a lot of stuff simply because I’m not comfortable putting that data in to their sandbox. So as much as anything privatesquare is about making a place to file those things away safely for future consideration. A kind of personal zone of safekeeping.

Second, privatesquare has its own internal taxonomy of event-iness. It is:

  • I am here
  • I was there
  • I want to go there
  • again
  • again again
  • again maybe
  • again never

The first item maps the easiest to foursquare’s model of “checking in”. It is what it says on the tin. The second is the thing that you can’t do on foursquare but everyone does anyway: Checking in after the fact if only to have a personal record of things you’ve done. This just makes the act explicit. The third is not unlike the “lists” feature that was introduced on foursquare, last year. It is also the one flavour of check-in that is not forwarded on foursquare. I suppose I could figure out how to add things to a list, but I haven’t yet.

The last four are a long overdue love song to Chris Heathcote and a plaintive desire for something like the Dopplr Social Atlas (not to mention Dopplr itself) but one that isn’t held hostage to the seeming neglect of its parent company, Nokia. Once upon a time, I went to Helsinki for Important Business Meetings ™ involving Flickr and Nokia while Chris still lived and worked in Finland. I asked him where I should eat during my stay and he sent back a long list of restaurants (all lunch places, I think) each flagged as “again”, “againagain” and so on.

The Social Atlas was a feature added somewhere around year two at Dopplr and is a list of places to eat at, stay in or explore. Places are added by the users and organized by city. It remains a lovely example of how to do this sort of thing though there’s not much going on there these days. You can flag as place as somewhere you’ve been, somewhere you like but not someplace you dislike. Which always seemed like a shame because I would find it helpful to know that someone I know and trust dislikes a restaurant in London as much as I despise Herbivore, in San Francisco.

Chris’ is a genius classification system. It does not get lost in the weeds of weird similes and absurd metaphors (wine tasting, anyone?) and by and large captures the experience of asking someone where you should go to eat in a place you’re not all that familiar with. It is also entirely bound to the relationship of the person telling and the person asking. It is not a recommendation engine.

It assumes that although two people would both do something again, or do it enthusiastically (“againagain”), they are just as likely not to do the same thing. Those details are left out of the equation (read: the computer) because it will never be able to account for the subtlety and history of experience between two people.

The “again” ratings (markings, like on a tree?) are an odd lot in that they don’t go out of there way to distinguish themselves in time. Is it just an indication that you went there some time in the past and want some record of the event? Or does it mean that you wait to check-in until you’ve decided how you feel about it? Or do you check-in and then say whether it was good or not?

I am very consciously punting on these questions for the time being in order to see how the thing actually gets used and what I find myself wishing it did. I suspect that most of the confusion that may be generated by these kinds of blurry and overlapping assignments can be overcome by displaying dates and times clearly.

It is worth nothing that privatesquare does almost nothing that foursquare doesn’t already do, and better. privatesquare is not meant to replace foursquare but is part of an on-going exploration of the hows and whens and whys of backing up centralized services with bespoke shadow, or parallel, implementations of the service itself. It is designed to be built and run by individuals or as a managed service for small groups of people who know and trust one another.

privatesquare remains a work in progress and I am not planning to run it as a public service any time soon but it is available as an open-source project, on Github, that you can run yourself:

http://straup.github.com/privatesquare/

The documentation and installation process still remains out of bounds for most people who don’t self-identify with the nerd squad but that will sort itself out over time. For what it’s worth my copy is running on insert a vanilla shared web-hosting provider that can run WordPress here so that’s a promising start, I think.

The site is built on top of Flamework, which is a whiteroom re-implimentation of the core libraries and tools that a bunch of ex-Flickr engineers used to build Flickr, the same way that parallel-flickr is. Meaning that some part of all these projects is just putting Flamework through its paces to find the stress points and to better understand the hows and whats of the process (installation, documentation, gotchas and so on) should be. And like parallel-flickr “it ain’t pretty or classy (yet) but it does work.”

Here’s an unordered list of the things privatesquare still doesn’t do:

  • Sync with the foursquare API. For a whole bunch of reasons you might find yourself checking in to foursquare using another client application. privatesquare should be able to fetch and merge all those check-ins that it didn’t handle first.

  • The “nearest linear” cell-tower problem. This is one of those problems that gives credence to all the hyperbolic hand-waving done by companies driving around mapping latitude and longitude coordinates for wifi networks. Without this data determining geographic location for a web application running on a phone is often handled by assuming that whatever cell tower your phone is connected to is “good enough”. Sometimes it is but just as often it’s not. You have a line-of-sight, a signal, back to a cell tower that exceeds the maximum radius in which to query for venues. Because your phone thinks you are somewhere else you always end up falling outside the hula-hoop of places that are actually near you.

    The map that’s displayed with venue listings (there’s a screenshot at the bottom of this post) is one possible alternative. As I write this the map isn’t responsive. It’s just there to try and help you understand why a particular list of places was chosen. Eventually you should be able to re-center the map to a given location and use that when looking up nearby venues, for those times when your web browser can’t figure out who is on first by itself.

  • There is no ability to delete (or undo) check-ins.

  • There is no ability to add new venues. Nor is there any way to record events offline or when you don’t have a network connection. I’m not sure whether either of these will ever happen. At the moment there are just too many other things going on. Beyond that I sort of like the fact that privatesquare doesn’t try to do everything.

  • There is no way to distinguish duplicate venues (same name, different ID).

  • Export, which is probably the single most important thing to add in the short-term. This includes a plain old web view of past check-ins.

  • Pages for venues, though I’m really sure what I was thinking when I was blocking out this blog post and wrote that. It’s probably related to what I wrote about cities (below) and the idea that the really interesting aspect of a venue page is seeing a user’s arc of again-iness for that spot over time.

  • Pages for cities. The other nice thing that privatesquare does when you check-in is “reverse geocode” the location of the venue and store the Where On Earth (WOE) ID of the city the venue is in. Which will make it possible to build something that looks like the Social Atlas. For example, if you were going to Montréal I might send you a link to all my check-ins in that city (WOE ID 3534) tagged “again”, “againagain” and “I want to go there”.

In a way privatesquare is just the foursquare version of parallel-flickr: a tool to backup your check-ins, albeit pre-emptively. Which is sort of an interesting idea all on its own. The differences between the two applications are that parallel-flickr doesn’t let you upload photos (yet) and privatesquare doesn’t really provide any mechanism for sharing your check-ins with a restricted set of users. Currently, it’s all or nothing (read: “nothing” because the code forces you to be logged in before you can see anything).

I am also thinking about forking; piggybacking; hijacking (piggyjacking?) some or all of the work that Stamen has done with the Dotspotting project. For two reasons: First they are both built on Flamework so it ought to be possible to make them hold hands without too much fuss. Second, there’s a nice un-intended feature in the way the code for browser things and the code for database things handle the data that people upload to the site: HTML tables.

In theory (and I haven’t tested this out yet) anything that can generate an HTML table, with the relevant semantic attributes, and send it to the browser along with the relevant JavaScript code will be able to take advantage of all the lovely display and interaction work that Sean Connelley and Shawn Allen did for Dotspotting. Just like that!

The reason this all works is that when we started writing Dotspotting it was during a time when Flamework was still pretty green and lacking any code for doing API delegation or authentication. Rather than trying to shave that particular yak we simply opted to use the HTML sent to the browser and jQuery as a kind of internal good-enough-for-now API.

Once it’s sorted for privatesquare it should be easy enough to swap out the table parsing code with proper API calls, now that Flamework has its own API delegation code, and then it could be dropped in to parallel-flickr as an alternative view of your geotagged photos.

It’s all still magic-pony talk and none of it addresses mobile (tiny) web browsers or anything but a pretty conventional linear paginated view of the data (no clustering or other fancy stuff) but, still: This pleases me.

In the short-term I’m going to continue to focus primarily on the data input side of things trying to make it as easy and fast as possible to record the data along with the simplest of CSV or GeoJSON exports, so that you could at least look at your data in tools like Dotspotting or Show Me the GeoJSON respectively.

And if I can get that part squared then it also might be possible to re-use some of the same work to make things like Airport Timer easier since the two projects are each a kind of side-car to the other, when you stop and think about it.

Quiet But Not Quiescent

Judge not the less yammer-y state of the studio blog to indicate that there is nothing worth yammering about. It’s just that the clang of steel caressing code has been going on and that in great measure, too. Some of you may have glimpsed and grinned at the fantastic electronified edition of the paper Drift Deck that we developed a couple of years ago. That’s right. We’ve added *batteries to the Drift Deck and it’s fallen into the *app well..it’s an app which is fantastic because it means the last remaining physical card editions can become properly *artisinal and the electronic battery editions can spread the sensibility of the Drift Deck concept to the rest of the world.

Release is imminent. Prepare ye iPhones. Hop expectantly from foot-to-foot. More news in a short while, including linkages to downloadables. In the meantime, check out the new Drift Deck webified “page” and the fantastic roster of hammererers that batteryified the ‘deck.

..And then — onto the next thing here. It’ll be quiet a little, but good things are baking in the kiln, rest assured.

*Willow next. The superlative friendregator for the discerning social being.
Continue reading Quiet But Not Quiescent

Locative Play

Ian Bogost‘s and his Persuasive Games operation have introduced an iPhone game called JetSet
— a curious little gem that situates specific locations as the enforced zone for game play.

Very interesting play mechanic — a location-based game that you can basically only play when you’re at any one of a huge list of airports in the world. And, your score (if it’s good enough..) goes up on that airport’s leader board. The only way to play, say — Madrid Barajas International Airport is to go to Madrid Barajas International Airport. You have to physically be at the airport to play and get on that airport’s leader board, get that airport’s “souvenirs” (this game’s equivalent of blue gems), and so forth.

Oh, the game — okay, you’re a security screener dude screening passengers, and the "prohibited" list changes so you’re constantly having to figure out what to remove from the traveler, from the mundane — shoes? hat? water bottles? coffee? to the obscure — bacon? rocks? snakes? robots? pudding cups? hummus? There should be a way to put leader boards up along on my Dopplr page and Dopplr personal annual report!

It’s simple and an exciting play mechanic that’s intimates at the near future of all kinds of interactive experiences as the digital continues to leak out into the real world. Nicely done.
Continue reading Locative Play

Red Light, Green Light, Go!

Vis-à-Vis is a series of multi-player games that utilize physical body movements to control the point of view in a first person perspective computer game. The framework uses a TabletPC, held in the player’s outstretched arms, to display the point of view one would normally see while playing a computer game.

To rotate, tilt, and move the games’ virtual camera, players need only to do so physically, as sensors measure all changes in movement.

The games, entitled ‘Red Light, Green Light Go’, ‘Dodgeman’, and ‘Act Normal’, are based on children’s playground games. Vis-à-vis explores the timeless fundamentals of games inherent to both digital and and classic play. Each game uses on our “reverse Turing Test”- one player tries to behave as much like their fellow A.I. characters as possible, while the second player attempts to discern the human player from the bots.

Arguably the most compelling experience provided by a Vis-à-vis game is that it not only requires the player to get off their couch, but to literally become physically active. The criticism that electronic games compel people to stay in their living room does not apply here.

The first game developed is a Vis-à-Vis version of the children’s game “Red Light, Green Light, Go”. Requiring a minimum of two players, the “Runner” player (along with 7 AI characters) tries to sneak up on the “Traffic Cop” player. That “Traffic Cop” starts and stops the approach by yelling “Red Light” or “Green Light”. This scenario plays out as a sort of reverse Turing test as the “Traffic Cop” spins and tilts their view in an effort to decide which of the approaching characters is indeed the human player.

Other possibilities range from numerous versions of playground games, roll-playing games, and location-based games. The multiplayer functionality provided through the Torque Game Engine allows up to 32 people to play in real-time from anywhere in the world.
Vis-à-vis games made its first appearance as part of SIGGRAPH’s Guerilla Studio on August 2nd 2005.

http://www.we-make-money-not-art.com/archives/006610.php

http://www.wired.com/news/games/0,2101,68548,00.html

Vis-a-Vis write-up

Technorati Tags:


Continue reading Red Light, Green Light, Go!

Battleship:GoogleEarth (a 1st Life/2nd Life mashup)

I’ve started working on a bit of summer laboratory experiment to see how Google Earth could become a platform for realtime mobile gaming. (Follow the link on the Flickr photo page to the URL you can load in your Google Earth client to see the game board in its current state.)

With Google Earth open enough to place objects dynamically using the tag, a bit of SketchUp modeling and borrowing an enormous battleship model that construction dude uploaded to the SketchUp/Google 3D Warehouse, I started plugging away at a simple game mechanic based on the old Milton Bradley Battleship game.

Battleship, for those of you who never played, has a simple mechanic — two players set up their navy ships on a peg board, hidden from the other guy. You take turns plugging a peg into your side of the board, with each peg hole designated by a letter/number coordinate grid. When you plug a peg in, you say where you put it — E4! If your opponent has a ship in that coordinate (or part of one, actually), they say, sorrowfully, “Hit!” and you register that peg hole with a color to indicate a hit. If not, you just put in a neutral peg to remind you that you already tried that spot. The game continues into one player has sunk all the other guys ships.

The mechanic I’m experimenting with is simpler. One person places their ships using Google Earth and the other person goes out in the normal world with a mobile phone, a GPS connected to the mobile phone. The phone has a small Python script on it that reads the GPS and sends the data to the game engine, which then updates the Google Earth KML model showing the current state of the game grid. When the player who’s trying to sink the ships wants to try for a hit, they call into the game engine and say “drop”. The game reads back the coordinates at which the “peg” was dropped and shortly thereafter, the other player will see the peg appear at the coordinate it was dropped. If the peg hits one of the ships, it’s a Hit, otherwise it’s a miss.

[ad#ad-4]

Next Steps
As I continue developing the engine, I’ll probably have the game engine let you know when you call in to do the “drop” whether it was a hit or not, or the opposing player can text or call to indicate the same.I want to put in a “ping” command for the call-in battleship control center to help whoever’s wandering around in the world navigate a bit. (Although the game is only really practical if you limit the boundaries over which it can be played.)

I need a lighter weight battleship — the current SketchUp model is too large, in data size terms and takes too long to initially load (although, it only needs to be loaded once.)

Goals
* Experiment with “1st Life” action reflected in “2nd Life” worlds (verso of the folly Ender suffered in Orson Scott Card’s simply fascinating Ender’s Game
* Learn KML
* Learn SketchUp
* Learn Python for S60
* Make a mobile/pervasive game in which one has to move around in order to play Equipment
* Google Earth client
* Apache+Tomcat+MySQL (Java and JSP on the server-side computer)
* Nokia N70 and a little Python app to connect to the Bluetooth GPS and upload the data to the server
* Voice Application (for the battleship control center to drop/ping)
* SketchUp Time Committed
* About 2 days learning stuff, and 1/2 a day programming the computer to make it do things.Why do I blog this?To keep track of and share the near future laboratory experiments I’m doing this summer.

Technorati Tags: , , , ,