About Us

Bulletpoint StarImulus® is a technology focused design + interactive agency.

In addition to our client services we also have a few products in the works. Our office is always filled with chatter and this blog is an outlet for our creative energy, rants and ideas.

Podium

Stacks!
Imulus built a task management solution that finally works for teams. It's a life saver, learn more at usestacks.com.

Featured Project

Nov28

An Interesting Challenge

Last week we had a client call us with an interesting problem. They have a tradeshow kiosk they’d like to use to capture form data from users and collect it at the end of each day.

The challenge: the kiosk doesn’t have an internet connection and can’t run a webserver. It can display webpages, but only through an IE8 iframe.

If the kiosk had a net connection we’d build a static form to post the data to a remote webservice. But that’s out. If the kiosk could run a webserver we’d build a simple webapp to handle the data locally. But that’s out, too.

We decided to solve the problem by saving the data to localStorage. localStorage is a key-value store built into most modern browsers, and a perfect mechanism for persisting simple form data. It has a minimal JavaScript API (setters and getters) via the window’s localStorage object that makes it really easy to work with.

Here’s how we did it:

We started by setting up a simple Storage class to interface with localStorage. This isn’t entirely necessary, but makes it easier to save and retrieve the data without having to parse/stringify on every transaction. (Yes, we love CoffeeScript.)


class Storage

  constructor: (@name)->
    @data = []

    # Check to see if the object already
    # exists in localStorage
    # If it does, grab the value
    # Otherwise, create a key in localStorage
    # with an empty array of data
    if localStorage[@name]?
      do @fetch
    else
      # We need to stringify the data as JSON
      # because it is stored as a string
      localStorage.setItem(@name, JSON.stringify(@data))

  # Pull the data out of localStorage and populate
  # the instance's @data array property
  # We need to parse the data as JSON
  # because it is stored as a string
  fetch: ->
    @data = JSON.parse(localStorage.getItem(@name))

  # Add an item to the instance's @data array and
  # re-save to localStorage
  add: (data) ->
    @data.push data
    localStorage.setItem(@name, JSON.stringify(@data))

Next, we set up a Form class to observe the form on the page and do some simple validation before finally committing it to a storage instance.


class Form

  constructor: (@$form, name)->
    @storage  = new Storage(name)
    @$fields  = $('input, textarea, select', @$form)

    @$form.submit (event) =>
      event.preventDefault()
      if @validate()
        do @save
        do @clear

  save: ->
    data = {}

    @$fields.each ->
      name  = $(this).attr('name')
      value = $(this).val()
      data[name] = value

    @storage.add data

  clear: ->
    @$fields.each ->
      $field = $(this)
      type = $field.attr('type')
      $field.val('') if type is 'text'

  validate: ->
    data = {}
    valid = true

    # Simple 'required' validation
    # Loop over each of the form fields
    # If the field is required, then check to see if it is blank
    @$fields.each ->
      $field = $(this)
      value = $field.val()
      required = $field.hasClass('required')
      if required and value is ''
        valid = false
        $field.addClass('invalid')
      else
        $field.removeClass('invalid')

    return valid

The client needed a means of retrieving the data, so we set up way to grab all of the data and render out a table with each of the entries.


class ResultsTable
  constructor: (@$table, name) ->
    @storage  = new Storage(name)
    @results = @storage.data
    $head_tr = $('<tr />')

    for field, value of @results[0]
      $head_tr.append $('<td />').text(field)

    $('thead', @$table).append $head_tr

    for result in @results
      $tr = $('<tr />')
      $tr.append $('<td />').text(value) for field, value of result
      $('tbody', @$table).append $tr

Finally, an example of how to pull it all together.

On the form page:


<form id="user-form" action="#">
  <input type="text" name="first_name" />
  <input type="text" name="last_name" />
  <button type="submit">Submit</button>
</form>

<script type="text/javascript">
  $(document).ready(function(){
    new Form($('form#user-form'), 'kiosk');
  });
</script>

On the results page:


<table id="results">
</table>

<script type="text/javascript">
  $(document).ready(function(){
    new ResultsTable($('#results'), 'kiosk');
  });
</script>

Given the constraints, we feel like this is great solution. Lucky for us, the browser environment was predictable and IE8 has support for localStorage. All in all, it was a fun experiment with localStorage.

Nov16

At Least Three States

A few weeks ago Microsoft released a video showcasing their idea of what the future of technology might look like. Some weeks later, Bret Victor wrote a rant about how unimaginative Microsoft’s vision is. The thrust of his argument is that the ubiquitous touchscreens depicted in the video are uninventive because it disregards the most fundamental and powerful tool known to man: our hands. He explains that the physical interfaces of today don’t take advantage of our hands’ ability to both feel and manipulate things.

