Something that I didn't find immediately obvious was how to deal with conflicts in Git, so here's a quick tutorial.

Conflicts arise when two different branches are working on the same file and then try to commit changes.

...A--
  /    \
M-------M-----X - Conflict
    \        /
     B------

Conflicts don't have to be catastrophic, it simply depends on what's happend with the file.

Simple Conflicts

Generally, if the changes that cause the conflict don't affect the same lines of code, git can auto-merge your changes together without too much trouble.

For example, if Branch A  was fixing a typo in a method getPatientByID and Branch B was working on a method called printReport, when the two branches are merged back into Master, assuming no other changes took place, git is smart enough to merge those changes.

Complex Conflicts

Sometimes, however, conflicts arise because two changes modify the same line of code. 

When this happens (here's the part it took me a while to actually understand) Git changes the source code of the file, and expects you to manually do the changes.

Git's response to a failed merge

And the updated source file

Let's get a closer look:

<<<<<<< HEAD
         alert("I'm... too lazy to act on my muted outrage!");        
=======
        var x = escape("I'm mad as hell, and I'm not going to take it anymore!");        
>>>>>>> dev

What are we looking at here?

Git has replaced the offending line of code with the code from both files.

From << HEAD to ===== is the branch you're currently working with, and from ===== to  >> dev is the branch you're merging in.

So what's the resolution? You have to edit the file back to what actually is needed.

So dev represents the new format of that line, and HEAD represents the new language the copywriters want you to use, you'd probably replace the whole thing above with:

var x = escape("I'm... too lazy to act on my muted outrage!");

Once this is done, you'll likely want to rerun any unit tests to ensure you didn't break the build, then re-stage the file using add, and commit your set changes.

Done!

Back in high school, you probably learned the Scientific Method. It probably looked something like this:

(quoted from sciencebuddies.com)

When I first got started with web design, I thought it was an art. That was bad news at the time because if you've ever met me, you'll know I'm not the most artistic or coordinated person in the world.

In reality, however web design, and most web-oriented business, is more akin to a science. Thoughtful, analytical research will drive much better results than pure artistic talent will any day.

That's not to say that there aren't some incredible artists in the web design community, there certainly are, and I envy them, but the ability to draw is not required for our craft.

In fact, lifting the scientific method right off the pages of your high school textbook can be a great way to apprach web design.

1) Ask a Question

The question is your client's business goal. Why did they bring someone in to build a website for them? More sales leads? Higher sales? Increased subscription rates? Launching a new product? There's a measurable, defined goal that your client has in mind that defines "success" for the website you're being asked to design, and your first job is to figure out what that is.

2) Do Background Research

Your next step is your market research. Look for best practices in their industry, talk to the target audience about what they want in a site. Do your research and find out how best to meet the needs of your client.

3) Construct a Hypothesis

Your hypothesis is your best guess at the first design. It's your gut instinct, and it's both good and bad news.

• For novice web designers, your gut is usually wrong, but you code it as-is anyway.
• For experienced web designers, your gut is usually close to the mark, but you test it to get it right.
• For veteran web designers, your gut is almost always correct - and you test anyway.

Don't ignore your gut instinct. Gut instinct is your subconscious mind building connections and patterns of the various data points you've experienced so far on the web. 

But like anything else, don't rely solely on gut instinct. Good science is based on multiple points of documented evidence. The more you design, and the more experience you get in the field, the better your gut instinct will be.

4 and 5) Test -> Analyze -> Repeat

This is the heart of good web design. Here, you test your hypothesis against the problem from step 1.

Your tools for this are mockups and user testing. Do some wireframes. Put them in front of people that resemble your target audience, and carefully watch their reactions.

The question you're trying to test isn't "do they like the design?". The question is "do they meet the goal criteria set out by the client?".

Are they clicking the "Buy Now" button? Are they successfully getting through the shopping cart? Are they quickly finding the information they want? Are they successfully entering the contest?

Whatever that call to action was - the goal your client's trying to achieve, that's what your design has to accomplish.

Iterate. Build on your idea based on the feedback you receive. 

While your first idea won't always be right, it doesn't mean that you're a failure as a web designer. The standard by which good web designers are measured is results. Are you solving the problem your client gave you? If so, move on to step 6; if not, try again!

If it takes you five tries to get a design that works, that's a success. You meet the goals laid out in Step 1, and your client is happy.

If you sell a client the first thing you think of and it doesn't work, your client won't be coming back.

6) Publish your Results

Once you've got a working design, build it. This part you should be familiar with.

Conclusion

Web Design is a beautiful science. You start with an idea, and create something beautiful as an outcome. A little bit of science can go a long way towards making that beautiful thing more successful.

Like what you've read? Follow me on Twitter.

Responsive Design, or the idea that a website should respond to the size and orientation of the device on which it's being viewed, is a tough concept for some designers and developers to wrap their heads around.

The best advice I can give someone who is just getting started in responsive design is to starting thinking responsively right from the start. Don't create a site for one device and scale down, think about all devices the whole way.

