MyPicasaPictures Part 2: Rolling up my sleeves, sketching out a Spec

I find that the more time I spend detailing exactly what features and behaviours I expect from something I’m building, the faster and more successfully I’m able to actually build the thing I’m seeking.  This is a truism of technology development (and an old boss would say, of project management), whether you’re a one-person shop or a team of thousands.  However, it’s a lesson each person has to learn and digest to be able to figure out exactly what works best for them.

mini “Functional Spec” for MyPicasaPictures

Here’s a list of the features I’ve dreamed up so far, and the priority (1=high, 3=low) I’m personally assigning to them:

  • Pri1: upload a currently-selected Picture to (the default, if such a thing exists) folder/album/library (or whatever Google calls its collections) on the photo-sharing server
  • Pri1: enumerate and select the working folder/album/library when there are multiple folders to choose from
  • Pri1: authenticate to remote server
    • Pri3: cache remote server’s credentials securely, using DPAPI
  • Pri2: view names and/or thumbnails of pictures already in the selected remote folder/album/library
    • Pri3: enumerate and present the other metadata associated with each picture (e.g. Tags) and each folder/album/library
  • Pri2: write the code so that it abstracts the service-specific logic – enabling future versions of this app to easily add support for other server-based Photo sharing sites such as Flickr, Windows Live Spaces, Facebook, etc.
  • Pri2: Assign a new tag for a photo that has already been uploaded
    • Pri3: enumerate existing tags from remote server, and allow user to assign tag(s) from that set (along with new tags not part of the existing enumeration, in a mix-and-match formation)
  • Pri2: collect tags from the user for photo about to be uploaded, and submit the tags simultaneously (if supported by the photo-sharing service) with the upload, or right afterwards (if simultaneous isn’t supported)
  • Pri2: upload a batch of photos all at once (i.e. entire contents of a local folder that has been explicitly selected by the user).  Note: this may not be possible, as buttons or other controls cannot be added to the existing VMC UI.
    • Pri3: pick & choose a set of photos to be uploaded (e.g. subset of a single local folder, subset of photos in > 1 folders)
  • Pri2: delete existing photos in online albums (one at a time)
    • Pri3: delete existing photos in online albums in a batch (e.g. a subset of one album, or a subset of photos that span multiple albums)
  • Pri3: resize the photo(s) before they’re uploaded
    • Pri3: enumerate and present “spinner”-based choices control for the user to select one of the photo sizes “supported” by the remote server (if there’s any sort of default/preferred sizes that the server chooses to assert)
  • Pri3: rename the to-be-posted picture where another of the same name already exists on the remote site

