Interface design for mobile app vs traditional web app

[Suchira Gharde]

How the interface design for mobile apps different from interface design for traditional web applications?

[Cameron Banga]

Hey Suchira!

Thanks for the question, it's a tough one. It'd be a bit lengthy to explain in depth, so going to do my best to discuss as simple as possible.

For web applications, we're usually designing with the following expectations in mind. That our user will be using a large screen (12-30 inches), while interacting with the site using a keyboard and mouse.

On a phone or tablet, we expect the user to be using a much much smaller device, likely with a screen 3-10 inch screen, and for interaction to be done completely with the user's fingers.


This leads to many different design patterns, mostly caused by the different interaction method. But should give you an idea on the overall guiding principle for the differences.

[Bear Bibeault]

Brings up a good point/question. In your opinion is it generally possible/feasible/wise to try and cram the views for widescreen displays with mobile displays into the same file/template? I see a lot of lip-service paid to responsive design and trying to present the same view regardless of device, just using CSS to adjust the display. The examples for this are almost always blog type views where it's simple to go from a 3-column view to a single-column view. But in the case of web applications (versus text-centric sites), I've found that the views needed for a mobile-sized screen and fat fingers are so different from those geared towards wide screens and mouse/keyboard that the view ends up essentially being a bunch of if/else nonsense. Quickly makes for a gnarly mess.

Any opinions on the subject?

[John Wetherbie]

Bear,

That's an interesting question. My experience leads me to go with that old engineering standby: It depends.

For sites that can easily translate between platforms using CSS, etc, and its not a gnarly mess, them that seems to be a good approach. Once the pain of maintaining the data in one place exceeds the value then splitting seems called for. Hopefully the improvements in maintainability and understandability outweighs the effort that may be required to change things in two places.

Is it possible to keep the common things in a single file and the platform specific items in another file (or one for each platform)? I haven't done anything big enough to know whether this would work or just cause a different mess.

[Bear Bibeault]

John Wetherbie wrote:Is it possible to keep the common things in a single file and the platform specific items in another file (or one for each platform)? I haven't done anything big enough to know whether this would work or just cause a different mess.

This is actually the approach I've taken for one client whose site needs to be mobile-enabled. And yeah, it's messier than I like.

[Cameron Banga]

Sorry for the delayed response everyone, but I'm going to follow up with a similar "it depends."

In my opinion, the word "responsive" has become an unfortunate buzzword, often overused by stakeholders working with developers/designers in the creation of web/mobile app.

There are tons of situations where in mobile web UI development (or even in Android layout XML files, or iOS autolayout files), where it's pretty simple to use some responsive design principles to develop a great UI that works between a variety of screen sizes. And when possible, I whole heartedly endorse doing this over building exclusive UI files/outputs on a per device/OS basis.

This being said, there are a lot of times where this isn't the case, and responsive designs become an absolute mess. I really don't know of a great way to point these out, other than they'll often feel like a bandaid solution very quickly into thew development/design process. It'll feel _bad_ and confusing. Once you start building a responsive design and you get this feeling, my recommendation is to abandon ship immediately and look into designs built specifically for a device/platform/screen size.

[Bear Bibeault]

Cameron Banga wrote:It'll feel _bad_ and confusing.

Yes, exactly. Most parts of the app in question are fine, but there are a handful of views that I feel are an unholy mess at this point. I think they need refactoring badly, and I'll likely follow the route of sharing what can be shared, but not trying to use a Single View to Rule Them All.

The tricky part is making the sharing organized and robust. That's what engineering is all about!