Foliotek Developer Blog

Spectrum Colorpicker In Foliotek Presentation

Spectrum, my JavaScript colorpicker project, has gotten some good news lately!

It was adopted by the WebKit project for use in the Web Inspector, which was on a few people’s wishlists, including my own.

Foliotek Getting Involved

We decided to add (and expand on) functionality and improve the design for use in Foliotek Presentation.

Geoff Leigh and I worked together, thinking about the color picking process from scratch and came up with a good workflow, I think.

Common Palettes

The palettes on the top are commonly used colors that are ‘sticky’. These are easy ways to grab a color that looks about right, and makes it easy to reuse colors. Clicking on any element from a palette instantly chooses the color and closes the colorpicker.

Template Palette

Part of what makes Foliotek Presentation cool is that we know so much about the designs that people use by analyzing the CSS and color changes that they do in our template editor. With this information, we bind a list of colors that are being used in their template. This opens up possibilities like reusing a heading color to accent a certain word in their portfolio.

User Colors

This is a list that remembers which colors you have chosen. It uses the localStorage object. It will automatically add any color you select that isn’t in the above palettes.

Since it is automatic, users do not need to add/remove/edit the custom palette. Right now, we think this is better than presenting the user with an interface for setting custom colors. We originally had some designs that handled this management, but we decided to go with the simpler solution for now.

Going Forward

I hope to continue development and make this the best JavaScript colorpicker available, keeping these goals in mind:

  • Good UX
  • Cross Browser Compatible (IE6 and up)
  • Doesn’t use any images
  • Easy to skin via CSS
  • Simple interface / easy to integrate with app

I am very happy with the changes and excited to be working on projects like these! You can follow development of the plugin, suggest features, or report bugs here:

Foliotek Open Sources AjaxQ jQuery Plugin

We have a lot of components we have built (and are in the process of building) for our presentation portfolio and assessment products.

We have decided to contribute some of this work to the open source community. The first one is a jQuery plugin for managing sequential ajax requests, called AjaxQ.

See the AjaxQ documentation or jump straight to the demonstration.

