PLEINA – PLAN YOUR PERFECT DAY With ai

Live PRODUCT site hosted at >>> www.pleina.io

Pleina is an AI powered planner and navigator created with the intent of making people’s real environments more accessible and interactive. Pleina would eventually open up new possibilities to users everyday.

I started with a general mission, I wanted to break people out of their everyday routines and enable anyone to live out their fantasies through some new kind of system. I was bothered by the seeming lack of variety in my life. I mean, how many options do we really engage with? How could we motivate to constantly discover all of the wonderful things we know are around us, and how could we possibly find the energy to constantly plan new and exciting routes for ourselves through our environments?

THE PROBLEM:

“how would I design a technology that Opens up users’ environments, and urges them to explore them, without triggering decision fatigue?”

I was worried that with a barrage of options came the same kind of avoidance patterns I was trying to combat in the first place. An example of this would be users who eventually fall into the pattern of always checking the same site for news updates, instead of search the myriad of options available on the web.

I initially debated two forms of solutions to this problem:

  • I could try to design VR software which playfully enabled users to digitally explore new environments and discover new kinds of user generated places.

  • I could design an AR solution via Swift and utilize mobile infrastructure to open up peoples’ existent environments through generated routes.

I went with the latter, practically creating a digital entryway into the real world through AI curated experiences.

Here’s why:

After conducting interviews with prospective users I realized that the barrier to entry for quality engagement with VR was too high. I wanted to avoid a system with limited participation and for a quality experience the VR system would need community generated maps. I wanted anyone to be able to create and share memorable custom experiences and I found through external research that in digital environments users with many preexisting map options would often fail to contribute to the map collection themselves. I didn’t want to create a system with star users carrying the entire community.

On the other hand, my prospective users voiced massive support for mobile. I identified a few major wins for the approach during the interviews:

  • Mobile technology is accessible when compared to VR.

  • Users were likely to use their phone to entertain themselves when they were bored over directly starting any other specific task.

  • Users were excited about the prospect of learning more about their cities in person (GPS made this possibility convenient on mobile).

  • Users were generally more willing to try something new that was specifically recommended to them over a more general recommendation.

After the interviews I began researching possible mobile solutions…

All it takes to make a truly standout experience is a little creativity and a willingness to try something new. The issue is getting users to discover that perfect new thing in their area without excessive burden placed on them during the discovery process. My attention began to turn to AI agent frameworks which were proving to be effective goal oriented problem solvers. This burden could be partially lifted by a this kind of system, and here’s why:

  • An AI agent could be trusted to be consistently new in its offerings

  • An AI agent could provide content for users with limited user input.

I decided to build an AI navigation and discovery tool which generates itineraries (or step-by-step routes as we will call them from now on) for users, based on a general request or narrative prompt. But AI was like a prodigy child. Someone with so much potential, but an utter lack of personal style.

The Problem: Give AI Style (personalize it)

This was near the beginning of 2023. I saw AI frameworks like LangChain in their infancy. I was stunned in particular by LangChain’s potential for reasoning through complex multi step goal oriented tasks and coming to cogent audited solutions.

Any of the major OpenAI models could easily make a general itinerary for a trip, however, AI struggled to create truly personal recommendations as if they knew you. This was demonstrated by the use of the first Alpha version of Pleina which lacked a user profile.

Fig. 1a initial mockup of main page

Fig. 1b final main page after development

Once I gave my app testers a demo version of Pleina, which was a simple stripped down version of the main page (fig.1a), I came to my first major development phase problem: at the end of the day AI models aims to please the largest pool of people, it was naturally opposed to personalization without excessive prompt sizes.

UI – MAIN PAGE

When working over revisions of the initial main page mockup I discovered two issues

  • The buttons needed to be reworked, the action-bar did not provide enough real estate for natural user interactions

    • So I updated button sizing and optimized touch target placements to assist users in app interactions.

  • The data output of the app was complex, was information dense and it was an itinerary. The design did not adequately respect the kind of data it was handling.

This was a guiding consideration in the design process: I needed to design a UI which could display and facilitate interaction with location based itinerant data.

The main screen of the app is where users enter their prompts and where generated routes are displayed. The majority of the screen is occupied by the AI generated steps in a to-do/notification style. The steps are styled and designed as “things to get to”, “things to do” or “things to check in on”.

Users can mark stops as completed with the check buttons on the right of each step (fig. 1b).

This functionality evolved from the initial design and replaced a clunky two-step “bulk edit” method which was toggled via a button in the action-bar. The update made the interaction easier for users and more appropriately handled Pleina’s step data. By changing the way users marked tasks as completed, the data no longer felt like backlogs of outdated info which needed to be updated in bulk. I was originally hoping to save room for text by moving the completion action to the action bar, however it was difficult to use and felt more like a data sheet interaction than a to-do list one. I ended up deciding to allow the steps to have as much real estate as they needed.