Questions that keep coming to mind

  1. How do I implement client-side support for a SOAP- or REST-based Web Service in MCML apps?
  2. What “model” should I aspire to use for this kind of development? [cf. Gang of Four]
  3. Where will the entry point(s) for this add-in be located?  Steven Harding crystallized a suspicion I had been gathering on this topic – “Unfortunately, you can’t add anything to an existing Media Center interface.  So there’s no “Send This Folder to Picasa/Flickr” possible.”
  4. What exactly is a Start Menu Strip, and why are only two of them allowed at one time (and why does VMC seem to “punt” the oldest one out unceremoniously when a third is added)?
  5. What is the real difference between a VMC application and a VMC “background application” (other than the obvious visibility issue)?  i.e. Under what circumstances would I want to use one approach and not the other?
  6. What does “running on the public platform” mean in terms of (a) additional functionality that’s possible, and (b) what kinds of security restrictions are lifted on apps running on that “public platform”?
  7. If the More Information (“i” button) is so strongly discouraged, how should we provide that kind of “added functionality” in context of the application, ONLY when the user wants it, and WITHOUT cluttering up the UI in a way that makes it harder for most users to get their basic needs met?
    • Should we use a horizontal, multi-layer menu that’s presented on the Recorded TV screen?
    • Should we try the vertical stack of buttons that stay resident for all contexts, such as you see when you browse the detailed info for a Movie?
  8. Why is it that 3rd parties can’t add controls to the VMC UI, but Microsoft gets to change the user experience whenever they please (e.g. with the “Internet TV (beta)” object that quietly inserted itself – without asking, and without giving me any visible way to opt out – on the TV menu strip a few months ago)?
  9. What parts of the VMC UI are off-limits to third-parties?
    • Adding new objects to existing Start Menu Strips?
    • Adding new objects to existing “More Information” context menus?
    • Adding new sorting/filtering options to existing collections of content e.g.
      • I’d love to add “Show only Movies” to the “By Title” and “By Date” choices currently enabled in the Recorded TV collection
      • I’d give my left…toe to be able to sort a TV show’s episodes by the “Originally Broadcast” date, so I could accumulate a bunch of episodes of some show and then watch them in the order they were meant to be seen, not in the order they happen to have been recorded
    • Adding new tiles to the “More Programs” collections that are buried one click away from the Start Menu?


  • 🙂 “I’ve watched a video on Channel 9 where Charlie Owen and a programmer (Mark Finocchio?) demonstrate how to do basic MCML.  That was slightly more illuminating (though it took 35 minutes to get to the programming), but then I discover that you basically have to create your own buttons from total scratch. It really is back to the ark stuff.”


  • 😦 “I’ll check in to the ability to catch the More Information button — last I recall the handler is there but didn’t work exactly as planned.”  [sounds like one of those famous understatements of the year…]
  • 😦 “There are only the very basic visual elements – ‘Graphic’, ‘Text’, ‘Colorfill’ and ‘Clip’. Everything complex – like a button, menu, scroller etc. must be built from those four visual elements.” [also see 😦 ]
  • 😦 “This question comes up a LOT.  Enough that I covered it in my blog… Please check out the article called ‘Scope in MCML’.”

Next Steps

Here’s the list of beginner articles I’ve seen multiple folks point newbies at, to get a feel for what I’m about to take on:

  1. VMC SDK‘s “Step-by-Step” walkthrough (linked from the Windows Start Menu once you install the v5.2 or v5.3 SDK)
  2. MCML: UI’s (Steven Harding)
  3. UI Properties: Making UI’s Flexible (Steven Harding)
  4. Model-View Separation (Steven Harding)
  5. Stage 1: A Basic Layout (Steven Harding) through Stage 11
  6. GData .NET client library “Getting Started” guide
  7. cURL client for testing upload of files to Picasa

Source code to investigate: (as it might have some hooks already worked out that I won’t have to learn from scratch)

Picasa Web Albums Data API + Vista Media Center = MyPicasaPictures

I’ve found over and over, if I don’t upload pictures to the web when I first download them from my camera, then there’s little or no chance I’ll do it later.  Out of sight, out of mind.

But I wonder…

If I had an add-in command in the My Pictures sub-app of the Vista Media Center, would I be more inclined to upload pictures to the web then (and give my mom at least a glimpse into my life more than once a year)?

Google developer help: plenty

Since I’m already personally using Picasa’s companion Web Albums for what few pictures I’m sharing, I’m inclined to tie the online component of such an add-on to Google.

Having already investigated the Google APIs, I figured there was likely an API tuned for the Picasa Web Albums, and so there is.  Further, it appears that it provides the ability to post photos, create albums, update & delete photos, manipulate tags, and review existing albums/photos/comments/tags.  Sounds like it provides more than I was even looking for.

From what I gather with a quick skim, the basis for the “PWA” Data API is the Google Data API.  And while I don’t know whether it’s absolutely necessary, Google provides a .NET Client Library (currently v1.1.2) to speed web services client development.

Similar apps

Big Screen Photos v2 — the Yahoo Flickr client for Vista Media Center.  It doesn’t enable you to upload the pictures hosted in Media Center, but rather to view the pictures that are already available on the Flickr site.