"But that's a lot of work!", you say.

It doesn't actually have to be. Here's a simple hack I use for wireframing sites that I want to be responsive, and it doesn't take much work at all.

Tools

All you need for this is:

1. a sheet of 8.5 x 11 paper, 
2. a pen, 
3. and if you're a slightly OCD like me, you might want a ruler.

Step 1

Fold your sheet of paper in half height-wise. You want two fat rectangles, not two long, slender ones.

Step 2

Fold the closest rectangle up. When pressed totally flat, the paper should look like 1/4, 1/4, 1/2.

Step 3

Open your paper up, and it should look something like this:

Step 4

Rotate your paper 90% and fold it up lengthwise. We're trying to create thirds here, so with the backside of the fold hidden and pressed completely flat, you should be looking at two equal halves.

Step 5

Open your paper back up again and use your pen to draw along the folds so your paper looks something like this:

You're done!

Now you've got a single sheet of paper ready for simple wireframing that gives you approximate dimensions for Monitors, Tablets and Smartphones, while leaving a little space for a Site and Page Name, as well as some Notes!

The dimensions aren't exact, but they're close enough, and at this point, you're just wireframing; you shouldn't be focusing on details anyway!

Using a tool like this, you can ensure that non-PC devices are first-class citizens, and your responsive with purpose, not as an afterthought.

Do you have any cool tricks that help you with web design like this one? Let me know!

If you like stuff like this, you can follow me on Twitter and drop me a line!

A new trend that I've seen in UI design lately is to try to redesign the scrollbar. While I understand the good intentions, we've seen some particularly horrible examples of UX from these attempts.

A Horrible Idea

Reinventing or reskinning the scroll bar isn't exactly a new phenonmenon. Ever since Flash became a popular medium, we've seen lots of different attempts to make scrollbars sexier.

Altering the scrollbars creates two problems:

1. Scrollbars are a central part of the application
2. Scrollbars are normally uniform across the OS of computer.

Scrollbars are Central to the application

Scrollbars are a tool to give access to content that normally wouldn't fit on the user's screen. They're particularly important because screen sizes vary so widely. Altering the design or function of the scrollbars leaves you in danger of discouraging or disabling access to some of your content - content that you presumably want people to see!

Scrollbars are uniform across an OS

For most applications, scrollbar design is set by the OS, not the individual application (similar examples would be the minimize and close buttons, or with window chrome). Changing scrollbars for your particular application or website can be confusing because your UI will be an exception. Even if your design is good, you're causing an initial element of confusion with your alternative view. 

Examples

Ubuntu 11 and the Unity UI

The most notorious example of Scrollbar UI gone wrong is Ubuntu's new Unity UI. Linux distributions have never been particularly pretty from a design point of view, but Unity was Canonical's attempt at stepping into the 20th century with UI design and bringing Linux closer to Windows and Apple in visual appeal.

Unfortunately, the scrollbars in the new UI are particularly bad. As a slim coloured bar with no iconography, they're largely hidden when not in use. The pop-up overlay is particulaly confusing, as it moves with your cursor even when not actively engaged.

Google Docs

I'm a huge fan of the clean design of Google now that they've launched Google Plus, but the scrollbars in Google Docs are not effective. Similar to Ubuntu, they've gone for the slim coloured bar with no iconography. There are also no buttons at the top or bottom as with traditional scrollbars. These scrollbars literally disappear into the screen noise. Not good.

Gawker

Gawker - The only indication that more content exists...

Worst of all designs is the new sidebar of Gawker. Their idea? No Scrollbars. They made the decision that between the scrollwheel and cursor (assuming the scrollbar has focus), the user should be able to figure out how to scroll. 

This is awful for many reasons, but the biggest of which is that the user has no visual clue that more content even exists. Unless you magically happen to scroll while hovering over the scrollbar, you'll miss that content. That's downright awful.

I think I read somewhere that they're planning on changing it back, and I certainly hope that's the case.

Conclusion

Look, I get it. Scrollbars are dull and kind of ugly, and everyone would really be much happier if they were just a little more elegant, but please, do your users a favour, unless it's absolutely mission critical to your application to modify the scrollbars AND you've done a ton of research and user testing on the new design, just leave them alone.

Please.

Ever wish you could collapse the comments on Hacker News like you can on Reddit? I sure did. So much so that I wrote a little script to add that functionality.

Not a complicated little project, but certainly satisfying.

• Download the Chrome Extension
• Download the GreaseMonkey Script
• View the Source on GitHub

I find myself having to append file names often in JavaScript. 

var appendToFileName = function(filename, toAppend) {
        var x = filename.lastIndexOf('.'), before, after, newFileName;
        before = filename.substring(0, x);
        after = filename.substring(x, filename.length);
        newFileName = before + toAppend + after;
        return newFileName;
};

Anyone know why substring in JavaScript isn't subString? That gets me every single time!

Applies to Learning, Coding, Writing, Sports and just about anything else worth doing...

