#staff blogs

[sreegs]

Does the CEO of Tumblr checks its employees Tumblr pages? Did someone got fired over a reblog?

You referring to David Karp or Jeff D'Onofrio or Matt Mullenwig?

I don't think anyone's been fired for that, no. They definitely read/did read staff blogs.

[flatironschool]

What Working in Baseball Taught Me about Web Development

Flatiron School Alum and Developer Adam Jonas left his job as a Major League Baseball Scout to pursue a career in software development. Although he thought he left baseball behind him, he found that successful ball players have a few things in common with successful developers—the ability to learn from mistakes, stay consistent, and be professional. In this post, Adam shares what baseball taught him about building software. Before I was a web developer, I spent my time on baseball fields helping teenagers realize their ultimate dream of playing in the Major Leagues. All of them had talent. Somewhere, someone had seen glimpses of it. Cultivating that talent and turning their potential into performance was the primary purpose of my job. Now, four years removed from the game, most of the players I worked with are out of professional baseball. Those who did succeed found a way to endure the grind and adjusted to the game’s emotional and mental demands.

When I see one of them on TV, it’s hard to not recall their younger, yet unmolded versions. It is why I was never the best scout. The baseball scout’s job is to imagine the possibilities. They envision a future version of a gangly youth whose body and mind has matured and whose flaws have been smoothed away to the point they can perform in the Major Leagues. It is a hard job but one that I wish existed in other industries.

Learning from mistakes

Successful people, in any field, often struggle with making mistakes. This isn’t surprising. We are wired for bad news. We internalize it. We personalize it. Repeated failure is exhausting. Ball players, whose hitting success rate is at best around 30 percent, are forced to cope because failure is an inherent part of the game.

Resilient players’ confidences seem immune to repeated failure. In fact, failure appears to be inextricably linked to their progress. This makes sense. We improve fastest based on negative feedback. The great thing about that big, red, error message is that it leaves an obvious clue. Sometimes these hints are more obscure than others, but bugs and errors inform us where to look and where to improve.

Getting repeatedly beaten by the same pitch provides feedback on where hitters need to improve in the same way that a familiar error in our terminal window instructs us where in the code to start looking for our mistake. As humans we learn through repetition and experience. The goal is to avoid getting beaten again by the same pitch or the same problem.

When I first started learning to program, I focused on never repeating the same mistake twice. This, of course, was impossible, but I recorded most my thoughts and posted them online to create a searchable collection of problems I'd encountered. The frequency of my posts have waned, but I still find myself searching my blog archives when I know I’ve solved a similar problem in the past.

While it was rare to see ball players jot down notes on opponents, most hitting savants can recall previous pitch sequences from past at-bats. Either way, the secret to coping with past mistakes or errors in judgment is to reframe them as valuable pieces of feedback for the future.

Staying consistent

As developers, we know that consistent performance is important. We construct our dependencies on the most stable parts of our applications. The same goes for managers: when Sarah demonstrates that she can meet deadlines on a day-to-day, week-to-week, sprint-to-sprint or quarter-to-quarter basis, Sarah’s manager can rely on her to build the feature to satisfy the high priority business objective.

Consistency also creates the opportunity for measurement. Like the measurement of feature velocity based on a set period of time, comparison of player’s abilities would be worthless without a standard 162 game schedule where the participants play nine innings with nine players on the field. Without a level playing field, comparisons are no longer valid and people can get really upset (see baseball and steroids).

Consistency is difficult because we are wired to break free from it. We are not as perfectly repeatable as the scripts we write. Our brains thrive on novelty. The day-to-day becomes mundane without it. We seek out adventure and variety. We endeavor to learn new things.

But mostly being consistent is just showing up—being there when products ship and stuff goes down. Career defining highlights are created when people are in the right place at the right time. Crashes on the production server and DEFCON 1 bugs are inevitable but these panic moments create opportunities. Under pressure, acting as you always do makes you a hero.

Derek Jeter’s lifetime batting average was .310. A consummate professional, he hit .308 in the playoffs. Just being yourself when the pressure is on and more eyes are on you makes it seem like you are rising to the occasion. No one is perfect, but bringing your best everyday provides predictability to our human unpredictability and separates the amateurs from the pros.