Yougle Vista — provides access to online Video, Music and Picture sites including Flickr.  Still no upload capability.

PhotoConnect — extends My Pictures with some interesting functionality including the ability to email pictures to others.  However, it looks like this vanished in a puff of smoke and synthetic ash.

FlickrMCE — another viewing app, only for Windows XP MCE 2005.

PictureBook 1.0 — screensaver add-in, not really all that similar after all.

Windows Vista Media Center add-ons: sorting through all this new technology

Most add-ons for Windows Media Center 2005 (i.e. Windows XP) or earlier were written as “hosted HTML” apps that ran outside the Media Center shell.  Now, while hosted HTML apps may still work in Vista, the drive is towards either the MCPL/MCML or XBAP/XAML:

  • MCPL: Media Center Presentation Layer (the programming model)
  • MCML: Media Center Markup Language (the managed code language derivative)
  • XBAP: WinFX XAML Browser Application (the programming model)
  • XAML: eXtensible Application Markup Language (the language in which XBAP is more-or-less implemented)

However, it appears that the XBAP/XAML model has already been dumped by the eHome team.  Lovely, not even a year out of the gate and they already drop support for the “future-forward looking” programming model — I wonder what hurdles they had to clear to be able to explicitly drop support for the whole WPF (aka .NET 3.0) (aka WinFX) (aka WS-*) company-wide drive.?  Oh well, at least that’s one less choice to confuse me…but I have to bitch just this once: when can we abandon app-specific languages?  Any language or programming model that starts with the name of the vendor-specific technology makes me feel more than a little soiled.

Other resources that should prove useful

Some specific coding issues that I’ve noted for future reference

Interesting Tidbits

  • 🙂 Add-ins run out-of-proc in a hosted process called ehExtHost.exe, and communicate with the main Media Center process using .NET Remoting over “Named Pipes” (aka IPC within .NET).
  • 🙂 Media Center unloads the add-in when the Launch( ) method exit.
  • 🙂 The entry in More Programs is created by the running of RegisterMceApp.exe not by the running of the add-in itself.
  • 🙂 In an MCML application, you can only embed a couple of visual elements, NOT including ActiveX controls (i.e. no native Flash rendering).
  • 🙂 You can’t embed a WPF app / window inside of MCML.
  • 🙂 Charlie Owen has invited anyone to provide good/bad developer feedback on Media Center and the SDK, and left his contact info here.
  • 🙂 You can’t override ANYTHING on the Windows Media Center screens — if you want any new functions, they have to be added on completely new screens, which would mean re-building the whole ‘Videos’ library.


I’m not 100% convinced I’m going forward with this yet — I’m inclined to spec out the features, dig into the SDK/MCMLookalike/Codeplex-hosted sources to get a feel for just how much (a) volume and (b) complexity of code I’m facing, and then decide whether to keep pushing forward.  I’d sure appreciate feedback from anyone who has ever delved into any of these areas for encouragement or “there be dragons” warnings…

  • MCML programming
  • web services integration in managed code — Google or otherwise

Cheers all!

Outcast Genius? Well, they got it half-right…

Another one of those (not quite) pointless online “tests”, but as always I’m amused by what it thinks it knows about me.

Your Score: Outcast Genius

69 % Nerd, 56% Geek, 52% Dork

For The Record:
A Nerd is someone who is passionate about learning/being smart/academia.
A Geek is someone who is passionate about some particular area or subject, often an obscure or difficult one.
A Dork is someone who has difficulty with common social expectations/interactions.
You scored better than half in all three, earning you the title of: Outcast Genius.
Outcast geniuses usually are bright enough to understand what society wants of them, and they just don’t care! They are highly intelligent and passionate about the things they know are *truly* important in the world. Typically, this does not include sports, cars or make-up, but it can on occasion (and if it does then they know more than all of their friends combined in that subject).
Outcast geniuses can be very lonely, due to their being outcast from most normal groups and too smart for the room among many other types of dorks and geeks, but they can also be the types to eventually rule the world, ala Bill Gates, the prototypical Outcast Genius.

