Le Wagon final project—Patched app

You have 10 days, a team of 4 junior developers and you need to design and build a functioning Ruby on Rails app

The Patched app on mobile

This was a 2-week final project completed while studying full-time web development at Le Wagon, Lisbon.

Before signing up to Le Wagon I had watched some of the demo days of previous batches. I had been blown away by what the groups had achieved. 10 days? A fully-functioning web app? Is this really possible?

Knowing that others had delivered great apps did not make the buildup to the final project any less daunting. The previous 2 weeks at Le Wagon had been an introduction to Rails. This involved us spending a week creating an Airbnb-esque marketplace (gnomify-project.herokuapp.com— a marketplace for garden gnomes) with our final project teams, and continuing to have lectures every morning. We’d had so much fun working together—I had a ball making musical buttons and animated rainbows!

Now, however, it was time to build something to reflect all of the coding skills we had picked up during the bootcamp. Scarier still, we were building my original brainchild, an idea I had pitched weeks before: Patched—an app to help first-time gardeners create their first vegetable patch. Things were getting real.

Planning

Thankfully day one of coding was not day one of preparation.

We had spent a full day at Le Wagon dedicated to product design 2 weeks prior. During this time we created a basic prototype together in Figma and ruthlessly prioritised what was feasible to build in 2 weeks.

How did we do this?
We got into our users’ heads.

Our first prototype—Patched app

Maria and João

My group was particularly imaginative in conjuring up the love story of our target user couple Maria and João. There was a lot of laughter but it was very helpful for making product calls. The team decided that the web app should be designed for mobile to truly fit into the use cases we explored. The core value of the app—advice that’s tailored to your garden—allowed us to settle on the information we needed to gather from users in the sign-up process. We focused on our users planting vegetables in raised garden beds (self-assembled) rather than accommodating different garden soil types—this narrowed our app’s scope further.

Team Patched’s visual ideas

Mood boards

Maria and João also helped us to decide on a visual identity for the app. Allocated class time was over but we went away and created mood boards to help decide on look and feel. We were strongly aligned on the vision being gender-neutral, unlike a lot of gardening apps currently out there on the market; we knew that Patched needed a broad appeal. I was amazed at how in-sync we were as a team on visual matters, and felt inspired to create the Patched brand.

High-fidelity prototype—Patched app

Prototype

We continued to work together on the flow of the app. I took all of the great ideas from our mood boards and morphed them into an identity for Patched. All of this work culminated in a final high-fidelity prototype, ready for day one of our app build.

Using Trello—planning and building in an Agile way

The build—Week 1

User stories

We wrote out all of our user stories (all the tasks a user needs to perform on the app) and planned out our database schema (structure) using an online tool to visualise the database’s tables and rows. We searched for suitable APIs to use for vegetable planting instructions but nothing fit the bill so we created our own spreadsheet and populated it with the relevant information.

Schema

We were very eager to get started but we still made sure to test our database using rails console --sandbox . We liked using sandbox to test out different ideas before committing to our final schema.

Seeds of seeds

To fit with the custom requirements of our app we populated the information in our vegetables spreadsheet as ‘seeds’ in our database and also set up Cloudinary so that we could host all the images of vegetables in the Cloud.

Now the vegetable data and images were living in our database and things were getting really exciting!

Authentication

I worked with my teammate to ensure our web app had the required signup and login security. We used the Ruby gem ‘Devise’ to do this, I then customised the app’s forms so that they were on brand.

Front-end foundations

My teammates tailored the app’s SCSS files to make our build as efficient as possible, setting up all colours and fonts as variables. This saved us a lot of time and made our code much nicer to read and collaborate on.

The build — Week 2

The core functionality of Patched

Ruby logic

All the foundations of our app were in place, but how was it actually going to work?

We needed to allow users to:

• See how many days to go until their vegetable seedlings should be planted in their ‘patch’
• See how many days to go until their grown vegetables could be harvested

Logic challenges:

• Different vegetables need to be planted at different times in the year
• Different vegetables take different amounts of time to develop
• The app needed to know when the user’s vegetables were planted or harvested

Solution—days until planting:

• In our vegetable model we created a global variable (an array of hashes) where we replicated the seasons, their lengths and their start and end days. Here’s an example for Spring:

SEASONS = [{name: ‘Spring’, start_month: 3, start_day: 20, end_month: 6, end_day: 1}]

• Next, to show the vegetable’s ‘days until planting’ we created a method which would be called if a vegetable was selected by the user for their garden patch. The method would register the start date of the planting season the vegetable matched with and the ‘date today’ (the date of the vegetable’s selection). The method would then subtract the dates to find the amount of days left until planting
• However, if the season had ended for the year, the method would start counting towards the same season in the following year:

