dabblet

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

URL and entity previewers in upcoming dabblet v1.1

A URL previewer was a very common request. I had my qualms at first but I decided it’s useful enough to outweigh the disadvantages. It should work for everything displayable in an <img> element, including SVGs and data: URIs.

Along with that, I’ve also implemented an entity previewer, which is useful when you’re not sure whether you remember an HTML or CSS entity correctly.