Being professional

Professional baseball is a child’s game played by overgrown men who make millions of dollars. Make no mistake about it, baseball is a grueling sport. The schedule is relentless. Players arrive at the stadium five-plus hours before the first pitch to weight train, stretch, hit, throw, review scouting reports, etc.

After a three hour game, players are expected to hold court in front of their lockers and answer questions that essentially boil down to, “Tell us about your glaring mistake that you made in front of thousands of people across America.” Each major league team plays 162 games in about 180 days—not to mention the the month of spring training before the season starts and, if they are lucky, a month of postseason games. Eighty-one of these games are in other cities, meaning players are switching time zones for weeks on end. The truly blessed ones do this for 20+ years.

While we developers don’t enjoy the fame and fortune of Major Leaguers, we do get to solve the worlds’ hardest puzzles for everyone. The impact of our code has touched the lives of nearly every human on the planet. All of the hours spent implementing a vision—all of the bug-fixing and small victories—are bolstered by a natural builder’s high.

Hacker News is littered with discussion on how writing software can crush your soul, but for many, the job retains its joy. Despite the jeering fans and elusive bugs, there are developers who simply love what they do.

Despite the jeering fans and elusive bugs, there are developers who simply love what they do.

Of course, there are stark differences between baseball and software engineering. Software has been in the hands of laymen for less than a generation and baseball has remained unchanged since before the Civil War. While software’s impact continues to accelerate, we should take a breather and remember that what is old becomes new again. There are lessons to learn everywhere we look and baseball has proven no different for me.

I love what I do. I’ve never been as challenged as I am when muddling through a new concept or totally lost in a self-created code mess. The wins and losses I’ve experienced as a developer are like nothing else I’ve experienced as an athlete or a coach. While I’m still a relatively new programmer, my experiences in baseball have taught me some valuable lessons on coping with failures, reliability, and professionalism.

Not all that long ago my work day consisted of spotting the subtle deficiencies in a pitcher’s delivery and the sound of a shortstop’s feet as he ran a 60 yard dash, but when I watch how a junior dev deftly uses her VIM shortcuts or the ease with which she writes a complex SQL query, I’m reminded it’s not so different after all.

Keep in touch with Adam on Twitter or read more posts by Flatiron Staff.

hbspt.cta.load(69751, '0d93876e-9890-43af-b462-b96a2133da90');

[flatironafterschool]

Teaching Object-Oriented Ruby to High School Students

Vanessa Dean teaches web development at Flatiron's Pre-College Academy. She's also a recent alum of the Flatiron School Web Development Immersive. In this post, she discusses how our instructors teach advanced programming concepts to Pre-College classes—using the same material taught in our adult classes, but tailored to fit the interests of high school students.

We focus on three things when we introduce a new topic to our Pre-College students:

Getting students excited about the topic

Demonstrating its relevance to programming and web development

Using concrete, real world examples to break down and explain the concepts behind it

For object-oriented programming the first two items go hand in hand because it is the way that professional programmers create all of the fun software our students use, from Facebook to Grand Theft Auto. When we taught object-oriented programming to our latest class we asked them which video game they were most excited about and they chose FIFA, so we used that game to illustrate how to build objects.

We started building out a Player class and talked about the attributes that a player might have, like league, team, name and jersey number, and building reader and writer methods for those attributes. We also covered initializing instances of the class with default values and how to use Ruby attr_accessors.

Our students were good sports (pun intended?) about following us down this path, but they really began to see the power of object-oriented programming and get fired up once we introduced the concept of adding actions to each player. We started out passing the ball between players with def pass(player) self.has_ball? = false player.has_ball? = true end Soon enough the players were also stealing and scoring goals and celebrating and the students were loving it. They were so fired up that when we set them loose to practice on their own, they were trying to make Sportscars that interacted with instances of Drivers to win DragRaces and their ambitions were far beyond their current knowlege.

Having students who are excited about programming and trying their hardest to build something that they are not quite skilled enough to build yet is a nice problem to have. I can’t wait to see where their ambitions will take them and what they all build by the end of our 12 weeks together.

