Strake ?

My Show ‘N Tell is a bit short on substance this week, but I wanted to mention a couple of things.

First off, I wanted to remind anyone who’s reading this that Show ‘N Tell Fridays are something I made up in hopes of getting lots of people to share stuff they’ve been working on. I’d love to see more people post something that they could share with their friends/followers/peers/stalkers/etc. It doesn’t have to be design or development related. Heck, it doesn’t even have to be on a Friday. Tumblr users can tag their post with #sntf so that they show up in the global Tumblr #sntf bucket. FWIW, my Show ‘N Tell posts can be found here.

On a share-your-stuff note, I’m now posting a few things on Dribbble thanks to an invite from Paulo Pereira - thanks again, Paulo! For anyone interested, you can find me at http://dribbble.com/players/jasonlong.

As for things I’m working on, the last week or two has been mostly unexciting maintenance work. I am, however, getting jazzed about doing some redesign and development work for the healthcare app that I built a couple of years ago. We’ve learned a lot about which parts could be improved, which need to be more flexible, and which are better off just stripped out. In addition to planned improvements to the visual treatment, I’ve made a list of the pieces of tech that I plan on using (or upgrading to a more current version of).

• HTML 5
• More CSS3, including ZURB’s Super Awesome Buttons
• Rails 3 w/ full RESTful API
• Bundler
• Formtastic
• jQuery 1.4.x
• jQuery UI 1.8
• Sass - the time has definitely come
• Haml - I know I poo-poo’d it a few weeks ago, but I’m going to give it a fair shot
• Cucumber
• Shoulda, Factory Girl, and Clearance from Thoughtbot
• Selenium or similar for browser testing
• Twilio for SMS messages, already using it - recommended!
• Postmark - need to evaluate if it seems better than our current mail setup using DomainKeys and SPF Validation.

I’d also like to take advantage of the RESTful API to build a proof-of-concept iPad app that could be used in the field by caregivers using our application.

So there you have it - perhaps some of these topics will come up in future Show ‘N Tells.

My previous Show ‘N Tell Friday posts have been mostly technical, so I thought I’d follow Jean-Philippe Cyr’s lead and use this opportunity to show my work environment. In the spirit of The Setup, here’s a look at my world.

Hardware

I use a 27” iMac i5 with 8GB of RAM. Even though it looks awful next to the iMac’s beautiful display, I use my old 23” Cinema Display for the additional 2,304,000 pixels. For the most part, I like the Magic Mouse - my only beef is that it’s somewhat loud on the (IKEA Galant) desk surface. Sound waves come from a pair of JBL Creature Speakers and subwoofer. I have a Wacom Bamboo tablet that works very well, but I haven’t gotten in the habit of using it much yet. An HP Color LaserJet and Epson Workforce 600 handle printing, scanning, copying, and faxing needs. I use an iPhone 3G and, like a good fanboy (and stockholder), a brand new iPad (16GB). My rear end gets parked in a Steelcase Leap chair most of the day (definitely worth the dough).

Other hardware favorites include blank copy paper, Sharpie fine tip pens, grey Prismacolor markers, and a big, fat Graphiti Grip 2mm mechanical pencil (as seen here).

Software

For coding, I use MacVim and TextMate. For pushing pixels, I use Photoshop (CS3 still, undecided about CS5 upgrade) for heavy lifting and Acorn for quick, tactical assaults. xScope is indispensable for checking alignments, colors, etc. I like to sketch rough wireframes on paper and then use Balsamiq Mockups.

For browsers, I like Chrome and Safari and really only use Firefox for testing (Firebug is tough to beat). I fire up Fusion and IETester (and pop a Valium) when I need to check my work in IE. About half of my projects use MySQL (the other half being PostgreSQL) and I like Sequel Pro for poking and prodding tables.

