Elevator Up

Getting Started with iOS development

As I mentioned in my last post, I had to delay jumping right into the programming environment for iOS development because Apple’s software development kit is only available for Mac and I’ve always had a PC. In the meantime I figured I’d do what a college student does best: study (not drink..)

Study Zone

My goal at Elevator Up is to create an internal app for the Factory and its members. Before I started here I had no idea how to create an app and really had no idea where to start. I did however know that I was going to be coding in Objective-C, so that’s where I decided to start. After a few hours of reading from the iOS Developer’s Library, I had a pretty firm grasp on the new language. If you know any other object-oriented language like C, C+, Java, etc, I highly recommend looking at a comparison between that and Objective-C to help you understand the syntax differencees. To be honest going right into the coding wasn’t the best place to start. The Xcode IDE included in Apple’s iOS SDK handles a lot of the tricky coding for you so being an Objective-C guru isn’t really necessary. The iOS Developer’s Library was definitely helpful in understanding the the app files, their dependencies and the data objects associated within.

Being a visual learner, and still finding myself pretty lost with the whole process I decided to watch a lecture series online so I could actually see the different processes in action. After doing some searching online I came across Dani Arnaout’s video series, a 50 part guided series called iOS 5 development. The entire series can be found on Youtube and I found it to be incredibly helpful. After completing the lectures I felt like I had the knowledge to start designing and building this app. I started with a very basic sketch of a storyboard to get ideas flowing.

This sketch paired some of the initial ideas that the team suggested with different tools I had learned from the development tutorial. Just putting the ideas on paper helped spark new ones for content and design. While a lot of these ideas will likely be scrapped as the app is developed and refined, this was a good place to start and I finally felt like I had a foot in the door of creating something awesome!

~Zach

TEDx, Early Shift and Thinking Wrong.

Sometimes it’s easy to compare Grand Rapids to big creative hubs like New York and the Bay Area. And not to be too mushy, but this week is one of those weeks that makes me so satisfied and happy with where I live.  

Yesterday (as most of Grand Rapids already knows) was TEDx Grand Rapids. It was my first time attending a TED event. It was a really good day, and the energy was amazing. 

One of my favorite talks was Greg Galle’s. Many of the day’s talks touched on innovation and how to be an innovator (buzz word overload), but Greg’s talk addressed concrete examples of how to capture ingenuity. 

Fast forward to this morning, after 12 hours (plus some) of eventing and talking the day before. AIGA and Design West Michigan rode the wave of TEDx and invited Greg Galle to talk via the Early Shift breakfast series. 

What was really fun about this morning talk was that Greg engaged the audience in some mini exercises. After a day of sitting and listening attentively at TEDx, this was a good tactic for any overlap. 

Greg walked us through three small exercises that his team will use when working with clients. Try this with your client or group next time you’re having some roadblocks:

In a way that…so that:

1. Ask a question that relates to a problem you or your client are trying to solve. For example: “How do we use creativity to solve economic disparity in Grand Rapids?”
2. Then ask your group to tack the phrase on to the end of that  question - “In a way.” For example, “How do we use creativity to solve economic disparity in Grand Rapids in a way that does not segregate people further?”
3. Lastly, add “So that” on to the end of that sentence. For example, “How do we use creativity to solve economic disparity in Grand Rapids in a way that does not segregate people further so that we can have a more diverse downtown”

Be Stupid. After we had completed the first exercise (above) we were asked to generate 10 really stupid ideas to solve that problem:

1. Work with a partner in the group to generate seriously stupid solutions. Let yourself think completely wrong. The only thing you can say to your partner is “Not stupid enough.”
2. Write the stupid ideas down on post its, and then share with the larger group. 
3. Pick on of the worst idea, and write it on a piece of paper at the top.
4. Then move on to the next exercise - “Yes, and” concept.

The last concept that Greg talked about was The Big Yes. Try to break the habit of being defensive. Instead of saying in critique or conversation Yes, but try Yes, and…. When someone is giving critique, listen, listen, listen. Listen first so that you can learn and reflect, even if you might disagree. Stop saying “Yes, but” and use “No, because.” When we are generating ideas, it’s not helpful to shoot down ideas before they even get out there. 

Yes, and…:

