The hard part is remembering to pass along the favor. Of course, once you solve the problem, and the solution is staring you in the face, it seems so obvious that it hardly merits mentioning or blogging. Isn’t it obvious how to do that now? Well, here’s one of those. I was working on this problem, and when I tried to see if anyone else had already done it, I didn’t immediately find an answer. It’s time to patch that little hole.

I was working on a website that was aimed at mobile devices. When you’re working with mobile devices, you’re inevitably trying to fit a lot of content onto a small screen and you have to hide things. In this case it was text. I decided to have a teaser of text displayed upon initial loading, and if the viewer decided to read it, they could simply toggle a link to display or hide the bulk of the text. I needed the text to stop dynamically in the middle of a sentence, and when the user clicked the “ Show me more” link, the rest of the text magically appeared, seamless with the teaser text that was there before. Here’s how I did it.

I created a couple of functions to truncate the text.

#truncate description
@contracted_description = truncate_text(@location.description,100)
@remaining_description = truncate_remainder(@location.description, 100)

With my helper functions looking like this..

def truncate_text(text, len)
  chars = text.mb_chars #converts string to char
  while(chars[len] != ' ') #make sure the break doesn't happen in the middle of a word
    len = len-1
  end
  trunc_text = (chars.length > len ? chars[0...len] : text).to_s
end

def truncate_remainder(text, len)
  chars = text.mb_chars #converts string to char
  l = chars.length
  if l < len #if text does not need truncated
    return ""
  end
  while(chars[len] != ' ') #make sure the break doesn't happen in the middle of a word
    len = len-1
  end
  trunc_text = (chars.length > len ? chars[len...l] : text).to_s
end

Now that I’m a little wiser, I could have done it like this. (I haven’t actually tested this code so caveat emptor.)

@contracted_description = truncate(@location.description, :length => 100, :separator => ' ', :omission => '')
@remaining_description = @location.description.gsub(/#{@contracted_description}(.*)/m, '\1')

Basically what going on here is I pass these functions some text and the amount of characters I want to show up in the teaser text. The first one returns my teaser text, the second returns the remainder text to be toggled on or off, and both of them will “back up” in the text provided to find the first white space to ensure we don’t break off the teaser text in the middle of a word.

Ok, we have our two pieces of text, now to display them. This site already was using scriptaculous effects in the menu to toggle nested menus, so we stuck with that. Assuming you have the scriptaculous library in your app, our view looks something like:

<div id = "contracted_description" >
	<%= @contracted_description %>
	<div id = "full_description" style = "display:none;">
		<%= @remaining_description %>
		<%= link_to_function("Less Text","toggleDescription()", :id =>"less_link") %>
	</div>
	<% unless @remaining_description.length == 0%>
		<%= link_to_function("...More Text","toggleDescription()", :id =>"more_link") %>
	<% end %>
</div>

Or if you prefer slim:

div id = "contracted_description"
        = @contracted_description
	div id = "full_description" style = "display:none;"
		= @remaining_description
		= link_to_function("Less Text","toggleDescription()", :id =>"less_link")
	-unless @remaining_description.length == 0
		= link_to_function("...More Text","toggleDescription()", :id =>"more_link")

And our toggleDescription() javascript function looks something like:

function toggleDescription(){
	Effect.toggle("full_description", 'blind', {duration:0.50});
	Effect.toggle("more_link", 'appear');
}

Now we have text that expands and contracts. It’s not seamless yet, but where almost there. As for our “Less Text” and “More Text” links, you could easily make them the same link, and change the text rather than have two different ones.

All that’s left is to make it all display like seamless text when expanded, rather than text separated by two divs. The text I was pulling from the database was already formatted with paragraphs that I wanted to preserve, so I used psuedo elements to display:inline the last element of type paragraph in the contracted text, as well as the first element of type paragraph in the remaining full description text. So our stylesheet looks like:

#contracted_description{
	margin-left: 10px;
}
 
#contracted_description > p:last-of-type{
        display: inline;
}
 
#full_description {
	display: inline;
	margin-right: 10px;
}
 
#full_description p:first-child{
	display: inline;
	margin-left: 0px;
}
 
