Puzzlepieces – tag ‘api’

so the problem of contact management is the opposite of new, and a lot has improved in recent years, but things still aren’t working for me

my contacts are split like so

primary list of contacts: Gmail. Auto-adding of addresses to the the list is usually good, but I wish it was easier to purge people with who I exchanged one email a long time ago (subject to manual confirmation).

secondary list of contacts: Pidgin. the great instant messaging software includes all my contacts on MSN/WL messenger (including my old account), Gtalk, Yahoo, AIM, ICQ (admittedly virtually unused now). while most of these protocols store the contacts server-side, I have manually combined multiple accounts of the same people, and this is stored in a local XML file. I wrote an XSLT a year or two ago which converts the XML to CSV which can be imported into Gmail. Of course, it is imported manually, doesn’t really deal with Gmail-Pidgin duplicates, and of course lacks the avatars which aren’t stored in the Pidgin local file to begin with.

secondary list of contacts #2: Facebook. Facebook makes for pretty nice contact management, but it is largely a walled garden. For one thing, email is preferable for non-trivial conversation (email works well, isn’t closed, can be better archived and searched, etc.). Facebook makes the process for emailing someone as (1) find their profile (2) find their email in an image and retype (not copy-paste) it into my email application. Ugh. Facebook does have excellent metadata, and importantly, everyone manages and keeps up-to-date their own data. Today I tried FriendsCSV, a Facebook application that converts your friends list to a CSV file which is nice, although they don’t violate Facebook’s terms, meaning of course that email address aren’t included. And thus importing into Gmail creates a million duplicates. The metadata can include the URL to their Facebook profile, but Gmail contacts don’t even support URLs, so the URL is plain text.

tertiary list of contacts: Skype. As I have never yet had a cell phone, I use SkypeOut as my “phone” and so it contains actual phone numbers (in addition to some Skype contacts), a piece of metadata which is largely absent from my other contact lists, but also quite important. Apparently Skype’s own export function doesn’t include SkypeOut contacts, which makes things fairly useless.

There are also various contacts spread out in LinkedIn and many other websites, but few that aren’t also in the previously mentioned lists.

Of course, now that I have a mobile device (currently an iPod Touch, although I will probably be switching this for a cell phone by August), I want to get the data on there, especially phone numbers, since that is the data I will need when I don’t have Internet access. So my current workflow looks like this

1. periodically prune Gmail contacts
2. periodicially import (and then prune) contacts from Pidgin->XSLT->CSV and Facebook->FriendsCSV->CSV
3. periodically delete Windows contacts, and then readd them all by importing the contacts exported from Gmail
4. synch my iPod, fortunately done automatically when charging

Of course, the iPod Touch has a great visual interface, rendered useless by the fact that contacts imported from Gmail through CSV won’t include Gmail’s avatars (and certainly not ones that failed to get imported from Pidgin and Facebook).

One big problem with this is all the manual pruning that is necessary, and largely incomplete, thanks to all the duplicates created. And let’s not even get into the problem that I have many contacts that I don’t know about because they are people who I exchanged email with before Gmail, and will be useless until I import the old emails into Gmail that were on Outlook Express and are now in that format on an external hard drive…

Google now has a Contacts API and Microsoft has their Windows Live Contacts API, although the latter is decreasingly useful as people migrate off Hotmail/MSN to Gmail/Google. And I don’t want to write the apps using the APIs, I’m lazy and want other people to do it.

Plaxo is supposed to be my saviour, synching things across everywhere, keeping data up to date, deleting duplicates, etc. If I pay of course (what?? pay for software?). I wonder if it is worth it…

I want the future now, dammit.

Why Facebook Shouldn’t Fear OpenSocial - I’m supposed to be studying, so of course it’s a good time to do some blogging.

Anyhow, I agree with Josh that the idea that the competition now being Facebook vs OpenSocial is silly. Facebook is doing an absolutely amazingly fantastic job pleasing users, developers, being innovative, and soon, generating profit. Their upcoming “Beacon” plans seem as brilliant as their previous ones. The only bad thing I have to say about them (from a business perspective), is that they have been way to slow getting their advertising products out. In the long run, that may not make much difference.

OpenSocial is not competition in any sense of the word. It’s just a little specification to standardize some web services, which is a good thing. And assuming it gains the traction it is expected (the supporters actually follow through), then Facebook will just join it too, and they haven’t lost anything, really. In fact they’ll have gained additional developers and applications.

Facebook would have to be really stupid to act any other way, and from what I’ve seen, they are anything but. Except their HR, I’m not so in love with that.

Is it just me, or is MySpace sitting on their laurels? Just copying Facebook isn’t going to do it, and besides, they don’t seem to be copying them very well or quickly. I thought being the major player was supposed to count for something, like having resources.

One last comment on OpenSocial… while it is certainly good for developers that there will be a common API, let’s not forget that this simply means it will be easy to have an application run on multiple websites… separately. Having an application that seamlessly uses more than one social website simultaneously will still be an enormous headache. So there’s plenty more to be done there.