By allowing the steps to be more verbose and take up more space I was able to create a natural useful look which proved more helpful to users on the go than the initial mock up.

The decision to reveal the address of steps on the main display (fig. 1b) emphasizes physicality. Pleina is meant to bring users into the world and not create hypothetical situations, so the display of addresses reinforces the primacy of the physical and informs users upfront of stop locations. Originally a step’s address would be revealed when the user tapped on that particular step on the main page (fig. 1a).

When a user taps the address link on wither design, turn-by-turn map directions are engaged in-app. On the updated design a user can also open a top down “survey map“ with their generated stops pinned with the map button next to the star (fig. 1b, fig. 11a).

Fig. 2 Final main screen toolbar

The final action-bar (fig. 2) is the place where users manipulate the category, display, and generation of routes. The buttons on the right of this toolbar (the map and star) control step-relevent transformations. By step-relevent transformations I mean processes which move or display the route to or in new informational categories (as map points or as favorites). The buttons to the left alter the generation or display of steps on the main page. The division of this toolbar was meant to make the app more intuitive through separation of actions into groups with directly linked or conceptually linked functionalities.

THE SYSTEM

What I had tried to do initially was to tailor the model using a hulking system prompt which would give it its directive. The system could self prompt, was goal oriented, and would output a final result, so I thought I could make it wise enough to interpret prompts effectively. My first attempt yielded moderate success. Generally, Pleina’s outputs responded well to the user’s prompt, and were formatted correctly. The results were beyond the base line of Chat GPT inquiry, but they weren’t consistent and depended largely on the compatibility between user and system prompt.

When I lacked a profile page the best I could produce was a very quirky machine via system prompts, Pleina lacked specificity and a respect for the views and beliefs of my total user population.

solution:

  1. Feed the AI user profiles.

  2. Give the AI access to real time data and self directed research on the internet.

What the AI did not lack was sheer informational capacity and inhibition. These were two things that made AI, in concept, perfectly suited for instructing us on how to accomplish our goals, make our plans, and realize our fantasies.

Fig. 3 final profile design

RESULT

With the inclusion of user profiles users started having more fun with the kinds of prompts they were entering, because the system could respond to them as unique and complex individuals.

You could even make ridiculous situations actionable. What if they wanted to be a vampire? Well, now Pleina was taking a profile which indicated a user was a vampire and was recommending this:

  1. That they should stay indoors until sundown

  2. That then go out for a vampire friendly evening of red wine (like blood) at X location

  3. Have a vampire friendly meal of sushi at X location

  4. Go dancing at X club

  5. Go for a long walk at X

Fig. 4 early “vampire test“ output before output was refined to be more accurate.

This leap was a major win.

Results became specific and personal and, for example, instead of telling a user who loved Techno to go to a “Electronic music show in their area” Pleina started to find events and DJs who were playing that week, or that night, in the user’s city and added the specific event to their itinerary on the main page... maybe after a dinner.

Fig. 5 AI result generation data model

DATA MODEL – AN OVERVIEW

The user creates a profile which is stored in Google Firestore along with the user’s past “Saved Routes” (this is all the data which needs to be saved for future sessions), this data is downloaded from the cloud and stored locally, populating the “Profile” and “Saved Routes” pages whenever a user logs in. When a user submits a prompt, Pleina sends the prompt along with the now locally stored profile as JSON data to the AI agent: a TypeScript document hosted as a Google Firebase Function connected to the Pleina project. By saving the data locally to the client device I managed to save on potential costs by limiting calls to the cloud service, and allowed the system to run faster by cutting down on unnecessary network calls. When profile or saved route content is altered locally the client sends the updated information to Google Firestore. The call from the client device to the AI TypeScript function triggers the AI chain on the Google Firebase server, and the AI begins self prompting and conducting self directing internet searches when the agent deems it necessary. Eventually the agent  decides it has come to a satisfactory conclusion and sends the final result as JSON formatted data back to the client device where it is parsed into variables and displayed on the main page and the map. The AI process is scalable because of Firestore’s ability to duplicate and run hosted functions simultaneously.  The steps of the route are variables connected many-to-one to a unique route ID. 
The user can then save the route to a Saved Routes page if they particularly liked it, or if there was a stop they would like to revisit one day. The saved routes preserve addresses and map functionality. 

Fig. 6 notes taken after exhibition

THE EXHIBITION –

I first publicly unveiled Pleina in an alpha stage at an exhibition at UCLA, where I collected information on how user’s interfaced with my app and conducted interviews with users directly there on the exhibition floor.

