It looks like a lot of steps, but there’s nothing too difficult involved in setting up Github hosting, just make sure you get all the steps in the right order!

Note: These instructions are specifically for Github for Mac, and though the process should be the same on Windows, your mileage may vary

Step 1: Sign up for Github

Create a free Github account at Github.com.

Step 2: Download the Github Application

Download the Github application for Mac or Windows. Open the application and complete the setup process. You’ll need to log in to your Github account.

Step 3: Create a new repo

In Git/Github, projects are referred to as “repos” or “repositories”. To add your project to Github, you’ll need to create a new repo for it.

Go back to Github.com and click the “Create a new Repo” Button in the toolbar. Give your new “Repo” (Respository) a name, and click “Create Respository”.

From the next screen, find the “Setup in Mac”/”Setup in Windows” button in the “Quick Setup” box. This will launch the Github application

The Github application will ask what you want to clone the repo as (what name you want the folder to have) and where you want to add it. Pick a location on your computer where you keep your web projects, like your documents folder. Click “Clone”. You now have a copy of your empty “repo” on your computer.

Step 4: Add files to your repo

Next, navigate to the location in which you saved your repo, and find the folder with the matching name. Open up this folder. This is where you will put all the files that you want to put online.

If you’ve already created a web page, you can copy your files into this folder. Say you have a folder called “website” which contains an html file, as well as an images folder with some images in it. Select the contents of this folder (not the folder itself) and copy them into the newly created repo folder. Note: name your html file “index.html” if you want a shorter URL for your website.

Go back to the Github application, and click on the “Changes” tab. There should be a list of files in your project and the title “Uncommitted changes”. Enter a “commit summary” into the text box (something like “Initial commit”), and click “Commit”.

Step 5: Sync Changes

Next, click the “Publish Branch” button in the top right corner of the application. Github may ask you to log in again, or may ask permission to use your login credentials. Once your project is synced, you should see the message “No unsynced commits”.

Step 6: Publish

To publish your website, click on the “branch” icon in the bottom left of the application, where it says “master”. In the text box, type “gh-pages” and hit enter.

Click the “Publish Branch” button again.

Wait a minute or so, and then your website should be published!

You can visit your website at your-username.github.io/your-repo-name. You can also find the link to your hosted project from the “Settings” page of your repo on the Github website in the “Github Pages” section.

Making Changes

If you want to update your website, keep making changes in the folder that has the same name as your repo. When you want to publish the changes, just open up the Github application and click “Publish Branch” again. Your changes should be live within a minute or so.

Using a custom domain

If you have purchased your own domain name, you can connect it to Github so that you can use your custom domain to view the site you published at your github.io url. This requires configuring the Domain Name Servers (DNS) through your domain provider. The instructions for setting this up are on the Github Help Site

It’s easy to make a site with lots of code – a program can blindly spit it out for you: unoptimized, a nightmare to edit, useless for accessibility. It takes skill to craft a beautiful site with the bare minimum of markup, but that site will be fast and search engine friendly, easy to edit and add on to, and easily made accessible and portable.

It’s easy to code superfluously. Your aim is to code succinctly. To that end, here are some quick tips on how to cut unnecessary tags from your HTML:

Avoid presentational markup like the plague

Presentational markup is non-semantic, i.e., it is not needed to make the content make sense in its unstyled state; it is purely for visual effect. Before adding another container element or an empty element, ask yourself if there is a way to not need it. Most of the following points contain solutions for avoiding presentational markup, but using CSS3 cuts out the need for a lot of it: use CSS for rounded corners, multiple backgrounds, gradients and border images.

Style the <html> tag

Developers sometimes forget to take advantage of this as an extra element to style. If you find yourself having to add another container within the body just to add or extend a background, see if moving the styles from body to html and from the extra container to body will work. For example, I’ve applied a background to the html element to match the site’s footer style (when it’s different from the main content background) so short pages will look like the footer fills the empty space at the bottom instead of ending up as a bar hanging mid-air.

Style pseudo elements

Pseudo elements are “elements that don’t exist explicitly in the document tree.” There are a few, but :before and :after are usually the ones leveraged to pull off clever styling tricks without additional markup. Find some tips here and here.

Don’t use an empty element to clear floats

Use a clearfix applied as a class, or use elements that always follow to clear by putting the ‘clear’ property on them. Understanding floats will help you know where to use which technique.