[flatironschool]

From Board Game to App: How to Build a Single Page Web App for Mobile

Amanda Himmeltoss is a developer and Instructor in Flatiron School's Web Development Immersive. An avid board game player, she explains how she made one her favorite games more portable with JavaScript, HTML, CSS, and Rack.

I few weeks ago, I was faced with a dilemma. I really like playing the game Carcassonne, and I wanted to be able to bring the game with me when I traveled, but while the pieces—small cardboard squares—can easily fit into a small bag, the board used to tally players' scores is larger and awkward to travel with. So I decided to solve this problem by building an app to replace the board. The app needed to allow a selected number of users (who can choose their meeple color) to be able to increment their count by clicking the number representing that count.

The first task was to get the basic logic and functionality in place for user interaction. Client-side JavaScript is obviously perfect for this. I decided to go to town on it as an exercise in writing good, clean JavaScript, but that's for another blog post. But to give a general background of what the app is doing:

a user can select the number of players and their colors

.onClick() the user increments the score count by one

There are Player prototypes that:

keep track of player scores and color

methods to reset the game

decrement the score (if you make a mistake through overeager clicking)

and a bunch of jQuery powered front-end methods

Let's dive in to some effective and easy ways to make a web app completely mobile friendly, with as close as possible functionality to any simple iOS or Android app that achieves the same thing.

The Layout

The app is a single page / single user experience design. The main focus of the page is each players' block, which holds their score number with the background-color whichever color they selected. The templates for each number of players is hard-coded into the index.html page, because I think it makes more sense than dynamically rendering it, given how there are only 5 different templates.

Here's what the app looks like for a two player game with blue and red meeples:

The entire page, no matter how many players were in the game (2-6), needed to be entirely fit for a mobile screen. For this I set the height and width to view width (vw) and view height (vh). CSS selectors, from body to each container for a players' block, use vw/vh instead of pecentages or pixels. This means that no matter the size of the screen (an iPhone 6 vs a Nexus 7 vs a Moto X) the color block, given the HTML template, will fit the view's width and height. This fixes the size of that HTML element to whatever "percentage" is selected. So for the above two player template, the CSS looks like this:

.container2 .player { width: 100vw; height: 50vh; line-height: 50vh; }

This remains entirely responsive to whatever size screen / device the app is viewed on.

Clicking / Tapping Functionality

The main functionality of this app is clicking, or in the case of mobile use, tapping. One problem I encountered with the tapping functionality was that most mobile devices initialize double-tapping zoom as soon as tapping reaches a certain speed. On this single page, given that the view's width and height is always fixed to the size of the screen, zooming isn't necessary. I needed a way to disable that double-tap feature to allow for rapid tallying.

First step is including in the <head> a meta property that disables the user's ability to change the view of the screen. This prevents the double-tapping zoom:

<meta name="viewport" content="user-scalable=no" />

Next, in order to utilize that double-tap functionality for rapid tapping, I used a super simple and easy JavaScript plugin called jQuery Finger.

In addition to setting an event handler on tap...

$(".player" + this.number).on("tap", function() { this.incrementNumber(); }.bind(this));

...you can also set one on double tap, using jQuery Finger's custom event handler:

$(".player" + this.number).on("doubletap", function() { this.incrementNumber(); }.bind(this));

Focused Swiping Functionality

What if a player accidentally increments their tally, and they need to subtract some points? Swiping backwards on the number area where you're tapping to increment is a logical gesture. jQuery Finger has an event handler for that as well:

$(".player" + this.number).on("flick", function() { this.decrementNumber(); }.bind(this));

Rack

Finally, I turned the single page application into a Rack app. This was entirely out of laziness, because I wanted to be able to host it easily, and Heroku is great for that. There are pluses and minuses to static Rack websites, and I won't go too much into that only to say I think it's fine for small, single page, side projects like this. I mostly followed this helpful guide on Heroku on how to set up a config.ru file.

Conclusion

