Notes from an UX Consultation

During one of our recent UX consultations– as is often the case– we hosted members of a UW department who needed some help navigating the early stages of a full-site redesign.  The current site, everyone agreed was confusing and not helpful in allowing users to quickly find the information they were looking for.  However, how in the world do they actually “fix” this?

As we realized that the challenges that this team was facing come up again and again with groups looking to redesign a current website, or even if they are starting from scratch, we’ve decided to post a generalized and anonymized version of the notes from this consultation on the blog. Keep in mind that this isn’t an exhaustive list…just a quick listing of some considerations that often go overlooked.

Continue reading

Dropbox & Anvil, Quick and Easy Web Server for the Mac


While faculty and staff at the UW have always had access to personal web servers, I have often found the process quite unpleasant to manage when doing active web development. More specifically, if you are having to work on multiple projects and rely solely on FTP to edit and transfer files. This was solved with Apple’s “Web Sharing” feature – until it was removed from the latest Mountain Lion operating system.

Out of all the hacks, tips, and tricks on getting the feature re-enabled, I found Anvil’s solution to be the most elegant. The more I used it, it dawned on me to start pointing my projects to my Dropbox folder. Follow along and see how I use the combination of both applications to get web project instances up and running in practically minutes.

Download and Install

Dropbox for Mac:
Anvil for Mac:


Dropbox is a great cloud-based file storage system. It creates a folder on your computer and you can access and store files in it – like you would normally on your computer. For my Dropbox web development setup, I created a folder called “Anvil” which I use to store all my development projects. You can call yours whatever you like.

  1. Create a new folder that corresponds to your new project. For this example, we’ll create a project called “test”.



Anvil is a good alternative to running and administering Apache on your computer – instead relying on a local Pow web server. It also manages custom local domains so you don’t have to do any domain configuration whatsoever.

  1. Find the Anvil icon in the OS X task bar and click on the “+” icon to add a new project.


  1. Navigate to your Dropbox folder and select the previously created folder called “test”.
  2. Anvil will detect that your folder is empty and give you the option to add an “index.html” page. Click on “Add index.html”.


  1. Anvil will now serve your project site locally using a server. You should now be able to visit in your browser.


That’s it! Fire up your preferred editor of choice and start coding! No more server setup or running Apache! I run this same setup on multiple computers – allowing me to keep projects in sync in case I have to work on something remotely.


One of the major drawbacks is that the URL will only work on your local computer. You will not be able to share the URL to collaborators. One possible work-around might be to create a “shared” folder amongst collaborators within Dropbox. Multiple people could run identical Dropbox/Anvil environments and collaborate that way. The latest version of Anvil suggests that it now features a way to share URLs across your local network. I will have to try this out and report back. Feel free to give this tip a try and comment back your experience.

CodeKit, A Front End Development Timesaver

CodeKit - Front End Development Tool

We do a lot of HTML/CSS prototyping and front-end development on the UX team. We are always looking for ways to save time and simplify our process and a new tool, CodeKit, has been a great asset. CodeKit is a front end development tool that helps streamline your workflow and has the potential to be a huge time saver. It has a number of features which might seem insignificant or easily completed with other tools, but CodeKit brings everything together in a simple application. Just add your project and you are ready to go.

CodeKit Front End Development Tool

First, it is a compiler and can handle basically every language currently in use from css preprocessors (Less, Sass), to JavaScript (Jade, CoffeeScript), to markup (HAML). It compiles all of these on save and provides error reporting and other warnings to help with debugging.

Secondly, it makes it easy to optimize all of your files. It has a built in image optimizer that can reduce the file size of all of your images at the click of a button. It also can minify CSS and minify and combine JS files to ensure you are including the smallest number of files at the most compact size.

Finally, it has an auto-refresh feature for both Chrome and Safari. This refreshes your browser window on save so if you use two monitors or a split screen development environment, you can see your changes without the need to switch to the browser to refresh.