I've spent the past week learning about Unit Tests and TDD. It's a frustrating process that shows a lot of holes in your code and your development methodolgy, but from what I've seen so far, I get better code from it.

I've heard a number of blogs and tweets mention that TDD is where creative code goes to die. The regimented approach robs development of the fun and excitement that comes from quickly "getting it working". I can kind of see where that's coming from, but at this point, I'm still a novice. Tried and true developers that consistently produce high quality code may have the credibility to eschew TDD and survive. They are not me. 

The Revised Coding Process

1. Diagram
2. Pseudo Code
3. Unit Tests  -> If you have trouble writing tests, refine pseudo code
4. Code
5. Test
6. Refactor

So, each bit of code I write seems to get a little bit better, which is great. Of course now I have to go back and rework all the code I wrote before this, but if this keeps up, eventually I hope to be consistently producing code people will pay for.

At this point, however, I must be competing for The Slowest Developer on Earth.

I love GitHub, but just realized a potential mistake that put me into a panic until I'd verified that I hadn't fallen pray to it yet.

Does your source code include passwords, keys, or other information in plain-text that you wouldn't like anyone to see?

Does your application include a web.config type file containing such information that is secure when loaded onto a web server, but might be included in your git repository?

Remember, kids! Anything you include in a public GitHub repo is just that - public.

You've got a few tools to mitigate this issue:

• Use your .gitignore file
• Add a hook to your git repos to remove sensitive data
• Use your framework's best practices to mitigate these issues (and improve application security).

Thankfully, I realized this before I'd made any mis-steps, but still. GitHub is a fantastic community and a fantastic tool; just be aware that when you're sharing source code, make sure it doesn't contain anything that you wouldn't want others to see.

I've been playing with Canvas recently and got to try out the excanvas library in order to extend 2d canvas functionality to IE. I can't speak highly enough about excanvas by the way, try it out if you get the opportunity.

Anyway, I found myself in a situation where I was loading excanvas in the header, and drawing on the canvas inside of jQuery's (document).ready(), but excanvas hadn't always loaded by the time jQuery started to draw.

I learned this little trick from Paul Irish's "10 Things I Learned from the jQuery Source" (watch it if you haven't, it's awesome.)

Here, we're using setInterval to check to see if excanvas has loaded every 1/10th of a second, and if it has, then doing our canvas work.

$(document).ready(function() {
  var canvas = $("#myCanvas")[0],
  ctx, interval, i = 0, MAX_TRIES = 10;

  (function draw() { // Self-executing function starts us off
    if(canvas.getContext){ // If excanvas has loaded...
    // draw stuff
    } else {
      if(i < MAX_TRIES) { 
        i++;
        interval = setInterval(draw, 100);
      }
      else {
        clearInterval(interval);
        // Fallback code here
      }
    }
  })();
});

You can add an alert(i); in once canvas loads to let you know how many tries it took for your dependency to load. I haven't run into a situation where it's taken more than a couple of tries, but it depends on latency.

Not exactly a groundbreaking script, but certainly something that helped me out.

If you've got any questions or comments, you can leave a note below or catch me on Twitter.

While I've been working on the web for a long while now, my personal projects have really stepped to the forefront over the past couple of years. My "process" for getting work done has evolved over that time, but not exactly in the way I expected.

"Process"

If you've ever read someone like Rands, you'll know that some nerds have a highly curated process for getting work done. My "process" for getting work done isn't so much a process, but a lack thereof, and while it works for me, I think it drives just about everybody else, including my lovely wife, nuts.

When and Where?

Work time for me is quite literally any time of day. At any given time, you can find me noodling on projects in the cafeteria before work, over lunch, on public transit, in the car on long trips, in coffee shops, at home on the couch, at my desk, and in bed after my wife as fallen asleep during occasional bouts of insomnia. This isn't so much a conscious choice, as a coping mechanism I came up with due to a long commute at my last job. I now have a significantly shorter commute, but I've gotten used to being in a constant state of working on my projects, either physically when I've got a few minutes, or mentally when I'm on the move.

I have noticed that my focus seems to get better as the day wears on, but rarely have the opportunity to capitalize on it 

How?

While most developers I know have a facination with having great hardware, my development machine is actually an Acer Aspire One netbook. Yes it's slow, but it's also incredibly moble, which is a critical because I literally carry my netbook with me at all times. If I've got more than a 10 minute lull and a place to sit, odds are I'm going to bust out the netbook and continue noodling at whatever problem I was working on last time. Heavily tied to this process is my Blackberry, which I use to tether to the internet. For whatever reason, accessible wifi just isn't usually available during my day-to-day, so a tethered Blackberry and a healthy data package keep me moving. It also helpfully takes up the lull times that are more than 10 seconds but less than 10 minutes.

I'm not emotionally tied to either of these devices from the perspective of brand loyalty - they're simply what was available at the time, and they work, so that's good enough for me.

All In

So, that's about it. If you see me, brow furrowed in front of my netbook. Feel free to tap me on the shoulder and say hello.