As part of Boulder Startup Week, Viget hosted a moderated panel session, How Startups Get to Great Design. With over 150 people in attendance, this event built upon the success of our 2012 event Startups + Great UX = Great Success.

This year’s event brought together designers from agencies and product companies to discuss what works for startups when going through a redesign. The session was valuable, with moderator Jackson Fox doing an excellent job of keeping the topics on track and making sure each panelist had a chance to speak to their experiences.

The panelists, talented designers working inside local startups and agencies, included:

• Andy Stone - Art Director at Mocavo
• Matt Gist - Product Designer at BirdBox
• Blair Culbreth - Designer at Viget
• Mike Rivera - Director of User Experience at Slice of Lime

The floor then opened up for the Q&A portion. 

If you didn’t get the chance to get your question addressed, please use the comments below and the designers will do their best to respond here.
 

Sharing makes my work easier and more effective. Here are three examples of how sharing comes up in the recruiting work I do:

• We've asked the last twenty-five people we've hired how they first heard of Viget. Ten of them referenced something I would categorize as sharing -- a blog post, our code on github, an application we built and made public, etc.

• About a quarter of recent applicants have mentioned their affinity for our Pointless Corp endeavors. This reveals that the candidate has done research into Viget and they've uncovered a small, quirky, but important aspect of our company. It's a short-cut to confirming culture fit -- a quick way to know that they care about something that's important to us.
• Here's how a recent applicant started his email:

"Last week I attended a talk that Trevor Davis hosted and was impressed by the quality of work he reflected and his knowledge and passion for Front-End JavaScript. I felt immediately drawn to finding out more about his workplace, as it seemed very well aligned with my interests, passions and experience."

Is there a downside to so much sharing? Yes. I think sometimes we paint such a full picture of what it's like work here, that applicants get ahead of themselves and imagine themselves fitting into that picture before we've had a chance to discuss skills, talents, and the actual job responsibilities. It can sometimes make evaluations and rejections that much more stressful and disappointing, I think.

Is it hard to share so much? Not really. It comes naturally to many people here -- they love sharing what they're learning on the job and many of them are gifted writers and speakers. For others, it may take more work, but they believe it's worth the effort. Sharing is inherent to the Viget culture; it's not forced.

Does Viget share everything? No, not with the whole world anyway. There is a lot going on here that only gets shared internally (via basecamp, campfire, and yammer, mostly). And I have conversations all the time with coworkers where I'm surprised to hear some details about what they're doing. 

Should applicants share a lot, too? I think so. When candidates are active on github, dribbble, twitter, or their own site it helps us determine if their skills and interests are relevant. When they are, we get excited (and, of course, prepare to get to know them much better). We still look at resumes and cover emails. I will still dig you up on LinkedIn. But when you share what you're learning, making, and experimenting with, we have such a better idea of what it might be like to work with you. And I think by hiring people for whom this comes naturally, we continue to nurture the Viget culture of sharing.

Is this blog post sharing thoughts about sharing? Yes, yes. Very meta.

Want to share with us? We're hiring!

Building it in R

Assembling your materials

• Download and install R - this is the core binary for the language. Their site is a frameset nightmare, so I linked directly to UC Berkeley's mirror.
• Download and install RStudio Desktop - this is an IDE that runs atop R. It's free and makes working with R much easier.
• Get a copy of the heatmap script - once unzipped, this should give you the source code needed to create a heatmap. 
• Download RGoogleAnalytics 1.2 - this is the library that helps us connect to Google. Get the tar.gz version; we'll use this later. Edit: Version 1.3 was posted a few hours ago and after a cursory look, it seems to work too.

Installing the libraries

Installing RColorBrewer, RCurl, and RJson

Most libraries in R are super-easy to install. Just issue a command and R installs the right thing from the Comprehensive R Archive Network (CRAN). Let's do it now. 

Navigate to the Packages panel and click Install Packages. In the dialog that follows, type rjson, RCurl, RColorBrewer  into the Packages field. Confirm the other settings match the screenshot below and click Install.

The installation process will write its status to the RStudio console. Once it stops, you should see a line that states that the downloaded binary packages are located in some byzantine path on your machine. Don't be afraid: this is good and signifies that they were installed properly.

