Shad Reynolds

Inconsistent Tendencies

2011-11-02T00:00:00-07:00

The Back Button and Inconsistent Tendencies

There have been a number of posts lately about Android’s hardware back button, but they have, so far, missed the key issue. Basically, user behavior around the back button is inconsistent.

At ‘Food on the Table’, I have watched nearly a hundred people use our product on Android and iPhone (both live in person, and through UserTesting.com). One of the things that I’m constantly surprised by is how inconsistent user behavior is around the hardware back button. Some users will immediately jump back whenever they get somewhere unfamiliar. Others will just continue going deeper and deeper, always looking for some onscreen indication of where to go next, until they finally “give up” and tap the back button (“Well, I don’t know what to do here, so I guess I’ll just go back now”). While still others will get deep into the app and simply give up (“No idea what I should do now”).

I think one user put it best, “I don’t like to use the back button. It makes me feel like I’m failing. I like going forward in life”.

That’s a pretty incredible statement given that the entire design of the Android operating system sort of depends on you understanding how the back button works. To have three subtly different ways of looking at the same control is certainly not a good thing.

This sentiment has been echoed in some form or another by about 50% of our Android users. Whats more, in A/B tests where we exposed additional on screen controls for getting “back” to previous screens, we saw significant improvements in users “getting around”. However, when we ran these very same experiments on the iPhone, there was little or no improvement. iPhone users already know how to get around, they don’t need additional cues.

Takeaway for me: design for the least common denominator. Always have onscreen buttons for navigation. You cannot assume that users will understand the back button. I can assure you, they do not.

My git aliases

2011-02-09T00:00:00-08:00

My `git` aliases

I use the following aliases in git all the time.

Status Info

`br = branch`

Simple branch info. No muss, no fuss.

`bra = branch -v`

Branch info with just a little more muss & fuss.

`st = status --ignore-submodules=dirty`

Current status, excluding changes in those dirty little submodules.

Preparing for commit

`unstage = reset HEAD --`

Remove all, one or many files from staging.

`co = checkout`

revert one or more files back to original state.
move to another branch.

Log Viewing

`lm = log master..`

Show me commits on this branch that differ from master.

`mt = mergetool`

Bring up visual merge.

`lg = log --graph --pretty=format:'%Cred%h%Creset -%C(magenta)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative`

Show me the first line of each commit, with simple branch info & visualization.

`lgm = log master.. --graph --pretty=format:'%Cred%h%Creset - %s' --abbrev-commit`

Show me commits with first line of everything that’s changed since master.

Cleanup & Pushing

`pom = push origin master`

Horrible command, do not add this one. You’ll use it all the time. Even when you don’t intend to.

`remas = rebase master`

Rebase on master.

`fixup = commit --amend --reuse-message HEAD`

add files to staging
update the last commit with them

/via @jeffxl

Pausing a Branch

`wip = commit -a -m "WIP"`

Checkin all current files and denote that the work contained there is not complete. Usefull when you want to move to a new branch, but not lose track of exactly where you were on the current branch.

See go below for picking back up.

`go = reset HEAD^`

Pop off the latest commit on a branch and go back to working on it. Best when used in conjunction with wip

Alias from `~/.gitconfig`

[alias]
  co = checkout
  br = branch
  bra = branch -v
  st = status --ignore-submodules=dirty
  unstage = reset HEAD --
  lm = log master..
  mt = mergetool
  lg = log --graph --pretty=format:'%Cred%h%Creset -%C(magenta)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
  lgm = log master.. --graph --pretty=format:'%Cred%h%Creset - %s' --abbrev-commit
  pom = push origin master
  remas = rebase master
  fixup = commit --amend --reuse-message HEAD
  wip = commit -a -m "WIP"
  go = reset HEAD^

Food on the Table

2010-11-17T00:00:00-08:00

Food on the Table

I’m happy to announce that on December 1, I’ll be joining Food on the Table as a senior developer. It’s been a great year here at Workstreamer, but I’ve decided to move on.

Food on the Table is still small, only a handful of people at this point, but they’ve already made great progress. On top of that, a small, but growing, community of people have noticed (check out the wall on thier Facebook page).

I could not be more excited! :)

Building a JS Library

2010-03-20T00:00:00-07:00

Building a JS Library

Javascript is a beautiful language when you used correctly. More and more, entire applications are being built primarily in Javascript. Getting started, though, is often the hardest part. This article will attempt to provide a starting point for building reusable javascript libraries.

Wrap Your Code

Right off the bat, it’s important to wrap all of your code:

(function () {
  /* All of your code goes in here! */
})();

Wrapping code in an anonymous function ensures that nothing is “leaked” into the global context. This may not seem so important at first, but as your app grows, it really is nice to know that you’re not “stepping” on yourself (or other libraries that you may be using).

Expose Functionality

Now, what if we want to actually expose some code to the surrounding page. For our example, let’s assume we’re developing for spicyjs.com, and our code is in the file spicy.js. We’ll create a single global variable named “SPICY”.

(function () {
  var spicy = {}
  window.SPICY = {};
  
  /* ... */

})();

Here’s another alternative:

var SPICY = (function () {
  var spicy = {}
  
  /* ... */
  
  return spicy;
})();

