Friday night coding

This evening I decided to stay home and hack around with some KitchenPC code, as I’ve neglected to really do much in the technical realm lately.  What better way to get back into a coding groove than to implement a few features that have been requested by real-life users?  I had time to address three of these issues, and figured I’d write a bit about each before going to bed.

Calendar Scroll Back

A problem with the calendar, as voiced by at least two people, is you can only scroll forward in time but not backwards.  Apparently, people want to scroll back in their history to see what they’ve made in the past.  Sometimes, people just want to jog their memory of what they’ve eaten recently, or perhaps send a recently cooked recipe to a friend.  Other people might forget they had something planned even though they purchased ingredients for it, and have to scroll back to see.  Whatever the reason, it was a great example of a bad assumption on my part during the initial design.  I had even gone out of my way to add explicit code to prevent people from scrolling back earlier than the current date, and toggling the visibility of scroll buttons based on the current date range.  The lesson learned is not to limit your users through arbitrary boundaries that have no technical or business justification.

Total Result Count

See? KitchenPC has plenty of chicken recipes!

One of the comments from the UserTesting.com video was that my site doesn’t contain enough recipes.  While this is probably a valid opinion, I believe the impression the tester got was skewed due to my search result limitations.  I limit the results of any query to 100 recipes so as not to generate too much HTML or too much data being serialized across the wire.  While the ideal solution is to implement paging, this seemed not necessary for an MVP as most users never bother searching past the first page of a search engine.  I figured they can just narrow down their search criteria easier than digging through 100 recipes to find what they’re looking for.  The drawback of this approach was exemplified when the user commented that my site apparently only has 100 chicken recipes, when in fact I have easily fifteen times that amount.  The fix was to publicize the actual database count of the query, while making it clear to the user that only the first 100 matches are being displayed.

For those who care, I ran across a great PostgreSQL function called OVER() that allows me to very easily get the total database count even when using a LIMIT clause in the query without having to return multiple tables.  This made it incredibly easy for me to gain access to this data and include it in the UI.

Sortable Results Page

Another comment on the UserTesting.com video was about the arbitrary way recipes were displayed.  In my defense, the results were sorted by rating; it just happened that nothing on that page had been rated by any user yet.  There was no UI indication that any sort order was applied to the results, and the user became frustrated scrolling through the recipes trying to find what she was looking for.  Well, not only did I fix this by adding sort direction arrows to the page, but I added the ability for the user to toggle both the sort column and sort direction by clicking on the column header.

Chicken recipes ordered by descending cook time

Allowing the user to sort the results allows them to easily locate the recipes they’re interested in.  It also provides the secondary benefit of allowing the user access to recipes that might have not been otherwise displayed.  For example, if the user searched for “chicken” and got all 1,500 results, they would only see the top 100 chicken recipes with the highest rating.  If they then sorted the results by prep time, they could then see the top 100 lowest prep times regardless of the rating; in other words, I sort the total result set and not just the recipes displayed on the page.  True, I have to hit the database again to re-sort but I figure it’s a pretty good solution while I have a relatively small amount of data in the database.

So, not too bad for a Friday night eh?  I’m planning on round 2 of improvements this weekend, as this will hopefully pave the way for some major feature redesign coming up in the next few months.  Stay tuned!