Cross-platform functionality is a core value of the Reonomy UI team.

Once upon a time, we had the freedom to build our product from the ground up. Anyone who’s done this knows it’s at once exhilarating and stressful.

You have big decisions to make that are going to follow you for the life of the product. Even if you dramatically refactor, the ghosts of these decisions are going to follow you around in the code somewhere.

For a more detailed introduction of the Reonomy product, read on here.

After much deliberation, we decided to build a responsive site (as opposed to separate mobile and desktop templates). One of the primary features of our UI is a search form with multiple dropdown menus. We set some goals for what this experience had to be:

  • Mobile first.
  • Fully functional from 300px width (a small handheld device) to 2,560px width (a 26 inch monitor).
  • 100% keyboard accessible.
  • HTML5 input type support

Dropdown menus in mobile are a dicey subject. A simple html select is handled beautifully on modern mobile OS’s, but our dropdowns contain multiple fields, including input ranges, checkbox lists, radio buttons and date-pickers. We knew what this should look like on desktop, but were struggling to find a pattern in the mobile html world that suited us.

Search Form Desktop Dropdown

Our desktop search form is a set of dropdowns with multiple form elements inside.

Search Form Desktop Dropdown With User Input

As the user types the form dynamically updates to reflect if the data is valid or not.

All the patterns that involved a dropdown menu with multiple inputs in mobile were ugly. There’s a bevy of issues related to vertical scroll. The user can scroll outside of the dropdown and not even know it’s open.

The alignment of the vertical scroll is off when you open the menu in almost every case, and trying to “fix” this with javascript creates even more issues.


Stacked Search Form for Handheld

On handheld devices the search form is stacked, making a dropdown a clunky experience.

We ended up doing what we usually do when we’re stumped for an answer: look to some of our favorite software.

Taking a step back and looking at some mobile apps made it clear, dropdowns are not the gold-standard in mobile UI. It became apparent pretty quickly that we had been thinking about the problem wrong. A few good rules of thumb when creating handheld UI (or otherwise):

  • Pair down the elements on the screen to just the task at hand.
  • Give all your elements room to breathe.
  • Let the browser handle styling (i.e. don’t write crazy js hacks to make the browser do things it wasn’t meant to).

What we needed in handheld wasn’t a “dropdown” at all. But a new “view” that only handled the tasks at hand. CSS offered us everything we needed.

We were using a simple expanded class to open and close our dropdowns. We updated that class to be position:fixed for handheld, and remain position:absolute in tablet and desktop.

sample less:

.dropdown {
display: none;

&.expanded {
display: block;
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
// allow the inner content to scroll if need be
overflow: auto;
// this gives us native momentum based scrolling on supported browsers.
-webkit-overflow-scrolling: touch;

@media(min-width: 750px) {
position: absolute;
top: 100%;
right: auto;
bottom: auto;

All we needed now was a little bit of UI to give the user some context on where they are, and an easy way to get back to the primary UI. We followed the standard pattern of a little close button on the top right, coupled with a “fat” close button on the bottom.

Effectively we added a header and footer to our dropdown content. Then we simply set them to display:none on the header/footer for tablet and desktop and have our simple dropdowns, same as they ever were.

Handheld Debt Input View


We changed the css for dropdowns on handheld devices so that they would appear as full screen views.


On desktop our form dynamically validates inputs and submits the form. In handheld we block the auto-submit functionality because of device limitations.

As such we needed the user to understand what the next required action is after they have entered a value.

The next step became apparent: Once content was entered into the form we needed an explicit “apply” button to submit the form, so there was no confusion on what would happen when you hit it. Naturally, a submit button should come with it’s cousin “clear”.


Handheld Debt Input View With Active Inputs

When a user begins to populate an input view the “close” button changes to explicit “apply” and “clear” buttons.


I wouldn’t ever argue an html site as a substitute for a native app, however I also don’t think “not being native” is an excuse for a sub-par handheld html experience.

Taking a step back and implementing native app UI patterns in our handheld html allowed us to create a smooth user experience.

We managed to avoid some of the unfortunate behavior that tends to be the hallmark of handheld html sites.

Unlock commercial real estate insights and opportunities with ease Start Searching

Related Posts