I redesigned this site a smidge. It's not a huge re-thinking or as big of an undertaking as v10 was, but it's different enough I'm going to call it v11.

Some of it looks like this:

Less

Gone is the Downloads section (also has been called "Demos"). While that got a good amount of traffic, I never kept it up and the demos were getting long in the tooth. I live in a world of demos and that place is CodePen now.

Gone is the Gallery. As much as I liked it, experience taught me I didn't update it enough to be worth it. I still have a huge archive of screenshots I obsessively capture, but until I can figure out a smoother way post them (and do it responsively) I'm going to let that be.

Gone is the ability to search specific sections of the site. All that did was link to different Google Custom Search engines specifically limited by sub-directory. The default search is good enough.

The logo is just simple one-color Gotham Rounded now. I still think of the asterisk as the logo mark for CSS-Tricks, but I couldn't figure out a good way to incorporate it. I'm sure it will return someday.

Gone is the slew of links in the footer. Only the important ones are left.

The homepage (and rest of the site) is 2-column instead of three.

Simpler feels better around here.

More

While in some ways there is less, there is also more posts shown on the homepage. It's such a lightweight and easy thing to do, might as well.

Speed

Speed is always a goal here, as it should be on any website.

There are less icons in use. For the ones remaining, I dropped icon fonts in favor of an inline <svg> icon system, meaning zero requests.

There are only a handful of images left and I plan to nix as many of them as I can.

A good homepage load is typically under a second, which is a solid place to be. I plan to keep working on it. I think there is a few more resources I can either combine or remove.

On pages with a lot of comments, it's clear that Gravatar is the slowest thing, mostly because it can be a ton of individual requests. I'd like to start attempting to lazy load those. I'm not ditching them I don't think; I've always been a fan of avatars next to comments and other user-authored content.

Type

The CSS-TRICKS logo font is in Gotham Rounded. Love it.

While I was using H&FJ Cloud Typography fonts, I originally went with Ideal Sans for the body font. I also love it, but I got a ton of complaints right away that it rendered poorly in the classic Window/Chrome scenario. I could have tried out some things, but the fonts were also loading a bit slowly, so I decided to nix Ideal Sans and go with a (gasp) non custom font. Just regular ol' Lucida Grande. I don't love it, but it's fast and renders fine everywhere.

Look

Generally better aesthetics is another upgrade - at least in my opinion. I've long been a fan of bright, fun colors, especially on dark. It's a thing I've (poorly) copped from Kevin Hale, which you can see from his slide decks like this one:

There is only a handful of colors defined and I use them over and over in as logical of a system as I can. Feels decently cohesive I think.

A fairly major aesthetic change is the big-ass headers:

I've always liked that — when an article greets you that clearly. It was sort of a last-minute change for this design, and the newish nGen Works blog pushed me over the edge when I saw theirs:

Validation

Dribbble actually validated the whole idea for this design. I posted a simple example there and it got so much positive feedback I decided to go for it.

We're about a week post-launch as I write this, and the design has largely been met positively. That's literally a first =).

Resizeable CodePen Embeds

I was hoping to add more functionality to the site this round, but unfortunately I didn't get to do as much of that as I would have liked. One thing I did get to was making all CodePen embeds resizeable.

Since that functionality is only really useful on large screens, I did a super basic cutting of the mustard to load it in from my global JavaScript:

// Cut mustard
    if ($(window).width() > 1000) {
      $.getScript(__templatePath + "/js/min/mega-mustard-ck.js");
    }

I wrote it up on the CodePen Blog.

Forums Upgrades

• You'll get an email notification when you are mentioned by @username in a thread. So you know if someone is talking about you or specially trying to get your attention. You can also still subscribe to a thread after commenting (like you can in the blog comments) if you want to keep up to date on all follow-up posts.
• You'll get an email notification if your post gets caught in spam, with instructions on who to notify so it's not lost to the ages.
• The concept of Featuring and Burying Comments has made it to the forums. Myself, any of the moderators, and the person who started that topic have links to feature and bury replies. I hope that encourages better answers.
  
• For regular Forums visitors, you might appreciate the new All Topics page which shows the most recent activity in all the sub forums combined.
• Markdown has made its way into Jetpack, so rather than use a separate plugin for it, I'm using that now. Via a plugin I had custom built by Justin Sainton, Jetpack-markdown is in use in the forums as well as the blog comments, but not on the blog itself (legacy reasons for me). I also replaced the live comment preview with a preview tab in the blog comments. What's nice about that is that it's a real live preview rendered by the server, so it's not faking it with a client side lib like it was before.
• In v10 I never quite finished the responsiveness of the Forums. Should be much better now in v11, although not perfect.

