Watch It Later: A Comprehensive Review of four “Instapaper for Video” apps

In the past, I’ve tried pushing videos to Delicious under a “watchlater” tag or adding them to Instapaper, and neither of these options is effective. So it’s great to see this space coming alive, and how! Here are the options.


VHX is feature-rich, with hipster black background and stretching-to-the-edges full screen app experience. Login: Supports login via Twitter and Facebook. (I wish all the other services here also acknowledged site-specific login is passé. Lazy Reg ftw.)

  • Viewing experience: Uses an elastic layout where you can easily drag the side menu in and out to switch to a “almost fullscreen” view and it’s also easy to switch to completely fullscreen.
  • Discovery: The Channel feature is great – connects to your Twitter, Facebook, etc, as well as general media like BoingBoing, to find videos. There’s also a Dashboard to see your friends’ videos (and apparently the general user community if you don’t yet have any friends!).
  • Social features: You can “like” internal to the site and also share to social networks. The bookmarklet is also social.
  • Archiving: A “history” feature includes all the videos you’ve watched. (It was broken for me just now though.)
  • Bookmarklet and Adding: The bookmarklet identifies all videos and lets you click to add to your queue or share it immediately.
  • Other: One major annoyance is it launches straight into a video from the Dashboard, and this is exacerbated by the fact many of these videos are of the “funny viral” variety (Look! It’s a dog spinning around in circles. ROFLMAOCOPTER.) It would be a tiny change, but make much more sense to launch into your queue.


SQURL is also very feature-rich, with more of a “clean website” UI.

  • Login: No Twitter/etc here…need to make a new username/password, etc, you know the drill.
  • Viewing experience: Reminicent of YouTube in HD mode – video takes up most of the screen, with white margins. Controls for sharing/liking available.
  • Discovery: Discovery happens by curation – any user can create a new “gallery” and curate it, and it’s easy to browse these galleries. (Although adding a new video from here to your queue takes 4 clicks – 3 to many!).
  • Social features: As with SQURL, you can “like” internal to the site and also share to social networks. The bookmarklet is also social.
  • Archiving: All your significant actions, not just past videos, are shown in an Activities section.
  • Bookmarklet and Adding: The bookmarklet identifies all videos and lets you click to add to your queue. There’s also a Chrome extension to automatically stick Youtubes/Vimeos into your history.
  • Other: A major selling point is compatibility with many different video platforms, whereas the others seem to be about YouTube and Vimeo.


Instafilm is more about simplicity and has a neat slider to let you filter by time. (I wish it let you choose minimum time, not just maximum; on a day off, I sometimes want to watch a long video I’ve saved up.)

  • Login: Yep, it’s another startup who probably loses 50%+ of potential users because there’s no federated login support. Lazy Registration people!
  • Viewing experience: Didn’t like it as much as the others, found the video relatively small. I like the max-out approach best.
  • Discovery: No discovery. This is arguably a feature – the simplicity helps it to differentiate.
  • Social features: As with SQURL, you can “like” internal to the site and also share to social networks. The bookmarklet is also social.
  • Archiving: Hmm it lets you “Archive” videos, but this seems to mean “Delete”!!! I can’t find the video I archived anymore.
  • Bookmarklet: The bookmarklet is standard, but I did find it reports ok (“filmed”) whether it captures a video or not.


Like Instafilm, Radbox is a more down-to-earth experience that will be familiar to Instapaper users.

  • Login:Hurrah! It’s not just “create a new username and password”. You can at least login with Facebook, though other options would be nice too :).
  • Viewing experience: As with SQURL, a YouTube-like experience – video mostly maxed out on white background, with controls around it.
  • Discovery: No discovery. This is arguably a feature – the simplicity helps it to differentiate.
  • Social features: As with SQURL, you can “like” internal to the site and also share to social networks. The bookmarklet is also social.
  • Archiving: No archive as such, but you can add into a “Lists” as a form of categorisation. This feature, albeit basic for now, could make the service grow into a video an organising tool, not just “Watch Later”.
  • Bookmarklet and Adding: The bookmarklet is standard, and there are several other InstaPaper like tools available: a secret email address for inbound mail additions; an RSS feed; adding from Google Reader; and an API.