#full_description p:nth-child(2){
        display: block;
}
 
#more_link{
	display: inline;
	text-decoration: underline;
}
 
#less_link{
        text-decoration: underline;
}

This is hard. Really hard. And it seems like more often than not, it doesn’t happen the right way. You can pare down your app by delivering 100% of your feature set, shittily, or you can pare down your app by delivering 50% of your feature set, really really well.

My concern is that in our industry, a lot of people feel that doing things the right way just doesn’t matter as much when you’re building a Minimum Viable Product (MVP). I’ve heard too many people excuse the sad state of a feature because “it’s good enough for an MVP”. We’re putting too much focus on the ‘M’ and not enough of the ‘V’.

If you’re an established company with millions of users, you can afford to put out a new feature that’s only 80% complete. You’ve already got those users. They’re not likely to up and leave your service just because this new feature doesn’t work as smoothly as it should. If you’re a brand new company that doesn’t have any public trust, though, the second a user starts to hit the smallest barrier, she’ll up and leave your app faster than you can say “command-w”.

Don’t get me wrong,we’re huge proponents of agile and lean, but, to us, that doesn’t mean cutting out quality! Instead, we work with our clients to identify the minimum feature-set required to deliver on the core value the application is to provide and then, using our proven process, we develop those features until they’re perfect.

Would it be nicer to have feature X? Sure, but if it isn’t required to perform the core value, it’s off the list. That’s what future iterations are for.

As developers, I think it’s our duty to our clients and our industry to help entrepreneurs choose about which features are key and which ones can wait. This means pushing back and saying “no” sometimes. And once we’ve helped them make those difficult choices, then it’s our job to build the hell out of the remaining features to give our clients the best chance at breaking into their niches. If we can all agree to spend as much as the ‘V’ as on the ‘M’, magic can and will happen.

Hence, my laptop was shipped off to a better home in Florida, and I started a grand experiment: doing all my work on an iPad and my iPhone. I was excited to answer a question we’ve been floating around the office: Do you really need a computer anymore? What does the future of software look like? What will we be building in five years? Will it be desktop-oriented or will everything be an app? Will people even still be using desktop computers? Will corporate America replace its towers of gray CPUs with slim touch-screen tablets?

I have seen the future, and I’m telling you: those desktop computers are gonna be around for a while.

What I’m going to say next will surprise no one, but I have empirical evidence that it’s true: typing on the iPad is not good for business. That’s the first hurdle to a touch screen-based workplace. I don’t care how responsive and awesome that screen is; Mavis Beacon taught me to type with a real keyboard, and that’s where I can get stuff done. I’m pretty sure we’d would lose an automatic 30% in productivity if we all had to switch to touch screens for day-to-day business. (Yes, there are bluetooth keyboards for tablets, but if you’re going to buy a keyboard, where’s the point in using a tablet?)

The other hurdle, again, perhaps unsurprising, was the lack of tablet support by conventional desktop applications. For example, Intuit Payroll has a tablet app, but it’s a watered-down version of the desktop application, and there’s no way to opt out of the tablet version. (My partner Trey suggests that’s because the desktop version relies heavily on functionality that doesn’t work in tablet form—like hovers—and in the next breath he points out that shouldn’t be an insurmountable obstacle to a good mobile browsing experience). I’ve been waiting for years for Intuit to release a Mac-based Turbotax for business; since I’ve yet to see that, I have little faith in that behemoth’s ability to adapt to mobile devices. Intuit isn’t the only company guilty of this, I’m sure.

So there you have it. If you don’t need to type a lot and you don’t rely on slow-moving enterprise software for your day-to-day job, then yeah, maybe you’ll be working on a tablet in five years.

As for me, I am going to work happily with my tiny new Macbook, knowing that the world is going to need online software developers (and companies like mine) for a long time to come. It might not always be Ruby and Rails that we’re writing, but whatever it is, I know we’re going to continue to be awesome at it.

To illustrate what she means, here’s a scenario I feel like I come across all the time: The client wants any paragraphs mentioning their new videos to have a special video icon on the left hand side and a light blue background and rounded corners. You check the markup, and make a decision to add a .video-content class to your stylesheet. Something like…