1. Now your team should have a crazy idea. One in the crowd was “Demo all the schools.”
2. Pass the paper to the next person in the group, and they simply write “Yes, and…” and fill in the blank with more crazy ideas. 

The message I took away was to push yourself and your team members to think wrong and explore avenues that you would never explore normally. Greg made the point that, how many times have we been in hour and a half meetings that go on and on? These types of meetings can be really intellectual, but lead us no where. Thinking wrong, and then betting small can help overcome this. 

Greg’s Early Shift talk was clearly just a small taste of the work done at Future Partners. You can learn more about Greg’s work at Future Partners on their website. 

Lessons Learned in RWD

nth-child() - order is important

We’re in the process of designing/building a new web site for The Factory. The Community page will have a grid of members, initially six wide.

I’m using SCSS and Susy for my grid system, and at a certain breakpoint, I wanted to go from 6 to 4 members across. This meant I wanted to float every 4th element right, and remove the float: right from every 6th element, so I tried this:

This worked well for the first couple of lines, and then it all fell apart. Of course this is because 4 and 6 are both factors of 12, so the omega is added to the 12th member by the :nth-child(4n+4) rule, then removed by the :nth-child(6n+6) rule.

Solution: Reverse the order (remove, then add). This seems obvious in hindsight, but it had me scratching my head for a minute.

TIL: always remove-omega before adding it using nth-child in #susy or it’s always removed where add/remove integer are factors of same child

— Andy Westmoreland (@akwestmoreland) May 9, 2013

SASS variable calculations

When working with variables in SASS, it’s important to note that calculations involving units work more like agebraic equations than concatenations.

For instance, using addition throws an error as value+units results in a quoted string. The correct way to concatenate value and units is with multiplication. The same is true for percentages. Note that the multiplying a value by 1% makes the value a percentage, It does not return 1% of the value.

and this is what my complete setup looks like:

I’m also experimenting with JS behavioral breakpoints and various types of responsive navigation. More on that soon.

Further reading

• SASS/SCSS: sass-lang.com
• Susy: susy.oddbird.net

~ Andy

The Intern Experience - Zach Gill

Hello Elevator Up followers! My name’s Zach and I’m the newest member of the Elevator Up team here in Grand Rapids. This summer as an intern I will be focusing on the mobile app development process from start to launch and as I go along I’ll be blogging here about my experience. Each week I’ll be posting about the learning process, difficulties, strategies and what it’s like to be a new member of the tech industry.

A little background info about me: I’m originally from the Grand Rapids area. I went to Grandville High School and this fall I’ll be a Senior studying Computer Science at the University of Michigan in Ann Arbor! Basketball is my favorite hobby and I also love to read, whether it be a new coding book or some great fiction. I have always loved computers and being able to work and learn with them every day really is awesome.

The First Day: After taking the elevator up (ha!) to the top floor I still was unsure of what to expect for my first day. The glass door across the hall said “the Factory” and I couldn’t help but laugh at the fact that two years ago my summer job was at a real factory, and after a miserable 4 months I said I would never work in another factory again. Well “the Factory” that is Elevator Up’s work space instantly changed my mind. It’s a huge open space with desk, couches, tables all promoting the members to work where they feel most comfortable. There’s conference rooms, big open windows, and white board walls. The Factory environment promotes working together and thinking in new ways. I know at the university I love to study at home because I can make coffee, take a mental break on the couch or maybe grab a snack, and the comfortable environment actually helps my productivity. Here at the factory there’s always coffee made, I can kick back in an awesome chair, and the fridge is stocked. This really is the ideal working environment.

If you’re currently a second year or earlier computer science major you’re probably thinking the same thing I was: I have coded until my fingers bleed working with C, or C++, or Java, but how will I be using this when I’m making a website, or how do sorting algorithms for a million inputs effect an app that has a single page view. After only a week here the focus of CS classes is a lot more clear to me. At UofM they introduce coding in C++ and use it in the next 3 track courses, so after 2 years you should have a pretty firm grasp on the language. Starting in Objective-C I was thinking I would have to read the developer’s library tome do know it well enough to start the app. However, Objective-C is also an object oriented language and I found the transition was really easy looking at syntax differences between the two. Although apps may not take a million inputs (although they certainly could) there is limited space on iOS, so efficiency is key, and the algorithms that you’re learning now effective no matter the scale. Efficiency is important! I can’t stress this enough. If you want a clean user experience your code should be operating as smoothly as possible.