Installing RGoogleAnalytics

Running the script

Connecting to GA

Open the Google Analytics Heatmap.Rproj project in RStudio using the project menu, then open traffic_heatmap.R from the Files pane. We'll do most of our work here. 

ga <- RGoogleAnalytics()

Choosing your profile

Since each GA account can manage many different profiles, you will need to choose the one you care about. Stepping through the code with ⌘-Return, you'll encounter this line.

( ga.profiles <- ga$GetProfileData(access_token) )

Running this will echo the profiles that you manage in GA. Find the number of the profile you want to use. This will be the number in the far left column.

1      2219134   www.example.com
2    239481199   www2.example.com
3    232342324   beta.example.com
4        47342   legacy.example.com

Querying and displaying

Now we can get some data. First, replace the "1" after  my_profile with the profile number you just chose. You'll probably also want to change the date range.

my_profile    <- 1           
my_start_date <- "2013-01-01"
my_end_date   <- "2013-03-31"

> ga.data <- ga$GetReportData(query)
[1] "Your query matched 168 results that are stored to dataframe ga.data"

In Conclusion

• compare different sections of a site
• map unique visitors instead of pageviews
• look for time drifts in device usage
• gauge uptake from social media efforts

Oh, and by the way, we're hiring!

We're looking to grow our UX team in all three of our office locations. Check out our UX Designer job listing and, if you think you're a fit, please get in touch!

One of the most repeated tasks in the build-out process is saving out an individual asset in the comp as a .png or .jpg. If you ever find yourself repeating the same sequence of actions over and over again in Photoshop, STAHP, and open up that dusty actions pallet.

Before we get into actions, lets compare two ways to do this manually...

A bad way:

1. Turn off all the layers behind it your asset
2. Use the slice tool
3. Zoom in 1000% to make sure you're not cutting off any pixels, or leaving any blank ones.
4. Save for web
5. Delete all of the non-slices you just accidentally exported along with the one slice you did want, because you forgot to customize your export options.
6. Remember which layers you hid to export that one piece, and re-enable them.
7. Delete the slice you created that's overlapping another asset you need to cut out separately.
8. Have an emotional breakdown as you realize you must repeat this process 99 more times today.

This was my terrible work flow years ago. Let's never go back there, friends. There is a better way.

A better way:

The best thing about this workflow, is that it's COMPLETELY automatable, meaning we can turn this in to a reusable action.

1. Right click on the layer or group title and click "Duplicate Layer/Group"
2. In the dialog that pops up, change the destination document to "New" and hit ok.
   • Now you have a new photoshop document with just that isolated asset!
3. In the menu bar, select Image > Trim... > Transparent Pixels
   • Now your document is exactly the size of your asset, to the exact pixel
