Skip to main content

Mobile

The Art of App Development: Design and Engineering Lessons Learned

Enlighten was acquired by Perficient Digital in December 2015
Enlighten’s Executive Art Director Mike Gatto and Software Engineer Voratima Orawannukul are the two minds behind the award-winning Hunter Douglas iPad application, “The Art of Window Dressing.” Here, they share their process of creating the app, from initial planning challenges to finally getting into the Apple App Store.
Q: What do you believe was the most challenging part of creating this application for the iPad?
Orawannukul: This is the first app we worked with a client. An app development is something completely different than a web development, which is what most clients are used to. Setting expectations was what I found the most challenging.
Q: Can you expand on that?
Orawannukul: When a website doesn’t work it just stops altogether; but you still see something visual—the browser. But when an app doesn’t work, it just crashes. That sometimes seems more alarming or severe than just a typical website. With a mobile device, everything is smaller. The processing power becomes smaller. Trying to compact a rich web application down to an app is not an easy task. The clients may wonder why we can’t do it the same way as the website. Sure, we can do it on a computer, but an iPad doesn’t have that same capability so it’s going to be different. We had to figure out how to get these messages across somehow.
Q: How about setting client expectations for the interface and the world in which the app will live in?
Gatto: Well, for the interface, it was about taking a really complex web application and trying to work that into a simpler touch screen environment. If we look at the current implementation of the Hunter Douglas iMagine Design Center, it’s really complex and has a lot of functionality and data available. So the big task with the app, from a design standpoint, was taking all the functionality from the website, putting it into a touchscreen interface and making the clickable targets big, while also having the necessary secondary functionality available. That’s why in the main interface there’s only a focus on a few pieces of functionality, and other things appear on collapsible palettes or slide in. That’s just the nature of how it has to work. I think it gave us the opportunity to prioritize what’s most important for the user, whereas the last one was probably driven a little bit more from a company and product standpoint, where all the product information and SKUs needed to be there. The reality is, for most users, it’s a pretty basic visualization tool. It’s not a tool to get to a specific SKU. That was the key thing, from a usability standpoint—finding ways to make the interface more intuitive.

Q: I would think because there aren’t many visualization iPad apps out there. You probably had a lot more of a blank canvas to start with. Do you feel like that gave you more freedom, or made it more challenging?
Gatto: The challenge was the touchscreen—it was very different. How you orient the functionality is all about that. We developed screen comps for three to four weeks and we just internally hammered on “What can we do?” We worked iteratively, internally, and I think we were able to come to a much more solid solution that was pretty well baked. From there, the clients saw it and were like “Yes, that’s great,” and then it was just down to making small changes. I think that made it a lot easier, being able to work out most of the critical functionality before the first client review.

