Horizontal Scroll Web App

Question

I'm developing a new web app. The app's core is mainly a system for managing business data.

And because there are a lot of fields to manage (list, view, edit, delete, organize, ...), I was thinking of creating a web app with horizontal scrolling instead of vertical so I can have e.g. the edit form pop up next to the list view instead of changing the page and loading the edit form as a single page.

Let me illustrate it for you:

This image only shows one level of menu popping into the right, but it can have multiple menus popping up next to each other making the horizontal bar significantly small and generating a big wide screen like 12000 px x 900 px.

Secondly, this app may have it's own version for mobile devices (IOS, Android, Windows Mobile) and will be accessible throw mobile browsers.

So what I'm asking is, what are the pros and cons for user experience in having a web app where it's main way of navigation is horizontal?

---

UPDATE
The purpose of having multiple menus popping next to each other is to maintain a coherent line throw the root (starting from one of the company projects) and descending throw its hierarchy of sub-projects, tasks and actions.

One of its structure could be the following one:

1. dashboard -> List of all projects
2. selects Project A -> opens List of All Sub-Projects from Project A
3. selects Sub-Project C -> opens List of All Recent Activity of Sub-Project C
4. selects Manage Tasks -> opens List of All Tasks
5. selects Task X -> opens List of All Activity Related to Task X
6. selects Manage Task X Notes -> opensList of All Notes assigned to Task X
7. selects Edit Note Y -> opens Edit Form to Update Note Y

Answer 1

A con I see immediately is the use of the mouse wheel, unless you are able to override the default vertical behaviour with an horizontal one.

UPDATE:

The same is valid for the Page Up and Page Down keys. May be you want them to behave like the List Mode of Windows Explorer.

Answer 2

I see the main pro as the user's retention of orientation within the app. If the horizontal scrolling keeps a portion of the list visible when the edit fields are toggled as illustrated in your example, it should be clear to the user how to return to the list (whether through a swipe gesture, 'back' button or 'cancel' button referring to the cancellation of the edit action). The interface option that allows the user to return to the list view without completing the edit should be made very clear.

The main con may be lack of available horizontal screen real estate, especially on mobile devices. If I am viewing the app on a phone or small tablet in portrait orientation and open an edit window, depending on the final interface implementation, it may become difficult to fit all of the edit fields within the vertical space without requiring vertical scrolling. This could create confusion with scrolling below the list item to complete its edit, and possible gesture confusion between scrolling, swiping, cancelling, etc.

Also, people are accustomed to scrolling vertically. While I can see potential advantages to scrolling horizontally within your app, it may at times introduce additional cognitive burden.

In reviewing your post, I had a few questions:

If all of the editable data for each item is displayed within the list view, could the edit button toggle the static text to become editable? You had mentioned steering away from vertical expansion, but could the edit button expand the list item vertically to allow for inline editing rather than opening an 'edit' page?

You also mentioned:

multiple menus popping up next to each other

Can you elaborate on the purpose/use case of multiple menus?

Answer 3

Horizontal navigation is really good, but only when the user is actually doing a swipe action across the screen. To put this in another way, its good on handheld touch devices. A Web App might not be good target for horizontal navigation unless its made in a really wise way.

Now from the way I understand the working of your app, the illustration on the right side of the pic, is more like the better way. Once the user clicks on it, the screen animates and scrolls to the left, to accommodate the edit scren, without letting the edit screen to be completely taking up the whole screen. This in a way gives the user access to both views and also allows them to easily move back to the list view screen. The users wouldnt also be need to memorize which row they were working on. This is good UX i believe. But I wouldnt really recommend to extend the scroll for long to as much as u mention.

Also, the problem here is, when you have a long horizontal scroll (or even a vertical scroll) people tend to forget whats on the top of the page. It might add to their cognitive load to be trying to remember and think - "Now, where did i see that thing ??"

Heres an interesting read from the NN Group on horizontal scroll. This did help when I was thinking of horizontal scroll. Find it here
http://www.nngroup.com/articles/horizontal-scrolling/

Answer 4

Most mice only support vertical scrolling. In mac os you can hold shift (maybe you can in windows too?) to make the scroll wheel horizontal, but don't expect the average user to know that. Once people use tablets, though, horizontal scrolling should not be a problem.

How is your business data organized? If it is an excel-like table view with potentially a high number of columns, I would definitely discourage horizontal scrolling. Problem is, that you never know what users are going to put in the table view and how wide it would have to be in the first place - especially if viewed on smaller screens. If the table is too wide it will be really annoying having to scroll so far (sort of the same issue as if you had all the editing properties below the table and then one day it is 1000 rows long).

I've used Podio quite a lot - which is mostly awesome- but one of the things I dislike about it, is the fact that you have an "inspector" view to the right of your table view. This inspector can never be hidden. That's a big problem once you have a wide table or a lo-res display.