Use HTML5

…If you aren’t already. It saves a few bytes with its short-and-sweet doctype, and doesn’t require the type attribute on style, link and script tags. Be careful throwing around the new, semantic elements though. Not each individual image needs to be in a <figure> for example. You may be tempted to use the new elements for styling since they’re semantic so that means they’re ok, right? Not exactly. Consult the HTML5 Doctor to see when adding an HTML5 element makes sense.

Be conscious

Each time you go to add a new element to achieve some desired effect, think about different ways of doing it. If you find yourself stuck with adding presentational markup, do some quick searches to see if someone else has come up with a cleaner solution to your style issue. Make each element earn its way onto the page and soon you’ll be writing the leanest HTML you can.

Spoiler alert: lots of Apple and Ikea

James Costa — Creative Director

Toronto, Ontario

I’ve moved my desk around my condo a lot in Scarborough, Ontario (Canada), but I have always found the best places to have it are near windows. I love simplistic, clean setups — but my desk usually ends up being caught under piles of paperwork, and the desk itself has plenty of stains because of my lack of coasters. That being said, I’ve somehow found more productivity being in my room, but we’ll see how long I can last without napping instead of dealing with the overflow of paperwork.

• Canon Pixma MX870
• Macbook Air (1.8 GHz Intel Core i7, 4GB RAM, 256 GB SSD)
• 27′ Cinema Display
• SuperDrive and ethernet to USB adapter (because I’m retro like that)
• Western Digital 2TB Notebook
• Wireless keyboard and mouse
• iPhone 4s
• IKEA desk, chair, and fix ins!

Tom Neal — Designer

Chesterfield, United Kingdom

You know that saying: “Clean home, clear mind”? I totally believe in it. This workspace is where I spend the majority of the day, and having everything clean and organized boosts my productivity ten-fold. Living in rented accommodation means having to put up with boring beige walls, but an effective work-around was to add splashes of color with the lamp and picture frame. My fiancée and I are moving into our very own home later this year, so be on the lookout for an update!

• iMac 27″ (2.7Ghz Intel Core i5, 12GB RAM, 128GB SSD, 1TB HDD)
• 1TB Samsung M3 external HDD
• Energizer USB battery charger
• iPad Mini
• Altec Lansing Expressionist Bass speakers
• Monster Beats Solo headphones
• Wacom Bamboo pen tablet
• Freelance Ain’t Free print – Mikey Burton
• Original pen drawing – Chad Lenjer
• Mini Munny doll
• 8Ball (for those tough decisions)
• Lane Notebook
• Ikea desk, chair, lamp and picture frames.

Flip Stewart — Developer

Austin, Texas

I enjoy having a dedicated area strictly for working. By including only the necessities, I can focus on the important things — a big desk and comfortable chair. I also limit my distractions. Other than Hacker News and Adventure Time, of course. If I was going to add anything to my office, I’d put a coffee machine right on my desk, but I’m not sure the internet could handle me with that much caffeine.

• 13″ MacBook Air
• iPad Mini
• Apple Wireless Keyboard
• Magic Trackpad
• HiRise
• 60″ x 30″ Turnstone Table in Virginia Walnut with Tapered Platinum Metallic legs
• Uno Select Turnstone Chair in Blue Jay
• 16 oz Ball Mason Jar
• Ice
• Coffee

Matt Herron — Project Manager

Austin, Texas

I installed this standing desk in my apartment two weeks ago. It consists of a 2′x4′ laminated desktop from Ikea ($20), two 20″ shelf brackets from home depot ($35) and 6 screws ($5) connecting the shelf brackets to the studs, and the desk to the brackets. It’s a cheap, elegant solution for a standing desk. I set it up so that the desktop is 43″ high, exactly at my elbows, so my arms can rest comfortably on the desktop. Being an active, high energy person, I prefer a standing desk because it gives me the freedom to move around while I’m working, which helps my brain work better. Additionally, it’s a lot more comfortable in the long term: fewer back problems, prevents bad posture, avoids the sedentary lifestyle. I also have in the photo my yoga mat, backpack, the books I’m reading (listed below), and a lamp to light the space at night.