4. Save for Web (works cleanly since you're saving the whole document - no accidental extras or generated filenames)
5. Close your document.

And now you're back to your pristine Photoshop file, with your perfectly sized asset saved out and ready to go. There's nothing to undo to get back to where you were.

Now, let's look at how to set that up as an action.

The BEST way:

1. Press F12

One keystroke, name that file, and you're onto the next one. How you do dis, you ask? ACTIONS my friend. Saving the steps listed in "A Better Way" as an action with a shortcut key is SUPER easy. 

Here's how:

1. Select the layer or group containing your asset
2. Open your actions palette (window > actions)
3. Hit the "Create New Action Button", and name it. (I called mine "Asset to File")
4. Press record (figure a. below)
5. Carefully repeat each step listed in "A better way", including closing the document
6. Hit the stop button (figure a. below)

Your new action should now look something like this:

Make sure to switch on the "dialog on/off" toggle box next to "Export" (figure b.). This tells the action to pause when the save for web window appears, so that you can change your settings and name your file before exporting. At this point, you can use your action on another asset, by selecting it, and hitting the play button (figure a.)

The last step is to assign a function key.

• Select your action in the actions palette
• Open the actions palette context menu (figure c.) and select "Action Options"
• Choose a function key (and an optional modifier key if needed)

To save you some time, I've saved out this, and an alternate version of this action for you to download here. The alternate version only opens the layer in a new file and trims it. I bound this to shift + F12, and use it when I need to isolate the layer, but make adjustments before saving.

That's all I got! You now know how to make actions, and how to save out any layer or group with the press of a button. What are some of your favorite time-saving actions? I'd love to hear what tricks you guys and girls are using to speed up your build-out workflows.

To a developer, this is not an assumption — it's truth, and obvious. But to non-developers, the necessity of reproducibility is not obvious. If it were, devs wouldn't see so many bug reports that say little more than "A vague thing vaguely happened — fix it!!!"

I think this disconnect is the primary cause of frustrating-to-devs bug reports. If we can better understand the reason for the disconnect, maybe it'll be easier to convince non-devs of the necessity of reproducibility. 

So what causes this disconnect? Here's my theory:

I believe that most non-developers think developers are like Neo in The Matrix: that devs can see all parts of an app simultaneously at all times, like Neo's living-ASCII-art view of the Matrix itself. That devs are omniscient, omnipotent beings in regard to an app. I've come to think of this mental model as the Neo Fallacy.

If pressed, I don't think we could say how we think developers do this. (Optic fiber running from servers to devs' brain stems? Magic emanating from the bowels of 4chan? Google Glass?) But I can't think of a better explanation for why so many of us assume devs can figure out a bug from so little information.

Returning to theory No. 1, I asked some Viget developers why reproducibility is so important. Some of their answers:

• "So we can hopefully write a failing test first, and then have one in place to prevent future regressions"
• "To confirm it's an actual bug"
• "To know when we've fixed it"
• "To be able to investigate the issue deeply"
• "So we don't waste our super valuable time"

All make sense. But those answers are beside the point to someone operating under the Neo Fallacy: "Fine, but why do you need to reproduce the bug to achieve all those things? Can't you just 'see' what's happening?"

Here's an answer that I hope helps reframe the way we think about developers:

Developers are not Neo. Yes, they have superpowers when it comes to writing code. But they're mere mortals when it comes to knowing what's happening in an app in real time. They're not omniscient.

Occasionally, they may be able to quickly ascertain a problem based on an intuitive sense of an app's behavior and an auto-generated error report from Airbrake. But most of the time, a context-free, vague bug report will mean no more to a developer than it would to you. Literally: without the details I outlined in my other posts — URLs, login creds, specific steps — you might as well submit the bug report to yourself. 

And having to spend time trying to glean meaning from such a vague report? For devs, that's about as fun as hanging out with these guys.

What might you expect? Besides great beer and company, you’ll enjoy -- and hopefully contribute to -- valuable conversation with your peers as we build a community of project managers in the Boulder area.

One of my favorite topics from our last Meetup was the role project managers play in driving innovation. We all face the challenge of supporting teams who need to grok a client’s business goals, work towards a strategic vision, but stay mindful of time and budgets. We discussed how innovation in our teams’ work, and in our approach to project management, can address (and sometimes complicate) these challenges. The conversation has stuck with me in the last month and informed some of my day-to-day work here at Viget.

On the 14th, we’ll be talking about the format of these events moving forward. Please join us now so your voice is heard. We welcome your input on how this group can best serve the needs and interests of our community!

RSVP here.

Code Examples

Let's say you have a basic layout with a reusable header and footer, like the one in the example below. 

<!-- location: views/layouts/default.php -->
<html lang="en">
<head>
    <title>Example Layout</title>
</head>
<body>

    <header>
        <?php $this->render('shared/header'); ?>
    </header>

    <div class="content">
        <?php $this->getContent(); ?>
    </div>

    <footer>
        <?php $this->render('shared/footer'); ?>
    </footer>

</body>
</html>

<!-- location: views/about.php -->
<?php $this->layout('default'); ?>

<h2>About Page</h2>

<p>Lorem ipsum dolor copy.</p>

If we opened domain.com/about in the browser, we would see the About page content loaded within the default layout we created above. (Note: In the above example we could lose the layout declaration at the top since Layouts with Views expects to load default.php as the default layout. This setting can be changed in settings/config.php.)

