Date Slop: building a deliberately bad UX with AI

A while ago, the author entered a Bad UX competition, where the prize went to the worst date-picker. The author then polished the date-picker and made it safe to release to the public, despite not winning the contest. The idea behind the project was to parody a future where AI assistants are so widespread that they become a hindrance rather than a help to the user.

The date-picker form element was intercepted by a bot that insisted on entering the date for you and needed to establish the user's date of birth through tedious questioning. The assistant refused to simply accept the date when told directly.

The author faced several challenges while building an AI-powered application for the first time and using the OpenAI API. The initial architecture involved intercepting the date-picker form element, starting a conversation, and storing the conversation history in memory. The client made a request to initialise the conversation when the user focused the date field, creating a chat session in application-server memory and sending an initial request to OpenAI.

The assistant's first response, containing its greeting and opening question, was returned to the client along with the session ID. Each new OpenAI request included the accumulated message history.

The author learned several lessons during the project. Cold starts were a challenge as the assistant would take a while to "wake up" if a user tried the demo after no-one had used it for a while. The solution was to trigger the serverless function in the background as soon as the app opened, ensuring the initial greeting and question would be fetched by the time the user opened the conversation dialog.

The author also faced challenges in getting the prompt right, as the LLM would occasionally accept explicitly stated dates and ask uselessly vague follow-up questions. The final lesson was not to keep conversation state in server memory, as this could lead to in-memory session state growing indefinitely and causing issues with the UI. Instead, the conversation history should be stored in client-side application state.