Only Microsoft can make something so simple this complex.

  • Article

By the end of reading this post you will either think:

Wow, Microsoft really wants a great experience for their users.

or

Wow, Microsoft just can’t make anything as simple as it really is.

I really hope that you think the former, but it appears that some people already think the later, especially when it fails them.

As you might have guessed from the link, the exact feature I am talking about is ‘Insert Video’ from Windows Live Writer.  From first glance, this should be one of the most straight forward features for a blogging client.  You simply need to insert an embed into the blog post, and publish to the blogging service.  However, Windows Live Writer has to bend to the will of three different set of constraints.

The 3 areas of the most influence are:

  • The content needs to appear in the WYSIWYG editor correctly, and needs to be editable as all other content.  This means it need to be selectable and have a sidebar, delete-able, drag-able, and resizable.
  • Different blog services strip certain elements from the blog post body when they come in through XML-RPC.  This often boils down to services removing embeds and/or JavaScript.
  • Different video services have unique problems, which we will go into more later. 

Long Upload/Processing Times

Most blog posts are written in less then 15 minutes.  Though with both Soapbox and Youtube, the amount of time it takes to upload a video and for a service to process it is much longer.  Youtube in it’s public documentation says that a video might take a long long time to process, and in some cases might be as little as an hour.  That just doesn’t fit in a blogger's current workflow. While a video is being uploaded to a video service, you cannot close the window.  WLW will let you close the application once it has moved into the processing phase (after upload), but it won’t let you publish the blog post.  This means that you can write a blog post, embed a video from your hard drive and be all ready to publish, but you can’t, because the video service isn't ready for you to embed the video.  A new time constraint has just been placed on the user, even worse, the user might not understand this constraint and place the blame on WLW.

Not All Videos Are Embeddable

Not all videos can be inserted through WLW with the Insert Video feature.  There are two reasons that a video can’t be inserted.

First, sometimes URLs do not contain the video ID that would be needed to generate an embed code.  This will be discussed later in the post.

The second reason WLW can’t insert the video is because the video is protected against embedding.  Soapbox and Yahoo! both have videos covered by copyright which don’t let the user embed them in their personal sites.  So when a user pastes the video URL into WLW, they don’t get converted into embed.

Adaptive HTML

Some blog services let all video services through, while others don’t.  This means WLW has to make a judgment call about how it will present the video. WLW will pick one of three different routes for each blog post with a video. 

  • If a blog service is very conservative about what they let through, WLW will try to take a snapshot of the video player and embed it as an image that is linked to the video on the video service. 
  • If the blog service lets JavaScript through, but no objects/embeds, then WLW will put a placeholder for the video using the above technique and try to replace the placeholder with the actual embed using JavaScript’s onLoad event. 
  • And finally, if the service lets the embed through it will just drop in the video’s actual embed, which is what the user probably wants.  

Even with this set of rules, there are some exceptions still.  For example Wordpress.com has a way to add Youtube video to the post using a microformat instead of the embed for secuirty reason.  Keeping up with all these rules is quite a task which is a burden on blogging clients.

All these restrictions make it hard for WLW to give the user a truly WYSIWYG view, depending on the service you are pointing at, what comes out might be different on different bog services even though it is the same post within WLW.

Snapshot

As mentioned above, sometimes WLW will try to replace your video with a snapshot of the video.  This sounds great, but it turns out that it is harder then it seems.  Taking a snapshot involves WLW embedding the video into a simple html document, and then opening it in a browser in the background.  When it thinks the video has finished loading it turns the webpage in the browser into an image and snips out the video player from the snapshot.  Sounds simple right?  Turns out, predicting when a video is loaded is a difficult task.  We implemented rules to try and decided if the video was done loading by comparing pixels of the snapshot repeatedly to see if they changed, or looking for at a certain region to see if it is a color we know might be the background color(for example, the older Youtube player was always gray).  

So what kind of problems do you run into with this?  Video services change their players.  When Youtube changed their player to have a black background, that triggered a lot of false positives, and people ended up with snapshots of a loading player on their blog; this is what happened to Paul in the link I had above.

Cannot Convert URL to Embed

One of the features of Writer is that if you paste in a URL to a video then we convert it to the embed code for the video.  This is easy to do for services like Youtube where the video ID is in the URL, simply parse out the video id and drop it into the the embed code.  We support about 15 video services.  As it turns out, with pretty URLs, a lot of services have a URL like the following:

www.example.com/Title-Of-Video

There is no way to turn the URL into an embed code because the the URL doesn't have the ID in it.  This left ~4 services in the dark for this feature.  If they just would have done something like:

www.example.com/452345/Title-Of-Video

We would be able to convert the URL to an embed for our users.  Its unfortunate not everyone does this. 

Embeds in the Editor

Embed/object codes in the WYSIWYG editor are troublesome.  If you just insert these into your post in their raw format they aren’t very user friendly.  Since the editor itself acts like a browser, clicking the video will usually start to play the video, and there is no way to delete it from your post without switching to source view.  This is the reason that WLW originally swaps the video out for a snapshot of the video while in the editor.  This lets the user resize, align, and caption the video straight from the editor.  But this isn’t how it will be shown the user’s blog in the event we publish the embed code; and if the snapshotting failed the user will see a broken video while editing with no idea what will happen when they publish.

Embed Code Reformat

WLW has to have a standard format embed for each video service.  When a URL or embed code comes in, we must convert it to the smart content, as mentioned above (in Cannot Convert URL to Embed).  We need to know where to replace the width and height in the embed code when the user resizes the video.  Unfortunately this means any customization of an embed code will be lost when we reformat it.  For example, if there is a param that lets the user customize the background color of the player; it will be lost when we generate the embed code.  Hopefully in the future we can identify regular expressions to just change the embed code instead of replacing the whole thing to leave the user’s customizations in tact.

 

So What Did We Do About All This?

In the newest release of WLW we tried to address a few of these problems.  WLW can’t fix all the problems, it has no control over the blog or video services.  But, we took the following steps to improve the experience:

  • Videos inside the editor are all now in their true embed.  We add an additional parameter to them so mshtml handles them a bit better then normal embed/object codes inside the WYSIWYG editor. Then we surround them with our own div that has special properties using CSS selectors so the user can resize, select, and drag the objects. 
  • Snapshots are now read directly from the WYSIWYG editor so that it is true WYSIWYG.  This brought us away from background browser snapshotting and what I liked to called snapshot hell.

 

I hope everyone is enjoying Windows Live Wave 3 Betas!