.video-content {
  padding:15px 15px 15px 100px; 
  background: url(/cool-video-icon.png) no-repeat 2% 50% #e3f8fe; 
  border:1px solid #666
}

You then apply this class to any paragraphs that talk about your client’s videos, and you feel pretty good about it. The client’s happy and you imagine a web standards guru like Eric Meyer would be happy, too, if he were only watching you work. His blue eyes would twinkle, perhaps, as he slipped you a complimentary pass to his next speaking engagement in Honolulu.

Your new .video-content class applied to a paragraph

Then, the rub. The client comes back a month later, complaining that the video content just isn’t standing out enough. He or she would like a heading to be grouped in with any video content that says, “Check out our video!” So now, your previous solution doesn’t work anymore. Still trying to win the imaginary approval of Mr. Meyer, you sigh quietly, and create a new class for the <h2> called .video-heading. To this class, you assign the same light blue background and the two rounded corners that top the section. Bit of a pain, but no big deal, really. Just another day for a front-end developer who truly cares about web standards.

Your new markup - the heading takes the styles for the top rounded corners

However, a week passes, and the client still isn’t getting enough video views. The CEO feels that the paragraphs describing the videos are too long, so a request comes in to split them up into lots of little paragraphs. “Sure!”, you say. So you make the change to the markup, and…

So you probably see where I’m going here. At this point, if you have any sense, you break down and add that stupid DIV you’ve gone out of your way to avoid in your quest to be pure in your separation of content and presentation: Nicole’s point (if I understand it correctly) is that equally important is the separation of “tasks” within your CSS, even if it means adding a little extra markup to keep things maintainable.

Right now, I’m working on a really fun site/app here at 12 Spokes. It’s a reading/content-centric kind of thing I can really see people using on a tablet on the couch at night, so I decided to be trendy and make the front-end 100% responsive to the width of the device—whether you’re on a smartphone, a Galaxy, an iPad, or whatever, the layout should adapt to fit your screen. However, in laying out the basic grid using percentages, I came across a couple of cases where differences in the way browsers round percentages were breaking my layout when I added padding to the grid columns. I’m not a huge math fan, so working with declarations like “padding: 3.00084%” was making my little designer brain hurt.

So I took a deep breath, tried not to think of Eric Meyer, and added a little div to my grid inside each layout column. I called this div .pad-box, and yes, all it does is add padding to any element that might need it. That’s it. My 2008-era semantic web standards self would probably hang himself on his An Event Apart lanyard if he could see this, but thanks to Ms. Sullivan, I don’t care. Yes, it’s extra markup, but it’s bulletproof, repeatable, and has the pleasing effect of making the grid’s padding uniform across the app. If I want to space things out a little, all I have to do is adjust that div’s padding from, say, 10px to 15px.

I was a Philosophy major. And because a full-time, entry-level philosopher position with decent benefits STILL hasn’t opened up over the past 10 years, I’ve ended up a web designer. I can’t complain, but sometimes I feel a little sad how little philosophy I remember from my college days. One thing I do remember, though, was that I liked Aristotle because his writing seemed practical and actually applicable to my modern life—in particular, the idea of moderation, not excess in either direction, being a key to happiness. So it is, perhaps, with presentational markup. A lot of DIVitis will kill your CSS, but a little might just make it stronger.

Jasmine, if you haven’t used it, is a way to test your functionality in the same environment and at the same level as your javascript code. Much like when we’re working on the server-side, the test and the code share syntax and vocabulary (and running the resultant tests is very fast). The downside? Much of the time the javascript in our applications is working very closely with text and elements in the DOM of the web page that it’s included in. It could be argued that maybe this shouldn’t be the case, but if your use case is something like, “when I click this link, I want a modal dialog box to show up”, how far should the code really be abstracted away from the DOM that it’s working with? Because of this close relationship, jasmine tests often need to have a mocked DOM created and included that replicates the html we’d find coming from the application server, and this means keeping them in sync in order to preserve the usefulness of these tests (there is much to be said on HOW you can do this, but that is probably outside the scope of this post).