All this talk about hands and feeling and manipulation got me thinking. Given the current state and inertia of technology, it should be our foremost goal to make our interfaces feel good.

Feeling is often the indescribable property that separates a good interface from a great one. It’s the gap between the pixels and your finger (or mouse, by extension). You hear people mention this all the time when talking about software; “I don’t know, it just feels good”. Of course they’re not actually talking about how it feels, they’re talking about how their brain perceives it would feel if it were a physical interface. They’re talking about how well it responds to their input.

Without tactile feedback, as is the case when using a touchscreen or navigating a mouse cursor around a screen, our brain can’t depend on our hands and instead relies on our eyes to proxy visual feedback. We use this information on a subconsious level to confirm our last action and plan our next one. How an interface feels is the fidelity of the visual feedback to how our brain predicts it should feel.

It’s easy to see how important visual feedback becomes to the user experience in the absense of tactile feedback. It explains why skeuomorphism has prevailed as a common user interface design approach: it’s comforting to us as users when what we see and feel in the virtual world matches our perception of the physical world. This is why buttons often look like buttons and calendars often looks like calendars.

But how an interface feels goes deeper than the pixels on the screen; it’s all about trust. As an interface designer, you enter a contract with your users. Your design implicitly guarantees the user: “When you click X, the software will do Y”. It’s the job of your interface to back this guarantee by providing the feedback necessary for the user to feel assured you kept your end of the bargain. The gap between what your UI promised and what was delivered is received by the user as negative feeling. We’ve all experienced it, that brief moment of cognitive dissonance when you beckon the software to do one thing and it appears to do something different, or worse, nothing. That’s broken trust.

I have long preached that every clickable element (links, buttons, etc) deserves at least three states: idle, hover and click. I also encourage additional states for active-hover and active-click, but they are less necessary. Even novice designers know to make the idle state of their links obvious, but it’s surprising how many neglect to provide the user proper hover and click states. The hover state signifies that the element is clickable at this moment and the click state confirms that the element was clicked, both of which are crucial to keeping up your end of the UI contract.

The very best user interfaces are those that have a two-way conversation with the user, with equal transmission amplitude from both parties. When the visual feedback provided by your interface falls short of what the user expected, you’ve subconsciously broken their trust and left them with an indescribable feeling of doubt.

Oct12

Using SublimeVideo HTML5 video with generated HTML

Recently we pushed a massive update to Stacks, our group task management solution. Part of this update was reworking the onboarding and help process for users — instead of using totally separate pages we moved to a simple lightbox solution that could be loaded on any page. This allowed us to show a lightbox whenever it was requested programmatically or by the user. For additional flexibility (and to save loading time) we made the lightbox ajax in whatever HTML content was needed. This process works great, but it did cause a few issues with our recently implemented HTML5 video script, SublimeVideo.

lightboxed

A few words about SublimeVideo

SublimeVideo is not video hosting platform like Wistia, Vimeo, or Ooyala, instead it’s just a javascript player that makes populating already-hosted videos incredibly easy. On most sites you simply include the javascript snippet provided by SublimeVideo and add a class to your video elements that calls the script, like so:

<video class="sublime zoom" width="1026" height="572" ⌉
preload="none">
	<source src="http://site.com/video.mp4"/>
	<source src="http://site.com/video.ogg"/>
</video>

This will immediately replace all of the video elements with a beautiful HTML5 player and Flash fallback for browsers that either, don’t support HTML5 video, or don’t support that particular video format. For most day-to-day scenarios this is perfect and is by far the easiest solution I’ve seen.

The Catch

SublimeVideo’s script works by looking at the source once loaded, grabbing all of the video elements, and then applying the player to those elements. However, with the Stacks lightbox solution the video elements are being loaded only after the lightbox gets ajaxed, therefore they aren’t available via the initial DOM load. This means that playing videos within the generated HTML won’t work. It also means the sublimevideo video lightbox won’t work either.

Basically SublimeVideo has two object states. First, when the script is loaded without video being detected and is waiting to be called. Second, once the object has been told there is video on the page to work with. See the states below:

object-instances

The Solution

In order to get the sublime video object to run we need to load it under a document.ready function, SublimeVideo supposedly has a sublimevideo.ready function that is more accurate than document.ready but it doesn’t seem to work. Instead, use the following method to load up the sublime object when no video lives on the page:

<script src="/link/to/sublimevideo.js"></script>
<script>
	$(document).ready(function() {
		sublimevideo.load();
	});
</script>

