dabblet

Idea: Show/hide panes with toggles instead of tabs

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:

• There are certain pane visibility combinations that simply aren’t possible, e.g. HTML & JS & Result. Out of the 15 (2⁴  - 1) possible combinations of 4 panes, Dabblet currently only offers 8 (CSS, HTML, JS, Result, CSS+Result, HTML+Result, JS+Result, HTML+CSS+Result).
• The view setting mixes pane visibility & pane layout (The “Separate” option actually hides panes), which can be confusing.

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.

Updates over the last few months

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

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!

Dabblets through POST

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.

Integrated Prism into dabblet

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.

Fixed XSS issue

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.

General bug fixing

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.

One click code validation for CSS and HTML

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 Codelet

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 :)

Dabblet thesis

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.

Lots of improvements in the pipeline

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:

• Adding JavaScript support — This will be a challenge UX-wise, as it shouldn’t run on every keystroke, like the HTML and CSS, but it should run on startup and it should be straight-forward how to get it to run. Perhaps it will also run after a significant pause in typing.
• Dabblets that are not stored in Github, but get their data through POST requests.
• Improving cross-browser support
• Strengthening security
• Integrating Prism. Dabblet’s syntax highlighter might have been Prism’s precursor, but currently Prism has solved many of its bugs, and these fixes need to be pushed to dabblet at some point.
• General bug fixing

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!

User profiles come to dabblet

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:

• Lea Verou
• Roman Komarov
• Chris Coyier
• David DeSandro
• Vadim Makeev
• bigbossSNK
• Benny Schudel

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. 

Dabblets now degrade gracefully in non-CORS browsers

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. 

New feature: Custom font size per dabblet

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:

• Cmd/Ctrl + + increases font size
• Cmd/Ctrl + - decreases font size
• Cmd/Ctrl + 0 resets the font size to the default

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.

Full page result is now on its own subdomain

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”.

View all panes at once and other updates

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.

Always visible menu bar for larger screens

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). :)

Linking to individual revisions

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