Cucumber, on the other hand, is the Golden Hammer of web application testing. It runs the whole stack, database to front-end javascript, so your front-end code is being tested in the exact environment that it runs in, including full interaction with your server code in it’s current state. A scenario will, in one fell swoop, log in to the site, load page, start clicking on things, and confirm that the visible results of your actions occur as you intend them to. Of course, as a result of this kitchen sink approach (which is necessary for full integration testing), the time it takes to run large suites of tests is not exactly low. 13 difference scenarios for testing different nuances of javascript-y interaction with a simple form can easily consume 30 seconds or more on each test run. Multiply that over every part of your application and you can be waiting a long time to make sure everything is still working.

During our latest team retrospective, in order to strike a balance, we’ve settled on a policy that I think leverages the strengths of each tool in order to reach a relative best-case scenario. Our core value is this: speed is critical because fast tests get run. Tests that run slowly just don’t get executed as often during the development cycle, and this quickly hurts their value to us. Because of this, we use jasmine for all of our front-end javascript. Just like our ruby code, nothing should be written without a unit test to cover it. In order to mitigate the issue with having HTML that accurately represents what’s being delivered by the server, we have a clever way of generating these fixtures of static html from the current server-side code base just prior to running the tests. Cucumber is in the mix, but only for what it was designed to be anyway: for integration and acceptance testing. Our cucumber scenarios (which, when done correctly, should be somewhat fewer in number than our unit tests) provide assurance that our main requirements from the customers are met and that all the elements of the application are working together successfully; meticulously executing every line of browser-based javascript is simply beyond the scope of such a tool.

As with all development tools, these things only have value to us insofar as they help us provide value to our customers. With our new strategy in place, I like to think that’s exactly what we’re accomplishing.

As a designer who uses Git and Terminal on a regular basis, it pains me to talk to other front-end web developers that aren’t even aware such wonderful things exist. I could go into the many ways that Git has helped me become a better coder and designer, not to mention how many times it’s saved my ass. As far as I’m concerned it’s the best version control out there right now and more designers need to get on board using it.

GUI vs Console

There are plenty of apps and plugins out there for Git. These are great for learning and for looking at diffs that come up, seeing what’s in the queue to be committed, etc. Let’s face it though—you’re not going to be a killer web designer if you use a wysiwyg for all of your coding, just as you will not be a pro with Git unless you use a terminal or console to work with it.

What is Terminal?

“A terminal window allows the user access to a text terminal and all its applications such as command line interfaces (CLI) and text user interface applications.”¹ How it relates to your Git repositories is that it becomes the hub of your project. You’ll be running everything locally through it. For example, I’ll usually have a tab open for Git, a tab for running the project, a tab for Sass, a tab for Coffeescript, etc. etc.

Most operating systems already come with a default terminal application. I’m on a Mac so I just use “Terminal” but if you’re on something different here’s a big ol’ long list of terminal applications you can peruse through.

Terminal Basics

Let’s just get down a few basic commands in Terminal that will help you out when you’re using Git.

First off, it helps to know where you are right now. Whenever you’re in the terminal, you are currently in a directory somewhere on your computer.  To see which directory it is, just type:

 pwd

Good start!  Now, to CHANGE where you are, you can use the following command:

 cd [some directory]

Example:

 cd websites/new_project

But, this only lets you go deeper into the directory structure.  If you want to back out of the directory that you’re in, you can use this to move up to the current directory’s parent:

 cd ..

In order to see what’s available in the current directory you’re in, you can use this command:

 ls

Running Processes

Depending on what your project is built on, you can use Terminal to start your projects and keeping them running in the background. At 12 Spokes we concentrate on projects built with Ruby on Rails, so a lot of times I’ll open up a tab, navigate with “cd” to the project I’m working on, and then run…

 rails s

… to start the server for that app.

This idea carries through to libraries like Sass that involve having processes running that perform updates or other actions whenever you make a change. So if I’m using sass or scss on a project all I have to do is open up a tab in Terminal and type:

 sass --watch /scss_folder_path:/css_folder_path