Then, when the lightbox (or generated HTML) appears you’ll need to associate each video with the sublimevideo object (remember, it doesn’t know these new video calls even exist):

<script>
	$('video.sublime').each(function(){
	    sublimevideo.prepare($(this).el);
	});
</script>

The above method will grab all the video elements with a class of ’sublime’ and push them to the sublimevideo object for preparation. That’s it, now the generated HTML will re-associate all videos and work with the player properly.

Sep21

ClickTime API Wrappers for Ruby and JavaScript

For a few internal projects at the Imulus office, we’ve been collecting timesheet data from the tracking software we use, ClickTime. Lucky for us, they offer an API with full access to all of our data. Unfortunately, however, it’s a SOAP API.

SOAP can be a bear, so we’ve rolled some code to help alleviate the pain of working with it:
a Ruby wrapper and a JavaScript wrapper. Both are open source, and we hope they make your life easier. Below are some examples of how to use them.

Ruby

The Ruby wrapper (ruby-clicktime) comes in the form of a single file with one class, ClickTime.

Requirements

ruby-clicktime uses Savon, so be sure to install that first:

$ gem install savon

Usage

The ClickTime class has two methods:

ClickTime#actions will return a list of all actions available to the ClickTime SOAP API

clicktime.actions  # un_sync_all, get_sync_id, set_sync_id, ...

ClickTime#exec will execute an API call and return a hash of results

clicktime.exec :api_action, {params}

Example

First, create an instance of the ClickTime class:

require 'clicktime'

clicktime = ClickTime.new :key => 'api-key', :password => 'password'

The GetEmployeeList and GetClientList API methods, as defined in the ClickTime API docs:

<GetEmployeeList xmlns="http://clicktime.com/webservices/2.2/">
	<UserID>string</UserID>
	<ActiveOnly>boolean</ActiveOnly>
</GetEmployeeList>

<GetClientList xmlns="http://clicktime.com/webservices/2.2/">
	<UserID>string</UserID>
</GetClientList>

To execute these queries, you would call the following:

employees = clicktime.exec :get_employee_list,
    {"UserID" => 'your-user-id', "ActiveOnly" => 'true'}
clients = clicktime.exec :get_client_list, {"UserID" => 'your-user-id'}

Notice the action is passed as a snake_case symbol from the list of available actions. (clicktime.actions to list them)

JavaScript

The JavaScript wrapper is a CommonJS module, ready for use in your Node.js project via npm.

Installation

In your project:

$ npm install clicktime

And in your script:

var ClickTime = require('clicktime');

Example

First, create an instance of the ClickTime object:

var clicktime = new ClickTime({
  key: 'your-api-key',
  password: 'your-api-password'
});

The GetEmployeeList API method, as defined in the ClickTime API docs:

<GetEmployeeList xmlns="http://clicktime.com/webservices/2.2/">
  <UserID>string</UserID>
  <ActiveOnly>boolean</ActiveOnly>
</GetEmployeeList>

To execute this query you would call the following:

clicktime.exec('GetEmployeeList', {
    UserID: 'some-user-id',
    ActiveOnly: true
  }, function(response){ // your callback function
    console.log(response);
  }
);

Reference

Source code:
ruby-clicktime on GitHub
node-clicktime on GitHub

ClickTime SOAP API Documentation:
http://app.clicktime.com/documentation/webservices/2_2/WebServicesDocumentation_2_2.asp

Sep1

Exposing an Imulus Discussion: Should Designers Know how to Code?

The following is the result of an email conversation from our team here at Imulus. We thought we’d post our differing opinions.

Taylor Smith
Chimero on Designers Learning to Code http://blog.frankchimero.com/post/9594863189
And on a related note, here’s a nice site to learn JavaScript: http://www.codecademy.com/

Scott Hooten
I don’t see a place to comment on his site, but I totally disagree. Maybe I am challenged in that part of my brain, but working on code consumed so much of my time that I had very little time left to think about and further my design skills. I don’t think his point about print design skills is valid, because what I learned about printing 20 years ago is pretty much the same.

Bruce Clark
I’ve come around on this to an extent. When first starting at Imulus I felt designers needed to code. Looking at it now, I think along the lines of what Malcom Gladwell talked about in Outliers. Basically that to be an expert in something it takes a fuck-ton of practice. To be a great designer you need to spend a lot of time designing. To be a great developer you need to spend a lot of time developing.

Can you do both? Sure.
Will you be as good at one or the other compared to doing one full time? No.

A designer needs to know the constraints of the interface they are designing for (and only to a point, as design should push boundaries). In some instances knowing the constraints can be taught by learning how to code, in others it just means having a ton of experience designing for that interface.