It was because of the information gleaned in my exhibition interviews that the saved routes page was made.

I was hearing many positive responses to the application. However, a demonstrated need emerged after users voiced some disappointment during interviews that the routes they generated couldn’t be saved. I needed an accessible and helpful user-interactive data storage solution.

  1. How could I make users’ experience of their routes lasting?

  2. How could i respect and reuse the data users production? (this is a big questioN!)

Fig. 7a (left) first screen on saved routes. fig. 7b (right) detailed view of a saved route

UI – SAVED ROUTES

The Saved Routes page was developed as the solution to these problems. The data Pleina generates is personal. Its users’ real life journeys, something deserving respect. This leads me to our big question surrounding respecting and reusing user data. So often user data goes nowhere, it just kidn of floats away, or is stored on a far off server, or it is sold from under the nose of the user. I was delighted to find a way to repurpose user data into a useful and satisfying tool.

I decided to respond the personal nature of this data by crafting a fluid interface of postcards with sliding transitions, documenting user travels. All pages within saved routes, including the survey map, can be dismissed with swipes. Each page slides over one another and when searching through saved routes this sliding feels organic – zooming in on the past and revealing particular memories. The fluidity of the swiping motion and the intuitive logic of a stack makes interaction natural and lightweight. The design of the cards was to evoke the sense of revealing memories like we do with picture slides and postcards. In this way the design subtly evokes and builds upon preexisting mental models.

Fig. 8 design ideation process for saved routes page implementation

The planning stage for saved routes included charting the path from where we started from to the newly planned implementation. Originally I had a simple saved routes page flow. After the exhibition I was able to regroup and come up with a new implementation. When working alone I often create modules like (fig. 8) where I work through ideas, and decide on next steps.

The exhibition gave me the chance to float some more questions about loading times and menu styles.

After the exhibition, I work-shopped a bolder interfaces with custom icons for the menu (fig. 10) and crafted a captivating loading animation (fig. 9b) which received astonishing amounts of support form users who had waited through the original animation. The new animation was mesmerizing and kept users informed that their info was processing.

Fig. 9a original animation

 

Fig. 9b updated animation

During the most recent round of interviews users voiced that the new animation drastically diminished their sense of waiting. Users were now more satisfied looking at the animation during wait times.

The menu design with its revolving icons was chosen to add a forward movement and dynamism to the app’s design whose purpose is to facilitate movement and exploration.

Fig. 10 main menu collapsed and expanded on main page (top) and saved routes page (bottom)

 
Waiting times were at time of the exhibition upwards of a minute after prompt submission. This was the time the AI agent took to generate a response and send it back to the client. Later in development I was able to cut this upwards of 60% through reworking the TypeScript code, cutting down on max iterations, and updating the AI to a more advanced model which was about to receive a price per call cut. 

Fig. 11a survey map with active route stops pinned

Fig. 11b turn-by-turn navigation view

UI – THE MAP

Users can explore a custom interactive map with their generated stops pinned. The pinning of stops was introduced to add fluidity to the UX between the steps popping up on the main screen and the turn-by-turn navigation functionality which Pleina provides through the Mapbox API. Originally the address links on the main screen linked directly to Mapbox turn by turn directions, which directed to the address the user clicked. The original address functionality remains providing an information primary view for users. However, sometimes users are more concerned about location and proximity and wish to orient themselves through their journey that way. The survey map provided this option for users. Users could now preview where each pin for each step is in relation to one another and to themselves. Users can tap these pins to get reminders of what the stop is, or, can click a pin and then a “navigate“ button to initiate directions another way. This revitalization of the map was a major breakthrough adding a convenient and informative flow between output and navigation.

The update would recenter relational physicality, something which aids a deeper understanding of one’s environment. This is critical to the Pleina purpose.

THE COLOR SCHEME

The color scheme of the app, was chosen to be like a blank slate filled with the journeys of the user – their activity. The emphasis of light airy design was also to balance the fact that the app’s output was information dense. A busy screen was less ideal for this case than a modern approach which allowed users to go explore information without overwhelming the senses.

Fig. 12 Pleina logo

 

Fig. 13 Pleina naming breakout session

THE LOGO

The logo for Pleina is a reference to the eye from the icon for the Bauhaus design school out of early 20th century Germany, which attempted to unify the individual vision of the artist into the functional reality of life. I believe it to be a fitting companion for Pleina, which is made to incorporate the complex individuality of the person into a near-endless multitude of real plans for their life.

THE NAME

Pleina is a portmanteau of the french phrase “plein air“ or “en plein air“. In context this usually refers to a style of painting which happens outdoors/out of the studio. I decided on the name because Pleina was meant to bring users out into the world through the AI’s collaborative composition which is the route.