Building real things for real people 2009

Building Real Thingsfor Real People

Human Experience Design

#M3Real@developerjustin

Justin FerrellDeveloper


Introduction. Justin Ferrell, I’m a developer.


Digital Relativity. Fayetteville, WV. Started with mobile web in high school, studied computer science and IT at a couple of schools in WV and VA. Eventually ended up at Relativity doing mobile web, learned Titanium and Mono, and started doing desktop web.

Design vs

Development


Jump right into it. The idea of design vs development. A lot of people like to silo these and draw a hard line between these like they’re black and white. But, I don’t really think that’s the case anymore. Even this morning, learned that Dan Shultz, great developer, great speaker, has a fine arts degree. And he is 100% developer. The one of many cases where design and development converge. Hopefully we can find some more common ground today. Because that’s what it’s going to take to push us forward. We can see it happening everywhere around us. Design and engineering are converging, and it’s paying off. Look at Apple…


Last Fall, Apple fired Scott Forstall, who was head of iOS at the time, and appointed Jonathan Ive senior vp of design and Craig Federighi Senior VP Software Engineering. Together, the two took over his duties.

All Apple products released since, including iOS 7, the iPhone 5C, the iPhone 5S have been the brainchild of these two, working together. BusinessWeek interviewed them recently. The two described how their working together, design and development working together, allows them to build and ship better products because they are “less than a minute” from each other. Not only are they shipping better products, but they’re doing it faster. It wasn’t forced or anything unnatural. Working together just allowed them to work better.

Development + UX


Generally, the products we’re building are not simple beasts. There are moving pieces and parts that have to play well for us to get to where we want. It’s usually up to a designer to determine how it looks and how users interact with it. But the burden to not only build it and make it work, but to build it and make it work well, comes down on developers. Managing bandwidth constraints over poor cellular connections, optimizing code, gracefully degrading, device support. Failing, as all software will do at some point, is something that developers have to handle. Even if the designer handles the look of the failure, the developers have to catch it. It’s on them to determine what an error actually is. Neither of these disciplines could really handle this without the other.

Tear Down The Wall


What we’re looking at is tearing down that old-school mentality of designers and developers living in different worlds and speaking different languages. This doesn’t mean that your designers should be writing PHP or that your developers should learn how to use Photoshop. But they should be collaborating. There’s a reason you can take a PSD and ship it off to be ripped into HTML for $200. Because it’s easy, and because the people doing it don’t care about usability or things like load times and bandwidth constraints. Steve Jobs said that computer science was a liberal art, and it very much is. We have to approach these problems creatively to come to creative solutions. If we could solve problems and solve them well without being creative then all of our smartwatches would have ethernet ports. Which is where the case for collaboration comes in.

Collaboration


Collaboration allows the team as a whole to ship better products because there are no “phases”. You’re not playing telephone with the product. Imagine that the UX folks wanted one thing, the designer came up with another thing but the developers did it another way so that they could use a certain framework. Just...No. That system is vastly flawed because it prevents us from following a cohesive vision and building something that we can all be proud of. It seems like that is the root of the disconnect between development and design because it’s so hard for the two to pass ideas back and forth without things being lost in translation. For us at Relativity, we start with information architecture, then we do wireframes, then we hit photoshop and then we use that to build the product. There are phases just like with anything else, but we’re all involved in every phase. The moment the architecture is finalized, the other developers and I get access to it. Before there is even a wireframe, the developers are involved. This helps us outline better deliverables and ultimately ship better, more optimized products. Optimization is key here, because speed and responsiveness are huge parts of usability.

But how does it work?


System design is a huge part of the usability. Let’s say we’re building a trip planner and every stop on the itinerary has to be its own page, or every product page needs to be the child of a product category page, but there are no forward-facing category pages. But, how will the map work on a phone? Maybe we need to show all 1,500 products on one page that is filtered dynamically with jQuery. Developers hear these sorts of demands from designers and UX folks every day. But how do you build these things? What does the backend of that look like? How can these be optimized? These are legitimate usability concerns because performance and graceful failure directly impact usability. Developers have to be slimming down their database queries, moving as little information back and forth as possible. Trimming their API calls to conserve data. Watching memory allocations on the client and server sides to keep everything running smoothly. Monitoring bandwidth constraints because let’s face it, not every connection is wifi, and not every wifi connection is solid.

Development + UX


These are all things that impact usability that developers have to address as much as designers do. Development is, or should be, a huge part of the usability and design process because it is, in most cases, the last lens that a product goes through. The quality of the design and the experience don’t really matter if the dev team isn’t working toward the same vision. Which is what creates a need for developers to strive toward better user experiences. Your chain is only as strong as its weakest link and your product is only as good as the worst phase in the production cycle.

Trim the Fat