History

I've added v11 to the absolutely embarrassing Design History page on this site.

Issues

There are still some things I'm ironing out. If you see a bug, the best way to make sure I'll see it is to shoot over a message - and it would be much appreciated.

Design v11 is a post from CSS-Tricks

There are no test tubes, petri dishes or microscopes in Ivan Erill’s  research lab.  No chemical cabinets or safety goggles.  In fact, this room on the first floor in the Biological Sciences Building at UMBC looks more like a typical office: a bunch of desks, computers, and swivel chairs.  It’s what scientists call a “dry lab.”  (For the rest of the story, click on website link ).

HTML5 games still have a lot of promises to fulfill, but the W3C gamepad specification is a great example of something that’s going well. The spec is still a working draft, but the prospect of reading game controller data in a browser environment is tantalizing enough to start experimenting.

Why Use a Gamepad?

A gamepad is a type of input device commonly found on popular gaming consoles, like the Xbox, PlayStation, and Wii. Some hardware makers, such as Logitech, also make these controllers for use with a PC (and by “PC,” I mean Windows, Mac, or Linux hardware). While many avid PC gamers will claim that a mouse and keyboard are superior, console controllers can feel more familiar to a broader audience.

A PlayStation 4 controller. (Photo by Nick Pettit/Treehouse)

Secondary to games, a gamepad could also be used as an alternative input device in the context of the “10-foot experience,” when users are sitting far away from a large screen. For many individuals, this is the preferred remote control for watching movies and television shows. I’ve written about television experiences previously, but I think gamepad support is a great addition for any web app designed to function in the living room.

The Gamepad Specification

The W3C specification for gamepads has been through several iterations over the last few years. Early on, JavaScript libraries like gamepad.js were necessary for basic features like button mapping, but this is no longer the case. Most of these libraries are now deprecated (including gamepad.js) because the working draft evolved to include support for more key features.

Also read: HTML5 Games: A Land of Broken Hopes and Dreams

The W3C smartly narrows the definition of a gamepad to devices with buttons and axes, specifically excluding motion sensing, gesture recognition, and a few other points of potential confusion. Additionally, they define only one canonical button layout known as the “standard” mapping.

The “standard gamepad” is the default mapping for controllers. The mapping property should be set to the string “standard.” (Illustration courtesy of W3C.org)

If gamepads become more than just a curiosity for you, I recommend you read about all the new gamepad interfaces in the specification, but the most important is the “gamepad” interface that has the following attributes:

• id – This is a string that identifies the brand or style of gamepad.
• index - When multiple gamepads are connected, the index can help select a specific gamepad device.
• connected - This is a boolean that says whether or not the gamepad is connected.
• timestamp - A timestamp indicates the last time the gamepad data was updated.
• mapping - The only currently supported mapping is “standard” so this isn’t really too important (for now).
• axes - This is an array that typically stores the values of analog sticks.
• buttons - This is an array containing “GamepadButton” objects. Each GamepadButton has a “pressed” boolean property as well as a “value” float property that can be used for other miscellaneous analog controls, like the triggers on the back of modern gamepads.

Cross-Browser Gamepad Support

If you’d like to test your hardware and software configuration for compatibility, plug in your favorite USB controller and head over to the HTML5 Gamepad Tester. Results may vary, but in Google Chrome on Mac OS X 10.9, I was able to use my PlayStation 4 controller right away. At the time of this writing, Firefox doesn’t have support enabled by default, but you can turn it on by searching for “gamepad” in the about:config settings.

The HTML5 Gamepad Tester is a site that makes it easy to try out your hardware and software configuration and check for gamepad support.

Programming with the gamepad API isn’t too difficult. The W3C recommends coordinating the polling of controls with requestAnimationFrame, so that the framerate of a game does not become oddly de-synced with the input. Gamepad data should also be polled as closely as possible to the renderer to maximize responsiveness and minimize controller latency.

The other quirk right now is spotty browser support. As I mentioned previously, the gamepad API only works in Firefox and Chrome. In Firefox 27 and lower, you’ll need to enable it by setting dom.gamepad.enabled to true in the about:config settings. That being said, Firefox has the best support right now. In Chrome, the events that detect when the controller is connected and disconnected are not implemented. Instead, you have to initiate input by mashing a button on the controller. Additionally, Chrome uses the webkit prefix when polling for gamepads using navigator.webkitGetGamepads() so you’ll need to account for both in your code. For more details, I recommend you read the MDN documentation on the gamepad API, because it includes lots of in-depth cross-browser example code.