And then sass will sit and wait for me to make changes, compiling them into normal css files as I go.  Now, this is just the bare minimum line to get sass working. It comes with a lot of options built in for how you wish your css to output so I definitely recommend going and taking a look over at the documentation.

Git & Github

Why Use Git?

Here’s a list of just /some/ of the reasons to use Git:

• Keep track of changes
• Roll back to previous versions/commits of your site (VERY IMPORTANT)
• Easy collaboration with more people
• Again, Version Control (HUGE WIN)

Git-ing Down to Business

Now that we have some basic console knowledge down, let’s start doing some Git stuff.

Note: I’m going to assume you have Git installed on your computer. If you don’t, check out the Git page for information on installing Git.

At 12 Spokes, we use Git version control on all of our projects and GitHub for all of our project collaboration. If you don’t use GitHub, I highly recommend it. I’ll be basing a lot of this tutorial around it (though it’s not absolutely needed). If you don’t know what it is, go check it out (no pun intended).

Cloning a Repo

A repository (or ‘repo’) is where all of your project is stored. So to get started, let’s clone a repo from GitHub.

• First, get to the folder on your local machine where you want to keep all of your projects

   cd /Projects

• Once there, we want to go to GitHub and copy the path to our git repo, which should look something like this:

  git@github.com:12spokes/tandem.git

• Back in Terminal, type in:

   git clone git@github.com:12spokes/tandem.git

• Complete! You should see it create the folder for your new repo and download all the stuff that’s inside it. Congrats—you now have a git repo of your very own!

(PS: if you don’t have any repos that you can clone down to your machine, you can just create a new one for yourself by going to the directory where you want it to exist and typing:

 git init

and then you’re ready to start making changes!)

Commits

Just like other version control systems, Git is built upon the idea that you make changes and then commit those changes. Think of a commit as a type of milestone or a marker; it’s a collection of file changes, additions, and deletions that you’ve decided to group together because they’re all focused on the same thing. We use these commits not only to see what’s been done, but also as points to roll back on. For example, if we’re working on a site and commit some new changes but realize that something isn’t working we can roll back the website to the previous commit when things were working. Get it? Good. Now let’s do it.

1. Get to the repo you want to work with

    cd /path/to/repo

2. Open up your project in a text editor and make some changes. Save those.
3. Go back to Terminal and type in:

    git status

   You should see those files that you changed listed

4. Right now they’re on an ‘unstaging’ side of Git. One of the best things about commits is that you can choose what you want to commit, so you can logically group things together that are related to one another. For the sake of the tutorial we’re going to go with everything though. So we want to:

    git add -A

   This will ‘add’ all of those changes to staging, and make them ready to commit.

5. To commit, type in:

    git commit

   … to just commit everything, OR (preferably)

    git commit -m 'This is a message saying what I changed'

   … add ‘- m’ to the end of it to add on a message describing what you did in that commit. I HIGHLY recommend adding a message, because if you leave this project for a while and come back and need to find something you’re going to be very grateful for those notes.

6. You’re done! Congrats! You made your first Git commit.

Push-me Pull-you

If you’re using something such as GitHub to store your git project outside of your local machine you’re going to want to get friendly with pushing and pulling.

It’s good practice to pull down any changes from the remote repo first (say, for instance, if more than one person is working on the project). Pulling both gets the changes from the remote repository and then merges them with the copy of the repo on your local machine. To do this (get to your project directory) and type:

 git pull

Now that we’re up to date, let’s say we’ve made changes, committed those changes and are ready to push back up. It’s as easy as…

 git push

This will push any commits that you’ve completed.

Conclusion (for now)

That’s it! You’ve tackled your first Git project! It wasn’t as hard as you thought it would be, huh?

If you’re ready for more, stay tuned for Part 2 of the article where we get more in depth with more awesome Git abilities; such as, Forking and Branching and Stashing!! Oh my!

Protips:

• On a mac you can drag and drop a folder you want to use after typing in ‘cd’
• Soon as you start typing the name of a folder you can quickly finish out the name by pressing ‘tab’
• Commit frequently! If you find you’re at a good stopping point it’s a good habit to commit those changes.
• Sometimes it might be nice to look at what changes were made in your commits or before you commit. GitX has a nice interface for seeing these differences.