• 13″ Macbook air
• iPad mini
• UX Sketchbook
• GoalZero portable speakers
• Books (The Psychology of Influence, The Wizard of Menlo Park, The Imperfectionists, 1492, and SPIN Selling) for distraction/education
• Coffee
• Yoga Mat
• Backpack (for portability)
• Standing lamp

Jenna Boese — Developer

Saskatoon, Saskatchewan

I have a desk and chair somewhere and was going to stage them all pretty for you but it would be a lie. Lately, I’ve been working from my living room couch. Although I sit in the same space where I watch TV outside of work hours, during the day I don’t turn on any music or TV, and don’t take game breaks. It’s almost like the TV on/off switch toggles my living/work space. Sometimes I take the MBP outside to enjoy the nice weather, or to a coffee shop for a change of scenery. I do use the desk and chair, where my Mac is, for the occasional design work.

• 15″ Macbook Pro
• Hot pink clipboard with notes on printer paper
• iPad in sock
• Couch, cushions, ottoman, rug
• Serving trays
• Glass of water (where coffee is earlier in the day)
• Various game controllers and TV remotes
• Misc magazines
• Lots of cat hair

Tessa Thornton — Developer

Toronto, Ontario

My tiny desk is an Ikea kid’s desk that my little brother grew out of. The drawer is hacked into a keyboard drawer, which has allowed me to put off getting a grown-up desk for the past 8 months. The desk sits in the corner of my living room beside the big bay windows, so it gets a lot of light. Now that it’s warm out, I usually work on my porch in the mornings until my laptop dies.

• 13″ Mid-2010 Macbook Pro with128GB  SSD
• 23″ Samsung SyncMaster monitor
• Apple Extended USB keyboard (I need that forwards delete key!)
• Magic Trackpad
• Bose SoundDock with CableJive DockBoss to connect to my laptop
• Moleskine Daily Planner (Star Wars edition)
• One of my roommate’s giant coffee mugs
• Cheap Sony headphones
• Too many cables

Alexandra Bond — Brand Strategist

San Francisco, California

My office is in the loft of our apartment, which is nice because that means it’s far away from the kitchen but also the bathroom

Having an office upstairs helps me transition from home to work. My vintage desk is a pain to get in and out of apartments, but I refuse to part with it because it works well for my process; it’s super long, which is perfect for transitioning from taking notes to sketching to designing (to eating). I can spread out a lot. Also, it’s pretty.

Mostly I love the space because it’s surrounded by windows, and even opens to an outdoor patio so I can spend some time outside.

•  21.5″ iMac
• WD external drive
• LaCie external drive
• Midcentury vintage desk (that is solid wood and weighs too much)
• West Elm Mia table lamp
• Ikea Kvissle whiteboard
• Ikea Expedit bookshelf
• Behance dot grid book
• Oldest office chair in the world
• Authentic Hokusai ukiyo-e woodblock print
• Painting of a lemon

Nathan Yates — Designer

Liverpool, United Kingdom

Part of the great thing about working from home is that you’re in a comfortable environment whenever you need to be productive. I’ve tried to center my workspace around productivity by removing distractions, which makes me focus on my tasks.

Initially, the plan was to setup a dedicated office in one of the spare rooms in my apartment, however I found that having my desk in the lounge allows for a much more ad-hoc work schedule, perfect for working from home.

• 21.5″ iMac
• 13″ MacBook Pro
• iPad
• IKEA LINNMON Table
• Cambridge Audio Amp & Speakers
• Beats Solo Headphones
• Cheap Notebook
• New York canvas x 3

Conclusion

Though we live all across the hemisphere, our workspaces all share a dedication to productivity and creativity, and  a focus on creating a work-life balance. Our lively company chat room and weekly video chats keep us all connected and up-to-date, so we never have to sacrifice collaboration and teamwork for the independence of working from home.

In this example, let’s say we have a list of questions and answers that we want to show as an accordion. An accordion usually works like this: only the questions are seen, and when you click on one, the answer expands below it. When you click on a different question, the previously shown answer hides and the new answer expands.

Write the markup

For a list of questions and answers, you can use the oft-overlooked definition list element. Any similar markup pattern will work; this one is handy since it’s not often used for other things.

<dl class="accordion">
  <dt>Why is the sky blue?</dt>
  <dd>Because lorem ipsum</dd>

  <dt>Why is grass green?</dt>
  <dd>Because lorem ipsum</dd>
</dl>