I’m on the fence between SQURL and VHX.

Key advantages of SQURL:

  • Platform support is a big deal here, and it seems to integrate with many more video platforms.
  • There’s already an iOS app (Android please). To be fair, I haven’t evaluated any of these on mobile, and SQURL does claim an optimised iOS web UI, though they’re also working on an app.
  • The curated galleries feature is excellent, they’re seeded it with a ton of galleries to begin with, and you won’t run out of interesting content anytime soon.

Key advantages of VHX:

  • Better UI. I like the video watching interface better overall, with its maxed-out videos, although some will find the initial jump into the Dashboard a little painful, and won’t stick around long enough to work out how the queue works.
  • One-click adding videos to queue, from within the app.
  • Exquisite bookmarklet. The way you can choose between adding to queue or sharing it immediately is awesome.
  • Channels are an excellent source of discovery, as an alternative to SQURL’s curated galleries, though so far, they weren’t niche enough to interest me. If they can build better curation into channels, ie custom channels made by users, that will be the best of both worlds.
  • Login via Twitter and Facebook.

For now, I intend to use VHX for day-to-day adding to queue…while using SQURL for its collections of videos in the event I feel like watching a random video that’s not in my queue. This may change fast though as it’s clear there will be a ton more innovation down the line.

I hope you found this useful, and please add any experiences or additional services in the comments.

Video Sync with WebSocket and Node

[Update 2015 – This was made on a very early version of NodeJS and may not work anymore; if you are looking for support to run this, please ask on StackOverflow.]

Wanting to explore WebSocket, I made a demo that syncs videos for all users looking at the page (See the Code). Any user can “take control”, so that the other videos will follow the controller’s video. Writing it was a cinch with the Javascript WebSocket API in the client, and the very straightforward Node WebSocket Server powering the server.

Note it’s just a simple demo – there’s no security model here and there’s a very simple sync mechanism: When a “slave” client receives the latest duration, it adds a second to account for lag, and moves the video iff there’s a 5-second discrepancy.

How does a WebSocket client look? Well, it looks a lot simpler than a traditional Comet client. Initiate the connection with “new WebSocket”:


  1. var conn;
  2.   $_("#join").onclick = function() {
  3.     conn = new WebSocket("ws://localhost:8000/test");

Upload a message to the server with send():


  1. video.addEventListener("timeupdate", function() {
  2.       if (iAmControlling()) conn.send(video.currentTime);
  3.     }, true);

Receive a message from the server with conn.onmessage():


  1. conn.onmessage = function (ev) {
  2.     if (matches =^pause (.+)$/)) {
  3.       video.pause();
  4.       video.currentTime = matches[1];
  5.     }
  6.     ...
  7.   }

And when it’s time to draw the curtains, close the connection with another one-liner:


  1. $_("#leave").onclick = function() {
  2.       conn.close();
  3.       ...
  4.     };

The server is also rather tiny. It mostly just broadcasts (sends to all clients) any incoming message and it’s up to the clients to deal with it. Which is why I say there’s no real security model here.

As you can see in the above snippets, “video” plays an excellent cameo role here, with its equally simple API. One downside, which others have mentioned too, is the lack of styling in the default video controls. It’s great the API supports automatic controls, but it’s unfortunate there’s no CSS manipulation. In this case, the “slave” browsers should be able to see the time, but not have the ability to change the progress. I hope this changes in the future, because the API is otherwise very powerful without compromising simplicity. Until then, libraries will arise to fill the gap.

The demo works in both Chrome and Safari (and they play nice simultaneously).

Audio/Video Tag: Don’t Forget to load() before you play()

This is a gotcha that will catch a lot of people out because it goes against the expectation that you just change an image’s appearance by setting its “src”, done. And also, it’s a deviation from the more general convention that you change DOM properties declaratively to make stuff happen. Probably for good reason, given the temporal nature of audio and video playback, but just beware it’s a different model.

