Making the Vino App with ChUI: Part 2

chocolate chip UI


In part one about making the Vino app, we introduced you to Vino, a reference app we created which explores the wines of Northern California, borne out of Sourcebits dual passion for innovation and nearby Napa Valley. Our goal with Vino? Create a template for anyone else who wanted to follow in our footsteps and play with ChUI’s abilities on their own.

Previously, we addressed (in detail!) the first 6 major parts of the workflow we used to create the Vino app and explained how we incorporated ChUI. In this second post, we share a comprehensive look at the finished Vino app and the next 6 steps in the workflow: the detail view, the bottom toolbar, data binding for range input, search results, and payment workflow.


The Detail View

With the horizontal scroll panels up and running, it was time to make the panels tappable and lead the user to a detailed view of the tapped wine. We’ll need one template for the list in the article that will hold the wine’s details. The H1 and H2 will get their contents updated at the same time. But before we can render the template for the wine, we need to set up the tap handler for the carousels so that we know which wine the user selected.

Bottom Toolbar

The bottom toolbar has two buttons, one to show info about the app and another to show a search sheet. We decided to have different controls in the search sheet depending on the size of the phone, therefore we need to test the dimensions of the device at load time. To create the search sheet, we need several different templates because we will be assembling pieces based on the size of the phone. This complex assortment of templates and size checks gives us the best screen use for each phone size. With this method, we can now create the search sheet and populate it.

Data Binding for Range Input

Since the search sheet has a range input to indicate the price range, we can bind the value of the range input to the price label above it. The sheet’s navbar template has two buttons, one to cancel and one to perform the search. To enable the cancel button, we attach a handler to it. To perform a search, we need to create a handler that will check the current values of the selected sheets, segmented controls and range input in the search sheet and use those to filter down the available wines. When the user interacts with the select lists, segmented controls and range input, their values are updated on that object. We access those values to filter the wines. After the user taps the search button, we also need to close the search sheet, then navigate to the results page. Before we output the result, we check to see if there was a match. If there’s no match, we let the user know in the results page and encourage them to go back, change the parameters, and try again. It is possible to choose parameters of type, body and price with no search results.

Search Results

The list created from the search results is a typical iOS navigation list. Tapping an item will take the user to a detail view, the same detail view we created earlier. Since we are back at the detail page again, we can move on to navigating.

Back to Detail Screen

To go to the detail page and show the selected wine, we have a handler which identifies the selected wine, filters the wine data down to just that one, goes to the detail page and publishes a broadcast with the selected wine. Since it publishes the same channel that we defined previously to show the detail for a wine selected from the carousel, we do not need to do any more to render the chosen output.

Payment Workflow

We want to enable the purchase of the wine by tapping it. Before anything happens, we want the tap to pop up a dialog that notifies the user that he or she is about to buy an item and also show its name and amount. The actual purchase process has two stages. The first stage shows a progress bar indicating how much time is left. When this finishes, the user is presented with a message indicating that the purchase is complete. Tapping “OK” will dispel the purchase sheet. Below are images of the process:


The template for the purchase sheet will enable this two-step purchase flow. But the handler should also do some clean up, setting the progress and confirmation panels back to their original states for the next purchase.

What we learned:

As we mentioned in our first post, gathering all the data about the wines was actually the hardest part of this whole experiment, and the process flowed much more smoothly after that was accomplished. With all the data collected and the design features clearly defined, we were able to start building the app fairly quickly. As our work proceeded, we made various adjustments to accommodate changes in the process to keep the Vino app on track. We’re very proud of our final effort, which we hope will encourage you to explore the awesomeness of ChUI on your own. Try Vino here.

Piotr Gajos, Chief Innovation Officer

Piotr is Sourcebits Chief Innovation Officer. A 2006 Apple Design Award winner, Piotr draws much of his inspiration from film and music, and focuses on leading our Innovation Strategy Workshops, generating new ideas for Sourcebits, and consulting on projects.