Update Nov 5. After reading a few things elsewhere, maybe myspace isn’t doing nothing, they just decided to let Google deal with all their advertising, and hope to make enough from that. But since that will likely be almost all of their revenue, might that not be a bad idea?

Popfly - I heard about this first though email, but it’s all over the web as well. Microsoft has done an amazing job of making it really easy to combine web services, and I only hope that the output itself (something in an iframe?) is just as web malleable as the services it uses.

SmugBlog: Lifetime free Pro accounts to developers - now that is a smart idea

Google Code - Updates: New GData API: Google Base - two of my biggest hopes - Google opening up Google Base, and more wide adoption of APIs based around OpenSearch - all at once. This could be big.

Google Data APIs Protocol - interesting move from Google. I (and others) have thought for a while that combining OpenSearch’s read capabilities with the Atom Publishing Protocol’s write capabilities would create a very powerful API, and that’s roughly what Google is doing here.

It’s great to see the OpenSearch support (a bit - they’re using startIndex, totalResults and itemsPerPage), but I’d like to see them using it more. Some of what they’re doing is contrary to how OpenSearch works (that’s not a problem per-say), as they’re using predefined query names such as q and max-results (and a folder for categories) rather that allowing people to use whichever they want and then specify them in an OpenSearch Description file.

In that same vein, it would be nice to see them make use of autodiscovery, as Atom, RSS, OpenSearch, and others do. Upon first inspection I would say these autodiscovered documents could be OpenSearch Descriptions, but I may be wrong about that.

One interesting thing to note is that they mention how startIndex is 1-based (which is true), and then display an example with a value of “0″. Sounds like DeWitt is right, it does need to handle 0-based numbers too; even Google is making that mistake.

DeWitt brings up some other good points as well.

Via Niall.

Update: Joe Gregorio weighs in

Update 2: Marc Canter (one of my favourite bloggers) finds this linkworthy although I’m always amazed at the spellings my name gets.

Google Toolbar API - Guide to Making Custom Button - aaaargh. I see Google’s recreated the OpenSearch Description format. Nice job guys. Oh yeah, and it also functions as an RSS feed information thingy…. which as far as I can tell, only provides refresh rate…. if they need that so badly they could make that element an extension to RSS/Atom.

It seems like Google’s attitude nowadays is “developers like APIs, and they like XML, so lets create lots and lots of little tiny APIs and new XML formats.” How about a new search API, like for images. The web search API was last updated years ago… . Oh, in case we’re counting, Google now has created XML formats for sitemaps (but they accept RSS and Atom, so what was the point?), homepage modules (why not use HTML, as I’ve written before?), “buttons” (Google Toolbar), 50 (exaggeration) kinds of microcontent (Google Base), etc.

More later when I get back from school and have time to look into this more fully.

Someone please explain to me why the Google Homepage API is a small XML format that includes an HTML bit, instead of just HTML itself?

Okay, so they introduce a few bits of meta data. The links, such as screenshot can be handled by <link /> with rel=”screenshot” and such. The other bits of data can be handled by <meta />, except for the title… there’s already one of those in HTML

Note that I haven’t taken a good look at any of the Microsoft Live Gadgets, Google Sidebar API, Yahoo! Widgets (Konfabulator), or Dashboard.

From metasearch to distributed information environments (Lorcan Dempsy) is a good overview on metasearch in the academic enviroment, and search/metadata APIs.

I looked at a number of the documents, including the first two PowerPoint files and the information on MXG. All worth looking at.

In terms of meta/federated search, those schools (first two PowerPoints) are definitely making leaps forward. The commercial and academic worlds are beginning to learn from each other. The improvements are great, but need to be much greater.

The MXG (.doc file) proposal looks to me like an attempt to make a simpler but not as great version of SRU, which tried to do the same for Z39.50. Which is good news, the authors seem to have the right attitude. I also like how they’ve made levels of the specification, each of which is more complicated, and thus closer to SRU (that last is SRU).

If I were them I’d think hard about OpenSearch. It is a much simpler specification (clearly not originating from the academic world) which accomplishes less than even MXG Level 1. But not that much less, considering how much easier it is to use.

One specific thing that OpenSearch does that the other specifications don’t, is allow search engines to use their own URL variables instead of predefined ones. It looks fairly trivial to me for this concept to be integrated into the SRU/MXG specifications.

Back to academic ‘multi’ search tools, there is UWhub, my personal project. Right now it does web search and image search (just added that this week), but I would definitely like to expand this to include searching within the school’s library, among other things.

Google Maps API - finally, and thank goodness. I haven’t looked at the API yet, hopefully it still leaves a place for Mikel’s fantastic worldKit. Via Google Blog.

Update later June 29: also today, the Yahoo! Maps Web Service. All because it’s the beginning of the Where 2.0 conference. I’m still not sure how I feel about the industry practice of launching things to coincide with conferences…