I will say, a lot of firms don’t look at design like Imulus. They expect designers that can code. I don’t know if this is good for them, but it’s what they expect. The truth is a designer that can code probably does have better luck getting hired in the industry.

Bryce Hammond
I’ve only met two designers who could write great code, and who had great design. One was swiped back by 37Signals and the other is still one of the creative director’s at Wall Street that started the mobile app team with me. On the whole great designers don’t code and great coders don’t design well (I think their are some crossbreeds in the front end developers, especially at Imulus :) . I’m personally hopeless without a designer. The world needs to be saved from engineer designed interfaces.

Scott Hooten
Going back to the print design analogy. I don’t need to know how to run the press to know that I can’t print an 8 color design on a 6 color press. It’s important to understand your medium, but you don’t need to be an expert on all the inner workings to design for it. 

On another note, I still think a day will come when great websites can be built without writing any code. I’ve designed a ton of stuff in Postscript, but never written a single line of Postscript. It’s been rendered by printers and image setters and platemakers from a lot of manufacturers. Obviously the web is more complex because it is interactive and variable, where print documents are static, but it’s hard for me to believe that as the web matures that it won’t be possible.

Taylor Smith
I think I disagree. I don’t think designers need to learn how to program, but I think there’s a huge value in learning how to write HTML and CSS, even if it’s rudimentary. I don’t think I can think of a single high profile web designer who doesn’t know how to code. Sure, maybe they’re not experts at it, but I think having an intimate knowledge of the medium makes their work that much better.

Looking at using something like CSS3 media queries to create responsive designs – I think it took the creativity of a designer to figure out how they could be used the way they are now, and apply it to a site’s design. My guess is that the first wave of developers who took a stab at creating responsive sites this way were also designers.

As for building sites without code, I disagree unless there’s a huge shift. Casey and I have been discussing this lately. Looking at Google+ source code, they’ve clearly come up with a system for building sites where the benefits of the build process outweighs the loss of semantic HTML. That’s kind of fucking awesome, but the standardistas probably hate it. I can see this becoming standard practice eventually, though. If Google, et al is smart enough to figure out your sites content, then who gives a fuck if your code is semantic. And with JavaScript taking off like crazy, who gives a fuck if your site even has markup? See: https://twitter.com/#!/jashkenas/status/108343261906735105

I do, however, believe a better application for designing sites will eventually come to fruition, built upon webkit, just as JSM predicted: http://v4.jasonsantamaria.com/articles/a-real-web-design-application/

I think an app like that would be a huge improvement for designers. It would get them out of the fixed width world and give them the opportunity to design buttons with multiple states, and all that fun stuff. But even if it could save out HTML/CSS, I still don’t think it will give you the level of detail and precision that we pride ourselves on building.

Casey O’Hara
To Scott’s point: I can also imagine the day tools have evolved to a point where websites can be built without writing any code.

Taylor and I have been tossing this idea around a lot lately, specifically about how important the core web stack (HTML/CSS/JS) will be moving forward. The markup behind Google Plus is an indication that they’ve developed a tool that generates most of it for them. Also, Joe Hewitt (inventor of Firebug, iOS dev at Facebook) and Jeremy Ashkenas (inventor of CoffeeScript, Backbone, Underscore and a ton of other stuff) have been talking recently about the concept of “empty body tags” — where basically all markup is generated. Seems to be working for them.

HTML and CSS are coming off a huge movement for standards and semantics. This was great because it got a lot of designers and developers in the right mindset and got the browser vendors to catch up and lead the way forward. Perhaps we’re reaching the point where these technologies just don’t matter anymore.

That said, web programming isn’t going away. It doesn’t matter how much the tools evolve. Even today it’s possible to create a “good” website without writing a line of code (think Dreamweaver), but a “great” website or complex web application? Forget it.

We have robots that can build cars, but Ferrari still builds every engine by hand.

Scott Hooten
I agree that web programming is not going away. I just wonder in 15 years with increased bandwidth and much faster computers and mobile devices how much of the web could be created with an app rather than writing code. I would say right now you can get an econo box out of Dreamweaver without messing with code. In 15 years maybe you can get a Toyota Camry. The Ferraris are still going to be built by hand.

Casey O’Hara
One thing I’d like to add is that since being at Imulus I’ve grown to really appreciate and rely on the expertise of the designers as true specialists. As a developer, I see a huge benefit in being able to treat a design as a build spec. In the same way that you wouldn’t want your architect swinging a hammer.

Agreeing with Bruce, the distinction between designers, developers and programmers is what makes Imulus special.