Eventually I would love for Carcassonne Counter to be turned into something that's in the App Store/Google Play Store, but ultimately this solution makes the most sense given the simple problem and the usage. The app is completely responsive for any sized screen, which makes it pretty versatile for users, and has many of the same mobile gesture capabilites as an iOS/Android app. Ultimately I'll be building a Rails back end to persist game data and support other game counting/scoring as well, and at that point, this app will most likely be expanded on substantially, and perhaps I'll even delve into making at iOS/Android then.

Stay in touch with Amanda on Twitter or GitHub.

[flatironschool]

The 10 Principles of Good Web Design for Developers

Good design is innovative

Innovation is the process of introducing new methods or ideas to an existing medium. This doesn't mean you need to reinvent web design every time you create a new site. Instead, be cognizant of design in other areas of your life and look for ways to incorporate it into your web designs. See an interesting commercial animation. What made it interesting? Try adapting that design to the web.

Good design makes a product useful

At the end of the day, you want people to use whatever you've built. Good design aids the user and helps them operate your web site or application. Highlight useful content and minimize distractions. For example, if you're working on a shopping site, the design should help a user select an item and move forward in the purchasing process before it does anything else. This book is a great place to start.

Good design is aesthetic

It's common sense, but the site should look nice. Studies show the quickest way to build trust with your users to have a professional-looking site. Take some time to learn the elements and principles of design (from this site, perhaps). Then find your favorite websites and analyze them. What aesthetic choices did they make? Why do you like their work? How can you use what they've done and make it your own?

Good design makes a product understandable

Design has it's own language. Even if you are not a designer by trade, you've probably picked up on a few of its principles—repetition, balance, contrast, hierarchy, and more. Your users will also be familiar with the established design patters in which they are constantly immersed, like having a navigation at the top or along the left side of a page. You have to reinvent the wheel. Use established patterns whenever possible to help your users immediately understand your website.

Good design is unobtrusive

Can users find information easily? Your website should be easy to navigate and operate. If it's a web app, does the design augment the process of using the app, or is it obtrusive? Accessibility should never be sacrificed for something that "looks cool."

Good design is honest

Honest design exists to aid the user, not trick them. If there is an important element on the site—like a "Buy Now" button—design it to direct your user where they expect to be directed. With great power comes great responsibility. Use this power for good, not evil, and avoid the dark side.

Good design is long-lasting

Trends come and go, but good design is forever. Compare 2002's apple.com with today's and you'll notice the site remains remarkably similar. Sure, color and fonts have changed, but the soul of the website is the same today as it was in 2002.

Good design is thorough down to the last detail

The 80/20 principle tells us it takes 20 percent of the time to finish the first 80 percent of a project, while the remaining 20 percent takes 80 percent of the time. Finishing a design is tedious. Sometimes you'll spend hours laboring to get one section to look just right. You'll be tempted to call it it quits, but good design is thorough down to the last detail.

Good design is environmentally friendly

While your web design will probably not affect the environment in the same way an industrial designer's might, you can still use conservation as a principle—just for a different purpose. Using lightweight frameworks and optimizing your code and images will help reduce the page load time for your users. A happy user is good for the environment, too.

Good design is as little design as possible

The adage, "less is more," applies here. Don't burden the design with non-essentials. I know you love that animation of the dog riding a fire-breathing dragon that you worked on for days, but id it's not essential to the design, lose it. Jost like bloated code, you will need to refactor your design, tweaking it several times before arriving at the optimal version.

All this is to say that the best designs get out of peoples' ways and let them do what they came to your site or app to do as quickly and as pleasantly as possible. This should matter to us developers because visual communication is an inherent part of what we do. The key to creating a well-designed product is to always remember that you're building for people above all.

[flatironschool]

You're Not an Impostor: How to Manage Self-Expectations as a New Developer

Ian Miller is an instructor in Flatiron School's Web Development Immersive—and a former student. Having been through the program himself, he's well-aware of the internal struggles that new students face when grappling with gaps in their skills and transitioning to entirely new careers. Here's the advice Ian gives to students on believing in their individual abilities and staying positive through a difficult learning experience.

When I started programming over a year ago, I kept second guessing myself every step of the way. I believed couldn't implement code correctly—that I was a burden on others, and the best strategy was to keep my banal questions to myself. Looking back, this was bad for my team and bad for myself. I wasted so much energy tricking myself into believing that I wasn’t good enough, and that I never would reach a state in which I was content with my abilities. I had no idea that I wasn’t alone.