Speaking as a developer, I can say that we’re fairly easy to spoil. We’re really good, as an industry, at building things that do work for us that we used to do ourselves. Things like content management systems, garbage collection, javascript frameworks, HTML5 boilerplates, SDK’s and libraries. There was a time when we built these things every time we built anything. We’ve all been guilty of cutting corners at one time or another. But it isn’t so much cutting corners itself that’s an issue. We work smart, not hard. These frameworks removed a lot of work and made the industry as a whole more efficient and helped us move on to building cooler more powerful things. The issue with cutting corners is when you’re not working smart or hard. I’ve got a pretty good example of this.


This is a great example. What is the first difference that you see between these two files? There are a couple things that are wrong with one of them, but we’re looking for two things in particular.

$thisIDget_the_ID()


$cfarrayget_post_meta()

The difference is this. We were calling get_post_meta once for every field when we really only needed to call it once. And for every get_post_meta call, we were calling get_the_ID(). That’s two database calls for every field when we really only needed two calls total. To a lot of people, this is really obvious. It was obvious to us after we looked at it for a couple of seconds. But there are developers around the world who would ship this because it does work. The end result is exactly the same. It’s about a second slower, but what impact does that really have?

Need for Speed


It matters a lot more than you think. Google has made it very clear as far back as 2009 that page speed impacts search. If no one can find the site, no one can use it. Another statistic released by Google explained that 1 in 4 users will abandon a site that takes more than four seconds to load. They also noted that while it handles over 3 billion searches a day, increasing load time by less than half a second, 8 million queries were immediately abandoned. AND a similar study revealed that 3 out of 5 users who abandon a site will not come back. Experience design is only half the battle if we don’t have people finding and using the products. So obviously, literally, every little bit counts. Speed and performance directly impact the success of a product across the board, from find-ability to usability. If no one’s finding the product, no one is using the product. And even if they’re finding it, no one is using it if it’s slow. So where can we, developers, start if we want to trim down the size of our products?

Image Optimization

@developerjustin #M3Real

The first big one is image optimization. There is so much information in image files that just isn’t needed at all. It just takes up space for no real reason in most cases. And we load it all into memory when we display these images. Each and every time. It impacts memory consumption, it impacts memory allocation, it impacts binary size. So much information that we just don’t do anything with. And in some cases, our largest graphics aren’t even used because the devices the apps aren’t installed on don’t have screens with a high in enough pixel density like retina or most high-end android. It’s just wasted space and ultimately, wasted system resources. So how can we work to optimize our images, and what are some examples of image files optimized really well?

#M3Real

The first and probably best example of image optimization done really well is Tweetbot for the iPad. Most of you probably know what Tweetbot is. It’s is a great example of image optimization done correctly. Tweetbot is, as most of you are aware, an iOS-only Twitter client. And it’s pretty awesome. Great features. But the UI uses A LOT of graphics. The entire UI is really rich, graphically. But even on an old first gen iPad like mine, it’s really snappy and a lot of that is thanks to image compression.

#M3Real

There is a free program for OSX called ImageOptim that literally strips all of the stuff that isn’t needed from graphics. I use it on every single piece of software that I ship. I’ve seen it reduce the size of image files by over 95% while maintaining virtually the exact same quality. If we zoom in a bit on that chart…

http://imageoptim.com/tweetbot.html - #M3Real

You can see that when used with ImageAlpha, another free tool offered by the same people who built ImageOptim the overall size of the graphics is reduced by over 75%. ImageAlpha does this by removing unused alpha values and transparency information from PNG and GIF files.That’s a huge difference though. The difference between file size between ImageOptim and Xcode optimization is unreal. That could make the difference between someone being able or not being able to download the app over a cellular connection. Remember no code changes, no loss in quality. The exact same app. But less than 20% of it’s original size. But what about actual performance?

http://imageoptim.com/tweetbot.html

http://imageoptim.com/tweetbot.html - #M3Real

We immediately see the relationship between file size and performance. With xcode compression disabled, we see that ImageOptim and ImageAlpha combined can give us about 2.5x regular speed when displaying UIImageViews. Now think about that on the scale of something like a twitter timeline where every row has a remote image associated with it. That alone is saving us seconds at a time on a large scale. These are the kinds of things that can make or break a user experience and they require absolutely no code or loss of quality or functionality. We’re just removing unused information from image files.

http://imageoptim.com/tweetbot.html

http://sam.roon.io/image-optimization-on-ios - #M3Real

Another great example of this is Incredibooth, from the folks that build Hipstamatic. Universal for iPad and iPhone The app was originally 70mb. After using ImageOptim and ImageAlpha, they were able to get it to 31mb with no visible reduction in quality, even on retina devices. That’s close to half the size with zero code changes and zero quality loss. Just removing unused information from image files.

http://sam.roon.io/image-optimization-on-ios

ImageOptim + ImageAlpha


These programs work for mobile web, desktop web, everything. Smaller image with no quality loss are always better. Even on the web, these files are being downloaded, rendered and using system resources. So, a lot we can do to improve our graphical resources.

Efficiency


