The Active Record The Starter League Blog

The Starter League, founded in 2011, is a small school in Chicago that teaches Rails, Ruby, HTML/CSS, and User Experience Design. The classes are intensive, three months long, one to three days a week, and taught in person.

Our New Workspace

By Vince Cabansag & Caity Moran on April 1, 2014

We’ve been teaching since 2011. In that time, we've called a few places home. We started in a corner of the Groupon offices, moved for a brief time to the John Hancock Center, and for the last two years, we’ve been running The Starter League from our own space within 1871.

With the success of Starter School, our nine-month grad school, we found ourselves needing more space. These students typically work 10 hours a day, five days a week, all from a single classroom. 1871 has been a terrific workspace in lots of ways, but it's been clear that the students need more space. A place to call their own.

We began looking for a new space in the fall. Quickly we learned of a 12,000 sq. ft. space, split over two floors, soon to be vacated by Sprout Social. It was great: it could accommodate our current needs and give us room to grow. So we pulled the trigger.

With the help of a grant awarded by the State of Illinois, and using the same architect and construction company that built out the amazing 1871 space, we’ve created a space fit for our students’ needs. The classroom has two projection screens, writeable walls and a layout that facilitates our hands-on approach. Students also have access to open workspaces, breakout rooms, a kitchen and eating area, and lounge spaces. Plus, it's just down the hall from Basecamp, the company that invested in us. We're also excited to have lots of new friends to go to lunch with.

That's the top floor. The ground floor is the new home of The Starter League. There are lots of desk and meeting spaces, enough to see our team grow much bigger. We also have room for an alumni coworking space, which we're in the beginning phases of planning out. Starter League alumni interested in joining us can email me at vince@starterleague.com.

The Starter League will continue to have a strong presence at 1871. We’re teaching AngularJS and User Experience this spring, and in the summer we will continue our teacher training initiative, teach a class through the Center for Talent Development, and hold a new Middle-School Makers program for kids.

Finding and building a new space wasn't easy. We're grateful to the people who helped us along the way. Here's a sincere thank you to Jack Keenan, Andy MacGregor, Dan Polito, Jim Melachrinakis, Ray Kennedy, Jennifer McKenzie, Justyn Howard, Aaron Rankin, Rachael Pfenning, Darren Green, Craig Shultz, Phil Denney, Jason Fried, Michael Berger, Shaun Hildner and Geoffrey Euston. We love our new home!

Another thank you to our alumni, mentors, instructors and community partners for your support over the last few years; we couldn’t have done it without you. We’re proud of the school we’ve built, and we look forward to sharing this next step with all of you.

Our new space is in Chicago's West Loop at 30 N Racine Ave. The Starter League is in Suite 110 and Starter School in Suite 210.

5 Tips to Get You Out of Your Procrastination Rut

By Mike McGee on March 20, 2014

You might be thinking:

"Why did Mike post tips about staying productive DURING MARCH MADNESS?!?"