¹  http://en.wikipedia.org/wiki/Terminal_emulator

Still, it kind of baffles me, because no matter what you do, don’t you have to make your presence known by consistently generating value?

Imagine I’m a mechanic. Someone brings their car in for repairs and then gets a ride to work for the day. I’m my own boss, so I have no supervision. Since I’m especially crafty, I figure out that I have the perfect scam–I can charge for my time without actually doing any work! The customer comes back later to pick up the car, I hand them the invoice, and the profit is all mine.

… except the car still won’t start.

A mechanic who actually wants to stay in business will assess the car, research replacement parts, provide an estimate to the customer, send someone to the store, perform the repair, verify that things are working properly, and create a detailed invoice.

The process is nearly identical for me. When I get assigned a new story, I need to gather requirements by talking with the client. I may also consult with my fellow team members and do some research to find solutions to similar problems. Then I give an estimate of its complexity, write the code and tests, and send the changes off for review by one of my teammates. Once everything is approved it’s sent to the client, and after a final approval it ends up on the production site. This cycle repeats itself daily, with every change being viewed and approved by someone on our team, the client, and ultimately the rest of the world.

Outside of our usual process, I need to make myself generally available for questions in our team chat room, e-mail, Skype meetings, and the occasional emergency. And yes, many of these things happen while sitting motionlessly on my couch next to my happy dog.

We also don’t just check in and check out; we are expected to log our time in detailed 15 minute increments. By the end of the day, between logging time for projects where I’m the primary or support developer and internal projects and meetings, I may have something like 20 entries for 5 different projects.

This remote working arrangement goes hand in hand with our shorter-and-less-soul-crushing-than-normal work weeks. I only log my time when I’m generating value. Each week I’m logging 30-35 hours of actual work, not just hours of being in an office. Sure, I’m able to sleep in more than most people and I don’t have a commute, but when you remove all of that overhead and can focus on accomplishing things, you’re able to work at peak efficiency.

But as a business owner, I’ve learned there are some logistical hurdles to managing a remote team.

1. Health insurance. We have people in many, many different states. Some insurance companies will cover lots of states, provided you have a critical mass (i.e., 50% of your staff) in your home state. But who wants to be constrained like that? I don’t want to be presented with the option of an awesome developer in Montana or a mediocre one in Utah and have to choose the Utahn because it keeps our balance over 50%.We insure through United Health Care, because it was our only option for nationwide care. Fortunately, it’s a good plan that we can enjoy.
2. State taxes and registration. This might seem like a no-brainer, but every time you bring on a new employee in a new state, that means you need to fill out that state’s specific tax forms. Some states are pretty simple, others are a pretty big pain in the butt. (DC, I’m looking at you). Some of them require that you fax in your forms, others have online forms that require Internet Explorer (WHO DOES THAT??). It’s a big mess.
3. Payroll service fees. We use Intuit Payroll. For every new state we add an employee, we add an extra $9 to our monthly fee.

The alternative to all of this is to hire a PEO (professional employer organization), a getup that becomes a “co-owner” of your company in charge of HR. You’ll circumvent all of these problems, but you’ll pay for it. The last quote I got was $155 per employee per month. Since these problems are mainly up-front issues (once you figure out your health insurance and register your business with the state, you’re mostly done), I don’t think it’s worth the additional monthly bill.

But I’m certainly motivated now to hire someone in Missouri, DC, Florida, Maine, Oregon or Utah.

We want to show that putting in the effort to do things right the first time makes a big difference, and that’s what we’re about. There’s a big difference between teams who do things the “right way” and teams that build things “good enough for now”. Here’s how we represent this idea graphically:

Two paths lie before our imaginary biker: a challenging uphill gauntlet to the summit, and an easy ride around the base. The former represents the hard work and resultant rewards of good architecture, solid testing, and aggressive project management; the later is hacky duct-tape programming with no real QA process and minimal customer involvement.