Now, anyone that wants to use our code outside of this file can through the “SPICY” variable. Internal to our library, we can refer to to this object as “spicy”. This sort of naming helps when dealing with multiple libraries that talk to one another. If you see your variable name in all lower case, you’ll know where you are.

As a general rule, it’s best to name all global variables in all CAPS just so you’ll recognize them easily.

To expose a function to the outside world, explicitly add it to the “SPICY” object.

(function () {
  var spicy = {}
  window.SPICY = SPICY;

  function button(spec) {
    // build a button
  }
  spicy.button = button;
  
  /* ... */
})();

When using this library, you’ll simply call your method through the SPICY variable.

SPICY.button({
  title: 'Click Me',
  action: function (event) {
    alert('I just got clicked, yo');
  }
});

References

Adios Amigos

2009-11-11T00:00:00-08:00

Adios Amigos

(Reposted from the Spiceworks Community Water Cooler)

After nearly 3 years, a dozen releases, and a great deal of consideration, I have decided to leave Spiceworks in pursuit of something new. An opportunity has presented itself to me which I simply cannot turn down.

Working here has been one of the most incredible experiences of my life. It is truly inspiring to see how this community has grown and matured with time. The success of Spiceworks is surely attributable to the direct involvement of you, our users.

Rest assured that the Help Desk and Extension Framework will continue to be well supported after my departure. And know that I’m not totally out of the loop. I will continue to make myself available to Spiceworks (as time allows) on a contract basis, and I will be watching closely, as I feel sure that things are only just starting to get interesting.

Thanks to all of you for making my time here so special.

Exploring GitHub Pages

2009-10-10T00:00:00-07:00

Exploring GitHub Pages

I’ve been playing around with GitHub Pages and I think I’m liking Jekyll (and Pygments) a lot. As someone who builds code all day long, typical blogging software (like Wordpress) always makes me feel a bit far removed from my content. I prefer getting a little closer to the metal (but not too close). So far, this has been the perfect mix for me.

Pages

GitHub allows you to easily create an host your own site. I would go through how to set that up, but it’s so ridiculously simple and well documented on their website, there’s really no reason. Once you’ve set up your GitHub account, just visit GitHub Pages for more info.

Pygments

I want to write more articles about Javascript and Ruby. I’ve read enough horribly formatted articles to know that if you’re going to have code examples, you need to have the syntax properly highlighted. B&W that streams over the right margin into home mortgage adverts just doesn’t cut it. Therefore, it’s essential that I have well formated code. Also, I’m lazy, so I’ll need it to be simple. Jekyll’s integration with Pygments is just that, simple and seamless.

For Example, when I type:

{ % highlight javascript % }
(function anon() {
  // do stuff in here.
  // A very long line mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

  if (this.istrue && /foo/.match('foo')) {
    return true;
  } else {
    // Do something else
    things.each(function (thing) {
      thing.setName('The Thing');
      thing.setDescription("Something old, something new, something borrowed, something blue.");
    });
  }
})();
{ % endhighlight % }

Pygments produces:

(function anon() {
  // do stuff in here.
  // A very long line mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
  
  if (this.istrue && /foo/.match('foo')) {
    return true;
  } else {
    // Do something else
    things.each(function (thing) {
      thing.setName('The Thing');
      thing.setDescription("Something old, something new, something borrowed, something blue.");
    });
  }
})();

Which looks pretty nice.

iPhone

I also wanted a site that would look really nice on the iPhone. Really, there’s not much to that. Just keep the content simple—try to keep things to one column. Set a width with your CSS:

#wrapper {
  max-width: 500px;
  min-width: 500px;
  width: 500px;
}

And include one simple statement at the top.

<meta name="viewport" content="width=500" />

Now when my page is loaded on an iPhone, it looks really nice.

Shad Reynolds

Inconsistent Tendencies

The Back Button and Inconsistent Tendencies

My git aliases

My git aliases

Status Info

br = branch

bra = branch -v

st = status --ignore-submodules=dirty

Preparing for commit

unstage = reset HEAD --

co = checkout

Log Viewing

lm = log master..

mt = mergetool

lg = log --graph --pretty=format:'%Cred%h%Creset -%C(magenta)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

lgm = log master.. --graph --pretty=format:'%Cred%h%Creset - %s' --abbrev-commit

Cleanup & Pushing

pom = push origin master

remas = rebase master

fixup = commit --amend --reuse-message HEAD

Pausing a Branch

wip = commit -a -m "WIP"

go = reset HEAD^

Alias from ~/.gitconfig

Food on the Table

Food on the Table

Building a JS Library

Building a JS Library

Wrap Your Code

Expose Functionality

References

Adios Amigos

Adios Amigos

Exploring GitHub Pages

Exploring GitHub Pages

Pages

Pygments

iPhone

My `git` aliases

`br = branch`

`bra = branch -v`

`st = status --ignore-submodules=dirty`

`unstage = reset HEAD --`

`co = checkout`

`lm = log master..`

`mt = mergetool`

`lg = log --graph --pretty=format:'%Cred%h%Creset -%C(magenta)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative`

`lgm = log master.. --graph --pretty=format:'%Cred%h%Creset - %s' --abbrev-commit`

`pom = push origin master`

`remas = rebase master`

`fixup = commit --amend --reuse-message HEAD`

`wip = commit -a -m "WIP"`

`go = reset HEAD^`

Alias from `~/.gitconfig`