Before I started using CodeKit I was skeptical. I essentially had all of these features through a combination of other software and scripts. I didn’t think it was really worth the $25 pricetag to bring them all together. I was wrong. Now I don’t need to worry if I have the latest version of any particular software and only need to interact with one tool rather than several. The auto refresh feature alone has saved me a tremendous amount of time. Everything is dead simple and “just works” as the author claims- it’s really worth checking out.


Using Font Awesome icons outside the browser


Over the last year, we’ve become fans of Font Awesome – the iconic font designed for use with Bootstrap. We have used Font Awesome icons in MyUW Mobile and most recently in the UW Event Calendar redesign. In fact, we like Font Awesome so much that we should probably just get a room.

Because Font Awesome is an actual font — as opposed to a graphical icon set — we needed a way to use the Font Awesome icons as images that we could add to mockups and wireframes during the design process when we weren’t designing in the browser. The instructions provided by Font Awesome for this purpose are not very detailed, so we thought we would spell it out in clear, unequivocal steps.

Lucky for us, the good folks at Font Awesome included a “cheat sheet” of sorts that allows any of the 361 Font Awesome icons to be used as images in design applications like Photoshop, Illustrator and many others.

So what’s the process?

Follow along with these simple steps and you’ll be using the font icons as graphics in no time at all.

  1. First, head on over to the Font Awesome’s site and download the latest version of the icon set.
  2. Unzip the downloaded archive and install the FontAwesome.otf font file on your computer’s font directory. For Mac users, use Font Book. Windows users can follow these steps.
  3. Once the FontAwesome.otf file is installed on your machine, open your favorite desktop design application (for this tutorial’s purposes, I’ll use Adobe Illustrator). Check and make sure the Font Awesome font was installed correctly by viewing the list available fonts in your application.

    Font Awesome font appears in my list of available in Adobe Illustrator

    Font Awesome font appears in my list of available fonts in Adobe Illustrator

  4. After font is installed, go to Font Awesome’s Cheat Sheet and copy the actual icon (not the unicode) and then paste it into your design application using it’s Text tool. For an example, I’ve highlighted and copied the “cog” icon, then I pasted it into Illustrator.
    Highlight and copy the actual icon and paste into your design application

    Highlight and copy the actual icon and paste into your design application

    Screen Shot 2013-07-29 at 4.08.10 PM

    Icon added as object in Illustrator

  5. Once it’s copied and pasted into you design application, you can edit the icon as you would any other object, and you can save and export in any format supported.

I hope this simple tutorial has been helpful. Let us know in the comments what you think.

What we talked about May 6-17, 2013

Some good stuff this fortnight — videos and presentations for you to watch, announcements and major product updates from Adobe and Google; data visualizations of varying quality; accessibility tools and reports; and a bunch of other cool things.

Rorschmap of our office

Rorschmap of our office

Continue reading

AngularJS Quickstart for Designers

Within the past year, our organization has gone through some major technology changes. Although the changes have been productive for our developers, they often result in some amount of challenges for designers, as we need to keep up with the rapid pace of change. As a designer, I am always looking for tools to bridge that gap between designers and developers – with the main goal being to get prototypes up and running as quickly as possible.

Now that much of our development is being done using APIs, I decided to take some time to try and learn something new in hopes of making me more productive and improve our design and development processes. In that short time, I discovered AngularJS – made available by the folks at Google. For me, AngularJS has become a good tool for fast and easy prototyping. In the past, I’ve often relied on our developers to setup our development environments, access to a database, or even explain to me some technical aspects of a project. With AngularJS, I’m able to get up and running without many resources and learn some technical things along the way. This makes it so I don’t have to spend time waiting for someone else – plus it’s always good to learn something new every once in awhile.

For this post, I’ll walk through the process of creating a simple AngularJS app and go over some of the key development concepts. By the end of it, you’ll be up and running with a simple multi-page app that uses a mocked API for displaying content.