For general biz needs, I use Gmail, Google Calendar, and Google Docs via Google Apps. Time tracking and invoicing is handled with Harvest and bookkeeping with QuickBooks (ugh!). I didn’t use it for a while, but I now find 1Password an absolute must-have. I use SuperDuper for backups (to a 1TB MyBook) and Dropbox, Evernote, Taskpaper (lightweight GTD), and Notational Velocity (with Simplenote syncing) for “cloudy” needs.

When I’m working with the Relevance guys, I stay in touch with Talker (running in Fluid).

* Tumblr readers should click through for code samples since the embedded snippets don’t render in the dashboard view.

Just a quick little tip this week. Most of my current projects are making use of Formtastic for generating forms. This tip is slightly Formtastic-specific, but could easily be adapted to any form markup.

One project in particular is extremely form-heavy, with a multiple step application (wizard-ish) process with many fields per step. The custom Formtastic CSS is pretty complex and styling elements with an error state came up as a task that needed some improvement this week.

Formtastic takes Ruby code that looks like

and generates markup like

Arguably a bit verbose, but we’re armed with several hooks for doing custom styling. When a form is submitted and doesn’t validate on the server, it will re-render this form and the line item for the invalid fields will include an “error” class.

And now with a couple of CSS tweaks, we can dynamically add a custom error marker next to each invalid element’s label.

Now create a custom PNG marker - perhaps something like this:

And add a dash of jQuery to drop them in:

A sample of the end result:

Over the past year, I’ve had the pleasure of working with Sustainable Harvest by way of Relevance. Sustainable Harvest is one of the largest buyers of organic fair trade in the US and they train hundreds of thousands of farmers across the globe in best practices in coffee production and quality control. Apple has even written a business profile about them.

The applications that we’ve been building for them help the company’s supply chain manage the flow of coffee beans from farmer to roaster with a constant eye towards quality testing each step of the way.

The application that we’re currently working on will be used in the field by washing stations and dry mills in these various countries. The tool will allow the users to improve their process of recording which farmers brought which coffee cherries in for processing, how they were washed, dried, milled, and combined into larger units for storage and shipping.

The gentlemen in the photo above were part of a user testing session that took place earlier this week. Silverback was used for capturing the users’ sessions while they were asked to perform various tasks. Updates to the application will come once we have a better analysis of the Silverback videos (which, in turn, await a viable way to make their way back to the product team - most likely on CD or DVD since Internet bandwidth is rather limited from Tanzania).

One interesting bit of feedback made it’s way back to already though. I designed the interface to use big and “chunky” elements. We knew that the eventual users would be very intelligent people, but not necessarily proficient with computers, so the UI was created to feel more like a simple kiosk than a traditional web app.

It turns out that the users are actually used to visually scanning spreadsheets full of dense data and had difficulty quickly identifying items in this style interface. +1 for real world user testing.

I’ve worked remotely on projects for many years now, but this one really takes geographic diversity to an entirely different level. I’m working in Ohio with the development team in North Carolina for a client in Oregon and building an application for people in Africa. How great is that?

All photos courtesy Sustainable Harvest

I spent a little time this week tinkering with Processing.js for the first time. I dabbled with the original, native Processing app a while back and have been wanting to get back into it for a while. My interested has been rekindled by all of the amazing things people have been creating with <canvas> lately.

For my initial experiment, I choose to keep it simple but interesting enough to be somewhat useful. I’ve got a working “sketch” (as apps are called in the Processing community) that grabs the top artists in a given tag from Last.FM and renders them as moving circles on the screen. The more popular the artist, the larger the circle. Some basic collision detection is in place to make sure all of the circles stay in the viewable area. The sketch is currently hardcoded to use the “alternative” tag and a hardcoded, recent chart listing. See it in action here.

And that’s about it really. I’m not sure exactly where I want to take this, but I’ve got a few ideas:

• Add a lightweight UI so that users can select different tags/genres.

• Allow users to enter their own Last.FM username to see personalized visualizations.

• Add the ability to click on a circle to bring it front and center with additional artist information (ie. artist photo, description, similar artists, etc.).

