I realized I have been avoiding leaving tips in Foursquare because I didn't have a good way to post them from my website. So today I added the ability to syndicate my posts as Foursquare tips.
I have three different ways my posts can end up as tips on Foursquare:
That last one is interesting, because it doesn't quite map to the normal way tips end up on Foursquare. But I realized that sometimes I write text in my checkins that is actually more like a tip anyway, so I wanted to give myself that option.
I'm probably most likely to use the first option of replying to one of my own checkin posts to leave a tip. Since my checkins appear in my reader, I can actually post directly inline from the reader to go back and leave tips.
I also made the decision to not try to syndicate these automatically, instead I have to manually click the syndication option before my site will attempt to syndicate the post.
Here's what a checkin post on my website looks like:
And here's what that tip looks like syndicated to Foursquare:
Overall this was pretty straightforward to do. The hardest part was dealing with finding the Foursquare venue URL from my own internal storage of my posts for the three different options.
The Foursquare API for this is reasonably well documented (Add a tip to a venue), but there were a few gotchas. It's not immediately obvious from that page that you need to include the access token as a post body parameter, and you also need to include an API version string. These are documented elsewhere in their docs, so it didn't take too long to find, but if you just start out reading the specific API method you want to use, it's not mentioned there at all.
There is also a parameter in the API docs called "url" which is described as "A URL related to this tip" with an example value of "http://blog.zagat.com/taco-survey-results-are-here". At first I was excited that I may be able to link my Foursquare tips back to my website. But every time I tried including a URL in the request, I got back a generic error "bad tips/add request". Leaving out that parameter made the API call work. Oh well.
So hopefully this will encourage me to leave more tips on Foursquare! I find the tips very helpful when I travel, so I'm happy to contribute back to this data set!
At IndieWebCamp Amsterdam I finally implemented unlisted posts for my website! This has been on my list for a while, and is a prerequisite for being able to do fancier things like posting full photo albums to my site, so I decided to take the plunge and finally get this done.
There has been some brainstorming about this for other Micropub clients and servers already, which was a very helpful start.
I made a couple decisions about how this should work on my site that I am not necessarily completely set on. I wanted to document this before I forget and look back at my code months later and think "why did I do it this way?"
On my website, an "unlisted" post:
That last point is very intentional. I don't want to accidentally start treating unlisted posts as a form of access control. I don't want to pretend they are not public. If I had used some sort of longer non-enumerable string in the URL, then it has the risk of looking like a secret URL, and I may be tempted to treat it as a form of private post. Instead, I want to implement private and protected posts as truly protected by requiring the viewer to log in to view them.
I'm on the fence about whether unlisted posts should show up in search. My reasoning is that the act of typing in a search term means you're looking for a particular thing, which is very different from browsing my home page or even tag pages. On the other hand, YouTube implements unlisted posts by making them truly not discoverable unless you know the URL (hidden from search, lists, recommendations, etc). I think I'll leave it like this and see if I'm comfortable after using it for a while.
Implementing this on my site wasn't very hard, because I had quite a bit of ground work laid already. The interesting thing was the cascade effect it had once I wanted to go and actually post an unlisted post. I decided to add a dropdown to Quill, the app I use to post most of my content on my site. However, since many other people use this app too, I didn't want to just add this dropdown if other websites won't recognize the field. So I had to add a mechanism to Quill to ask your website whether it supports unlisted posts.
We have some precedent in Micropub with this kind of thing around querying the Micropub endpoint for which kinds of posts it supports. Quill uses this to disable some of the posting interfaces for servers that don't support those kinds of posts. Micro.blog added this earlier this year so that if you're using Quill with Micro.blog, you will only see the posting interfaces that Micro.blog can handle.
This is the new dropdown in Quill:
If your Micropub endpoint returns "visibility" in the config query, then Quill will show this new dropdown in the note interface!
Special thanks to @sebsel for talking through some of this brainstorming with me during IndieWebCamp!