To self-criticize is human

Perspective is everything

As an Instructor for the Web Development Immersive at the Flatiron School, the responsibilities I typically have each day range from bug hotfixes to in-depth explanations of how the Rails framework handles controller logic. But another, less obvious part of my job is constantly helping others keep their expectations in check. From the start, we tell our students that it’s important to keep their skill level in perspective—that the path to becoming a better developer is a slow upward trajectory. We tell them, "you will never feel as dumb as you did today.”

So what exactly is impostor syndrome? It’s the feeling that “we are frauds and we do not deserve the success we have achieved. Proof of success is dismissed as luck, timing, or as a result of deceiving others into thinking that we are more intelligent and competent than we believe ourselves to be.” Even more simply put, it is an incongruous perspective—the act of people with actual ability underestimating their relative competence.

At some point in their career, a developer will experience impostor syndrome in some way, shape, or form. How they manage those feelings of insecurity depends on what strategies or techniques they decide to use.

Impostor epidemic

It wasn’t until I started at my first programming job that I really started to feel inadequate. I spent a lot of time trying to justify why I wasn’t qualified, and less time on looking back on the progress I had made since I made the decision to change careers into programming. I essentially spent a lot of time trying to attribute my success in the first few months to sheer luck or the efforts of others.

Simply put, you will never completely eradicate the presence of impostor syndrome. But you can manage it effectively through positive reinforcement and open dialogue. At Flatiron School, we allot time every Friday for feedback and sharing. During one of these sessions, I brought up my feelings with my team. I was surprised to find that they were widely shared—even among senior developers.

Dealing with impostor syndrome

Coming into programming from an accelerated learning route (via Flatiron School), impostor syndrome is something that our students run into firsthand. Going through the process of learning the nuances of Ruby, Sinatra, Rails, Javascript, and ultimately how to build a functioning web application can be extremely daunting. Even more so is the fact that they slowly have to remove their hands from the guardrails in order to stand on your own as a developer. This was the most challenging part about my own experience, and this is something our students face every semester. Here a few ways I've dealt with these feelings—and the advice I give to new Flatiron students.

Stay positive. It’s important to keep in perspective how far you’ve come in such a short amount of time. Play up your successes, and think about your failures, and how you can learn from them. It doesn’t matter how many times you fall—what ultimately defines you as a developer is that you continue to get back up, and recognize that there will always be moments of uncertainty and discomfort.

Talk about it. The realization that everyone felt the way I did was huge. With the help of others, I started using several techniques to keep my doubts about my abilities in check—like positive reinforcement from friends and co-workers, and journal entries. I started participating in weekly code talks called CodeNewbie that my friend, the amazingly talented and wonderful Saron Yitbarek, started and currently maintains. She spoke about her experience at RailsConf 2014 and in this post.

Be OK with not knowing everything. I’ve had to figure out how to be OK with (excited, even!) to not know everything—it’s an opportunity to learn new things and refine my current skills. If you’re a new developer, it’s fine to acknowledge the long path ahead of you. But know that you owe it to yourself to enjoy the process of learning along the way. Accept the fact that you will never know everything there is to know about programming, and that is fine. It should be about shared experiences and delayed gratification. Take pride in new skills, incremental returns, and be excited for the programmer you’ll become.

Learn with others and let them teach you. The best piece of advice I can give is that learning to become a programmer should not be an isolated, but rather a shared, experience. Through others, particularly a mentor, you can receive the validation and gentle pushes necessary to see you through more challenging obstacles. Go to Meetups. Reach out to a developer that you like or admire. Emulate their workflow through observation. Build a web application on the side with a friend. Great software developers are the sum of their aggregated experiences over time. I guarantee you that they’ve experience more failures than they have successes. You never know what may come of your efforts unless you try.

And most of all, believe in yourself. No one can predict the future. It is full of unknowns, and there are bound to be curve balls thrown here and there. It’s very easy to convince yourself that you are a tiny fragment of what you really are. Despite the dark storm clouds of negativity or belittlement that may gather in your mind, believe in yourself. Temper your lofty expectations. Adapt. Empower. Share. As Bruce Feiler says, “take a walk with a turtle. And behold the world in pause.”

