Design Decisions - Search Functionality

 I decided to scrap the universal search bar I started with in favor of a more traditional interface.  The original design was one field:

I added placeholder text to give some guidance - "Chicago to New York June 1-7" - and initial self-tests proved fairly successful in extracting the right information.  The Natural Language Processing (NLP) library I'm using, spaCy, was able to recognize Chicago and New York as locations and June 1-7 as a date range.  Great!  That meant I didn't have to write code to split the text into separate tokens and do the matching work myself.

The trouble began when testing other use cases, like "Austin June 7." Without enough context, the NLP labeled Austin as a person and would miss June 7 as a date.  Even "Austin, TX June 7" proved problematic.  The NLP returned a person (Austin), location (TX), and date (June 7) as labels.  It's not inconceivable that someone named Austin could be in Texas on June 7th, so the labels make sense, even if they're not obvious, but, either way, I had work to do.

I can't reasonably expect a user to enter "Austin, TX"  instead of just Austin to try and force a location match.  So, I started writing code to get around the NLP's limitations.  This quickly grew into a bigger project than I anticipated, leaving me with three options:

• Farm the processing work out to an LLM like Meta.ai or ChatGPT via an API call.
• Write the code to process the text myself.
• Create a more traditional form that doesn't offer the same unified experience but doesn't violate users' expectations and is easier to parse.

I tested farming the processing work out to a bot, and it worked like a charm.  The problem is that, in doing so, the cost would be variable - every search would need to call the LLM and therefore up my usage of the API and my ensuing bill, or would be fixed but high.  I'd need to procure sufficiently beefy hardware to run the Llama-3 model on my own.

In reality, neither of these is prohibitively expensive assuming I have sufficient user traffic to offset the cost - about $600 a month if I were running the hardware full-time on Replicate (and cheaper with less traffic).  But, I don't expect to make a cent from this, so I can't justify spending the money on the simplest solution.  If I expected to make any income from this - or if it's a loss leader when I make income elsewhere - this is the way to go (until I run into the next snag that I haven't even thought about and need to write another mea culpa article about why I'm changing strategy).

That leaves me the option of writing the text processing code myself or splitting the fields up into a more traditional scheme.  Since the more complicated form isn't so hairy as to confuse the user it's probably the better avenue.  Everything is just simpler.   

Writing my own logic isn't unreasonable, but it takes more time and is more error-prone.  Again, if I were expecting to make money and did the research to assume that a simplified form would lead to higher conversion rates, writing a custom solution would make sense.  But, given my limited time and information, I have to go with the least imaginative solution (which isn't always a bad thing):

I'm still concerned that my search bar may be too clever by half.  I try to reduce user surprises by employing autocompletion in the relevant fields for the possible destinations the site offers, but there are still some lurking quirks.

According to the design in my head, if the user only wants to book a hotel, they'd enter a location in the center box, but I can't expect that scenario to be intuitive, so if there's a location in either box, I'll assume the user is only interested in booking a hotel and act accordingly.

If it's two locations, I'll assume hotel + flight.  I'm expecting the user to take a leap of faith and tell me they want more options (e.g. they only want a flight or they want a different traveler count) after clicking the search button.  The worst possible outcome is that they expect that information to be present at the beginning and abandon the site after searching fruitlessly for fields I've placed elsewhere in the path.

The alternative is to add checkboxes for flight only, hotel only, or flight and hotel and block out the unnecessary fields based on what's checked.  Or...I could write a series of short forms prompting the user for more information at each step.  

I queried both ChatGPT and Meta.ai about the multi (short) and complete (long) forms and they both responded with solid pros and cons (probably because their responses agreed with my sensibilities) - Namely, that this current form isn't extremely complex, so users can handle the aggregate information rather than requiring a guided questionnaire.  

I'm also expecting users to quickly become power users after a couple of interactions, and a guided form would immediately annoy them with too much boilerplate.

Ideally, I'd run this through focus groups and or A/B testing to determine the best interface, but, for now, I'm basing the design on tradition, some intuition, and a belief (yikes) that others' thought processes follow my own.

Until next time my human and robot friends.