Use whatever questions you want in thes and whatever content you want for the answers in the corresponding. Repeat the <dt> and <dd>
sets as many times as needed.

Include jQuery and a script file

Before the closing body tag of your html file, include a script link to the latest version of jQuery and to a blank script.js file that you create. It’s good to get in the practice of keeping your scripts separate, maybe even in their own directory.

In your script file

Create a blank function and call it from inside the jQuery ready method. Nothing will happen yet!

var accordion = function() {
  
};

jQuery(function($) {
  accordion();
});

The following lines go in your empty accordion function:

// first, hide all the answers:
$('.accordion dd').hide();

$('.accordion dt').click(function(){
  // after clicking a question, close any open answers in the list:
  $(this).siblings('dd').slideUp();

  // show the answer (item directly after the question) if it is currently hidden
  if($(this).next().is(':hidden')) {
    $(this).next().slideDown();
  }
});

And that’s it! Now it will work as described above. Here’s the full example without code comments.

Extra credit

You should probably make the questions look clickable so people will know to click them. The bare minimum would be to add this to your CSS, which will change the cursor when hovering the question so it looks like a link:

.accordion dt {
  cursor: pointer;
}

You could also wrap the questions in a link, but this will require some other changes to your markup and jQuery.

You might also notice that the questions are visible for a second or so when first opening the page. That’s because we are hiding the questions with jQuery which is called after the page loads. Viewers without javascript will see the fully expanded question list. Avoid this flash of unstyled content by adding display:none; to a .accordion dd CSS rule, and you can get rid of the first line in the accordion function.

Have fun

The result of my pondering and research ended up being both a template of .scss files that go into each project, and a concept for defining the elements that make up a web design. So here’s what I’ve come up with: it’s nothing revolutionary, but I like seeing how other developers do things, so maybe you will too!

Core Concept: Modules and Components

You hear a lot of developers talk about modules in all kinds of development. Modules are re-usable bits of something. In CSS, you might have a button module or a breadcrumb module, or anything that you might use multiple times within a site or app. Now, modules are great, and it’s always good to be as DRY as possible, but I’ve come to acknowledge that not everything is a reusable module, and if I start treating every element on my page as something I’m going to use again in another context, I’m usually just fooling myself and spending too much time trying to abstract something for the sake of abstracting.

I now recognize that the sites and apps I work on tend to comprise both modules and what I’m calling components. Components may not be the most accurate term here, but it’s what I’ve come up with. Components are all the bits that make up your web site or app that occur only once, or only in one context. Things like your page header or footer or sidebar. Sure, you could have multiple headers or sidebars or footers, but in a lot of cases, you know that you won’t. You might still have multiple instances of a component, but you’re only using it in the one context. If you need to use a component in more than one context, you should turn that into a module. I the main difference between a module and a component is context: a component is context-dependent, a module is not.

Markup

I’ve never been all that vigilant about commenting my code, but I’m really pushing myself to change that. Since I know I’ll have coworkers working on the same code that aren’t familiar with my little system, I know I have to make everything as clear as possible. I use a system of corresponding HTML and SCSS comments to make it clear to anyone reading the HTML where in the SCSS they can find those styles:

File Structure

I always have a main.scss file that imports all other scss files and compiles to main.css, the files I include are fairly consistent, but sometimes change a bit depending on the project:

The order here is important, both for css specificity reasons and scss inheritance reasons!

Example: Space Apps Toronto

The team at The Phuse is working on something pretty exciting this spring: we’re helping organize a hackathon here in Toronto called the Toronto Space Apps Challenge, and my coworkers and I have been developing the event website.

Props to my coworker Tom for the awesome design.

It’s a fairly simple website in that it’s only 3 pages, but there’s a lot of content, a lot of images, and a somewhat unusual grid system going on (18-columns instead of the usual 12 or 16).

Component: Schedule

To illustrate my component/module distinction, I’ll go over an example of each. In the ‘Schedule’ section of the Space Apps Toronto website, there are 3 schedule tables, one for each day of the hackathon.

The .schedule-table element is repeated: there is one for each day, but it is context-specific: this layout is specific to displaying this kind of content. I could abstract this out to something more generic (and maybe later I will), but at this point that isn’t necessary and makes the code harder to navigate.

The code looks something like this:

HTML

SCSS

Module: Callout

