The event-site-to-rule-all-others has added a couple features that finally start to give it that Flickresque feel I’ve been waiting for! So what’ve we got? Well, check it out:
- Recent Activity – totally useful and something I’ve wanted without knowing that I wanted it!
- Social Network Browsing – Very nice… not as good as Flickr (import my avatar dammit!) but it’s nice to browse my friends’ contacts and be able to add them to my list just by clicking the little grey person icon
- Token-Based Authentication – not so useful for me, but I can imagine that by the next Mash Pit, this will be handy to have
Oh, and I’ve added a Microformats group if you’re interested…!
…and Brian Del Vecchio (hybernaut on Flickr) has created a cool Flickr group for Upcoming event photos (until the Upcoming guys add Plazes and Flickr photo support). Just add your photos from Flickr with tags like upcoming:eventnumber. For example, the Mash Pit tag would be upcoming:47957. Nice!
Factory Joe 
Thanks for the plug, Chris. I’ll let you know when I have something to show, but in the meantime, I’m hoping to drum up enough cross-tagging to get other mashers started. Your link will surely help, thanks!
The most-tagged event so far (for mashers to experiment with) is last week’s BarCamp NY, tagged with upcoming:46797.
Also, it’s great to see the Upcoming.org team getting settled at the Y! and pushing some great new features out.
Note that searches on upcoming:46797 lose the colon.
I was just thinking about the lack of tag=value pairs as a sort of tag, and wondering if/when flickr might support them (microformats depend on these, for example: rel=”blah” etc). It would be good to be able to search for “upcoming:46797” while having the same images all also included in a search simply for “upcoming” without having to add a second unadorned “upcoming” tag to each of them
I mentioned this to Tantek but he dismissed it instantly saying “some people will use ‘location’ and some will use ‘geo’ or ‘loc’ and you can’t have that” but that seems like a poor excuse. Synonym remapping is trivial and has a long history in UIs already.
Tags within tags. Seems inevitable. In fact we can see it’s already here.
Sure sure… but it should be emergent. I see the tag-colon nomenclature as simulating macros… or enabling them. I don’t think standardizing outright makes much sense. We’ve got conventions like to:read, to:try, for:someone, plazes:[hash] and so on… I think the beauty of this is that it’s totally emergent and flat. Anyone can do whatever they want.
Vimeo is great example of this — though perhaps taking it too far by allowing you to use flickr:imagenumber to get photos to show up in your sidebars. I mean, cool, but then you’ve just limited your members to uploading to Flickr.
Allow for free colon-tags but also allow for multiple-platform pairings. We could just as easily use eventful:eventID as upcoming:eventID. It seems this pairing might actually be better and more community specific than trying to give events some kind of UID. With tagging, you get original context and mashup-ability. A win-win sofaras I can tell now.
I’m not saying to enforce any semantics on tags, only to acknowledge the idea of a colon (or “=” whatever) as a separator for value pairs. The semantics can be emergent but it would be handy for tools (flickr, some API hack, whatever) if there were some useful convention for the syntax (only).
We’re experimenting at this point, so let’s try a bunch of stuff and see what works, and what catches on.
As for Tantek not digging tags, the main difference that I see is that tags make it possible for users to create new associations that weren’t imagined by the original publishers or platform owners, while microformats can generally only be implemented by the content publishers. I’ve implemented both, and I can tell you that if the Upcoming.org guys doesn’t dig microformats (I know that at least Lawrence doesn’t), it’s not going to happen. Open tagging, however, makes it possible for outsiders to add metadata, and build something from the metadata.
Um, of course I meant Leonard, not Lawrence. Sorry, Leonard.