Stay in touch with Ian on Twitter or through his blog—where this post was originally published.

[flatironschool]

Learning as Product: Building Better Education at Flatiron School

As VP of Product at The Flatiron School, Mat Balez often gets asked: what does “Product” even mean at a school that teaches people to code? Here are his thoughts on approaching education as technologists and designers approach building products.

It’s a great question and to answer it properly requires stepping back and thinking about the challenges and opportunities in education as well as the role technology and technologists are playing in its continued evolution.

Educators have the scary important job of shaping people, of turning them into whoever it is they’re going to become. It’s a heavy responsibility with an outcome we all share—who doesn’t wish for more, and better, learning happening in all corners of the globe?

It has been said that the tools we create shape us; indeed, perhaps nowhere is this more clear than in the world of education. Teaching tools shape the learning process, which shape students, who in turn shape society itself.

The question is a fascinating one, particularly because educational tools are increasingly digital and online—thus increasingly powered by software. It should come as no surprise then that technologists have taken up arms, with educators, to re-shape learning for our modern age.

And so it is, that “user experience” in learning has come to matter.

The new set of tools we, as a society, are creating for our fellow humans to teach and learn anything at all (yes, certainly like computer programming like we teach at The Flatiron School but really anything and everything under the sun) these tools will almost certainly be computer-based, and will involve people staring at, and using, software applications to mediate their learning experience.

This means that from the student’s perspective, beyond simply having teachers teach curriculum, software itself will be a huge part of what learning is all about: it will help them explore and ingest knowledge, stay motivated, find and interact with other students, remain connected with teachers, practice concepts, and demonstrate mastery. If we, the toolmakers, can make educational software that delivers a great user experience—beautiful, fast, responsive, super effective at communicating knowledge, simple to understand, genuinely fun and inspiring to use—these new tools will shape us all for better.

So we might think of this as the “productization of learning”. Which is an exciting way to look at things because it means we can throw everything we technologists have learnt (and are still learning of course) about human-computer interaction (HCI), psychology, visual and interaction design, software architecture and engineering, reliability, data analysis, project management, lean thinking, scaling etc.—in other words, the full weight of our modern product development machinery—at the challenge of making education not just incrementally better, but orders of magnitude better. That should collectively be our goal: nothing less than building learning tools that leap us forward in previously unimaginable ways.

Sounds fanciful, but we technologists, designers and product people at schools should take stock and realize that we’re actually super well-positioned to help make this happen. Why?

Because we are still so early in this phase of figuring out how to fully embrace the significance of the web and other online technology to rewire the way we deliver curriculum to students. A leap forward is possible simply because there is still so much possibility and room for new, creative approaches.

Because the distance between us and our users is unprecedentedly small. Where else could you find hundreds of users (students!) actively banging on your app in the same building, just a few tables away? Want feedback? Just wander around! Push a change that was bad? You’ll hear about it immediately, literally. Need to user test something? Easy. Being co-located with students in such a use-rich environment makes it possible, unavoidable even, to be laser-focused on your user—and like Google suggests, all else should follow from that.

Because education is highly measurable and what you measure matters. Changes to the product can be tied back to real changes in user (student) performance that can be tracked, not only while at the school, but beyond—and related to real changes in peoples lives. There’s no fooling around when “life transformation” is your metric.

But technologists can’t get there alone. With a product-mindset, I think everyone can help change the education game. Here’s how:

If you’re a parent, consider your child’s education from the perspective of their user experience. How might it be better? Be a voice for constant improvement and find the product outlets at their school for being heard. If those outlets don’t exist, try to create them or consider more forward-thinking schools.

If you’re a product person or engineer in the tech world out there, give some thought to getting involved in remaking education. There is so much to be done and the time is ripe for putting your product skills to work to have learning be a killer user experience.

If you’re a school administrator and don’t have product people and engineers on staff, why are you still reading this post and not building that part of your team?