On the Space Apps website, I have several areas that are visually similar though semantically unrelated: the schedule for the pre-event party, the lists of media links on the press page, and the schedule for the NASA Youth Space Challenge page. This sounds like a good example of a module! I decided to call it ‘callout’ because it visually emphasizes the content inside it.

The code looks pretty much the same as it does for a component, but it lives in a different file:

HTML

CSS

On the Youth page, the schedule element is both a module and a component: It shares the callout styles with the press and pre-party schedule elements, but also has it’s own context-specific styles associated with the schedule component. (I’m re-using the schedule element here, but it remains a component and not a module because the context is the same).

Conclusion

I’m aware that this approach can seem backwards: treat elements as context-specific and abstract as needed, as opposed to abstracting everything and then adding specificity. I don’t have anything against the latter approach in theory, but in practice, I find I often end up with much messier code, because inevitably my re-usable modules need to be altered in one place but not another, a client or designer points out that actually those two elements should have different padding, or the text shouldn’t be bold in module instance #2, and suddenly the instances of my module are more different than they are similar, and at that point why even bother?

Surprisingly, I’ve found it easier to abstract out a component into a module as needed than to add increasingly specific styles to each instance of a module as a design grows and changes, and it leaves me with modules that exist out of necessity, rather than just for the sake of abstraction.

I’ve only been using this approach for 3-4 months, but it’s working well for me so far, and considering that after about a month of coding something I usually look at it and think it’s garbage, this is holding up fairly well. I’m always looking for ways to optimize my technique, and I’m currently experimenting with making heavier use of the Sass @extend function to create components as extensions of modules (but that’s another blog post…). I’m always looking for feedback with my coding techniques and methods, so feel free to leave your thoughts!

Imagine this scenario: you pop your new declarations into one of your stylesheets and reload the browser expecting things to be perfect, and they would be because you’re a kick ass developer, but nope, not so fast! Your elegant and masterful styles aren’t even showing up! So you pull up web inspector and see seven selector chains and their styles fighter for supremacy over the style of your elements. Not cool.

It’s alright though, you’ve got this. It’s not rocket surgery. It’s internets math!

Rendered styles are no coincidence; there’s a specific order of precedence. Let’s get you back in control.

1. !important

`!important` is a trump card. It will always win over any declarations, even inline declarations, but you should avoid using it at all costs, unless you’re up against CSS from an imported framework. When you find yourself wanting to use `!important`, a much better option is to refactor your styles to eliminate the conflict.

2. Inline CSS

Inline styles, styles applied within a HTML document, win over everything in your stylesheets. They should be avoided like the plague, though, as you don’t want to mix the styles with the content, and having styles in two places is confusing. HTML is concerned with content and CSS is concerned with styling. Let’s let both of those files do their jobs.

3. IDs

Even though `a.bar` targets a more specific type of link, the specifier with two IDs in the chain will override the first snippet.

4. Classes

Yep. Same thing as the IDs. Most of your miscellaneous fancy selectors, `.foo:not(.bar)` for example, also fall into this level of effectiveness. It’s important to note that selectors containing IDs will always win out over selectors that don’t, so even 100 classes won’t override an ID. 256 classes will in some browsers, but… please don’t do that.

5. Elements

For the sake of this discussion, that leaves basic element selectors.

Classes can cut out a lot of the pain that comes with nested elements, so don’t be afraid to name all the things!

Go Forth and Style!

Hopefully this gives you a better comprehension of the order of precedence styles take in your projects. With this rough outline, you’ll finally be able to get things looking how you’d like without any extra clutter or conflicts.

Stay Organized

Everyone will find their own system that works best for them, but here’s what I do: to-do lists. Whenever a new task or something to remember pops up, I write it down. I used to keep to-do lists in my head, or not go into as much detail, but putting a bit more in writing clears up brain space for other things, and greatly decreases the likelihood of forgetting something.

Each morning I look at what I can tackle for the day and put those tasks at the top of the list in priority order. It may take a while to learn to gauge how long certain tasks will take for you, but by tracking your time you can get a better feel for it. I usually prioritize by deadline and move tasks around to fit into work hours for the day.

I also keep a simple text file with details (like milestones, logins) for all projects I’m currently on as an overview. The different levels of organization help me keep a big picture view and zoom in for details. Project management apps can do that too, but if you use them with your team or clients, they can get cluttered. Not only does keeping my own lists keep me organized, I find that the simple act of writing things down helps with remembering them.