Right from the start I was treated like an equal team member. We all worked in the same area where ideas are shared and passed around by the team. At lunch we had our first meeting in the “War Room” where we brainstormed ideas for the app. We came up with some great ideas and had fun trying to expand on them and then narrow down our options. If I had questions everyone was excited to answer and help me learn. Each team member has their own strengths allowing the team to learn together and grow stronger as a whole. After being unsure of what I wanted to major in when I started college I left after one day at Elevator Up knowing I had made the right decision and that this was the industry I want to have a career in. I can’t wait to keep working and see what I can create.

Mac vs. PC!!!

Having always used a PC I felt like I was in an apple orchard my first day here. Since I didn’t know I was going to be a CS major when I bought my computer before college I went with a Dell Studio XPS which is a great computer, but if you are going to be coding, especially with iOS development (XCode IDE is Mac only!) I highly recommend getting a Mac. I am currently looking to make the switch to Mac and wish I had started out with one in the first place.

More to Come

Being my first post, actually first blog post ever really, this was a little long so I’ll stop there, thanks for reading! Next week I’ll talk more about the steps I’m taking to start the app design process.

~Zach

Lean UX with Jeff Gothelf

I took an O’Reilly webcast today on Lean UX with Jeff Gothelf. Jeff is a product designer, and the the author of the book Lean UX: Applying Lean Principles to Improve User Experience. Jeff did a really good job with his webcast and I got a lot out of the content. 

Following are my notes and additional thoughts on the webcast:

One of the biggest challenges on a project can be getting the people to care about the decisions being made and understand why one direction is being taken over another. You can’t do this by yourself, you need to get executive roles and team members together. This is also important for an internal team.

How do you unite a team and get people to care - Client side:

JEFF SAYS:

• Get execs and stakeholders in the same room at the beginning of the project.
• Ask them to sketch who they think they are building a product for.
• Have the team present to each other and point and out why the personas they created were important. 
• Boil this down to a few distinct personas
• Make these into playing cards for the execs to come back to and remember. They can be simple, hand drawn. 
• Similar exercises can be done on internal projects or with your internal team when kicking off a larger project. Having designers pair with developers early on is important. 

What Makes Teams Successful:

1. inclusion
2. collaboration
3. group exercises to show divergence and convergence 
4. create clear goals and outcomes 
5. safe environment to agree/disagree/participate 

Regular discussion leads to iteration:

• this builds shared understanding and team alignment 
• shared understanding is the currency of lean UX

What is Lean UX:

Inspired by Lean Startup and Agile development theories, it’s the practice of bringing the true nature of a product to light after, in a collaborative, cross functional way with less emphasis on deliverables and greater focus on a shared understanding of the actually experience being designed 

Agile values

• Individuals and interactions over processes and tools
• Go talk to people
• Working software over comprehensive documentation
• Show me how it works, don’t tell me how it works 
• Customer collaboration over contract negotiation
• Bringing customers into the process so you know you are building the right thing
• Responding to change over following a plan
• Realize things are going to change
• It’s more valuable to respond to a change than to stick to a plan and be naive to reality 

Designers can’t hide behind their monitor anymore more

• this is a designer-led initiative
• take ideas in sketch format
• put your work out where you can get feedback
• designing everything at once but in the wrong direction is a waste of time

5 things to do in your organization to practice Lean UX

1. Solve the problem together as a team 

• Give the team a problem to solve, not a solution
• Let them choose which solution will achieve desired specific business outcomes
• These teams will be far more effective and motivated if they are are working on their own solution, not someone else’s

2. Sketching

• with the front end back end and visual design
• build a shared understanding while working on a sketch together
• build the product together at the same time

3. Prototype it 

• build an experience, not a document 
• palm pilot example - wooden block was how it started
• the palm pilot creator prototyped the experience first - what was it like to walk around with a device in his pocket, starting with a wooden block in the shape of a handheld device, and then incrementally investing in the idea 

4. Pair Up

• engineers pair with designers and vice versus 
• this saves time and builds a common language between the two 
• pairing sets designers free and empowers developers 

5. Style Guides