The above example shows a basic application of Layouts with Views. Check out the Github page for examples of features like:

• Multiple layouts
• Nested views
• Passing variables to views
• Allow for common control structures (if, foreach, etc.)
• Referencing page assets (images, stylesheets) using an absolute path
• Simple routing (Create the file, done)

Download

git clone git@github.com:tommymarshall/layouts-with-views.git 

In Conclusion

Layouts with Views sets out to solve a small problem and that's it. There's no customizable routing, no crazy templating features, no unusal syntax to learn. It’s just a simple way for me to build out comps. That's what I like about it.

Since current analytics services lack a tool to digest raw search query data into a list of the most important words, we built one fit for the task.

Introducing Search Words

Search Words is an application that restores some sanity to the search keyword analysis game. Raw search query data goes in, and a list of searched words and their summed search volumes comes out.

Specifically, Search Words is a Rack application (built on Sinatra) that takes a CSV file containing search queries with corresponding search volumes, and returns a combined list of search volumes for each word contained within those queries. The application also combines plural and singular versions of a particular word if both forms are present, and will ignore common words (e.g. "a", "and", "or", etc.).

Example Input and Output

Input
|---------------------------------------|
| Search Phrase        | Total Searches |
| ======================================|
| Lemurs               | 1,000          |
| durham bulls         | 500            |
| bull fighting        | 100            |
| lemur dance          | 2,000          |
| Durham               | 700            |
| How to catch a lemur | 35             |
|---------------------------------------|

Output
|---------------------------------------|
| Search Word          | Total Searches |
| ======================================|
| durham               | 1,200          |
| bull                 | 600            |
| fighting             | 100            |
| lemur                | 3,035          |
| dance                | 2,000          |
| catch                | 35             |
|---------------------------------------|

Demo and Installation

A demo of the Search Words application can be found here. To install Search Words, see the project's repository on GitHub. Complete installation instructions can be found within the readme.

Search Words is a very simple application at the moment, so feel free to drop us a line if you have suggestions for improvement.

Ever since Viget turned 10 we've celebrated each successful year with an overnight adventure, and this year was no different. We absolutely fell in love with Montfair two years ago and we jumped at the opportunity to return. From a planning standpoint, there's a huge advantage in being familiar with a venue. It lets you focus more time on how to make the event even bigger and better, and that's just what we did.

The Boulder team flew to either the Falls Church or Durham office and spent a few days working from the East Coast. Our project managers, user experience designers, business development team, and developers held team offsites the days leading up to TTT. By Friday, we were ready to have the whole team together.

As everyone arrived at Montfair, we enjoyed a catered, grilled lunch on the deck by Chef Ted and his team.

Once we filled our bellies and soaked up some sun, we settled in for the quarterly progress meeting. Each of our labs shared "core beliefs" and we demoed a very exciting project that we can't quite reveal yet, but let's just say Viget has something very cool in the works.

When the clock struck 5, it was time to party. We started with drinks and appetizers on the deck.

Brave campers pitched their tents before the sun set behind the mountains.

And before we knew it, the lodge was transformed into a cozy dining room.

Dinner was delicious, but slightly overshadowed by silly straws, tattoos, and the photo booth.

We were thrilled to mark the 5 year anniversaries of five of our teammates: David, Brian, Mindy, Owen, and Tom, who all started working at Viget in 2008.

As always, the Vigetry competition was fierce, especially this year since we raised the stakes.

As night fell we gathered around the bonfire, sang songs, and roasted marshmallows.

The morning came quickly and the air was brisk, but quickly warmed up just in time for a hawk show-and-tell from local falconer, Kevin Markey.

It wouldn't be a true camping trip without learning how to live and survive in the wild. So we had The Living Earth School come teach us how to make a fire using a bowdrill, find edible plants in the wild, build a shelter from debris, and shoot a bow-n-arrow at a target.

A huge "thank you" to these guys for letting us celebrate 13 years of Viget.

But more importantly, for creating a company where this, this, and this are the norm.

For these examples, I'm assuming the following:

• jQuery is being used on the site
• All of the JS for the site is concatenated into a single file and loaded on every page.

Everything in document.ready