Stay Productive

The best way to be productive is to just do the work. Sounds simple, but sometimes it can be hard. How do you feel when you put off work, or avoid doing things you know you should be doing? You might have the nagging feeling that there is something you should be doing, or something that you are forgetting. The more you put things off, the more the pressure builds. Simple little tasks start to look overwhelming. Procrastination is a downward spiral and, like with any habit, the more you repeat it the harder it is to break. Imagine how good it will be to have the weight your to-do list lifted, and start actually doing those items. Form a new habit of doing, and you will feel happier and healthier.

Sometimes, even with the best of intentions, you may find yourself dreading some important task or wanting to put off work. In that case, I suggest productive (or structured) procrastination.

Stay Motivated

My daily to-do lists are essentially daily goals. Sometimes I celebrate reaching those goals with little rewards! It doesn’t have to cost money or be something you do every day. For example, a nice warm bubble bath at the end of a long day feels like a reward. Keeping a box of bite-sized chocolates around to snack on after crossing off a to-do works, too.

When you enjoy your work, just knowing you’re doing a good job is enough. Other times, you may give yourself a little push to accomplish things by telling yourself you can have ___ if you complete your tasks. If you have a hard time keeping yourself accountable, enlist the help of a friend or family member.

Stay organized, productive and motivated! It sounds simple, but really requires some self-discipline that, if you don’t have, you can learn.

What challenges have you faced regarding working from home or any of the above points?

Working on the Internet has many perks. One of them is that we work remotely. The Phuse has team members in Canada, The United States and England, which means we have the ability to work on our own schedules, using our own techniques, in whichever chair we choose to sit.

However, in this line of work, communication is absolutely critical. Taking a project from concept to completion requires a solid connection between all team members. Without a physical office and the ability to shout annoyingly across it to a teammate, we must take great care to ensure our communication is consistent and top-notch. Any breakdown in the communication process could potentially cause disruptions with the client’s timescale and budget, and that’s what should ultimately be avoided.

“We are not self-made. We are dependent on one another. Admitting this to ourselves isn’t an embrace of mediocrity and derivativeness, it’s a liberation from our misconceptions.” – Kirby Ferguson

Why Have Audits?

Our developers have carried out code-audits for a while now. They prove to be extremely useful as it ensures they are using optimal techniques to create a website or application which is built to last. It’s a chance to share, learn and collaborate.

So, if it works so well for them, surely it should work for designers? Therefore we recently started a series of weekly design audits. These are essentially short meetings in which our design group can get together on Skype and share what we have been working on during the past week. We start off by discussing the projects we’ve been hacking on and any problems we may have faced. Then we take turns to share screenshots of design work and ask around for critique. This is in addition to weekly kick-off meetings and an almost constant line of communication whilst working.

This new method of communication allows us to develop our critical thinking and improve the way we express ourselves through other people’s work. Also, as any other web designer will tell you, the longer you work on something, the easier it is to see your design through rose-tinted spectacles. Using another set of eyes gives us the chance to discover potential flaws in our design, which a client or another team-member may not have initially noticed.

This has improved our work process by opening up our own little project eco-systems to the rest of the team. It re-enforces the knowledge that, despite living thousands of miles apart, we can still work together, help each other and enjoy doing what we love the most – design kickass web stuff!

Global Jet via Compfight cc

A successful project starts with a complete understanding of the design process on both sides. If you’ve ever had trouble explaining your design process to clients, using a metaphor will help you get to a deep understanding quickly, without having to go into too much confusing technical detail.

So far I’ve only found one metaphor that fits. When explaining the design process to clients, I begin by telling them, “We’re the race car, and you’re the driver.” This establishes our roles early in the discussion. The details follow from that.

To swiftly reach a deep understanding, nothing is better than a good metaphor.

Don’t Bore Them with Details

In the past, when I wanted to explain the design process to a new client, I dove straight into agile methodologies, the iterative process, personas, wireframes vs. mockups, frontend vs. backend, bla bla bla. I could barely listen to myself talk without nodding off!

Now, when a client asks about our process, or what to expect when working with a design studio like The Phuse, I start with the metaphor.

“We’re the race car, and you’re the driver.”