You're right. It's crazy. But once your bracket is completely busted tonight (oh don't argue with me, it will), you will want to do ANYTHING but watch basketball.

When that happens, we will be here for you. Here are five tips from The Starter League team on how to get important work done.

More from Vince:

"There's a great TED talk about this. It's not necessarily meditation, but a total clearing of your mind, bias, aspirations, struggles, thoughts and what have you. Try it for a week and see if it's helpful to you."

More from Neal:

"Keeping a short daily list helps you focus on what's important for you to do today, and also eliminates the guilt we feel when there's extreme task buildup.

I built an app 18 months ago to address this, it has since evolved since John Chan took it over and ran with it a bit further http://dailystandupapp.com."

More from Sandy:

"The number of important emails that I need to know about it right away is very close to 0. If someone is really in a rush to get my response, they'll text. I like to keep email turned off when I'm trying to work, and only check it a few times a day."

While you don't need to take exact 13-minute naps, there is research backing the power of short naps during the workday.

Like Sandy, I agree that in order to get your most important work done, you have to limit how much time you spend with email. However, it doesn't mean quitting email altogether. My routine is to check email for 15-20 minutes in the morning, early afternoon, and early evening. These timed sessions allow me to power through email without being consumed by it.

Hopefully these tips can you help you get something done during March Madness. If so, you might want to consider keeping them in your productivity toolbox long after your bracket is busted.

Let your designers go crazy detaching javascript from your HTML

By Daniel Lopes on March 17, 2014

One common weak spot while dealing with UI behavior is how we tie Javascript to HTML. It's important to make sure your HTML can be changed without breaking the Javascript behavior.

Since DOM manipulation is heavily based on css selectors, we try to keep the javascript behavior detached from what a designer would potentially change. We never use ids and classes with our Javascript code. Instead, we mark the HTML elements with the expected Javascript behavior using HTML5 data attributes and query those elements with jQuery. Here’s an example:


# Rails - erb code
<%= f.text_field :content, data: { behavior: "autosave" } %>

# jQuery code to apply the behavior to the element
$.behavior("autosave").autosave()

In the code above, we defined the autosave function somewhere else as a jQuery plugin so we could apply it to any dom element. The $.behavior plugin only queries the current document for elements with data-behavior attributes. Here's the plugin code:


// Find elements in the scope of another element
$.fn.behavior = (value) -> $(@).find("[data-behavior~='#{value}']")
// Find elements anywhere in document
$.behavior = (value) -> $("[data-behavior~='#{value}']")

So with this plugin our DOM ready callback looks like this:


 $(function() {
    $.behavior("autoresize").autoresize();
    $.behavior("uploadable").uploadable();
    $.behavior("date-field").dateField();
    $.behavior("time-mask").mask('00:00 ZZ', translation: {'Z': {pattern: /[PM|AM]/i}});
    $.behavior("toggle-expandable").expandable();
    $.behavior("dirty-track").dirtyInputConfirmation();
    $.behavior("autosave").autosave();
    $.behavior("editable").rteEditable();
    $.behavior('tooltip').tooltip();
});

With this short and quick to implement code we let our designers free to change the CSS without ever breaking the Javascript.

Focus on big leaps instead of small tweaks.

By Daniel Lopes on March 5, 2014

There’s a lot of talk about how important iterations are to make a great product. But what we don't talk about enough is the extent of improvement you get with each iteration. If you iterate one more time can you make your new feature way better or just slightly better?

Everybody wants to ship the perfect website. One that has great pictures and animations, or the perfect feature with a carefully crafted and optimized user interface. But if your first few iterations accomplished 80% percent of what your users need, and your next iteration will improve it by 5% but will cost you a week, you should consider it good enough and move on to the next big thing for your project.

I've been part of projects that spent too much time with small enhancements that didn't make our users 200% better at what they're trying to accomplish, but just 5%, at most. And while the team is working on those small tweaks there are other areas of the app that could use more attention to add more value. A few months in, you'll realize that you didn't make significant progress, you didn't ship feature X that turned out to be vital, but feature Y and Z that are already good enough we only marginally improved.

To avoid this trap I'm constantly asking myself if there's something preventing the usage of the feature we just built. If the answer is no, I timebox the next iteration and after that time is over, it doesn't matter if it's not perfect yet, it's time to ship it and move on to the next big leap. The next big leap could be a brand new feature or a big refactoring/redesign of another feature that is going to make our users life a lot better, not just slightly better.

Collecting inspiration

By Daniel Lopes on February 26, 2014

I've being collecting reference for years and that helps with both the visual/illustration side of design but also with problem solving in general. I split my references in two separate categories:

Visual design inspiration

If you ever had art classes and tried to learn how to draw you know that the first lessons are always to copy a reference object. All illustrators, no exception, uses reference for drawing. And by using a reference or copying something you start to build a library in our head of what works well together and what doesn't.

Although, most of the time, the visual side of web software, isn't something hard to illustrate it still helps me to collect a bunch visual design inspiration. By doing that I build my own mental library with colors, shades, styles and etc.

For years I've being keeping screenshots of everything I consider interesting on the visual side. For that, websites like Dribbble are quite helpful too.

UI pattern inspiration

Another category I pay attention to are UI patterns. This is different than the visual side. Because with visual I'm only focusing on the illustration, but UI patterns is a much deeper concept for me.

With patterns I analyze how things work together in the context of a the whole idea of a feature. For instance, Tumblr, when you hit the publish button you also see an arrow on the left side with more options that behaves like a dropdown menu. I collect that or by taking screenshots or recording small videos and writing a lot of notes of what caught my attention.

I add these patterns to my mental library so I can reuse them on my own projects when I see myself in a problem that could be solved in a similar fashion.

Organization

Today, I keep two private boards on my Pinterest, one for Visual Design and another for UI Patterns. They are both private because I tend to write big descriptions of what I've liked and sometimes where that UI pattern or visual style would work on my current projects.

Inspiration VS Rip-off

The process of building your own reference library is something crucial for any type of creative job. That works for illustrators, photographers, writers, programmers which is no different for UI Designers.

What is important to understand is influence and inspiration is different than outright copying something.

If you deeply understand the problem you are trying to solve and somebody else has already come-up with a UI pattern or visual design that solves the same problem, great! Now you can adapt it to your problem, but it's important to remember that adapting is very different than saying: I need a forum, so I'm gonna clone Google Groups and merge that into my app. Or I like Basecamp's look and feel and I'm gonna clone their CSS.

By trying an already invented UI Pattern and or Visual design with knowledge of the problem; you'll always end up asking different questions. That process will help you come up with a genuine and unique solution to your own.

Future of programming

By Daniel Lopes on January 27, 2014

It is human nature to adapt and accept the current state of things as good enough. That's not so harmful with disciplines that have existed for thousands of years like civil engineering and architecture, but in software development, it's  dangerous to assume that we've reached a state of maturity. For example, in web development, I would love to see more innovation around how designers and developers interact with each other.

To remind myself of our field's infancy, and the infinite room for growth and improvement, I love watching and re-watching this presentation from Brett Victor.


What do you think the future of programming could be?

Newer Posts →