cgwalters

So Microsoft has released an initial version of their Windows Live integration. If you can't be bothered to read the article, here's the summary interesting to tech folks:

Microsoft’s new Windows Live software suite includes an updated electronic mail program, a photo-sharing application and a writing tool designed for people who keep Web logs.

Taking this point by point:

• Better integration with Hotmail - Presumably things like mail notification. Ok, we have that in the most part; there's notifiers e.g. GMail in Pidgin and the sidebar. I'll talk more about this in a minute.


• Photo sharing - Here we fail currently. The default in GNOME when you plug in a camera is that the photos sit on your hard drive, viewable only by you and just waiting to be lost when you drop your laptop. We need someone to fix this - I had some suggestions for part of that. Conduit looks useful for transferring bits, but doesn't look like it is attempting to solve the problem of helping a normal person get started putting photos online by default.


• Blog tool - eh, we have tons of those. The web editors for most of them are basically good enough anyways. Not important.

Ok, so overall, they win on photos. Now, we have a vision for the Online Desktop (as relates to GNOME/Firefox/Linux/Free Software). Part of that vision is:

Open source doesn't have an agenda like this; our online desktop will be integrated with anything and everything users want to use.

In other words, it's easy for Microsoft to do photo integration because they can just hardcode the OS to integrate with Windows Live Mail or Windows Live Photos, not everything else. A problem we're running into now is that we just haven't yet defined what the framework is for integrating with different kinds of online services. Havoc says:

a) add separate APIs to list, watch changes in, and get named
properties of each type of object; this can be merged into the Online
Desktop data model perhaps. For each type of object the implementation
will be different, since we'll have to talk to or scrape a different
app.

Yes, we need to do this. This API question is an instance of the larger problem I see, which is how do we make the desktop integrate in a generic way with the websites you use, and if you don't yet have a service, how do we make finding one possible?
The mailto: handler we have is basically a perfect example of an application waiting for this integration API. The mailto handler has no way to know whether you use Yahoo! Mail, Hotmail, GMail, or whatever.


Of course, it isn't just the mailto handler. To get the experience right for photos, it's crucial, as I talked about above. Another example is the IM client. What I would love is that on a new account, if I log into GMail, the IM client automatically appears, configured to use Google Talk. It must likewise work for Yahoo! Mail.


What I would really like to do from this point on in the Online Desktop effort is to for each feature we add, try to integrate with at least 2 services in the feature category. As most programmers know, there usually isn't a big difference in effort between supporting the case of 2 versus an arbitrary (but reasonable) N.


So, back to the API. Actually first, let's think about what the user experience should be instead of starting by coding the D-BUS API we made up in our head. Here's a screenshot from a related application, Mugshot:


Now, Mugshot's list of "websites I use" is subtly different in that right now it's really "websites I use that my friends will be interested in". For example, the desktop should have E-Bay integration (bid watching apps) but I'm dubious about the value of stacking things I'm bidding on to my friend's desktops. There is also the technical issue in that honestly right now it's a lot of work to add a service to Mugshot; a lot of that work is in the stacking support.


However, the more I think about it, the more I do think it makes sense to ultimately have a UI similar to the Mugshot one. From this flows some technical decisions such as that we're storing it online, we can use the data model to retrieve it. We do need to figure out the problems I mentioned above - how do we have private services? And how do we scale the UI to support a long tail of services? The current list is already fairly big, and if we added even a few more photo sites and such it'd be unwieldy. Also, how do we encourage the user to list (and maintain!) their infos? It needs to be a key part of the experience. They need to understand why we want say their EBay or Last.fm username.


One other detail - passwords - some people thought Mugshot stores your passwords to retrieve data. It never has, and likely never will. Though if we wanted to do social network importing from other sites, we'd probably need to do that. Sigh. Anyways, ignoring that: In my opinion, we should concentrate on unifying the logins outside of Firefox first. As Alan Cox mentioned, there are some gotchas in doing syncing to the web browser. If we can fix the few key programs (mail,IM,photos) to share your Google and Yahoo! logins, we'll be doing pretty well.


So the executive summary is here - I don't feel we have a coherent answer yet for this problem. Responses welcome if you have other ideas - it's actually a complex and hairy problem, involving a big cross between desktop apps, the web browser, and web sites, which is why it isn't solved yet.