For many months, dabblet was just a web application with hardly any social components and that seemed to work fine. However, discovering new interesting dabblets was a pain. While user profiles do not completely solve this, they are a step in the right direction and something that was requested multiple times in the past. They’re basically a wrapper around Github profiles combined with a user’s Gist listings, presented in a way that’s more suitable for Dabblet (e.g. with previews and without all the non-dabblet gists).
Accessing a user profile can be done in a number of different ways:
- You can access your own profile if you are logged in, by using the menu under your username and selecting “My profile”:
- If you are viewing a dabblet by someone else, you can access their profile through the cloud menu:
Keep in mind that this UI might change very soon, as I’m thinking of splitting the current dabblet info into its own panel.
- Through the user profile itself, for example when viewing followers and following.
So what are these user profiles?
Each user profile includes information about the user, latest dabblets, followers and followed users. All this information is fetched from Github, through the Github API, client-side. Here are some screenshots from my own profile:
The dabblet previews were quite tough. For a while I’ve been wondering how to do it. There is still no reasonably cross-browser way to capture an entire page as an image in the Web Platform set of tools. I had thought of iframes, but dismissed the idea without testing as “too performance intensive”. However, when I was at Front Trends 2012, I had a chat with Chris Coyier who was working on his (then still in private beta) CodePen. He told me they solved this in CodePen via iframes and the performance seemed reasonable. So, when I got some time to work on it, I tested it for myself and it does, indeed, seem reasonable. I guess it might be a bit laggy on older machines, but hopefully still bearable.
The dabblets are rendered in a 800×600 viewport and then scaled back to 400×300 through CSS scale transforms on the iframes. To minimize the number of requests to Github, I also implemented a lazy loading system that only loads the previews when they are actually visible on the screen and not e.g. scrolled off it. Also, to improve client-side performance the iframes are loaded one by one and not in parallel.
On all three tabs 30 items at most are displayed initially, and you can click on the “More” button to load up to 30 more every time. This page size is hardcoded by Github and it seems there is no way to change it.
Furthermore, although the page size in the “Followers” and “Following” tabs is exactly 30, in the “Dabblets” page it could anything from 0 to 30. This is because there is no way to tell which gists are dabblets until actually fetching them and checking the file names.
Interesting user profiles
To play a bit with them yourself, I’ve included links to my profile and some other interesting profiles below:
If you know of any other users with a lot of interesting experiments on Dabblet let me know and I’ll add them to the list.
Github API limitations :(
The Github API, although elegant in what it supports, it showed its limits a lot while I was developing this page. For example, to name a few:
- I can’t display more information about the following or followed users without making one request per user, as the only info returned is their avatar and username.
- There doesn’t seem to be a way to check if user A follows user B, unless user A is the currently logged in user. So, although I wanted to show whether the user whose profile you are viewing is following you back, I can’t.
- The inability to only fetch dabblets and not gists in general is quite crippling. For example, I can’t make a page with the latest dabblets, since I can only fetch the latest gists and I would guess only a tiny percentage of them is actually dabblets.
- I would love to create a page with “hot” dabblets that would fetch predefined dabblets off a list of gist ids. However, that would involve sending a separate request for every item on the list, and I’d guess that would hit the hourly rate limit quite quickly.
- I would love to show how many times a dabblet has been starred and even rank dabblets by popularity. I can’t do either.
I hope Github API expands in the future and shifts some of these limitations, since the small set of calls it already supports is a real pleasure to work with.