One short sentence acquaints them with their role in the process. We can then use that as a jumping-off point to elaborate on their understanding.

“We’re the race car.” We keep the project on course. The studio’s purpose, as the vehicle of the driver’s success, is to move us swiftly towards the finish line.

“You’re the driver.” You define the goals. The client’s duty, as the driver of the vehicle, is to define the rules and milestones of the race.

The Race Car and Driver Metaphor

To further flesh out the metaphor, here’s a little sketch. I hardly ever repeat this story in its entirety, although I may use a sentence or two as appropriate. Good communication is about going with the flow, not reading from a script.

For the purposes of this article, however, I find it educational to see how well the metaphor matches up with our process.

“We’re the sleek exterior, the power steering wheel, the curving headlights illuminating the road’s next bend. We’re the anti-lock breaks, the record-breaking response time, the suspension that absorbs any imperfection in the road.

This automobile is smart. It’s made of many moving parts that all work together. It’s also adaptable—it can change directions with ease and stop on a dime.

But we’re nothing without our clients. Without YOU. You’re the most important part. If we’re the race car, you’re the driver. You tell us which track to drive on and how far to go. We can tell you how many miles (hours) we’re getting per gallon (out of retainer), but it’s your job to put fuel in the tank, turn the key, and step on the gas pedal.

Your goal as driver is to get us to the finish line. We’ll get you there in record time—and with style—but it’s up to you to determine where the race starts, and how to tell when we’ve reached the finish line.

What’s at the finish line? Good question. Your users are there, waiting to admire the work we’ve done together.

And at the finish line, when the MVP meets your users—that’s where the team finds its glory.”

Completing the Circuit

Nothing beats that car metaphor to convey a full understanding of our respective roles and responsibilities in the project. We want to empower clients, to work with them as a team, which is why the race car metaphor works for us.

We put the client in the driver’s seat, and our job is to take them swiftly and safely to their final destination, but we work best as a team. The best car in the world won’t win the Indy 500 without a capable driver behind the wheel. Similarly, the driver needs a top-notch machine that can handle the curves and carry them across the finish line without breaking down on the way there.

The State Of jQuery—Dave Methvin

The conference kicked off with jQuery Foundation president Dave Methvin giving his ‘State of the Union’ address about jQuery in 2013, which was great timing, since jQuery 2.0 Beta 2 was just realeased on Friday. Key takeaways:

• jQuery 2.0 does not support IE 6, 7, or 8. It’s being developed alongside jQuery 1.x (currently at 1.9.1) and maintains an identical API. They’re not expecting people to be using jQuery 2.x in production any time soon, but they really would like people to test out the beta!
• I’d somehow never heard of the newish jQuery Migrate Plugin, which can detect and restore deprecated features that are being referenced in your code when you’re running 1.9. Though intended as a tool to help you bring your code up to date with jQuery 1.9.x, it will also just patch in missing functionality to save the day if you’re *gasp* using deprecated functionality like .live() and $.browser (but you’re not, right?)
• jQuery now supports modularized custom builds that can get you down to just 17kb if you can live without Sizzle, animations, event aliases, and css. If you’re using plugins, don’t do this, as they most likely depend on something you might exclude.

That’s right, reject any module in our jQuery reality and substitute your own.
— Dave Methvin

Hardware Access and Device APIs with JavaScript and HTML5—Wes Bos

Toronto JavaScript guru Wes Bos gave a fun talk about accessing hardware APIs on mobile devices using JavaScript and HTML5. He talked about speedometer, accelerometer, camera, and file access, and showed us how he built a super cool security/mail camera with a live feed to his computer using WebRTC, node.js, socket.io, and a Nexus S.

It was cool to see how easy it is to access device hardware these days, but my favourite part of Wes’ talk was how cleverly he managed to solve his first-world problem (home office in back of house, mail comes to front of house) using the technology he already had and knew. I’ve often thought about attempting this kind of project myself, but always thought I’d need to obtain an Arduino and learn C. Now I’m planning on turning my old Galaxy S into a next-bus-display in my kitchen using my local transit system’s API.

Check out the HackPad and the slides

Bower and Grunt

Conveniently, after I spent Friday playing around with Yeoman, I attended two talks about two of Yeoman’s main tools: Ralph Holzmann of Twitter talked about Bower and other client-side package managers, and Dan Heberden gave a talk about Grunt for running tasks. I was already leaning towards trying out these tools for some of my projects, but now I’m more solidly convinced and feel like I have a good starting point.