• create a repository for all the pieces of your system 
• headers, footers, grids, carousels, colors, type, code snippets,
• goal is to use these to create prototypes much faster

With Lean UX and Agile methods, as Jason Fried says it, sometimes it’s

“Speed first. Aesthetics second.”

But on the other hand —this point I really could relate to—A creative director that Jeff knew explained that this way of working made him/her feel, without having time to come back and iterate on the “speed first” approach, that the work was always: “Going for the bronze.”

This is where making sure the team does in fact have time to come back around and polish and iterate on a project is the difference between true Lean UX and something different. Without truly having the time and budget to iterate, converse, and solve problems, then you do end up with the bronze. Jeff says: It’s not iterative if you only do it once.

Validate your hypotheses with customers

• 3-4 people at a time, once a week, to keep that easy and light and a constant flow of customer feedback 

It’s not the spec that gives you control

• Lead with conversation, trail with documentation. 
• You are in the business of solving problems. You don’t solve problems with design documentation. You solve them with designed solutions 

How to start doing this with your team:

1. Build environments for you teams to work this way and and incentivize them around solving business problems 
2. Give the team the freedom to experiment and explore 
3. Have your designers lead brainstorming or sketching sessions
4. Have your team members pair up and work together
5. the Lean UX process is distinctly anti-hero, everyone participates 

Learning to See by Information Architects

The typographer Jan Tschichold illustrating the concept of Fingerspitzengefühl

In my first typography class, our very first assignment required us to go out around campus and photograph different examples of type on signage and storefronts. A serif, a sans serif, an angry font, a happy font, a clean font, a silly font, a poorly kerned font, an all caps font, etc. The list was extensive and though I am by no means a master of seeing, this was a great exercise. It opened all of our young design eyes to seeing in a new way. It starts with being able to see. 

Learning to See by Oliver Reichenstein of Information Architects is the type of content that I feel compelled to share.  If I were a professor, I’d want my design students to read it. I want to read it again. Reichenstein frames the article from the beginning as a “love letter to my profession” and I totally ate it up. If you are a designer or work with designers at all, taking 20-30 minutes out of your day to read this will serve you well. Ready, go!

Written by @juliajamieson

Do you need a resume?

From time to time, we find ourselves engaged in friendly office banter. This morning Aaron and I were arguing about resumes. Do you need one? What use is a resume these days? There is research out there that states online job applications and resume submissions rarely result in in a new job, and make it even more difficult for HR to find the right candidate. Many HR departments, particularly of larger companies, use search tools to quickly scan text resumes by specific phrases letting excellent applicants slip through the cracks. Alternatively, this online application black hole encourages unqualified candidates to apply easily, diluting the candidate pool.

In terms of the job search, I whole heartedly agree that it is better to create relationships and have a strong portfolio of work than rely on your resume and online applications. Find the company you’re dying to work with and find a way to have a conversation with them. We’ve all heard that. But somehow, resumes have endured. The question is, do you need one?

Three things about resumes and who should have one:

1. Skill level and experience make a difference. 
   
   If you are new to the game, and are a designer, you should keep an excellent resume in your back pocket. If you’re Jessica or Frank, then a traditional printed resume is probably moot. If you’ve been at it a few years and have started to create a name for yourself then your website probably does an excellent job of telling your story, dictating your experience and area of expertise. That said, until you get to that point in your career, create a polished resume but don’t feel like you should lead with it. 
   
   
2. It depends on your area of practice.
   
   If you are a Ruby developer or back end wizard of some kind, I am less concerned with your resume and think that type of web practitioner can find job success with a great portfolio, social media awareness, and personality. However, if you are a designer or even a front-end developer who is expected to have a strong understanding of typography, either web or print based, I find significant value in a resume. My process of creating a resume from when I began design school to when I finished years later was hugely important in beginning to understand typography, organization, editing and presenting myself. And for that matter, typography is a practice, not a piece of software. The basic task of creating a resume is always a good exercise to practice. 
   
   
3. Your portfolio should stand on its own, so why do you need a resume? 
   
   We all have to start somewhere. For a junior level designer, if you cannot put together a resume that represents your ability to handle typography and be an editor, then you’re likely not going to have a body of work that is strong either. Or perhaps, somehow you’ve put together a handful of nice portfolio pieces but your resume is a typographic and content catastrophe, I’d be wary of vouching for you. 