Before I go into preferred methods, I figured that it makes sense to talk about what you shouldn't do. This is how I used to do it when I first learned how to use jQuery, and I still see some people doing this today.

$(document).ready(function() {
	$('.tabs').tabs();
	
	$('.carousel').carousel();
	
	$('.slider').slider();
});

Just don't do this. Even though jQuery fails silently, there is no reason to just throw stuff at the DOM and hope it sticks. Come up with a plan to execute only the JS that you need for each page.

Dom Based Routing

Paul Irish initially talked about this technique in 2009. The idea is to use the id and class attributes on the body element to determine which JavaScript should be fired.

Let's pretend that your body element looks like this:

<body class="shopping" id="cart">

And you have some JS that looks like this:

SITE = {
	common: {
		init: function(){ ... },
		finalize: function(){ ... }
	},
	shopping: {
		init: function(){ ... },
		cart: function(){ ... },
		category: function(){ ... }
	}
};

The execution code is set up so that it calls the following methods:

SITE.common.init()
SITE.shopping.init()
SITE.shopping.cart()
SITE.common.finalize()

Garber-Irish Implementation

This technique came out of my coworker, Jason Garber, working on a Rails project and had a desire for a little more structure. The idea is to use the Rails controller and action to execute specific JavaScript.

For example, on the users show page, the body element would look like this:

<body data-controller="users" data-action="show">

So you create objects based on controllers with a method for the action. The JavaScript would look like this:

SITE = {
	common: {
		init: function() {}
	},
 
	users: {
		init: function() {},
		index: function() {},
		show: function() {}
	}
};

The execution code is set up to call the following methods:

SITE.common.init();
SITE.users.init();
SITE.users.show();

This pattern has worked great for a number of sites, and I've even used the pattern for non-Rails projects. But, as we have continued to build more responsive and modular sites that are more system-based instead of page-based, the pattern has become less and less ideal.

Feature-Based Execution

This technique takes a feature based approach instead of a page specific approach. The idea is to break each feature out into a separate object, and then add the features that you want to execute as an attribute on the body. Here is an example of what our body element would look like:

<body data-features="timeline tabs filters modal">

Here is how we have each of the features broken out into separate objects:

SITE.features = {
	filters: {
		init: function() {}
	},

	modal: {
		init: function() {}
	},

	tabs: {
		init: function() {}
	},

	timeline: {
		init: function() {}
	}	
};

Then, I typically add an init method onto our SITE.features object to initialize all of the feature based execution:

SITE.features = {
	init: function() {
		var features = $('body').data('features');
		var featuresArray = [];
 
		if(features) {
			featuresArray = features.split(' ');
 
			for(var x = 0, length = featuresArray.length; x < length; x++) {
				var func = featuresArray[x];
 
				if(this[func] && typeof this[func].init === 'function') {
					this[func].init();
				}
			}
		}
	}
};

View as Gist

So when we call SITE.features.init() on document load, we grab the data attribute off of the body, and execute each feature. It would execute the following methods:

SITE.features.timeline.init()
SITE.features.tabs.init()
SITE.features.filters.init()
SITE.features.modal.init()

Feature-Based Execution + Script Loader

An idea that I have been playing with, but haven't implemented yet on a site, is to use a script loader to load features for the page instead of including them in a single concatenated file. Here is what the modified SITE.features.init() method looks like using the yepnope script loader:

SITE.features = {
	init: function() {
		var features = $('body').data('features');
		var featuresArray = [];
 
		if (features) {
			featuresArray = features.split(' ');
 
			for(var x = 0, length = featuresArray.length; x < length; x++) {
				var func = featuresArray[x];
 
				yepnope([{
					load: 'scripts/features/' + func + '.js',
					complete: function () {
						if(this[func] && typeof this[func].init === 'function') {
							this[func].init();
						}
					}
				}]);
			}
		}
	}
};

View as Gist

jQuery Meetup

I recently had the opportunity to give a presentation on this topic, along with jQuery plugin development (go to slide 72 if you want to skip the jQuery plugin development piece) at the DC jQuery Meetup.

What Did We Learn?