As the bike climbs the mountain, the world gradually becomes more beautiful; flora blooms, the sun comes out, and vibrant colors coalesce into a portrait of the ideal day. But when the biker chooses the “easy” path, gloomy skies prevail, the clouds roll in, and storms arise on the horizon.

This was our vision, and with the help of the new canvas support in most modern browsers, we’ve made it something of a reality. What follows is the short list of recommendations I now feel qualified to give after the implementation of such a project. Heed these, and you too can have a spiffy bit of flair to make people sit up and notice you when they arrive at your digital home.

1) Pick an animation library

Of course, if you’re really hardcore, you could do all the animation yourself, from scratch, directly with the canvas API. I actually considered this at first; how hard could it be to specify coordinates on a 2-D plane and make images move to them in a coordinated manner? Well, it might not be HARD, but it can definitely be very tedious. Animation of any type requires somewhat repetitive tasks that are commonly reused, and an abstraction layer makes this go WAY faster. We used fabric.js for our little mountain-biking escapade, and it worked just fine, but after some additional exposure to other options, I think paper.js would be what I would choose if I were to do it over. A lot of what took up most of my time was defining the path and various angles the bike would have to appear at frame-by-frame, and paper.js has some great path-simplifying functions that would have been quite helpful.

2) Think in terms of what REALLY needs to be animated

My first pass at making our little bike travel up the mountain involved 1 bike image and 4 background images (each one a landscape involving the mountain, the sky, clouds, and the various stopping points along the way). The idea was that each checkpoint on the way up the mountain would have the background looking greener and more alive, and the images would fade into one another as the bike traveled up the mountain path. I did this by putting the 4 background images on the canvas at the same location and gradually adjusting their opacity from one to the next as the bike moved. This worked, but involved a lot of calculations to step the fading along proportionally to the bike’s travel speed, and the performance on Chrome quickly degraded (the background was a large image, and adding 4 of them to the canvas took time).

We realized quickly that since the background wasn’t really being animated, just fading in and out, that putting it directly on the canvas wasn’t truly necessary.  We solved the performance issue by making the images smaller (jpg instead of png, and added some compression), and by placing them BEHIND the canvas and using jquery’s “fadeIn” and “fadeOut” methods to fade between them with little work on our part, leaving the actual canvas animation for the only really moving part of the scene (the bike).

3) Work smart, not hard.

The most tedious part of the whole process was moving the bike up the mountain. Since the mountainous terrain was a jagged path, the bike had to be moving at different angles, constantly changing direction and speed. At first I simply tried to do this frame by frame, specifying coordinates and adjusting them manually as necessary. This was very functional, but very tiring. Ultimately I realized that there was a simpler way. A straight line is easy to extrapolate all the coordinates along programmatically, so the trick we used was simply to break this complex path into multiple straight line segments. By manually positioning the image at the points where direction changed (maybe 5-8 points per path), we could use a script to divide the segment into a fixed number of frames between each point along a linear path (difference in x and difference in y). That saved my fingers a TON of typing.

4) Test in multiple browsers

All canvas implementations are not created equal.  What worked just fine in FF ended up running the bike behind the mountain in Safari and running in almost choppy slow motion in Chrome. This is really a given on any project anymore, but you have to do your dedicated browser testing before you release things into the wild (and yes, our bike rides well on the iPhone, too).

Long story short, a little animation (gimmicky as it may seem) can add quite a bit of personality to an otherwise mostly informational web presence. As easy as it is now to make this kind of magic happen, there’s no reason not to consider adding that additional special something to your next product.

Why I hate it: It’s fine when I know the phone number I’m entering. But if I’m entering a number I don’t know, I have to copy and paste it piecemeal rather than just plunking it in. More room for error.

Moreover, I think it represents laziness on the part of the developer. A developer looks at a phone field on a form and knows that people are going to enter their numbers in many different ways:

• (555) 555-5555
• 555-555-5555
• 5555555555

All of the above are acceptable, but you’ve gotta write software that’s smart enough to know what is and isn’t a phone number. It takes a little more work. Breaking the field up into three boxes takes away some of that extra effort (and instead makes the user do the work).

What I’d prefer: One big text field for my phone number. Duh.