Bottom line is – load() between changing src and play()ing:


  1. function play(url) {
  2.   var audio = document.querySelector("audio");
  3.   audio.src = url;
  4.   audio.load(); // !HUL|_O! PAY ATTENTI0N!
  6. }

A lot of online sources talk about play() and omit to mention this vital fact, because they’re only play()ing a single track…and the first track works fine. This is an oddity – you can just call play() the first time and it will automatically load. This happens whether you set “src” in the initial HTML’s “audio” tag or whether you set it programatically. I did some fiddling and it looks like the behaviour is the same in Chrome and Firefox. It’s like the track is auto-load()ed the first time you set its source. (And note that Firefox doesn’t auto-buffer so that’s nothing to do with it.)

devx has you covered on this topic, and points out the subtle issues which you would need to look at for a quality production:

However, media by its very nature is a time-spanning process. You’re working with both the need to load and cache audio and video files and the network connection, which itself can prove to be a challenge that’s usually not a factor for most non-temporal resources. For these reasons, when dealing with video and audio on the web, if you want to take control of the process in any way, you have to work asynchronously, tying into the various events that are passed back to the client from the media-serving website. Table 4 (taken directly from the HTML 5 documentation) provides a full listing of the various events and when they are dispatched. … Of all the events in Table 4, perhaps the most useful are the canplay and canplaythrough events. The first, canplay, will fire when enough data has been loaded for the video player to start actually rendering content constructively, even if not all of the data has been loaded. The canplaythrough event, on the other hand, will fire when the data has essentially completely loaded into the browser’s buffer, making it possible to play the video all the way through without the need to pause and retrieve more content.

Screencasts with Audio on Wink

I’m at a workshop on widgets. At a lot of workshops, people build some code, demo it, and then go away and no-one can see it running again. In an ideal world, we’d keep the apps running forever, but that relies on a complex tangle of internal and external services remaining online and staying in the same form. For example, will Twitter’s experimental OAuth have the same interface in six months time as it does today? In an experimental workshop involving mashups, there are bound to be numerous calls to services like that. The best way to preserve the work is not to keep the apps running, but to capture screencasts where the developers can explain the underlying concepts.

On Mac, I use iShowU for screencasts (like the Web-O-Random screencast I did a while ago). For Windows and Linux, though, there’s the possibility of Wink, which is nice as it’s (a) free; (b) capable of producing SWF files directly (Flash movies which can be embedded in a web page like YouTube). Last tried Wink two years ago to make some AjaxPatterns screencasts that never happened. (It’s funny to think that at the time, I was bothered about how to host and serve these files, a few MB each. Now I’d just store them on Dreamhost at 1+TB/month for about $20.) At the time, Wink didn’t handle sound, so you had to go through contortions to get an SWF movie containing the screencast with audio. Now it does, but it turns out to be not brilliant. When I tried to record with the “audio” option checked, the audio ended up being broken – 1 second on, 1 second off. Would be indicative of a buffering issue, but there’s plenty of memory available.

So here’s what I discovered, which actually works (using Wink 2.0). Instead of simultaneous audio and video, you can record audio over a single – frozen – frame. i.e. the frame will be frozen while you say your thing. It’s not Tarantino, but good enough for an explanatory screencast.

  1. Start a new project, with audio option not checked.
  2. Record the interaction without audio (Shift-Pause to start, Alt-Pause to stop). Don’t slow down on critical events as you can easily add delays during editing.
  3. Once you’re done recording, Wink will show a reel of all frames on the bottom of the screen.
  4. Click on a frame showing a critical event. On the right of the screen, there’s a dialog showing properties for this frame.
  5. Click on “+” audio button, which will produce a recorder. You can now record some audio which will sound out while showing the frame. The frame is automatically paused for as long as the audio you record.
  6. Now do Project Menu|Render and then Project Menu|View Rendered Output to see your video and hear your narration.

(I’m aware this is a plain-text post, explaining how to use software without screenshots or screencasts. Isn’t it ironic?)