Don’t just haphazardly fire a bunch of JS functions that may or may not be used. Come up with a pattern for triggering JS on each page that makes sense for your site.

So what methods have you used for executing JavaScript on sites?

In just a couple of weeks, Boulder will host Boulder Startup Week 2013 (#BSW13). The annual 5-day event keeps getting better with more and more participation from local businesses all coming together to celebrate the awesome startup culture of Boulder.

Last year, we showed our support by creating and hosting an event called Startups + Great UX = Great Success. We were joined by folks from around the world for an afternoon of fun and insightful conversation. This year, we're doing it again but changing the focus a bit.  

Here are the details...

How Startups Get To Great Design

Startups are all about build, build, build. But we know users love refined design. How do you find time for design when you’re building nonstop? We’ll hear from a panel of talented designers working inside local startups and agencies (Mocavo, Birdbox, Slice of Lime, and Viget) who will share their experiences helping tech startups get to great design. Prior to a moderated Q&A session, four panelists will briefly share their experiences and work.

Last year's event was a huge success and we hope this year is even better. Jackson Fox, Senior UX Designer, will be the event moderator. Among the four panelists will be our own designer, Blair Culbreth. If you're interested in attending the event, please visit the Eventbrite page for more information and to register.

Viget believes strongly in being involved with our local communities and supporting the growth and development of local talent. If you're local to one our offices and have an idea for how we might collaborate, please feel free to reach out to us at info@viget.com. If you're in Boulder (or coming to town for Startup Week), we hope to see you on the 17th at 2pm!

Viewing project management through this lens doesn’t mean throwing out the contract, foregoing estimates upfront, or simply winging it. A good portion of any project can be driven quite precisely. For instance, commitment from your team and client is still something you need to establish. But know that things can and often do turn out differently. It’s disappointing when such inevitable changes make project managers feel stressed and frustrated. Prepare for the imperfect, and spend your energy (and time) worrying about those influences and disruptions that truly matter.

Risk management is a term that comes to mind within this subject. Sure, you can document risks upfront, devise mitigation strategies, and cuddle up with that plan believing you’re secure and prepared. That approach, however, is just another form of management; and oftentimes, micro-management, which is even worse. Successful project management is not just about being prepared, it’s about being adaptable.

At Viget, we have a number of tactics baked into our approach that help us embrace the inevitable project imperfections. Some include:

1. Managing against a lower budget cap: For every project, we establish a “buffer” (typically 10-20% under the contractual cap), which allows us to appropriately allocate more time in areas of the project as needed, as our understanding evolves.
   • How does this help? If we find ourselves revising comps more times than originally intended, the overall budget isn’t suddenly blown.
2. Booking team members 80% on a primary project: When a new project is underway, the reflex among most PMs is to make sure the designer, for example, is focused solely on that one project. But that’s risky. What happens if that designer is needed for another project they worked on previously; or an emerging new business opportunity requires their attention? At Viget, team members have headroom week-to-week to tend to emergent or smaller tasks.
   • How does this help? If Elliott is heads down on WWF design and suddenly gets pulled into a sales pitch, that time spent outside of his primary project has already been accounted for and shouldn’t disrupt the timeline or client expectations. And if no such disruption surfaces that week, Elliott’s free to get ahead on his primary project. Planning for the unplanned means your project and timeline can productively adapt.
3. Revising the task order at the project start: At Viget, we keep our contracts fairly high-level since we understand that only so much can be known during the sales process. Does the client really need 12 user flows? It’s hard to tell at that early stage. After we kick off a project, one of our first deliverables is typically the Project Charter, which refines details included in our contracts and more accurately sets the stage (and client expectations) for the work ahead. To be sure, this doesn’t mean we’re pulling a bait-and-switch, but instead establishing a more accurate plan based on client input.
   • How does this help? To do our best work, it’s critical to have meaningful input from the entire team and the client. While we do everything possible to include that as part of the early sales process, it’s not always feasible. Your deliverables and approach will be much more successful if you have the latitude to refine them (within budget and other core contractual bounds) following focused kickoff and project conversations.

I think most PMs understand this inherent variability and that a project usually finishes in a different place than originally intended. What I don’t think most in our field embrace and admit is that this is OK. We need to acknowledge that projects will always be imperfect in one way or another, and focus our energy and attention on being flexible and adaptable within this unpredictable landscape.

I wanted a new challenge.

As an experienced programmer, the basics of the language were unsurprising (as expected). Variables, conditionals, and loops presented no surprises as I've seen these concepts time and time again in other languages. I will admit that understanding pointers was initially as confusing as when I first encountered them more than 15 years ago. This confusion reinforced the fact that C is not a language for the faint of heart -- there are a number of challenges that a programmer has to overcome when working in a lower-level language.

These challenges weren't without their benefits. During our course of study, we became proficient with a number of language features and related tools:

• Memory allocation — Once I moved past writing trivial programs, heap allocation became a necessity. Not only did I learn how to use malloc and free appropriately, but also when to use realloc to create dynamic data structures and calloc to create robust allocations for storing string data.
• Makefiles — Zed's introduction to make and subsequent discussion of its advanced features really helped to de-mystify the tool for me. The additional documentation and alternate applications helped me understand its utility for building C programs and other automated tasks.
• Function pointers — It was interesting to me to see that such a low-level language contained functional programming concepts. I found function pointers a useful refactoring technique when dealing with different collections of structs. For example, when sorting an array of integers or strings, I was able to use functions with the same signature and behavior but with different implementations.
• C pre-processor — From the beginning, Zed made heavy use of the C pre-processor to create macros for debugging, iterating, and otherwise simplifying the code that I needed to write. After gaining more experience with the language, I learned when to choose a pre-processor macro over a subroutine (or vice versa) to refactor and improve readability of the code.
• Variable argument functions — Surprisingly, this language feature came in handy more often than I thought. Internally, this is how the printf family of functions is implemented. I used it to create functions like max_length(char *s1, char *s2, ...) to get the overall maximum length of n number of strings, and array_push(Array *array, ...)` to add elements to an array based on its underlying storage type.
• Valgrind — I have no idea how you would create a stable program without this tool. Time and time again, I would write what I thought was robust code, but valgrind would call me out on my mistakes. Whether it was a simple memory leak or an off-by-one error when accessing a segment of memory, I was able to quickly diagnose those mistakes and correct them. Without valgrind, these errors could easily slip by undetected.

Overall, the challenges presented with C really forced me to think deeply about how I organized my code and interacted with the machine. Understanding that balance between bare-metal performance and human understandability definitely revealed the language's sweet spot. Even in an industry where older technologies are constantly rendered obsolete, that balance is the reason developers of major modern software projects continue to choose C for their implementation language.

If you're interested in (re-)learning the language yourself, I recommend LCTHW as a good starting resource. Working through the exercises as a group helps keep everyone motivated and generates some fun ideas for other programs to write.

So processes! How we learn, how we teach, how we advance our industry and ourselves, why something works or doesn't work, what we're aiming for and where we are in the meantime. There was much introspection and celebrating of the journey, more so than the destination this year. The panel for 100 Year Starship beautifully summed up the merit of examining how we're all working, growing, and how we'll carry on in the future:

Pursuing an extraordinary tomorrow creates a better today.

Here are some ways that pursuit was illustrated at SXSW this year:

Of course, responsive design was a big topic this year. The consensus was that no one has the best process for creating a responsive site nailed down just yet. Which is a good thing! We now have an opportunity for designers and developers to rethink how they collaborate and how to create responsive sites that use responsive to its full, creative potential.

Always look for ways to grow. Here's maybe my favorite thing I learned this year: a person has either a fixed mindset or a growth mindset. Those with a fixed mindset see their intelligence, skills, and abilities as built-in and static. Those with a growth mindset see them as things that can be developed with hard work and learning. As a result, the work of those with a fixed mindset is static. They aren't as interested in alternative points of view or negative feedback. Meanwhile, those with a growth mindset are sponges for criticism; they want to know how they can do better and how others before them have succeeded. Seek honest feedback and perspectives that challenge your own, not just praise and reassurance, and your creativity and quality of work will grow.

Study and share processes, not just finished products. Whether it's a site, app, or a planet outside our galaxy, we can learn so much more from their growth than from just studying their final state. Every project has a story full of successes, failures, and breakthroughs that are valuable. Show a man a nice site, and he learns how to create an inferior, derivative site. Teach a man how a nice site was made, and he learns how to create nice work of his own.

Embrace your silly and side projects; you never know where they'll lead. Whether it was science hack days or just doing something about one of life's little annoyances, silly side projects were stars this year. Why do them? Even if it's a weekend-long project that goes nowhere, it's a chance to play and try new things you wouldn't get to otherwise. Best case scenario: your bit of fun ends up being the first step in a process that ends with helping scientists detect cosmic rays in a cloud chamber. 

The space exploration sessions were not only a highlight of this year's lineup, but also a fitting reminder why it's important to view our work and processes as works in progress that we're always rethinking. Space exploration has always meant pushing our technology to its limits to reach far beyond our planet. And the further we've reached out, the more we've seen there are no limitations. There is no final end-point to the universe, only another journey that take us further out than our last one. Similarly, there is no end-point in our field. There's always something to learn, a problem to solve, and a tool to use today that didn't exist yesterday. Just doing what worked yesterday is no fun. Pursue an extraordinary tomorrow, and you'll be better for it today. 

The Process of Being at SXSW

To visually bring you a piece of the SXSW experience, I could attach blurry photos of LeVar Burton (but I already did that.) Instead, here are some hopefully more informative visuals. First up, everyone should know my pain when it came to choosing between three or four sessions all taking place at the same time:

Wearable and self-tracking devices were a popular topic this year. Formally, this meant several exciting sessions. Informally, this meant I wore my FitBit all week and kept announcing to everyone how far we'd walked, whether they wanted to know or not.

And just where were we doing all this walking to? Well...

Your SXSW Homework

Should you choose to accept it, here's a list of assignments as varied as the sessions themselves.

• Do something fun and silly with responsive or adaptive design. Prove the complaints that responsive is just boring box rearranging wrong.
• Read Carol Dweck's original study about growth and fixed mindsets. Or at least get the gist of it from the slides for the session Why Your Brain Needs Negative Feedback.
• Create something classy with CSS Clouds.
• If you run, jog, walk, or hike, play Zombies, Run! and experience one of the best examples around of an experience that marries narrative and technology.
• Look at all the awesome stuff we can do with typography on the web!
• Watch When We Left Earth: The NASA Missions on Netflix Streaming. Because it's beautiful and inspiring.

Don’t Waste Time, Just Ask The Designer

After spending some time unsuccessfully trying to find a typeface match for the quote mark, I asked the designer. It turns out that the custom quote mark IS set in Lato. However, it’s simply two commas doubled up next to each other and rotated 180°. We actually can do this in CSS by using a few different tricks, but first, the base styling.

Base Styling + Rotation

Writing the CSS to style and position a hanging quote mark is pretty straightforward. Nothing too complicated here, but note the content and transform properties below (vendor prefixes omitted for brevity).

blockquote p {
  font-size: 24px;
  line-height: 1.5;
  font-family: LatoItalic, sans-serif;
  margin: 0 0 .7em;
}

blockquote p:first-child:before {
  content: ',,';
  display: block;
  float: left;
  font-size: 2.6em;
  line-height: 1;
  margin-left: -.6em;
  transform: rotate(180deg);
}

Of course this won’t work so well in browsers that don’t support CSS transforms, but we can easily test for support using Modernizr, and provide a similar and acceptable fallback.

.no-csstransforms blockquote p:first-child:before {
  content: '“';
}

And there we have it; unconventional custom hanging quote marks using commas, without resorting to using images, extra webfonts or custom icon fonts.

Other Possibilities

Using transforms on individual characters like this can magically make additional characters available for use, such as: rotating single and double “angled” quotation marks (‹, «, », ›) 90° to create up and down pointers. It’s also quite possible that rotating stacked characters from :before and :after pseudo-elements, can produce some interesting iconography. However, with minor rendering inconsistencies among different platforms, browsers and typefaces, that level of complexity would warrant the use of an svg icon or a custom built icon font instead.