4

I've written a weather app for Android. Its primary screen and function shows a data table with multiple columns (e.g. temp, wind speed, wind gust, pressure, etc). A feature of my app is the ability to customize which columns are shown, so the user can show only which columns they are interested in. Most phones can just about handle the default selection of columns in the app, but adding any pushes the data off the width of the screen for most phones.

At the moment I have horizontal scrolling to handle situations where the data table is wider than the screen. It would be great to enable side swipe navigation, but this is either not possible or at least not recommended with horizontal scrolling. Any ideas on how I might tackle this issue?

Improve this question
2
  • What's wrong with horizontal scrolling in this context? By swipe do you mean swipe=page or pixel-by-pixel panning gesture?
    – Zelda
    Commented Apr 19, 2012 at 22:29
  • 1
    @BenBrocka - in Android's 4.0 guidelines, one suggestion is offering side-swiping to alternate views/activites within an application.
    – Chris Knight
    Commented Apr 19, 2012 at 23:08

2 Answers 2

Reset to default
3

Side swipe is definitely not recommended for navigating wide data screens; it is for changing views, not for panning a view.

To be honest, it's hard to imagine a scenario where mobile users should be given the ability to add so much detail to something that they need to pan to see one row. This sounds like a feature in search of a problem. The mobile experience has to prioritize information; your main interface should display only the information needed to solve the issue, and secondary information should not be there at all, or relegated to a different screen.

If you must customize the information available, have you considered moving the details of a row to a second screen? This would be a valid use of the swipe gesture; select a row, then swipe to view its detail screen, swipe back to return (see: iTunes player).

Jacob Neilson on Mobile Usability: The second point is more conceptual — and harder for some people to accept: When you have a smaller screen, you must limit the number of features to those that matter the most for the mobile use case.

The research to back up this assertion is for sale for $300.

Improve this answer
3
  • Thanks. Yes, I'm trying to implement side-swiping for changing views while making the main data view as usable and flexible as possible.
    – Chris Knight
    Commented Apr 19, 2012 at 23:07
  • 'flexible' is not necessarily 'usable'. Are you absolutely sure users need the ability to add arbitrary columns? Can you handle the vast majority of use cases with two or three choices of view instead, or with a couple fixed columns and one 'user choice' column?
    – Myrddin Emrys
    Commented Apr 19, 2012 at 23:10
  • Good questions. Time to challenge my perceptions of what users really want and need and think out of the box.
    – Chris Knight
    Commented Apr 21, 2012 at 21:45
1

You should really avoid the horizontal scrolling for this (either scrollbar or panning), per Myrddin's answer.

If you feel you really must provide more data than will fit horizontally, though: what is wrong with horizontal scrolling? Yes, I hope we all agree that it's evil, but why is it evil? A big reason is the loss of context: in a table, the first column is probably important (keys) and that's the first thing you'll lose.

A solution to that problem is to make that column sticky; scroll/pan the other columns if you must, but leave the one that tells people what each row is in place.

This approach won't help with cases where you need to see the whole line at once, but for columns of disjoint data, particularly that the user can re-order, it should work -- though avoiding the problem is better.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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