Getting started

The first thing I liked about AngularJS was how easy I was able to get going. Because the application you are creating is all Javascript, you don’t need much in terms of a server. Any web server that supports HTML/JS will suffice. For this demo, I’ll be using my UW Staff homepage:

I typically start with a basic HTML5 page structure (i.e. HTML5 Boilerplate) and make any modifications to add additional libraries such as including Bootstrap, jQuery, and AngularJS through various content delivery networks (CDNs). I also include 2 Javascript files at the very end that will serve as the main code to power much of our demo application.

Tip: CDNs are a great way to include any library without having to download and install them. I’ve gone to strictly using CDNs for many of my development projects as it’s become a great time saver.


<!DOCTYPE html>
    <html data-ng-app="demoApp">
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
        <title>Angular Demo</title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">

        <!-- bootstrap -->
        <link href="//" rel="stylesheet">


        <div class="container">
            <div class="navbar">
                <div class="navbar-inner">
                    <a href="#/" class="brand">Title</a>
                    <ul class="nav">
			<li><a href="#/posts">Posts</a></li>
                        <li><a href="#/about">About</a></li>

            <!-- placeholder for views -->
            <div data-ng-view=""></div>

        <!-- jquery/angular -->
        <script src="//"></script>
        <script src="//"></script>

        <!-- app javascript -->
        <script src="js/app.js"></script>
        <script src="js/controllers.js"></script>


You will want to take notice of a couple things within the markup that are specific to AngularJS.

AngularJS uses a custom attribute “ng-” as a way to interact with the HTML. This is simply a shortcut to the “data-” attribute commonly associated with HTML5. Although you don’t have to add the “data-”, I prefer to use both attributes in conjunction (i.e. “data-ng-”) for code readability and validation.

Modules and Routes

We’ll use “app.js” to initialize our application “module” and define our “routes”. Modules are basically containers for the application or specific plugin functionality. For this demo, the entire HTML markup will contain the app and therefore, the module is initialized at a very high level. Simply put, anything found between the “html” code block will contain the “demoApp”.

The “data-ng-view” block will be used as a placeholder for the demoApp. AngularJS now knows that anything being outputted to the user for the demoApp will be done inside of that code block.


<html data-ng-app="demoApp">
    <div data-ng-view=""></div>


// app module
var demoApp = angular.module('demoApp', []);

