We're growing into something new. Read More

Nick Walsh

Wedding Single-pager

Just wrapped up the finishing details for our wedding site, which can be found over at: nick-walsh.com/wedding I'm not one to mess with illustration very often, but the birds/cages and such were quite a bit of fun to create. Font-wise, I'm using Ostrich Sans and Goudy Bookletter 1911 alongside Canaveral and Wisdom Script from the amazing Lost Type Co-op. The build side is pretty simple, taking into account a non-specific audience. I'm using a tweaked version of a rough jQuery plugin of mine for the navigation functionality - that can be found over at github.com/nickawalsh/sectionation


Try Ruby, v3

In the same vein as Rails for Zombies, we've launched version 3 of Try Ruby as a free course on the Code School platform. Even if you have little or no programming experience, it's easy (and fun!) to pick up and work through - and no account is required. @eallam is responsible for the sandbox implementation and framework for this version of Try Ruby, which was previously curated by Andrew McElroy, David Miani, and why the lucky stiff. For anyone going to RubyConf this week, Eric's giving a talk there relating to how we safely run user-generated code in the sandbox. Rubyists may notice some familiar characters adorning the interface - in tribute to the original Try Ruby creator, I fashioned a theme with elements from the beloved why's poignant guide to ruby. We're really excited to get this out - Try Ruby was a major inspiration when starting up Rails for Zombies and ultimately Code School. More about the project here.


Responsive Tabs

Last week, we launched an HTML5 & CSS3 course on CodeSchool. As with our other courses, the languages covered forced us to take a fresh look at the code editor and resources interface. After some wireframing, @jasonvanlue took to designing and came back with the new interface. In user testing, though, we had a problem cropping up - splitting the editor and resource (rendered html, css, etc.) sections horizontally with fluid widths was causing a lot of headache on small screens. To combat this, we've responsive-ized the tabbed area a bit, which looks like this. I've linked to the jsfiddle of a simplified, cleaned-up version of this to share. Expand and contract the 'Results' section to see the tabs and panels adjust a bit based on the available width. The goal was to avoid using JS listeners/events to handle splitting the panels and tabs, and using two active states solved that problem. Because the class changing is handled in the combined and split states, the user's latest selected tab conveniently will carry over if their browser is resized. There's also some consideration for JS-less environments in this version. Naturally, this example assumes your first tab/panel are important enough to split out on their own. Some modification would allow for multiple tabbed sections, rather than a 'static' section and a tabbed area. I know the JS probably isn't optimized, so any input on that is always welcome. :) If anyone wants to check out the course, it can be found over here

Rails Best Practices / Code School Launch

Here's a snap of a challenge page from our newly launched course, Rails Best Practices. A few months back, we at Envy Labs released Rails for Zombies, a free introductory Rails tutorial that allows all of the coding and evaluation to be done in the browser. It's been wonderful to see RFZ referenced a number of times in Forrst posts requesting intro Rails resources. Interface Additions If you've been through RFZ, you'll notice the interface above is quite a change. The first order of business was making the layout fluid and keeping the editor onscreen at all times. Watching devs work through the previous course really highlighted how inefficient the interface was - way too much mouse movement and scrolling. Now, the sidebar areas to the left and right keep their width and position, while the middle content flexes with the browser window. Error feedback no longer inserts into the body - messages are handled through a drop-down notice. We also upped the complexity of the challenges (since this one isn't considered an introduction), which required more information on screen. Where Zombies utilized mostly database tables for resources, now we're displaying routes, views, requests, and other pertinent info on the same screen. For this, we've contained the resources area and added the left sidebar tabs. Next up was the editor. We upgraded from Bespin to Ace, which gave a lot more skinning options. Most notably, we have multiple editors onscreen - either through a tabbed interface or split screen (the button to the right top of the editor toggles). It's been a big help to have the acutal 'file' names of the code being worked on, real editor style. Gamification One of the driving principles behind Zombies and all courses moving forward has been fun, and we're working to add gaming principles to the learning environment. With all of the courses under a common umbrella (Code School), public profile pages with achievement badges per course become available. Within the course itself, points are earned for challenge completion - and reduced as hints are utilized. There are definite plans to make use of the points in the future for leaderboards and such. Moving Forward It's been great to watch and contribute to the platform, and see how far the courses have come from our initial concept. There are a number of courses on the pipeline, one regarding HTML5 + CSS3 and another for jQuery. We've been rapidly iterating the interface and interactions, and hope to continue using feedback to make it better. I'd love to hear any feedback about the design or platform - making it as user-friendly for devs as possible is the ultimate goal. In case you'd like to see any of the sites, check out: Code School Rails Best Practices Rails for Zombies