Your resume should not be the single best thing you have to offer. Personality, your opinions and your portfolio are superior. However, if you’re just getting started cannot manage to edit a simple, one page document and make it look like a typographic dream, then you’ve missed something. 

So now that I got to banter about this quite a bit, what do you all think?

This post was created by @juliajamieson

Startup Weekend 2013

Last weekend, though it now seems like ages ago now, was Startup Weekend. 

The Factory was the venue for the event. With renovations and brand new conference rooms complete, the space was well equipped to handle the 150 some people that came in and out over the weekend. It was a three day blur of ideas, new businesses and collaboration. Thanks to Skyward Visual for the videos they created of the weekend. 

As a first time Startup Weekend attendee, it was an overwhelming but excellent experience to see the excitement and community that forms throughout the weekend (check the videos, you’ll see).  There were people there that I know and expected to attend, high school and college students, sponsors, and professionals from various places across the country drawn to the event for any number of reasons. 

The winner of the event was U-Turn, who is creating a physical product, unique because so many teams create web based products. U-Turn plans to sell their u-shaped storage option online and via retailers. Second place went to Curbserv and third place went to EZ Route. You can read more about the winners in the GRBJ. 

From Julia 

Are you a browser or a searcher, and does it affect how you code?

Janson asked me an interesting question recently, and I could tell by the look of exasperation that it was a loaded one: “Do you browse, or do you search?” My answer was immediate, and emphatic: “I search!”, to which he responded quietly: “That explains a lot.” It turned out that he was editing some of my CSS.

Janson and I sometimes have very different approaches to front-end development. This particular divergence in our methods centers around stylesheets: specifically the number of them. I have nothing against multiple stylesheets per se, but I find one per product area cumbersome to work with. Now, I know what you’re going to say: “Aren’t you compressing all your stylesheets into a single file anyway?”, and the answer is “Yes, of course!”, but my concern here is not for the visitor, but for the developer (me)

In the “olden days” of static CSS, Firebug was all I needed to find the offending style and learn it’s location. Now we’re using Sass, it’s not so simple. Despite my exploration of FireSass and other similar plugins, I’ve not found anything which will readily (without opening another file or pane) show me the line of the original, uncompressed CSS which needs attention.

Janson’s browser/debugger tools of choice are Chrome and its built-in inspector. I’m a huge fan of Firefox/Firebug, and I’m not going to give them up easily (certainly not for anything WebKit-based anyway). It seems however neither of our toolsets are fully up to the task, and this has a big impact on the way I work, which brings us to the crux of the problem…

I prefer the bulk of my styles to be in a single, large CSS file as that allows me to quickly CTRL/CMD+F the hell out of that thing in my editor of choice. Quick. Easy. Done. Except this makes my colleague want to kill me when he sits down to edit code I’ve written. Janson prefers many, small CSS files, named for the area of the site/app to which they relate. This makes complete sense to him, and he swears he knows exactly where to look for any rule he wants to change. The reality for me when editing Janson’s code is that it’s not so clear cut.

For instance, I’ve recently been skinning an e-commerce product. Upon starting the project, I inherited a file structure Janson had created for a similar product, for the same client. To his credit, he recommended I throw it all away and start from scratch, but I considered there was enough useful code in there that I’d use it as a base. Overall it’s going well, but I already know that at some point I’m going to want to combine all these stylesheets into one.

Obviously - as this is an e-commerce site - the main focus is products. My problem is, when styling a product do I reference _products.scss, _productdetails.scss or maybe even _common.scss for its rules? If the product is in my cart, should it be referenced in _cart.scss, _checkout.scss, or maybe even application.scss? Where is the overlap and where is the dividing line?

So, I ask you this: can you offer us any hope of a compromise? Are there tools which will as allow us to get on the same page? Do you experience these same frustrations when working With other developers, and if so how do you address and resolve them? Is “Developer Couples Therapy” a thing?

There’s plenty of discussion online about one-vs-many CSS files in terms of output and browser requests, but in general nobody seems to hold (or at least share) strong opinions regarding development. Perhaps I can encourage Janson to share his thoughts in a future blog post.

~ Andy: @akwestmoreland