If you’re a teacher, keep making people who they are. Try to look at learning, particularly when it intersects with technology, under the lens of “user experience” insofar as it promotes better learning. Partner with product thinkers around you, where ever they may be, to keep making improvements big and small.

If you’re an employer, make sure you’re hiring passionate, life-long learners. The education system is broken if it is not producing people that will enter your ranks full of love for what they do and a desire to keep learning.

If you’re a student, you’re probably already savvy in user experience, having grown up surrounded with so many technology products in your life. Try to make the most of the learning tools (and content and people) at your disposal. Suggest improvements, I’m sure you’ll have a ton. Try to break things and reassemble them and improve them. Learn to love to learn, really try to understand things, apply what you learn to useful ends. Become you. <3

[flatironschool]

Working With Size Classes in Code With UITraitCollection

This post on teaching students in our iOS immersive size classes and Autolayout was written by iOS Instructor Joe Burgess. 

With the introduction of different screen sizes in iOS 8 we now lean more heavily than ever before on AutoLayout to decide where our views belong given different screen sizes. Thankfully, Apple has given us some great tools to write one interface that will expand or contract given different phones and screen sizes.

Size Classes

Apple defines Size Classes like this:

A size class identifies a relative amount of display space for the height and for the width. Each dimension can be either compact, for example, the height of an iPhone in landscape orientation, or regular, for example, the height or width of an iPad. Because much of the layout of an app does not need to change for any available screen size, there is an additional value, any.

Going into the different Size Classes themselves is outside of the scope of this blog post but it boils down to a 2X2 grid of size classes. Here's a great blog post that explains it in more detail. 

Now, there is no concept of "rotation"—simply a change in the size classes being used. If you take a look at Interface Builder there is the size class selector at the bottom. This allows you to set different AutoLayout constraints for different size classes in IB. I really don't like setting AutoLayout constraints in AutoLayout because I find it confusing, limiting and very hard to teach around.

Whenever I'm teaching, I like to go from the explicit case to the implicit case—and move up layers of abstraction from concrete concepts. This allows students to properly understand what is going on before the "magic" of implicit definitions sets in, instead of just blindly using concepts. Because of this, I start my teaching of AutoLayout with code.

We start very early on with creating instances NSLayoutConstraint and adding them to the views. There is no ambiguity on what is going on and students gain a much deeper understanding of AutoLayout then if they used Interface Builder. As I prepared for the lecture though, I was curious about how to access the current Size Class from code and to respond to rotation events in the new iOS 8 world.

What Size Class Am I?

After searching and searching, I finally discovered that all of the size class information is kept in a UITraitCollection object. There isn't a ton of documentation on this sadly. If you take a look at the UIViewController documentation you'll note there is no mention of UITraitCollection. Looking closer we notice that UIViewController conforms to the UITraitEnvironemnt protocol. Hark! We found the location of the UITraitCollection property named traitCollection.

On viewDidLoad for your UIViewController take a look at self.traitCollection. In it we see all of the visual properties of our device! Here is an example one:

<UITraitCollection: 0x7f833b623e80; _UITraitNameUserInterfaceIdiom = Phone, _UITraitNameDisplayScale = 2.000000, _UITraitNameHorizontalSizeClass = Compact, _UITraitNameVerticalSizeClass = Regular, _UITraitNameTouchLevel = 0, _UITraitNameInteractionModel = 1>

From this we can discover that the device I'm using is a retina (@2x from the_UITraitNameDisplayScale) phone that is currently in the Compact Horizontal, Regular Vertical size class. That means this is a 3.5", 4.0" or 4.7" phone in portrait mode. Great, now depending on different Size Classes we can apply different AutoLayout constraints on viewDidLoad.

Handling Rotation

Before Size Classes we had a lot of code handling the rotation of the phone in the willAnimateRotationToInterfaceOrientation:duration: methods in our View Controllers. Apple has changed this with Size Classes. They've removed the concept of rotation. When the phone rotates, all that changes is the current Size Class. I love this change. There is no reason to think about how your phone has rotated. All that really matters is the dimensions of the screen are different. This Size Class change is caught in the traitCollectionDidChange: method. You will be given the previous UITraitCollection as an argument and are able to access the current UITraitCollection through the traitCollection property.