• Compare the artist’s current popularity with the previous week and set the circle’s velocity to be faster for artists gaining popularity and slower for artists that aren’t as hot.

• Resize everything if the user resizes the browser window.

Fork me? No fork you!

For those who are interested, I’ve created a public Github repository for the code. You’re welcome to fork it, clone it, etc., but two notes:

1. Realize that this code is pretty much proof-of-concept quality and badly needs refactored. Don’t look to this for best practices (yet).

2. Please change the Last.FM API key if you play with it on your own.

Here are a few interesting tidbits from this experiment:

• The built-in Processing map() function is very handy. This allows you to take a value within a known range and map it to another range. In this case, I’m using the “weight” that Last.FM returns for each artist to set the radius of the circle. Initially I found a multiplier to use to reduce the weight down to a reasonable size, but this was based on Radiohead (enormous weight value). When I looked at the electronic tag with this same multiplier, all of the circles were tiny. Using map() let’s you evenly map radius values between say 0 and 200 no matter what the largest weight is. Taking this idea a step further, the largest radius I map to is 1/8 the size of the window. This way everything scales nicely in a small browser window or a larger one.

• jQuery’s getJSON() works asynchronously only. This is usually fine, but in my case I wanted to call the API method that gives you a list of valid chart dates that you can use on subsequent calls. Since both calls fire off asynchronously (that is, they don’t wait around for a response), you can’t set a value from the first and use it in the second. I need to switch to using ajax() instead because you can set async: false;

• The Processing.js docs list a bunch of Processing proper methods that are not implemented, but this list is not up-to-date. Check the processing.js file when in doubt.

As a reminder, Show ‘N Tell Fridays are for anyone to talk a little about something they’ve worked on recently and it doesn’t have to be web design/development related. If you aren’t on Tumblr, drop me a line with a link to your post - I’d love to see what others are doing.

One of my ongoing projects is the street sign management application from Elumena. The software is used by towns and cities for keeping track of all of their signage and the information about them - their GPS coordinates, condition, installation date, etc. - about 30 fields in all. The application is primarily used by crews in the field using Motion F5 Tablet PCs. There are several interesting pieces of the application (and the client has given me free reign to discuss it all), but I thought I would touch on the searching and filtering UI today.

This is a feature I built about a year ago, but I’ve been doing some updates to it this week so it’s fresh in my mind. The original search implementation was very basic and it quickly became apparent that we needed a more robust tool. My initial inspiration was the search filter tool at MyFonts.com. Having the ability to combine any number of filters would be a big win for Elumena users.

The new filtering mechanism looks like this (see larger).

The actual search on the server is handled by the fantastic Searchlogic Rails plugin. Assuming you can massage the form parameters into the right syntax for Searchlogic, you have hardly any work to do on the back-end. In fact, the entire controller action for all of this looks like this.

def index
  @search = Sign.new_search(params[:search])
  @all_signs, @signs_count = @search.all, @search.count
  @signs = @all_signs.paginate(:page => params[:page])  
  @map_signs = build_simple_signs(@all_signs)    
end

The new_search method is doing all of the real work. The other variables are for getting the total result set of matches for display on the map (for which I’m using MarkerClusterer, a possible future Show ‘N Tell topic) as well as the pagination pieces.

The rest of the work is on the client-side. When the user clicks the “add” icon, the jQuery clone() function copies that filter row and places it just below the current row. jQuery event handlers are then used to watch for changes on the type of filter (ie. Street Name, Sign Condition, etc.) and updates the associated options. A “template” of all of these options are loaded with the page (in a hidden container) and copied as needed.

<select id="asset_id_filter_type">
    <option value="is">is</option>
    <option value="is_not">is not</option>
    <option value="at_most">is at most</option>
    <option value="at_least">is at least</option>
</select>

<select id="background_color_filter_type">
    <option value="is">is</option>
    <option value="is_not">is not</option>
</select>

