Currently, Dabblet employs a system of tabs to show/hide panes, with preconfigured options of which panes to show for every tab:
There is also a setting that modifies the layout of those panes:
This was done to minimize cognitive overhead and provide easy, pre-baked options to the user of the pane combinations they are most likely to need. However, after my colleague, Doug Schepers recently suggested a better idea, I’m starting to think it was just UI overengineering, as it has a number of issues:
His idea was to use a control to toggle pane visibility individually, allowing all 15 options, and a separate control for their layout. The tabs would be replaced by something like this:
and the view setting with something like this:
Like all brilliant ideas, it seems obvious after somebody else describes it to you. I later discovered that JSBin does something similar:
Although it doesn’t let you control the layout of the panes, and just treats it always as “Vertical”, which certainly simplifies implementation.
Implementation of the idea described here for Dabblet is actually pretty hard. The “Horizontal” and “Vertical” states are quite easy (although such a major change is always a lot of work), but the “Mixed” one would require a pre-set layout for all 15 possible combinations. So, before devoting all the time required to implement it, we felt it would be good to ask the community: Do you think it’s worth it? Would it make Dabblet’s UI more straightforward? Any feedback is welcome, even ways to improve on this, if you have any ideas.
There has been a while since the last post in this blog. However, this doesn’t mean dabblet is not moving forward. There have been a number of improvements, practically everything we promised in the previous blog post:
JavaScript support was added in a new tab. It will run when a dabblet loads, as well as when you hit the Play button in the JS tab or hit Cmd/Ctrl + Enter (⌘↩). If your script has errors, the first one will be displayed, no need to check the console!
You can now submit a form to dabblet with the fields “css”, “html” and “javascript” and its code will be displayed in the appropriate fields. You can test this functionality here. This can be useful for tutorial sites or using dabblet to preview e.g. theme changes. Make sure the form has method="POST" otherwise it won’t work.
The syntax highlighter powering dabblet is now Prism, which started from it but evolved into something much bigger. Prism is used by big industry websites like Smashing Magazine or A List Apart.
A long standing XSS issue in dabblet, that thankfully nobody exploited, was that the preview iframe was in the same origin, so someone could write malicious JS to steal the user’s Github access token. The preview iframe is now on its own subdomain and communication with the Dabblet UI happens through the Cross-Window Messaging API.
Several long-standing bugs were fixed. Especially bugs that had to do with the undo/redo functionality. The long-standing issue of previewers that remained visible in the top left corner of the screen also should have been fixed. There were attempts to fix the major issue with Dabblet’s “View Full page Result” functionality, which apparently hits Github rate limit and starts showing “Not found, sorry! :(” after a certain point, but it looks like it hasn’t been solved yet.
The CSS and HTML panes now have a validation button that sends your code to the W3C validator, which opens with the results on a new tab.
WebPlatform.org, W3C’s new effort to document the Web together with both the developer community and all the big players of the Web as stewards, has its own customized installation of Dabblet, nicknamed Codelet. Besides the skin, its main difference from Dabblet is that it doesn’t require a Github account to save, since every gist is saved in the WebPlatformDocs account. All of the above changes were also ported into Codelet, and in fact, many were done because of it. Since WebPlatform.org is part of my job at W3C, it enabled me to work on Dabblet during W3C time, so in a way, W3C sponsored these updates. Therefore, if you like these changes, you know who to thank, besides me :)
I recently finished my BSc in Computer Science, and Dabblet was my thesis. I’ve written the entire thesis in HTML (It’s even responsive!), and if you’re interested in the inner workings of Dabblet, you may read it here.
As many of you probably know, I’ve started working for W3C Developer Relations since this August. Half of my time is devoted to WebPlatform.org, a very promising project to document the web with the help of all major players, in a vendor-neutral way. Even before I joined W3C, we discussed using a hosted, customized version of dabblet in WebPlatform.org, as a platform for live code examples. I recently started working towards making this happen.
A lot of changes and improvements need to be made to achieve this, but the good news is, most of these will be pushed to dabblet.com as well! In a nutshell, this is what I’m currently working on:
These will probably be gradually rolled out in dabblet.com and tested by the community, before we integrate dabblet into WebPlatform.org. If a new feature is significant enough, there will be a new blog post about it here, but don’t expect blog posts about bugfixes. I’m really excited to see dabblet flourish, and I believe you will be too, once these updates are out!
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:
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.
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.
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 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.
Following a suggestion by Roman Komarov (@kizmarh), dabblet now redirects to the full page result when viewing saved dabblets in non-CORS browsers such as Opera 11.6 or IE9.
A new setting has landed in dabblet: Custom font size! It’s incredibly useful for presentations, where you might want to show the code at a very large font size. Also, it makes it possible to adjust the presentation of very small or large demos to give them a more suitable font size.
The setting is saved with every dabblet, so when you share one, you are also sharing its font size. Of course, the viewer can choose to change it if your chosen font size is uncomfortable. You may also change your default local setting the usual way: just set it on a new, unsaved dabblet. Dabblets saved before this feature was added will be displayed with the viewer’s local setting.
The new setting can be triggered by keyboard shortcuts:
This were also added in the help section, along with the rest of the keyboard shortcuts.
To avoid interfering with the browser default shortcuts, these only apply in editing mode (i.e. when a code area is focused).
Enjoy!
Note: This feature is available in the GUI only in browsers that natively support HTML5 slider controls (<input type=”range” />), which currently are WebKit-based browsers, Opera and IE10. In non-supporting browsers, dabblets will still be displayed with their saved font size and the keyboard shortcuts will work, it just isn’t settable through a UI.
So, for example to view the full page result for dabblet #2191425 you will now go to:
http://result.dabblet.com/gist/2191425
instead of:
http://dabblet.com/result/gist/2191425
Obviously, the new syntax is prettier, more in line with URL conventions and more consistent with regular dabblet URLs. However, this was not the primary motivation behind the change. The new syntax is more secure, preventing malicious dabblets from injecting JavaScript and stealing your access token. Don’t worry, there was no such incident so far. But I wanted to ensure it wouldn’t happen in the future either. :)
The old URLs will still work, 301-redirecting to the new ones.
No idea what this is? The full page result helps you test your demo in browsers that might not be fully supported by dabblet for authoring. For example mobile browsers, old browsers, Opera < 12 etc. It’s also better for providing a testcase with bug reports, as the developers won’t have to dig through the dabblet UI to debug. Apart from the above URLs, you can access it from the cloud menu by selecting the option “View full page result”.
One of the most frequent requests I get for dabblet is being able to see CSS, HTML and Result all at once, similar to how JSBin and JSFiddle work. As you probably know if you’re following this blog, I was planning to allow full customization of the number and layout of the tabs, and I’ve already implemented this in the experimental branch (albeit a bit buggily).
However, something inside me was preventing me from polishing it and pushing it to the main branch. Sometimes, allowing full customization is not the best option. It’s usually just an excuse to help UX designers avoid hard dilemmas. Who can blame them, after all, there will always be users that will disagree with any possible decision and I can understand trying to avoid that by giving full power to the user.
However, one of the basic UX principles is that what users ask is not always what they want. Giving this kind of power to users adds clutter. Clutter that can be avoided with decisions that will please the vast majority of users, even if some of them will dislike them. The fewer settings an application has, the less users will feel utterly lost while trying to configure it. I strongly believe that a setting should be a last resort, only after there is sufficient evidence that there is no decision that will please most users.
So, I decided today to simply add an “All” tab, which would display all panes at once, and delay full customization (indefinitely? Honestly, I don’t know). It shows all three panes in every view (separate, vertical split, horizontal split) with a different layout in each. The following screenshot is from the “separate” view. Since there was nothing sensible to do for that tab in that view, I picked something that seemed useful:
While I was at it, I added transitions on the panes, so that they animate when switching views or tabs.
Another change I made is that the “Behind code” mode was removed from views and is now a checkbox that applies to every view:
I didn’t add code for backwards compatibility with existing dabblets that used the old “Behind code” view, as those are very few and it’s super easy to update them.
Another small change is that now, in large screens where the top bar doesn’t autohide, the tabs are now contained inside the top bar rather than being on top of the panes:
Important: To fully get the changes you may need to hard refresh (or delete cache) and perhaps even change the view mode at least once, to clear incompatible stored settings. Yes, I could spend some time to save you from that hassle, but I guess you prefer me to spend my time in making dabblet better, right? :)
Hope you like the changes. Please note that like every update, there might be bugs at first, so I’ll be waiting for your bug reports.
One of the most frequent complaints I get about dabblet’s UI is that the top menu bar auto-hides.
This saves a lot on vertical space (and looks nice when closed), but I can see how it can be annoying. However, I hate preferences creep more than anything, so I was reluctant to add an extra setting for that, even when others did it for me.
However, today I came up with an idea: You don’t really need this kind of space parsimony on large screens, do you? In those cases, being easy and quick to use are more important than saving screen real estate, which we have an abundance of. So, I used a simple media query (@media (min-height: 799px) and (min-width: 1000px)) which makes the header always visible when active (i.e. on large enough windows). :)
You can now link to individual dabblet revisions, which is ideal for tutorials. Check these revisions of the same dabblet:
http://dabblet.com/gist/1695733/c68f732103cd030eda63ce3ba8bdbc88c4463ee4
http://dabblet.com/gist/1695733/a82c6bbf13a1fbd9ec56141b16504060ec98a57c
http://dabblet.com/gist/1695733/1e949dd3c1566124ef606cacd7fa8b5564502365
http://dabblet.com/gist/1695733/a60ee572806770e2dd19ff33a10d3aef3c138d63
http://dabblet.com/gist/1695733/4745f5592f273fd96a6ea1255ac6959dbf310c43
http://dabblet.com/gist/1695733/ed2e6efc272146f3d728e65341f4f51a91e65e03
To find the version hash of each revision, you have to visit the gist page (by clicking “View gist” on the menu) and click on the revision from the sidebar:
Then, take a look at the URL, the hash will be there, after the gist ID.
Of course the same functionality applies to the server-side generated results. Example: http://dabblet.com/result/gist/1695733/1e949dd3c1566124ef606cacd7fa8b5564502365