Orawannukul: We were also able to leverage the web version of iMagine and bring that into this iPad app, which made it easier. This left us room to create new and fun visualization, which resulted in a new feature called Color Filter.
Q: Did either of you feel like it was pioneering new ground?
Gatto: For me, absolutely. I’ve never done an app before. Because of the high resolution of the iPad, my designs looked about a 1/3 smaller. Screens render on a desktop screen at 72 dpi and when you look at your iPad designs they seem almost huge. Now, you take that same comp, put it on the iPad and it shrinks down by a 1/3 because the new iPad can squeeze 132 pixels per inch. As a result, the targets didn’t seem as big, and so there were adjustments to be made along those lines. That was not expected. I thought like every other web site design I had done, “Oh, what’s on screen is how it will be delivered.” Not so much. That was a real challenge too. Between us, I was like “Why can’t I get this right?” It’s because we’re designing on an iMac at 72dpi for an iPad screen resolution at 132 dpi.
Orawannukul: To a certain extent. A mobile device paradigm differs from a personal computer. The device runs one active application at a time. The developers have to be cognizant about memory usage—what to load, when, and as minimal as possible. It also forces us to have to think about how to load and unload application properly. You don’t normally have to think about these things when developing a website. A screen real estate is another limitation we have to think about. When you’re working on a computer you’re so used to having a lot of applications open on screen. But, on an iPad, you’re looking at just one application on a small screen. This plus Apple’s minimalist approach, we have to work with hiding things and collapsing things. But at the same time, a client is not used to that because they’ve been looking at the website for so long. So then we have to communicate why we need to collapse things, why things have to be this way.
Gatto: Right. Initially, there was a lot of information and functionality present in the original web design for sales people, like decorators and designers. Some of that information is still there for sales people—it’s there, and if you want to click it, you can open it up and you can see it. But the consumer would rather be looking at their window and how the product looks in it than categorical data about that particular piece of fabric.
Q: Any advice that you’d want to give for someone – an engineer or a designer – who is just starting an iPad project for the first time?
Gatto: The sooner you can see something on the iPad, the better. I mean, it’s all about clickable targets, proportion, and how the layout and hierarchy work. Whatever you’re doing on a screen on your computer is fine, but until you’re actually holding that iPad, using it and playing with it, it’s not real. You have to be prepared to make compromises from what you thought to what you actually see. As soon as you get it on the pad, the relationships you think are working might not necessarily be working anymore. There aren’t really any hard and fast standards for creating an iPad app. There are some that exist, some that are sort of being adopted, and some you can wave at—but once again, it’s all new and there’s a lot of ambiguity. What you think would be working doesn’t always work that way, or the client doesn’t understand it so you have to be agile and move and change. We did a lot of that as well.
Orawannukul: I agree with Mike. I think what makes this project successful is because we (designer and engineer) worked really closely together on this new territory. We didn’t have to have formal meetings or anything—we just interacted with what the other was doing, and got it done.
Gatto: The process of creating the app was reminiscent, I would say, of how we worked back in the day with CD-ROMs, where the engineer had to be fairly artistically inclined. Because there’s a lot of ways you can animate something, you want a programmer that’s thinking that way and can bring that extra level of creative interaction and animation. That’s a key reason why you need creative engineers, and you need artists or designers that understand basic engineering concepts. If you’re divorced throughout the process, you’re going to design things that aren’t going to be executable, and then you’re going to be frustrated trying to make changes and compromises on the fly that you didn’t intend on doing. There were a lot of things in there that I was like, “Oh, I didn’t think of that.” There were subtle things that make the app work really well that just came naturally from Voratima in the process of programming.
Orawannukul: For my advice, I think I would encourage engineers to run the app against Instrument, which is a tool set that comes with XCode. It helps you diagnose the memory issues. Run it immediately, as soon as you have a basic architecture implemented, and keep running it throughout the development cycle. It’s a tremendous help and if you don’t do it by the end of the project, you’re going to waste a lot of time redoing your code. We’ve used a lot of API for analytics and because app development is fairly new, sometimes those APIs have issues—like memory issues—so just look at them, and maybe if you have some time, play with them to see what’s going on. We did spend a lot of time trying to look and solve the memory issue, and it ended up being third-party library that was causing it to crash.
Gatto: That was the biggest thing: optimization. After all the planning, all the figuring it out, we spent months optimizing.
Orawannukul: I would say that 50% of a new app development goes into memory management and optimization.
Gatto: Right. The app would crash or something would happen that wasn’t supposed to, which made us have to go back and rethink, “Well, what are we loading here, what are we putting there?” To maintain the fluidity and seamlessness that you expect on the iPad, you have to make compromises.
Orawannukul: Think about a simple photo gallery with navigation at the bottom for example. On a website you can just load everything all at once and you hit next, next, next. And you see this smooth transition, right? But with an app, there’s a table view component that handles that—and if you use too big of an image, there’s a lag into the animation or a change in how responsive the interaction is. The device doesn’t have the same power as a computer. We had to optimize the images and unload a few user interface elements to release some memory to accommodate smooth interaction. Also, there’s multitasking gestures feature on an iPad. Besides pinch and zoom with two fingers, this feature allows you to use four fingers to exit out of the app or transition to the most recent app running in the background, etc. The device picks up on these gestures, so your app needs to be able to handle that as well. Sometimes the app gestures will interfere with the device gestures, and it can cause quite a bit of a headache.
For more design and engineering insights, follow Voratima Orawannukul on Twitter.
Download Hunter Douglas’ The Art of Window Dressing™ iPad App from the iTunes App Store.

Perficient Author

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram