I am developing a mobile app that offers a GIS utility. As such, the main feature of the app is a map and a graph. In order to run the utility, the user must input 2 locations, i.e. a start and an end. In this application they are called 'Observer' and 'Target'. The user must input both locations before hitting "run" and getting a result. This is similar to getting directions in a GPS app, except that I would not assume that one location is the user's current location. (I do want to enable that capability though.). The 2 locations can be entered out of order, but both must be present before being able to hit "run".
Entering a location for an Observer or a Target is identical, but both offer some options. I would expect average users to want to be able to either:
- Search an address / location
- Input GPS coordinates (latitude / longitude)
- Use the map to drop a pin
- Choose their current location for either the observer or target
So for both steps, I have 4 potential inputs. So I have a semi-sequential, repeated, nested form. Once the user completes and hits "run", a third step will open with the results.
Option 1:
My first design looked like this:
This is a visual representation of what I had described. I used tabs to hint at the non-sequential nature of inputting Observer vs Target, and within each tab, the user can select one of various ways of specifying a location. Once Both inputs are valid, a "Run Analaysis" button appears on top of the bottomsheet, which would grab the users attention and allow them to run the analysis.
The downside of this is that all 4 options for location input are jammed into one bottomsheet. They're crammed, and it doesn't leave much space for extrapolating on the search or coordinates concept, and the map is half covered.
Option 2:
Instead of using the tabs for choosing between observer/target, I use them for choosing an input type:
This forces a directionality to the steps which I think is still intuitive, i.e. input Observer -> input Target -> run analysis. Using the tabs for each input type gives me more space in the bottomsheet, and still saves me more screen real estate for the map. An added bonus is that the "search" tab has more space to include options like "use my location".
Option 3:
In the first case, having the button above the bottomsheet made sense because it only appeared once the form is valid, and is therefore more likely to grab the users attention. In the second case, it seems less needed, and obscures more of the map. So a version where the "navigation" buttons are on the bottom made sense:
I plan on adding some chevrons to these buttons (< & >) to reinforce their back and forth nature.
What is the best approach here? Does it make more sense to have the "first level" tab be which location the user is inputting for, with the input choices crammed, but clearly laid out, in a single tab? Or is a sequential approach more intuitive, where the user must focus on one step at a time, and one input type at a time, but there is more "breathing room" on the screen for each? I am leaning towards the third iteration, but I am not a UX expert.