My test tracked 3 variables How you compared to other people your age and gender:

You scored higher than 78% on nerdiness

You scored higher than 80% on geekosity

You scored higher than 91% on dork points


Ouch.  I think it was the last one that hurt the most.

Office add-ins: VSTO or Shared? Why should I care?

I’ve noticed an interesting pattern in the VSTO Forum on MSDN.  Cindy Meister (the queen of VSTO & Word programing) will very often ask a poster whether they’re developing a Shared Add-in or a VSTO Add-in.  Nearly all the responses to such questions indicate that the poster has no idea, and I can’t blame them.  It seems that even if someone’s used the VSTO solution templates to create a new project targeted at Office applications, they could still end up inadvertently creating a Shared (or COM) add-in.

I finally got frustrated enough at trying to judge whether a question I’d ask would be “worthy” of the VSTO Forum, or would just be punted back to me to find an appropriate newsgroup — so I decided to figure out what’s the point of this once and for all.

I quickly discovered that Cindy has gotten this question in the past, and has summarized some of the differences here:

However, that still doesn’t answer the question of “Why should it matter whether my VSTO project actually turns out to be merely a Shared Add-in?”

  • Does it change the way that you’d use certain .NET classes — or does it limit the kinds of classes that can be used by a Shared Add-in?
  • Does it create incompatibilities on the deployed client — or does it require a different deployment approach for a Shared Add-in?
  • Do certain data types, methods for creating Event Handlers, or Office PIA-encapsulated APIs not work in a Shared Add-in that would work in a VSTO Add-in?