It is designed to follow the $.ajax, $.get, and $.post interfaces and return values, only taking one extra parameter (the queue name). Here is a brief sample of the functionality:

 $.ajaxq (“MyQueue”, {  
     url: ‘’,  
     type: ‘post’,  
     dataType: “jsonp”  

$.postq (“MyQueue”, ‘path/to/your/resource’, onsuccess);

$.getq (“MyQueue”, ‘path/to/another/resource’, onsuccess);  

Each request will only run once the other finished.

All of the source code is available on Github, available under the MIT License.

Copy Images from Clipboard in Javascript

One of the pretty common in a Windows environment is copy/pasting image data across programs. In recent versions of chrome, this is now possible in the browser. Here is a quick demo of the javascript we’ll be starting from — you can copy image data from anywhere (Paint, Word, Screenshot, etc) and paste it into the div to have it appended.

This just appends an image that looks something like:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIkAAAAqCAYAAACHr...C">  

Which is pretty powerful in it’s own right, but it’s not terribly well supported across browsers – for Foliotek Presentation, ideally we would create a file they can manage just like any of their other files from the paste data, so, with a quick change to the reader.onload, we’ll upload the image to the server:

reader.onload = function(evt) {  
    var result =; 
    var arr = result.split(","); 
    var data = arr[1]; // raw base64 
    var contentType = arr[0].split(";")[0].split(":")[1]; // image/png, image/gif, etc 
    $.post("imageupload", {
        data: data, contenttype: contentType,
    }, function (ev) {
        var img = $("<img style='display:none;' src='" + ev.URL + "' />");
        img[0].onload = function () {
            var width = img.width();
            var height = img.height();
            var src = "<img src='" + ev.URL + "' width='" + width + "' height='" + height + "' />";
            div.append($(src)); img.remove();

And the content of the “imageupload” server route is pretty straightforward, and not too different than what you’d have for uploading an image from Post data:

 public JsonResult imageupload(string data, string contenttype) {
    byte[] bytes = Convert.FromBase64String(data);
    var ms = new MemoryStream(bytes, 0, bytes.Length);
    UserFile file = SaveByteArrayAsUserFile(User, bytes, contentType); // saves the content as a file associated with that user 

    return Json(new {

Pretty powerful, and definitely one further step in making web-apps feel like native OS apps.

Color Scheme Generator in JavaScript

ColorStash is a tiny web app I built for the 10K Apart contest. The goal of the contest is to build an application in under 10 Kilobytes. This includes all HTML, JavaScript, CSS, and images. This is a tight limit, but luckily you can include jQuery and not have it count against your size quota.

The main goal is to provide an easy way for to choose a nice color or scheme, and output those colors in a variety of formats. It supports hex, css names, rgb, hsv, and hsl as input and output formats. You don’t really need to know anything about these formats to use the colorpicker or built in image eyedropper.

I started learning about color when working on the template editor and color schemes

You can read more, check out the 10K entry, or see the more permanent (and possibly bigger than 10K as I make updates) app here:

Web Application Functional Regression Testing Using Selenium

At Foliotek, we use a rapid development methodology.? Typically, a new item will go from definition through coding to release in a month’s time (bucketed along with other new items for the month).? A bugfix will nearly always be released within a week of the time it was reported.? In fact, we are currently experimenting with a methodology that will allow us to test and deploy new items individually as well – which means that a new (small) item can go from definition to release in as little as a week, too.

Overall, this kind of workflow is great for us, and great for our customers.? We don’t need to wait a year to change something to make our product more compelling, and customers don’t have to wait a year to get something they want implemented.? We also avoid the shock of suddenly introducing a year’s worth of development to all our customers all at once – a handful of minor changes every month (or week) is much easier to cope with.

However, it also means that Foliotek is never exactly the same as it was the week before.? Every time something changes, there is some risk that something breaks.?? We handle this risk in two ways:

  1. We test extremely thoroughly
  2. We fix any problems that arise within about a week (severe problems usually the same day)

At first, we did all testing manually.? This is the best way to test, assuming you have enough good testers with enough time to do it well.? Good testers can’t be just anyone – they have to have a thorough knowledge of how the system should work,they have to care that it does work perfectly,and they have to have a feel for how they might try to break things.? Having enough people like this with enough time to do testing is expensive.

Over time two related things happened.? One was that we added more developers to the project, and started building more faster.? Two was that the system was growing bigger and more complex.

As more people developed on it and the system grew more complex, our testing needs grew exponentially.? The rise in complexity and people developing led to much, much more potential for side-effects – problems where one change affects a different (but subtly related) subsystem.? Side-effects by their nature are impossible to predict.? The only way to catch them was to test EVERYTHING any time ANYTHING changed.

We didn’t have enough experienced testers to do that every month (new development release) let alone every week (bugfix release).

To deal with that, we started by writing a manual regression test script to run through each week.? While this didn’t free up any time overall – it did mean that once the test was written well, anyone could execute it.? This was doable, because we had interns who had to be around to help handle support calls anyways – and they were only intermittently busy.? In their free time they could execute the tests.

Another route we could have gone would have been to write automated unit tests ( Basically, these are tiny contracts the developers would write that say something like “calling the Add function on the User class with name Luke will result in the User database table having a new row with name Luke”.? Each time the project is built, the contracts are verified.? This is great for projects like code libraries and APIs where the product of the project IS the result of each function.? For a web application, though, the product is the complex interaction of functions and how they produce an on screen behavior.? There are lots of ways that the individual functions could all be correct and the behavior still fails.? It is also very difficult to impossible to test client-side parts of a web application – javascript, AJAX, CSS, etc.? Unit testing would cost a non trivial amount (building and maintaining the tests) for a trivial gain.

Eventually, we discovered the Selenium project ( The idea of Selenium is basically to take our manual regression test scripts, and create them such that a computer can automatically run the tests in a browser (pretty much) just like a human tester would.? This allows us to greatly expand our regression test coverage, and run it for every single change we make and release.

Here are the Selenium tools we use and what we use them for:

  • Selenium IDE ( : A Firefox plugin that lets you quickly create tests using a ‘record’ function that builds it out of your clicks, lets you manually edit to make your tests more complex, and runs them in Firefox.
  • Selenium RC ( A java application that will take the tests you create with Selenium IDE, and run them in multiple browsers (firefox, ie, chrome, etc).? It runs from the command line, so its fairly easy to automate test runs into build actions/etc as well.
  • Sauce RC ( A fork of RC that adds a web ui on top of the command line interface.? It’s useful for quickly debugging tests that don’t execute properly in non-firefox browsers.? It also integrates with SauceLabs – a service that lets you run your tests in the cloud on multiple operating systems and browsers (for a fee).
  • BrowserMob ( An online service that will take your selenium scripts and use them to generate real user traffic on your site.? Essentially, it spawns off as many real machines and instances of FireFox at once to run your test – each just as you would do locally – for a fee.? It costs less than $10 to test up to 25 “real browser users” – which actually can map to many more users than that since the automated test doesn’t have to think between clicks.? It gets expensive quickly to test more users than that.

Selenium is a huge boon for us.? We took the manual tests that would occupy a tester for as much as a day, and made it possible to run those same tests with minimal interaction in a half hour or less.? We’ll be able to cover more test cases, and run it more – even running them as development occurs to catch issues earlier.

In my next post, I’ll talk about the details of how you build tests, run them, maintain them, etc. with the tools mentioned above. See it here: Selenium Tips and Tricks

Also, for Selenium 2 with ASP.NET Web Forms, see Simplifying C# Selenium 2 Tests for ASP.NET WebForms