Routes provide a connection between a “view” and “controller” – through the use of a URL. The routes are defined within a module config and basically tells AngularJS how to pair a “view” template with a “controller” based on a given URL the user is requesting. In the case of this demo, I have 2 views (welcome.html and about.html) each paired with their own controllers that add some logic to the views. Whenever the users visits a URL (i.e., AngularJS knows that it should use “about.html” and “AboutController” and render that output back to the user.


// routes
demoApp.config(function ($routeProvider) {

            controller: 'HomeController',
            templateUrl: 'views/welcome.html'
            controller: 'AboutController',
            templateUrl: 'views/about.html'
    .otherwise({ redirectTo: '/' });

Controllers and Views

Controllers provide logic to the application. The “controller.js” file will contain the controllers that we specified in our routes earlier. Functionality within a controller can only be used by a view that was given permission to access it via the routes. In a later example, we’ll do something more advanced like working with data. For now, we’ll declare a simple variable called “header” within each controller that will be displayed in the view.


// home controller
demoApp.controller('HomeController', function ($scope) {
    $scope.header = "Welcome to my Angular demo";

// about controller
demoApp.controller('AboutController', function ($scope) {
    $scope.header = "About";

Views are pretty much HTML snippets that comprise the app as a whole. Since the “route” makes the connection between the “view” and “controller”, the following view (about.html) is able to get a value for {{header}} which was declared in its controller (AboutController).


<div id="about">

Mocking API data

Much of the initial demo can be done using static HTML methods. However, the really cool things about AngularJS (as well as other JS frameworks) is the ability to interact with APIs.

Many of our more recent projects are web-service-based applications where we are often interacting with an REST API. In terms of doing prototyping or basic HTML/CSS work, I wanted to mock actual data rather than copying/pasting many lines of static code. Since our developers were actively creating the APIs, why not use what they had made to create true visual representation of the data? Often times, I found that designing with fake data was not always ideal as I would have make code changes once my templates were hooked up to a real data source.

Going back to our demo, we’ll assume next that we want to display some blog post that we are accessing via a REST API. In order to get our mock data working, we simply add a new route to “app.js” that will handle displaying our blog data.


        controller: 'PostController',
        templateUrl: 'views/posts.html'

Mocked data

AngularJS is robust enough that it has built-in resources that will allow you to interact directly with a REST API. However for this example, the Post data will live inside of a controller (PostController) in the form of a JSON array.

Tip: Get sample JSON datasets from your developers! It’s a good way to be in the loop with the actual data that you will need to design for.


demoApp.controller('PostController', function ($scope) {

    $scope.header = "Posts";

    // define json for posts
    $scope.posts =  [{
        "id": "1",
        "title": "Vestibulum Id Ligular",
        "author": "bob",
        "intro": "Aenean lacinia bibendum",
        "extended": "Aenean lacinia bibendum nulla sed consectetur..."

The new view (post.html) uses a “data-ng-repeat” directive to iterate through all the post items.


<div id="posts">

    <ul class="media-list">

	<!-- repeat list of posts -->
        <li class="media" data-ng-repeat="post in posts | orderBy: 'id'">
            <a class="pull-left" href="#"><img class="media-object" src=""></a>
            <div class="media-body">
                <h4 class="media-heading">{{post.title}} <small class="muted">by: {{}}</small></h4>


Once you visit the URL ( , you should now see all the Post data contained in the JSON. Instead of having to manage many lines of HTML, you are now able to focus on the design of the actual data that you will be using.

I’ll continue this demo series in the upcoming blog posts with some more advanced concepts of AngularJS. For now, please feel free to download the demo at the following URL:

I hope you find it useful. Thanks!

Additional Resources

What we talked about April 15-19, 2013

Michael Schultheis’ Archimedes Exegesis 01

Pretty diverse week — industrial design, Google Glass, maps, art, reading material, and of course accordions.

Blissfully becoming _____.

2001: A Space Odyssey (1968) Image via IWDRM

I recently attended 2013 SXSW Interactive conference in Austin, TX. The conference offered four days of sessions, parties, meetups, keynotes on a variety of themes covering art and inspiration, community and activism, design and development, entrepreneurialism and business. From the events I attended, I picked one that made the most impression on me and thought it would be fun to share in the blog post.

Ironically, for an interactive festival of that caliber, “What can we learn from the Unabomber?” was probably the only session that focused on a critical discussion of technology. In the sea of designers’ enthusiasm about introducing new technology to solve all kinds of world’s “problems” — I thought as session began — we simply are too excited about tech’s potential to think about the implications of our work. The debate-like session consisted of two professors of philosophy, Peter Ludlow and David Skrbina, laying out their views of whether there is something to learn from the presently-incarcerated Ted Kaczynski, aka the Unabomber. Kaczynski mailed a number of home-made bombs as a revolt against modern technology between 1978 and 1995, killing three people and injuring 23.

Dr. Skrbina argued that although he does not support the way the Unabomber carried out his revolt, he does agree with some of the ideas that the Unabomber put forth. Specifically, that industrial technology enslaves people with its dehumanizing mechanical, attention-controlling, and nature-destructive ways. And because people seem to lack control of the technology that is perpetually taking over their lives, causing psychological, physical distress and ecological disasters, we should “kill the system” altogether, and return to more simple ways of existence. That said, he agrees that it would be impossible to just “get rid” of technology, as it penetrates all aspects of our lives and a lot of us just have to use it to maintain a certain social position (Skrbina needs to use email to keep his teaching position). But possible or not, the way to deal with it, in Dr. Skrbina’s and the Unabomber’s opinion, would be to eradicate it.

The other debate participant, Peter Ludlow, instead of defending technology argued that there is nothing to learn from the Unabomber. In his opinion, the Unabomber’s arguments are weak and the only reason we are here (sadly) is because of our popular culture’s fascination with serial killers (Dexter, Hannibal Lecter).

He did, however, agree that our technological system is not benign and that radical measures do need to take place, but we can hardly learn anything from the Unabomber’s fallacious “jump to conclusion” arguments to completely eradicate technology.

Referring to Skrbina’s arguments, Dr. Ludlow pointed out that the increasing numbers of people diagnosed with various attention deficit and autism disorders, along with speculation about the harm of Facebook, should not be directly interpreted as a negative consequences of technology, and surely not enough to conclude that we should eradicate it altogether. He argued that instead treating technology as this mysteriously controlling and dehumanizing power, we should more actively engage with it by better understanding what it is and how it works as opposed to passively using it.

After the session, there was some time allocated for Q&A. The line at the microphone kept growing with worked up technologists lining up to to defend their profession. Most people at the microphone where there to express skepticism and even a bit of irritation on what Dr. Skrbina had to say. He was, after all, suggesting that what these people so lovingly do for living, i.e introducing more technology for the betterment of people’s lives, might have a less noble and romantic side to it. Lined up technophiles questioned his position with something along in the lines of the following:

— What do you mean technology is bad? I am creating authentic digital experiences for people, I am making their lives richer.

—But you use technology yourself, don’t you? How can you argue against it?

—We have been using technology from the time we picked up a stick, so how can we say that we are better off without it?

Aside from emotional reactions to “let’s get rid of technology”, the audience (including myself) was intrigued, but not quite prepared to discuss the flip side of our profession. Inspite of our varying degree of excitement about technology, we can all agree that there is something alarmingly strange about the way it is increasingly a part of the socio-cultural fabric. Yet we still don’t know where the strangeness begins and where it ends—we lack insight and sensitivity to the degree, intricacies, and implications of our interconnectivity with technology.

To many of us, technology is like that funny and confident friend (from way back when we were little kids) who everyone is so excited to be around. It seems that anything that friend says (sometimes the unthinkable!) amuses everyone and we all go along with it. And just because this friendship seems like a harmless adventure and “everyone is doing it”, we rarely stop to think about our friendship’s nuances and what it means to us beyond its immediate utility, convenience, fun, and feeling of “being there” along with the rest of the kids. And to Ludlow’s point, our friendship with technology is not benign—as it does not simply serve us in improving our well-being, but very much shapes who we are as humans. And if we are concerned at all with who we are becoming, I think we have to be more sensitive to the relationships that are shaping us. To me, being more sensitive means being critically reflective, or being able to step back— not from technology itself, as Dr. Skrbina and Unabomber might suggest—but from our immediate interactions with it, and look at the bigger picture of our friendship.

I think for creators of technology it might mean not only engaging in meeting user needs and wants with technological solutions, but also in research that focuses on articulating and helping others understand what is that we are becoming as a result of this relationship with technology. I don’t think that this research should necessarily be practical in nature and could very well be considered art. Nonetheless, it should be present and it should address the otherwise unnoticed—what all of our everyday interactions with technology (and strangeness that comes with it) amount to? This research could be hypothetical design explorations (“what if?” scenarios) or critique of the current technology and design industry trends (cloud computing, context-aware services, device agnosticism, etc).

No matter what shape this critical discourse takes, what is important is that our big picture understanding of our relationship with technology becomes more nuanced and that we could more clearly, and with less strangeness perhaps, see what it is that we are becoming.

Debate slides:

Peter Ludlow slides (Scribed)

Slides via debate moderator Jeff Young (Scribed)