That 1 Special Category



  • This is a long one.

    My company uses a third-party SAAS vendor to provide a special kind of search function to the users of our website.  This online system (LAMP-based) allows users to select any particular products and view related information.  The related information presented to the end user is based on the proprietary linking algorithm developed by the vendor, and the system is hosted on the vendor’s web server.

    I was first introduced to this software when my co-workers were complaining to me about invalid searches.  I decided to take a look to see if I could figure out why this was happening.

    WTF #1:  In order to do a search on a specific product, rather than typing in a name to search, select from a category, or use some other sane method, the system requires users to select 1 range parameter, the category, then the specific product from a giant, un-ordered, drop-down form element (1,000+ entries).

    Note:  Neither the first filtering parameter or the category selection has any effect on the drop-down list of products.  This means that if the user doesn’t already know what the range and category of the product is ahead of time (which the vast majority of users don’t know), then the user’s search will return 0 results.

    Further, the only way to reliably get any results at all for a specific product is to iterate through every possible combination of range and category (there are 90 possible combinations to search for).

    WTF #2:  If results are found, the user is told so with a single line of text.  To see the results, the user has to click on a link.  That link takes them not to the results, but to a form to select their country & state.  Once they choose their country/state (again, form a single drop-down), they can then finally see the results – provided there are any results.

    Rather than asking the user to submit their location in the initial search, and then immediately showing the results or a message that there were no results, the system first tells the user that there are results, and then makes them narrow down the location, which may very well have 0 results – wasting the user’s time.

    WTF #3:  Since a single product may fall under multiple categories, and have multiple ranges, if the user wants to find data for a single product with different criteria, they must go all the way back to the first screen and repeat the process.  

    The system is set up so that every time you go back to the initial search screen, your prior selections are erased, forcing the user to reselect everything (including finding the product in the giant drop-down, and then re-selecting your state/country).

    WTF #4 through ∞:  After doing some digging, with a little help from FireBug, I got to the root of the problem described to me by my co-workers (perhaps TRWTF was that they didn’t have a problem with the rest of the system).

    The issue was that if you searched for a specific category 1 time, every subsequent search would only ever display results for that category no matter what else you selected or searched for.  In addition, searching for this category removed the screen which asks users to narrow results by their state/country.  So, if a user searches for data under this category even 1 time, they would never again get results for any other category until they closed the page or their browser and re-opened it.

    Looking at the HTML, I saw that the system used a chain of hidden form elements to pass data from page to page, along with PHP session data, and JavaScript tying together certain functions.

    I went through several searches, looking at how the hidden form data changed.  I discovered that when doing a search for that 1 category, the hidden form element “stateID” was filled with an ID number that did not correlate to a state/country.  For that 1 category, the designers treated it like both a state and a category.

    Since the actual state selection screen was two pages away, they stored it into a session variable, which was then echo’d out into a hidden form element on the second page (I don’t know why – but I think it’s safe to say the developer(s) didn’t understand how session variables work).   So that when you clicked on the link to be taken to the third screen, where you would select your state/country, the third screen would see that stateID submitted via the hidden form from the previous page and automatically redirect you to the fourth screen, which shows the actual results.

    The problem was that this session variable was persistent, rather, it was never unset.  On the initial search screen there was a hidden form element called “stateID”, which PHP fills with the session variable once the user goes back to it.  As long as the form is submitted with stateID being non-blank, it will execute its search ignoring the category actually selected by the user.  So, when the stateID was set to that 1 special category, it would always display results for that 1 special category which simultaneously acts as both a state and a category, overriding the typical application logic.

    You might be thinking “if it stored the StateID in a session variable, why did users have to go back an reselect their state every time they executed a search that wasn’t for that 1 special category?”.  The answer to that is:  the system would only ever store the stateID for that one special category, and never for any other state/country.

    So, when searching for the 1 special category (which overrides state selection), you were stuck with it until you closed and reopened.  But, if you searched for anything else, you always had to reselect your state every time, because the designers didn’t implement persistent stateIDs for anything but that 1 special category, and they gave the user no way to change it.

    Of course, the simplest fix would be to get rid of the chain of hidden form elements and session variables and simply put the state selection drop-down on the initial search page – brining the four or so page search system down to just two pages.  Since I didn’t have access to the actual files, and I can’t communicate with the developers, I had to come up with another solution for employees to use internally.

    And the fix was very simple:  I created a bookmarklet that simply erased the contents of stateID on the initial search page, and users are no longer prisoner to That 1 Special Category.



  • Have you considered if it would be worthwhile to create a simple external page which set/reset all the necessary variables, with a friendlier interface?

    EDIT: ok, just read the other thread. I hope you're going to ditch these guys.



  • This is some true WTF-worthy stuff here.

    My reaction to the story, as I read along, went something like this:

    Wow, thats kinda silly.

    wtf?

    wtf!

    WTF???

    WTF?!?!?!?!

    ARE YOU F'ING SERIOUS?!?!?! WHAT THE....


    Yeah, I react in caps. Ask any coworkers.

    Outstanding WTF story.


Log in to reply