Do you think gamepads will help support the future of HTML5 games? Or is this just yet another browser API that will be relegated to obscure use cases? I’d love to hear your thoughts in the comments.

The post Gamepad Controls for HTML5 Games appeared first on Treehouse Blog.

Jon Liu at work at Name.com (Photo by Tim Skillern/Treehouse)

The “breaking moment” in Jon Liu’s teaching career came at 7 o’clock in the morning.

An hour before his students arrived for classes, he sat in his car, stared at the school where he taught and wondered:

What if I didn’t get out of my car today? 

What if I just sat in the car all day and I didn’t go in? 

What would happen? 

That morning marked the beginning of the end of Liu’s teaching career — and the start of a promising career in software development. But it didn’t happen along traditional routes.

He taught for a decade, first in California as an elementary school PE teacher and then web design, yearbook and journalism at a high school before finishing at a Denver middle school. He loved teaching, but it left him exhausted and eager to start anew.

Liu today works for Name.com, a web domain services company, as a front-end developer and codes in HTML, CSS and JavaScript. His first job in development was at the University of Denver, where he learned on the job while upgrading the university’s CMS tools to HTML5 and CSS3. Along the way, he’s absorbed new skills every day and credits online courses and developer conferences among his go-to resources.

“It never hurts to learn more,” he says.

(iStockPhoto)

Brighter Days Are Ahead for Web Designers and Developers

Liu talked with Treehouse recently about his path to the web development world and the pitfalls he avoided. He also shared advice he’d give to potential students who perceive a web education as too scary, too time-intensive or otherwise too out of reach.

In the United States, software developers earn a median annual salary of $93,000 a year — or $45 an hour.  That’s according to the Bureau of Labor Statistics, which projects that the field will grow at a “much faster than average” 22 percent through 2022.

But Liu, who earned degrees in business administration and education technology, wasn’t just lured to switch careers by a better salary and an outstanding job outlook.

“I really like writing code,” he says. “I really enjoy problem-solving.” Liu notes that his personality is suited to unraveling programming riddles and he finds an immense sense of satisfaction once he’s able to crack a problem.

A similar passion also led Jen Byyny, a senior UX designer at Yahoo, to explore a career change. She worked as an executive assistant at a California advertising agency when she discovered a talent and aptitude for web design. She tackled night classes in web design for three years and worked her way to art director at the agency in five years. She then left the firm to complete a master’s in media design.

“It wasn’t a traditional path,” Byyny says.

And education is increasingly not traditional for a lot of Americans who embark on new careers.

While the BLS doesn’t examine how often Americans change careers, we switch jobs every 4.4 years. And the way we’re learning new skills is certainly different. More than 7.1 million students enrolled in at least one web class in the fall of 2012, according to the Babson Survey Research Group, which tracks online education. That’s a 6.1 percent increase over the previous year.

In short: We’re revamping how we study for our future careers.

Resources like Treehouse are instrumental toward that, Liu says. Students should also seek a well-rounded education by exploring meet-ups in their area, following high-profile programmers on Twitter and attending developer conferences.

It’s Not Too Late to Play, Explore and Learn

What guidance do Byyny and Liu have for those considering a career change and who might view web development as too formidable?

• “Practice,” Byyny says. “With anything. People say that about sports, little kids say it about learning to read. It’s the whole ‘you won’t know unless you try’ attitude.” She urges students to create designs on their own time and unveil them to just a few people with whom they feel comfortable sharing.

• It helps, Byyny says, to grasp foundational knowledge like color theory and typography. And it’s never too late to learn: “It’s not too late because you can play, you can explore. There’s no harm in that. If possible, find a mentor because they can also help guide where [your] focus should be.”

• “Dip your toes in the water and try it out first,” says Liu, who took a web programming class in 1999 but is otherwise self-taught. “You can take a single class and learn that specific language and before you start working on the next resource. Before you know it, you have a full breadth of knowledge to transition to that career.”

• “From every failure, there is a learning opportunity,” Liu adds. “Even if you find [a project] doesn’t work the way you intended, that gives you the opportunity to learn how to do it the right way.”

Beyond learning new skills and making more money, what are the added benefits?

• “I don’t think any two days are the really the same,” Byyny says. “If you’re trying to solve different problems, it keeps you and your problem-solving skills sharp and allows you to grow.”

• Liu says the attitude and culture at software jobs are indispensable: “That’s more important than the code I write or the projects I work on. People are more important.”

But you first have to start.

“Do it,” he advises. “Don’t sit and think about it. Start doing something. Right now, start building something that you want to learn.”

The post ‘It Is Never Too Late’: How a Teacher and an Artist Switched to Web Careers in Midstream appeared first on Treehouse Blog.