It’s not really just about system efficiency though. It’s also about us being more efficient in the way that we build things. We need to be able to design, build and ship awesome products quickly. Devices and use cases are evolving. That’s where the need for things like responsive design and cross-platform development come from. We can’t really count on everyone to have the same device with the same processor and the same OS and the same pixel density and resolution. We just can’t. We live in a world where there are cars running embedded Android systems and Apple might be shipping a watch. We need to be building scalable solutions that work across the spectrum because that’s where the users are: the spectrum.

Evolution


And it’s that evolution, that fluidity, that should be changing the way that approach and solve problems. We have a designer at Relativity who just graduated from college with a degree in graphic design. Art scholarship, plenty of great work. Solid guy. And he was telling me that when he was just an intern at our company, his classmates were ASTOUNDED, like floored, that he talked to and worked with developers on a regular basis. And that just seemed silly to me. These kids thoroughly and legitimately shocked that he was able to talk to his coworkers. The real world is going to chew them up and spit them out. That’s just ridiculous. That, to me, paired with everything else I’ve shown you, shows me that we, as a culture, aren’t evolving quickly enough to solve the problems that exist within the products we create. We’re trying to get our products into the hands of as many users as possible right?

Users vs Humans


I would argue that that isn’t entirely true. We need our products in the hands of as many humans as possible. A car is a user because it uses gasoline. My laptop is a user because it uses the internet, it uses electricity. But human beings are different. Human beings are sensitive and malleable. They’re like overly ripe bananas. They’re mushy. In the keynote earlier, Chris compared it to Where’s Waldo. “Hey, there is a human being here. An actual living, breathing person is involved. And they’re emotional.” And he talked about existing patterns of behavior and how much of a waste of time and money it is to change them. There have been more studies in the last 30 years that outlines how things like font size, color, text direction and kerning affect human behavior. And it’s because we’re creatures of habit. Things affect us, as a species, pretty much the same way. Experiments have proven it. And the thing about experiments and findings that can’t be reproduced is that they are worthless because they don’t prove anything. But all of these things can be reproduced. They ARE reproduced. Every day. Around the world. By literally thousands of companies. All for the purpose of making people do things. Manipulating people.

Manipulating people. Because that’s really what we’re trying to do. Even if it’s for their own good. We need to get people, human beings, from A to B, because B is where great things happen. Ideally, in a morally acceptable scenario, there is something good for everyone when we reach B. You click the big red button, you get a Macbook Pro. You click the big red button, Apple gets paid for a Macbook Pro. All of the people involved in the creation of that Macbook Pro get paid. We all win. A friend of mine who is speaking here, Andrew Heaton, actually summarized this really well in his book Purposely Irregular.

@tigerstripe

Clients have money, clients have projects, clients have customers and sometimes a goal. We can make this shit happen. And that’s so true. All of the pieces exist. They’re all there, just waiting. There are human beings willing to do things and there are companies who need to people to do them. We just have to push the humans in that direction. That’s where the magic happens. That’s where users get awesome tools and we get paid for building them. We’re building tools that push all of the pieces together so we can all get to B because like I said, B is awesome.


Coming back to the Apple example. Apple invented the iPhone, the Mac, OSX, iOS all of it. So when they go the drawing board for the 5S or Mavericks, they’re working on solving problems that they may not have necessarily created, but they made it possible for them to exist. They just needed users to help them evolve past them. They presented the world with devices, and the world used it. They take that and use it to make that next version better. That’s how evolution works. So we see them and their devices evolving as the spectrum does. And their products are all the better for it.

Building Real Thingsfor Real People

Human Experience Design


So, the point of every good talk is having some kind of solid take away. Something to make it feel worth it.

Designers + Developers


First, Designers and developers should be friends. Don’t be afraid to talk to each other and work together. That’s where the magic is. The one way we’re going to get from A to B is together. And B is where great things happen for everyone. Collaborating between disciplines is what it’s going to take for us to innovate and evolve with our users. It’s like hockey. Don’t go where the puck is, go where the puck is going.

Speed Matters


Second, Speed matters. A lot. Every single fraction of a second that you can save is worth it because every delay is a chance for someone to turn around and leave. Keep things like bandwidth and performance in mind because those are the things that are going to make or break the user’s experience and determine whether they come back again or not.

ImageOptim + ImageAlpha


This one falls in with the last one but it deserves its own slide. Stop wasting unnecessary resources on images. You can reduce binary size, increase performance and just make your products all around better by removing a ton of data that you’re not using anyway. We’re talking about decreasing your app size by literally half and potentially even more, while also making it faster.

We Can Make This Happen


Finally, all of the pieces are there. All of them. The people, the tools, the languages, the devices, the marketplaces. It’s all there. We’ve been handed everything. It’s just up to us to push of all of these things together and make the magic happen. We just have to get everyone from A to B. Because B is great for everyone.


Questions

Questions?


Thanks!

Building real things for real people 2009

Technology

Transcript of Building real things for real people 2009