Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

All of us know that mobile first approach is the way to go developing new applications. But there are few cases where this is possible. Often the customer already have a web application online, which should be made responsive to fit a tablet and a mobile view.

So now we have a web site that needs to be responsified, often packed with information and features that make a whole web application. It's just so common that everything can't go in tablet view end even fewer items on mobile view.

How do we determine which features go where? The customer has a clear opinion, which need to be taken into account. The users have their different views on things dependent on what they use the web app for. Looking into web analytics we can see patterns of actions that stick together and which features are used the most.

Following just one of these demands, analytics or opinion will most likely fail. So the answer is probably a combination of the above. So that's why I'm asking how do we Determine which features not to show in responsive designs non-full site view?

share|improve this question
    
If you are just "making an existing website responsive" then that's not really best way to go. The content was designed for fixed-width desktop, not for consuming on a mobile. Therefore you'll likely have large decorative images, long paragraphs of text, Flash assets etc. None of this actual raw content designed to be used on a mobile device. You should start again afresh - plan out all the content with multi-device in mind from the outset. But if your brief is 'make this responsive' then you can do just that. All 'responsive' means (in a technical sense) is media query breakpoints... –  JonW Jul 24 at 8:18
    
...It's not design, it's just changing CSS at certain width. It's like saying 'take my Ferrari and make it a diesel'. You end up with the same car but totally unsuited to general use. So in your case that means you just reflow all the content on the site into a single column. And there you go, a 'responsive' website that will have a lot of vertical scrolling. It's unlikely to be a good site though, because you're taking desktop content and showing it on something that isn't a desktop. –  JonW Jul 24 at 8:18
    
@JonW I had this project over last Christmas with the requirement: "make it responsive in 250 h. Naturally I needed to change table based design to divs at first, and I did have the prestudy that determined hours and very little scope. Next time I need to be prepared for this situation. That's why I'm asking. –  Benny Skogberg Jul 24 at 9:14

4 Answers 4

up vote 3 down vote accepted

I believe you've already answered, partly, your own question.

Looking into web analytics we can see patterns of actions that stick together and which features are used the most.

That said it's important to ensure that options that may not be as popular can still be serviced to users who may require them.

Taking an existing web application and converting it to a mobile platform is so much more than just creating responsive designs. You should analyse usability functionality for the screen area available across a test-bed of device sizes, although I'm sure you know this already.

You don't mention the application or give examples, but unless there really is a myriad of options and you really need to cull some to make the mobile app usable, for me it would be driven by users needs followed by mobile functionality.

For example, we supply a mobile app to the building trade to carry out formal inspections of building work, there are many operations that the user can carry out that mirror the desktop suite, however one aspect of it, uploading, marking and zone'ing floor plans, just hasn't lent itself to the mobile platform as yet. We are constantly looking at ways to make this a viable options, but it usually ends up being too convoluted or inaccurate.

Testing continues - which forms part of my answer to you, perhaps several scenarios of functionality would also help you decide on what functionality to give weight to in your app and what functionality may be slightly harder to get to, give it some client testing and usability testing and take the matrix that provides to form your design.

Hope this helps.

share|improve this answer
    
+1 Good answer. It's the process of determining features in after and you give good insight on technical aspects of platform needs to be considered. Thanks. –  Benny Skogberg Jul 24 at 9:26
    
+1 Really what it comes down to, and many of the answers touch upon this, is content hierarchy - determining which module of content is more important than another, and thus should have more relevance in your ordering. Testing and analytics will help you figure this out. –  kretzm Jul 24 at 18:46

Considering the first part of the question, Mobile First Approach is not a constraint. It's an opportunity for designers to determine the MOST CRITICAL use case of a product. As we get only a limited real-estate to work on, we need to prioritise the use cases.

Second, you need to convince your client that It's not users who have to conform to their opinions. Instead they have to listen to their users and modify their product based on their opinions.

Third, As you mentioned in the latter half of your question, you can come to a middle ground using Data Analytics. But it's not the only way since data only shows what's happening right now, in the present design (which might be biased towards certain use cases and hence others aren't getting due importance).

To identify the core problem (and hence core use case) you should also go for hands on research(user interviews in the context of use).

[UPDATE] Prioritising doesn't mean that you have to reduce the features/functionality on mobile platform. Rather, make most necessary use cases readily available and keep all the others less prominent.

share|improve this answer

Actually mobile first way isn't actually the kind of approach it sounds like.Nobody starts design with designing for mobile first and then building it up. Although the concept generally says this only but a lot goes on backstage.The typical workflow that we follow is :

  1. We start with considering the necessary and absolutely needed elements we have to include in our project. These will be included on every viewport and you can say them the strip down version of the project.
  2. Then there is always one device that you majorly design for. Currently this is largely the L-viewport but every project has its specific needs.
  3. We design first for that viewport and with that stripdown version of elements that are absolutely needed.
  4. Then we add up extra elements that are visually appealing or whether just balance the whole design of the project.
  5. Now the whole mobile up approach comes in. The basic elements are kept in mobile version , some little but extra visually balancing and all that stuff is added. Now next bigger viewport comes in , more elements are added , size and positions are adjusted and use of negative space is introduced. As we move to bigger screens , extra ( all that visual balancing stuff ) elements are added for better experience and use of negative space is enhanced. More not so necessary information does also increases with screen size. Other than this, scale images fonts according to your needs.

Now back to your question :

Determine which features not to show in responsive designs non-full site view?

The features except that absolutely necessary elements list can be removed. Including background images( use gradients or solid colors ) , non necessary bulky labels in forms , tooltips ( can be replaced with static content ) and other non-necessary images , texts ( icon-/fonts can be introduced ) and any other thing that doesn't feels good with design (:lol:) on that viewport.

Even sometimes I tend to think , designing responsive projects on smaller viewports is much easier than on larger. Try designing for a 4K version and you'll get to know when increasing size of fonts dosen't compensates for it.

share|improve this answer

Don't reduce the function set of the webpage, people knowing the normal website will miss stuff and get upset about yet another crippled mobile page.

There is absolutely nothing wrong with scrolling a long paragraph of text on a mobile device, if it contains content and not just fillwords.

Making images smaller is a good approach, for example with max-width/height it keeps the aspect ratio.

You can of course rearrange items to have the prominent ones on top of each page or even splitting pages into several smaller ones, but that will be extra effort that can be achieved with a navigation menu and anchors too.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.