<select id="detailed_condition_filter_type">
    <option value="is">is</option>
    <option value="is_not">is not</option>
</select>

etc...

<div id="asset_id_filter_values">     
    <input type="text" class="search_entry text" />
</div>

<div id="background_color_filter_values">     
    <select class="search_entry">
        <%= options_for_select(BackgroundColor.to_dropdown) %>
    </select>     
</div>

<div id="detailed_condition_filter_values">       
    <select class="search_entry">
        <%= options_for_select(DetailedCondition.to_dropdown) %>
    </select>     
</div>    

etc...

These form elements, however, are not used on the back-end since they are not in a Searchlogic-friendly format. The final piece to the puzzle is to have one more jQuery event handler that updates a hidden field for each filter. Something along these lines:

$.fn.updateSearchValue = function() {  
  return this.each(function() {  
    var filter_field = $(this).find('select.filter_field').val();
    var filter_type  = $(this).find('select.filter_type').val();

    $(this).find('.search_value')
              .attr('name', "search[conditions][" + filter_field + "_" + filter_type + "]");      

    // get the value if it's a dropdown
    if ($(this).find('select.search_entry')) {
        $(this).find('.search_value')
                  .attr('value', $(this).find('select.search_entry option:selected').text());       
    }           
});

I glossed over a lot of the details obviously, but hopefully this helps illustrate how the use of a solid server-side tool can be used “out of the box” with some creativity on the front-end.

Ok, so this is my first attempt at my Show ‘N Tell Fridays thing. This is a look at one of the things I worked on recently, but I’d love to see others continue this trend and show what fun stuff you’re cooking up.

One of my current projects is building the UI for a security data collection tool. I don’t have permission to talk about the application specifically, but I am able to discuss some of the particular UI elements I created.

This application is a survey tool at it’s core and it asks a lot of questions with multiple options, of which multiple options may be chosen. Showing a bunch of questions with ton of checkbox options can be a bit overwhelming. I wrote about this issue a while back and I used a similar technique here.

The general idea is to only show what options have been chosen with a mechanism for displaying all options.

When the user is finished making their selections (by either clicking the “I’m done” link or the “Make Selections” link again), their choices are updated by way of some jQuery magic. Logic is included for detecting whether no options are currently selected and for the case where “Other(s)” was selected and something is entered to specify what “other” is.

jQuery.fn.extend({
  saveMultiselectOptions: function() {
    return this.each(function(i, panel) {
      var selection_count = 0;
      
      $(panel).prevAll('ul.selections').empty();
      
      $(panel).find('input:checked').each(function(j, checkbox) {
        selection_count += 1;
        var label = $(checkbox).next('label').html();
        if (label == "Other(s)") {
         label += " - " + $(checkbox).next('label').next('input.other').val();
        }
        $(panel).prevAll('ul.selections').append("
" + label + "
");
      });
      
      if (selection_count == 0) {
        $(panel).prevAll('ul.selections').append("
No selections yet
");        
      };
    });
  }
});

Here’s a stripped-down version to try out.

So what did you bring for Show ‘N Tell?

Even though I’ve never met most of the people I’ve discovered on Tumblr, I feel like I have a pretty good feel for their personalities and interests. For some of these people, I have a general sense of what they do for a living although I have no idea what they work on when they aren’t reloading their Tumblr dashboards.

So I had an idea I wanted to propose to the Tumblr community. What if we had a Show ‘N Tell Friday at the end of each week where you’d post something you’ve worked on? This goes for anyone - designers, developers, writers, musicians, photographers, etc.

Here are some general guidelines I was thinking:

1. On Friday (or thereabouts), take a few minutes and post something you worked on that week.

2. It could be big (you finally launched that project that took 14 months) or small (you made your life easier by making a tweak to your site’s deployment script).

3. Be sure to have permission from your employer/client/etc. if applicable.

4. Tag your post with sntf for easier browsing.

If you’re interested, please reblog this (or write up your own post) to help get the word out.