Listing form

Requirements

This project was self-initiated. My intent was to demonstrate the improvements we could make to our members’ experience when they're ready to enter a new property into our central database. (At which point the property typically becomes available to the general public.)

Agents currently have two choices: fill out a six-page PDF document—which must be emailed over to us—or enter the property details online through MLS software we license. The latter might seem to be the more appealing of the two, but it comes with its own shortcomings.

First and foremost, the MLS software doesn't have a responsive interface. When visiting the site from a mobile device the regular desktop layout is always presented. Secondly, even to look at it in isolation as a purely desktop-based experience, it hasn't been well thought out — the interface is clumsy and difficult to navigate. The clearest way to describe it would be to say it feels generic, likely the result of it originally being created for financial software more than a decade ago. Both of these shortcomings have a significant negative impact on the member experience.

So, how to address this? I envisaged an entirely schema-driven form: the structure, data and validation all living within a single JSON file, to be assembled into an approachable and intuitive interface by a modern JavaScript framework. The advantages would be threefold: members would receive a modern, mobile-first solution with which to enter their listings, one consistent with our branding; we would gain an additional way to differentiate ourselves from other boards in the area, an especially important trait when considering potential members living just outside of our jurisdiction; and we would maintain consistency of member experience if we switched to an alternative MLS software provider in the future.

Process

Ensuring the viability of my idea before getting in too deep was paramount, so I initially limited myself to only building a subset of the first page of the PDF. Only once I was satisfied with how it had come together did I proceed to assemble the rest.

Vue 3 was my framework of choice, mostly because of my preference for the developer experience it provides. Nonetheless, this project could’ve been realised with React just as easily.

In an effort to reduce the time I’d spend designing each individual input component, I decided to experiment with the PrimeFaces UI library. In this way I was able to quickly grab their base components and make alterations as necessary. One approach I used a couple of times was to group particular inputs into single components where it made sense to do so. For example: radio buttons and checkboxes were a natural fit, due to the significant degree of overlap between their behaviours and layout requirements.

Challenges

One stands out in particular: the best way to capture the extensive information associated with each room, bathroom and open house entered for a property. Each of these objects are composed of several different fields and have their own limitations on how many are permitted. In the end I built a “repetition” component, one capable of instantiating new versions of its contents whenever the existing instances had been fully populated with data. I was pleased with this approach because it strongly promotes component reusability: anything could be dropped in going forward, with minimal modification.

I also ran into an apparent bug with one of the PrimeFaces components. I opened an issue on their repository but I also cobbled together a temporary workaround so I wouldn’t have to wait on them. If they’re unable to address the issue then I should probably revisit the workaround to verify it’s the cleanest approach.

Future improvements

This whole project was very much a proof-of-concept, and the design reflects that. Maintaining the layout as a single page was as much for my own convenience as it was a design choice — going forward I believe there would be definite benefit to be had from splitting the form into separate sections. Not only to reduce the intimidation factor when a user first arrives, but also to simplify the process of getting back to a field when you can't remember where it’s located.

Otherwise, there are countless other improvements that would naturally manifest if this were to become a fully fledged project: auto-saving for people who want to resume later, the ability to upload photos, hiding certain fields if they no longer apply (based on choices made earlier, for example). There are plenty of possibilities.

Having said that — the most sensible immediate next step would be to solicit feedback from existing power users, of both the PDF and desktop interface. Hearing their thoughts at this early stage would help inform our priorities going forward, strengthening our ability to design for the people we’re most looking to help.