I'm designing UI for an enterprise application in which the users view their work environment in a single screen mode and dual screen mode (desktops only!).

With this system, the users fill in reports while performing analyses of an image (in one screen/window or both in a dual screen mode). This work procedure requires multitasking ability.

The reason the users have both screen modes is ideally that in their office they have their dual mode, and when they are working outside of the office they can still work in single screen mode.

This brings me to wonder, should I design some of the components of the system responsively? For example, the user will be able to drag some of the components from one screen to another. Should I provide users with the option to change the navigation/toolbar and make it responsive?

I know some people think that if it's not viewed via a mobile device then the responsive method doesn't fit, but what about this case, where my users use both screen modes? I'm thinking to provide small responsive adjustments to those specific features of the system.

4 Answers
4

Funny you should ask, because my first project had the same issue.
Our users needed to select event on a map, and then insert loads of data into it with a form (you know, the enterprise kind).
Naturally, we split the screen to the left and right sides. We designed it to be workable within only a single monitor, but knew many of the users would have two screens side by side (but not all of the, mind you). On a side note, this application was to be implemented in a web environment.

We thought carefully through this issue, and concluded it would be best to allow users to "undock" the map from the screen to a different web browser window. This way, it was possible to station the map window on the second monitor. This solution deals with the fact that MS-Windows lets you maximize windows inside a monitor, and that not always monitors have the same height. possibly, the only way to maximize a browser window across two monitors is by manually resizing it.

Two addendum notes:
1) The implementation team had a really hard time syncing the application between two browser windows.
2) This solution doesn't rid of the need to implement responsive behavior inside a single screen. In the current project I work on, the enterprise web application needs to be usable on the range between 1024x768 and 1980x1024. You'll soon discover that only very simple application screens work well across all this range, so we had some responsive design done

I'm currently working on a map based enterprise system where location based data viewed via the map will be required to fill in forms which appear as dialogue windows over the map.

I think the question you need to ask yourself with ALL functionality is:

Am I making the system easier to use for most of the use-cases?

You should make sure that all functionality is easiest to use in the most common set-up.

What I did with my project was make an HTML based interface that ran best at 1080p on a large-ish (~22") monitor but was usable on smaller monitors. The system's main use was in a control centre where I had control over the environment and hardware - so we could specify that for 80% of the system's use it would be used in firefox 10.0 on Windows 7 with a 1080x1920 res. The system had to work fine in 'all' browsers (IE8+, FF, Chrome) and on 'all' resolutions (within reason) - it was less comfortable and the UX wasn't as well planned, but what we lost for 20% of the time we more than gained back for the majority of use

I had a similar issue: there was a special search for an organization, and when you clicked on a search result row, a pop-up window was opening up with the details. That popup window was usually at the right hand screen while they used the left hand (as far as I watched them)

The problem was that it was awfully slow, taking more than 2 minutes to load the results.

As a UX designer and software architect, my job was to come up with a performing, easy-to-use solution.

We had web technologies, and the problem with pop-up windows is that they take enermous computation effort (and therefore: time) to open, always making the application sluggish.

So I designed a slide-in right hand panel instead, which would slide in whenever they clicked something, you know, just as an alternative test. I said, "we can make this a popup window, I'm just curious about your opinion on this". And they said they hated the popups and they find this version much more handy. All people participating in the test said this.

I'm not saying that popups can always be killed off, especially on a two-windows setup (far from it), it's just that in that particular case, the users felt more productive with the slide-in version, for which they didn't have to wait.

(Of course, that 2 minutes was also brought down to a mere 250-350 miliseconds, but that's a different story)

Watch what do they use the second screen for. There, they used it to watch communication mainly, they've got a lot of requests (more than 1 / minute) in e-mail.

Although responsive layouts have not started flying high enough within enterprises, its definitely picking up. Coming to your problem statement - if you are trying to decide between, a modal window or any other interaction, Aadam gave a really comprehensive answer which you have also chosen as the best answer.

Responsiveness and the effort needed to implement it will be justified if you target to make the whole app render seamlessly across multiple devices. In this instance, where your only requirement is to make sure the interaction which requires 2 different section to be involved, i would recommend you try using a customized solution like making the map float around, so that it can be positioned on the dual monitor space (setting it by default to the right most end or any suitable position will also improve the usability). Make the screen fullscreen, try implementing any keyboard shortcuts, try out innovative ideas like this. :)