if date[:start_month] >= today.month && date[:start_day] >= today.day
  season_date = Date.new(today.year, date[:start_month], date[:start_day])
else
  season_date = Date.new(today.year + 1, date[:start_month], date[:start_day])
end

• If the ‘days until planting’ equalled 0 then we would show the user a checkbox in the front end to register when the vegetable was planted:

<% if @vegetable.days_until_planting.zero? %>
  <% if params[:instruction_type] == 'planting' %>
    <%= render 'planting_check_box', crop: Crop.find_by(patch: @patch, vegetable: @vegetable) %>
  <% end %>
<% end %>

• Clicking this checkbox would also activate the vegetable’s ‘planting date’ and re-set the countdown process:

def planted?
  !planting_date.nil?
end

Solution — days until harvesting:

• In our Crop model (the model for the user’s selected vegetables) we created a method to work out the days remaining until harvest
• This method would register the ‘planting date’ and add the vegetable’s growing length in days (recorded in our database), then subtract this date and the date of ‘today’ (the date of the user’s session on the app)

def days_until_harvest
  harvest_date = planting_date + vegetable.growing_length.days
  [harvest_date - Date.today, 0].max.to_i
end

• When the harvest date equalled 0, the user would see a checkbox to register when the vegetable was harvested, return to the main harvesting page and trigger a congratulations popup to create an additional feeling of achievement for the user:

<% if crop.present? && crop.days_until_harvest.zero? %>
  <%= simple_form_for crop do |f| %>
    <%= f.input :harvesting_date, label: false, input_html: { class: 'd-none' } %>
    <%= check_box_tag :harvested, 1, crop.harvested?, class: 'd-none', id: 'planted_check' %>
    <%= link_to harvesting_patch_path(@patch), class: 'vegetable-card-checkbox-harvesting mx-3 mb-3 js-crop-check', data: { submit: "edit_crop_#{crop.id}" } do %>
      <span class="flex-grow-1 ml-3 font-size-h5">
        <%= image_tag("harvesting-icon.svg", class: "harvesting-icon") %>
        <%= crop.vegetable.name %> is harvested?</span>
      <div class="check">
        <%= image_tag("tick.svg", class: "tick") %>
      </div>
    <% end %>
  <% end %>
<% end %>

Demo day

It was time for us to refine the front end of the app and prepare our pitch for demo day. As our solution was reliant on vegetables being ready to plant and harvest at specific times of the year, we needed to tweak our database for the presentation so that we could be sure there would be vegetables to plant on the date of the demo day. We also had to tweak harvest time so one vegetable would be available to harvest live (for any of you eagle-eyed readers out there).

The result

Check out our demo below of the Patched app.

You can also visit Patched and have a play on your phone, once you’ve created an account, at www.patched.me.

The Patched app demo, here I am with my team-mate Luis (aka João)

Next Steps

With more time we have a long list of features we would like to build, including:

• Notifications—from a user experience perspective we wanted to add in notifications to ensure a user is alerted to the most up-to-date requirements for their patch. This ended up being out of scope for the limited timeframe.
• Gamification—from a learning (and fun!) perspective we wanted to develop a gamification aspect of the app, this would allow for further experimentation with JavaScript. We set up our database in advance to ensure we could explore this in the future.

Key Learnings

This was a project which provided endless discoveries along the way.

• Prototypes are powerful. I was aware of the aligning magic of prototypes from my previous professional experience. However, from a developer perspective I hadn’t appreciated how much of a difference a clear prototype makes to successfully executing a team vision and planning implementation effectively. It also helped a lot when communicating with teachers and teaching assistants when we were stuck or needed help with finding a solution.
• What’s in a name? Originally we had a model called ‘PatchVegetable’ for the vegetables selected by our app’s user. However, this caused a lot of issues for us. This is because Rails kept registering ‘patch’ as a command to perform a patch request. Eventually we realised what was going on and renamed this model to ‘Crop’. No additional patches or seeds or patch vegetables shall enter a database of mine again!
• “It works on my machine”. We worked really well together, pushing regularly to Github as a team. When it came to deploying on Heroku there were always many surprises! We certainly learned the importance of doing this at the end of every day and solving unexpected bugs regularly.

If you’d like to grab a coffee/chat all things design and development, get in touch: here’s my Linkedin and my website.

I couldn’t have lucked-out more, getting to work with the most fabulous, fun and collaborative team. You can check out their Linkedins here: Luís Vaz Pinto, Mariana Saavedra and Patrícia Nunes.

Plus, the excellent teaching staff and teaching assistants at Le Wagon helped us a lot during this project and we learned so much from their expertise.