How can I tell whether the project I’m developing is a VSTO Add-in or a Shared Add-in?

  • Is there some set of Imports/Using statements that only work in one or the other (e.g. Imports Microsoft.Office.Core vs. Imports Microsoft.Office.Interop.Word)?
  • Do certain Visual Studio Templates lead to either Shared Add-ins or VSTO Add-ins (e.g. Visual C# > Office > 2003 Add-ins > Word Add-in vs. Visual C# > Office > 2007 Add-ins > Word Add-in vs Visual C# > Office > Word Document)?  Or is it only relevant if the template used is Other Project Types > Extensibility > Shared Add-in?
  • Once I’ve created the project/solution, and if I don’t remember 100%, is there some filename, configuration setting, unique Event or other property of the project that would definitively indicate that it’s VSTO vs. Shared (e.g. ThisAddIn.vb, ThisAddIn_WindowActivate())?

For me, the specific issue that I have been having issues with, and which I’m beginning to suspect has a different solution depending on “Shared” or “VSTO” (despite the lack of clarity or obviousness in any of the sample code you’ll find on the ‘net), is the specific means by which a custom Event Handler can be created for CommandBarButtons in a managed add-in for Word 2003.

I’ve personally seen both code like this (C#):

uiButton.Click += new Microsoft.Office.Core._CommandBarButtonEvents_ClickEventHandler(uiButton_Click);

and like this (VB):

    Private WithEvents uiButton As Microsoft.Office.Core.CommandBarButton

It’s entirely UNclear whether these are exactly equivalent, and if not, under what environmental conditions/constraints one is better than the other.  It’s also completely beyond me whether this would be considered part of a VSTO add-in or a Shared add-in.  Finally, I wouldn’t have a clue what I should do differently were I to know which type of add-in this was – would it affect which of these two handler-setup approaches I used?  What types of objects I should use?  Something else?

What if Google Reader had a sucky API…?

I’ve been thinking more about the idea of building a VSTO add-in for Outlook that could synchronize between Attensa for Outlook and Google Reader (I wrote previously about the idea here).

I’ve had a heckuva time trying to figure out how to build Web Services client code into a Windows client application.  There’s a ton of books out there documenting how to build the server side of Web Services; even the books and articles that talk about building Web Services client code, are really talking about consuming Web Services into another server application.  I finally figured out a query or two that gave us some leads, but it’s wasn’t exactly a slam dunk.

I’ve also had more trouble than I expected to figure out what the story is with Google Reader’s API.  Back in 2005 there was an effort by Niall Kennedy to reverse-engineer the then-current Reader API; at the time, the Reader team even commented a couple of times on the imminent release of the API.  Ever since then, there’ve been various inquiries but no further details to let folks know where they stood.  [Well, at least from the SOAP API standpoint.]

I’ve been getting more and more suspicious that Google no longer intends to document and release a SOAP-based API for Google Reader.  I finally became convinced of this when I stumbled on a not-terribly-related article by Scoble, where he caught us up on Google’s inauspicious switch from their original SOAP Search API to an AJAX Search API.

My take: despite some of the comments on Scoble’s article that imply he’s just being paranoid, I happen to think there’s merit to the theory that Google has no interest in developing APIs that don’t further their advertising revenue.  It’s not that I particularly dislike Google (I’m a big fan of many of their services), but after two years’ delay from when the Reader team was about to release their SOAP API anyway, it’s pretty hard to imagine that the great disappearing act is not in some way deliberate.

The fact that they developed and released the Reader AJAX API in less time demonstrates that they’re capable of getting a Reader API out in that timeframe, and the distinct lack of mention of any further API development (either on the Reader group discussion boards or on the Reader team’s blog) pretty much seals the deal for me.

So what’s an in-their-spare-time developer supposed to do at this point?

Google Reader: toss it…

From what I see of the Reader AJAX API documentation, it’s not meant as a full-fidelity API for manipulating the contents of a user’s Reader configuration, article read/unread status or even the list of blogs to which they’re subscribed.  I’m not terribly interested in placing an eight-article list of links (+ Google ads) in a VSTO add-in to Outlook.  Nor am I all that interested in trying to use an undocumented and unsupported (not to mention still-in-flux) SOAP API — it’s enough trouble for me to do something once, let alone every week or month when they decide to rip out something else.  It sure doesn’t help to hear someone who’s been keeping an eye on this space say things like Google is embarking on the “creation of de jure and de facto standards which are pitched as being great for customers but seem suspiciously like attempts at Fire & Motion.

Attensa Online reader: no more

I probably wouldn’t even be going down this road if Attensa had kept up their own online web-based feed server.  However, despite multiple positive reviews and different URLs that used to point to it, it’s gone the way of the dodo bird.  Heck, I’ve even lost access to Attensa’s own corporate feed server (to which they gave me an account last year after all the bug reports I’d sent them).

MyYahoo: no published RSS APIs

Many news reports repeat the “fact” that MyYahoo is one of the most popular online RSS readers on the ‘net.  I dug into its interface, documentation, and searched around Yahoo’s site for a while, but it was so obtuse it was hard to actually find any references to terms like RSS or OPML.  I’ve come to the conclusion that there’s either (a) no official API for MyYahoo feed reading, or (b) it’s just not something Yahoo has invested any effort into.  However, Niall Kennedy has documented some API characteristics, and I stumbled upon Yahoo’s general developer documentation (among which they mention that most APIs use the REST approach).  The Yahoo SDK provides C# & VB.NET samples for Yahoo’s various search properties but nothing more.

NewsGator Online: in a word, wow

According to a trip report from ETech 2006, the Newsgator API “uses standard protocols (SOAP) which can be consumed from any platform” and it “supports granular operations [add feed, mark item read, rename feed, etc]”.  The Newsgator Online API has documentation and even C# sample code here.  Newsgator also provides a web-based feed reader that’s optimized for iPhone (which is my ultimate online target) and a Windows Media Center-integrated web reader (which’d be a bonus for me with Vista Ultimate controlling my TV universe at home).  Hey, they even provide a Desktop client that integrates with the IE7/Windows RSS Store (though it’s unclear whether it syncs with NewsGator Online).  Plus there’s an Outlook-integrated client that has some of the capabilities of the Attensa Outlook client (though not the free price tag). unpublished API (or less?)

This one was mentioned on Wikipedia‘s article for Google Reader.  I wasn’t able to find anything on Rojo’s site about an API, but I did see a few sporadic mentions on the ‘net (e.g. Yuan.CC’s archives through 2005, a Rojo forum suggestion).  Unfortunately, as the discussion seems to center around “undocumented” APIs, I’m even less interested in this than in Google’s limited interface.

Bloglines: “it sucks a lot

According to the ETech 2006 trip report, “The Bloglines Sync API didn’t work for synchronization since it is mainly a read-only API for fetching unread items from Bloglines. However it is complicated by the fact that fetching unread items from Bloglines marks them as read even if you don’t read them in retrieving applications.”

NewsAlloy: cool but not there yet

Currently in Beta, this free web-based feed reader implements the “Blogroll API” (whatever that means), and provides both a rich web-based and a mobile interface.  Unfortunately, the developer has been struggling off and on to keep this project going, but it’s a really cool looking project.

Feedlounge: cancelled

Read here.

Gritwire: no idea

Gritwire Labs (where I’d expect mention of APIs to show up) doesn’t mention anything about APIs.  The author once mentioned “It relies on an XML API to receive and provide data to the backend”, but there’s little if anything else that would help me understand what this “API” is used for.

Conclusion #1: Build a Generic Sync add-in

I’d started my solution as a Google-Attensa app (heck, I’d named it GoogleReaderSyncToAttensa).  Now, after looking into this, and not seeing any one clear “winner” among the online web-based feed readers, I have decided that the only responsible thing to do is to build this add-in on the assumption that others’ll want to add their own web-based readers to the codebase.  Thus, all the direct button-to-codebehind and code-to-Attensa calls should be abstracted as much as possible to not tie the code to any one web-based reader.  The idea is to make it as *easy* as possible for someone to add their own assembly/class that encapsulates the necessary site-specific functionality, and (ideally) not have to rewrite any of the existing code, other than to call into the appropriate assembly/class.

Heck, if I was feeling really generous, I’d even consider abstracting the Attensa interface so that Microsoft’s IE7 Feeds interface could be used as the local client, or even the inevitable Google Apps offline reader.  However, I’m getting waaayyy ahead of myself with this kind of thinking.  I’m going to have a hard enough time abstracting the remote site interfaces, let alone try to wire the classes for “plug and play” with various local feed reading apps.

Conclusion #2: I Should Just Cough Up the $30 for Newsgator Inbox

At my core, I’m just a lazy guy.  If I can find a pre-built application to do most of what I want to do, then I’ll suffer with the pain of that rather than go off and “build” something myself.  That was the core lesson I learned from Comp Sci 1A03 (first-year programming) in undergrad, and my computing bias was solidified that way ever since.

After looking at the breadth and depth of offerings from Newsgator (SOAP API, REST API, Outlook client, Windows Feed Store integration, iPhone web client, Windows Media Center client, and broad support for synchronization among all the feed readers) it feels like a tough choice for me: spend a few months developing a synchronization framework between Attensa and one or more online feed readers, or spend the $30 on Newsgator Inbox and postpone development indefinitely.

I guess the big question is, am I more interested in learning how to code Outlook VSTO and Web Services (SOAP and/or REST), or am I really just interested in getting on with my RSS reading and work on something else?  I do have plenty of other development projects I can continue doing, and it’s not like I have all this spare time to devote to multiple concurrent development projects.  On the other hand, this is an interesting space for development, and (for those folks not paying $$ to Newsgator yet) there’s something to be said for laying the groundwork for a generic offline-online RSS synchronization framework.

I’m going to have to sleep on this for a while — this is not an easy choice.