Awesome Chrome Dev Tools

Paul Irish’s highly-anticipated “Front-end Dispora 2013″ talk covered a lot of ground, from CSS selector optimization (hint: don’t bother) to Chrome’s new requestAutocomplete() feature. My favourite part of his talk was watching him demo some awesome new and not-so-new features in Chrome’s dev tools (most only present in Canary). Some favourites:

• He didn’t seem to think it was a huge deal, but the ‘un-minify’ button got a huge reaction from the crowd, and I’m pretty excited about it.

This button un-minifies production code!

• Pressing H when you have a DOM element selected in the web inspector will toggle visibility:hidden for the element. This feature is actually present in Chrome Stable, and I’m sure it’s going to be super handy
• Pressing ? brings up a list of keyboard shortcuts for dev tools, as well as links to settings
• Check out the ‘Overrides’ settings: you can play with user agent, as well as set screen resolution and orientation, override geolocation, emulate CSS media types, and emulate touch events with click
• Enable dev tools experiments by heading to about://flags, then pick which experiments to try from dev tools settings.
• Cool dev tool experiment: Snippets. Snippets gives you a multi-line console to run code within your browser and lets you create and save various named scripts. Once you’ve enabled Snippets support, you can access your snippets from the Sources panel, in the Snippets tab. Right-click to create a new snippet, then just click ‘Run’ to run it. Save a snippet with CMD+S from within the editor. You can also run single lines of code within a snippet by highlighting the line, right-clicking, and selecting “Evaluate in Console”. Sweet!

Create and run multi-line scripts from the browser using Snippets

• Another experiment he went over was Inspect Canvas. Enable this experimet from dev tools settings, then head over to the Profiles panel and select “Capture Canvas Frame” and click “Start”. The resulting trace log gives you a play-by-play of all the canvas calls recorded and lets you replay them step-by-step.

Inspecting the canvas of a shooting-stars experiment I did.

Gone in 60 Frames Per Second—Addy Osmani

Addy Osmani’s talk about framerates, scrolling performance, and paint/repaint times was worth the price of admission itself, and the many audible gasps and ‘wow’s from the audience suggest I’m not the only developer whose mind was blown. This talk was a huge eye-opener and will definitely change the way I approach performance. Some key points:

• Framerate is extermely important not only to site usability and the perception of speed, but also to user engagement. A framerate of about 60 frames per second creates the appearance of a seamless, smooth experience, while lower framerates give you the appearance of ‘jank’, where you can see frames changing. Facebook did tests with lowering the framerate of their native iOS app, and saw user engagement plummet.
• Framerates tend to be dramatically lower on mobile devices, so if you’re hovering just below 60 frames per second on desktop, you’re likely under on mobile.
• Chrome has an advanced selection of tools for visualizing and monitoring framerate, go to the Timeline panel, select Frames, and hit record for a couple seconds. Scroll up and down a bunch to record behaviour, then check out the results.
• In the resulting graph, tall, coloured bars indicate your expensive processes. Click on a frame to see what’s going on, and drill down through the listed events to see what’s costing you. The most costly events are layout and paint/repaint. Things like resizing and decoding images, recalculating sizes and positions, using some CSS3 properties (box-shadow is shockingly brutal), putting too much JS functionality in your event handlers (especially scroll), and using position:fixed will really kill your framerate and scroll performance.

This website’s main offenders: costly image resizes

• When you can’t avoid things like fixed positioning, you can improve performance on desktop by forcing GPU acceleration with null-transform hacks like -webkit-transform: translateZ(0). There are a lot of caveats to doing this, and it won’t help you out on mobile, but it can be handy in some cases.

Addy went over much, much more in his talk and covered exactly how to find and fix your performance problems in devtools, and you can read all about it in the slides for his presentation.The presentation was full of practical advice on debugging and improving performance, and I highly recommend you go through the slides.

Conclusion

There were many, many other awesome presentations, and I’d never be able to summarize all the valuable information I’ve absorbed over the weekend, but a huge thanks to all the presenters for sharing their vast knowledge. Slides and HackPads for all the presentations shold be posted on the jQueryTO website in a couple days, they’re all definitely worth a look.