Developing a Custom WordPress Plugin for Libertad Travel

Intro

This post documents the design and development of a custom WordPress plugin for Libertad Travel. We’ll look at how Libertad Travel is different from your typical travel agency, some of Libertad’s business goals, the design and development that went into creating the custom plugin, and wrap-up with what the future plans are for Libertad. So, without further preamble…

The Business

Marc Schwarz founded Libertad Travel to provide a unique way to travel through Mexico. An avid traveler himself, Marc knew there was a better way to provide supremely flexible, fun travel options for people who wanted to travel with a “twist.”

Here’s why Libertad is a better way to travel: you buy one ticket that gives you freedom to get on or off the bus route as you choose. The buses run frequently on a published schedule. Once you have a ticket, you can choose which day you’d like to depart from your current location and where you’d like to stop along the way. Unlike tour companies that sell experiences that last mere weeks, a Libertad Travel ticket gives you unrestricted access to the tours for a period of months, and you can make changes as frequently as you’d like.

The entire system works in real time, so you can make a change to your itinerary at (literally) the last minute. As long as you’re there to check in on your reserved bus when it arrives, you can select a bus for a given departure date and location, and then you’re off.

Here’s a quick example. One of the tours allows you to board a bus in Cancun that is bound for Playa Del Carmen. Once you get to Playa though, you can choose to head on to Tulum on the next available bus (or not!). When you’re ready, you can reserve a seat on the bus and head from Playa to Tulum, or pick up the bus anywhere else on the route such as Merida or Palenque (and many other places in this example).

The beauty of this, for the traveler, is the flexibility. The flexibility is where software comes in to help manage the complexity, keep all of the customers’ reservations straight, and present a simple way for the customers to set their itineraries.

Marc looked but couldn’t find any WordPress plugins that could do this, so he started searching for a consultant to build the system for him.

Marc and I met one another through an online job posting. We exchanged a few emails and had a call to agree to the scope of the project and the features he needed for the first iteration of software. We decided on a fixed price for the first phase, and I started designing the plugin that would bring Marc’s great idea of flexible bus tours to life.

The Need

As I mentioned before, Libertad Travel’s system needed to provide its users with supreme flexibility. The primary interface would be a reservation screen, which we quickly started calling the “Trip Planner,” that would allow any paying customer to log-in and make changes to his or her bus reservations in real time.

Here is a very early concept of the Trip Planner interface, drawn on my whiteboard.

whiteboard-trip-planner

The Trip Planner for every customer would be consolidated on a mostly read-only page called the “Drivers Area” where the bus drivers on the tour could check-in customers as they boarded the buses.

Finally, Libertad Travel’s staff needed a way to create and manage tours, including which cities they would stop in and on what dates.

Design and Development

One of my goals from the start was to design the entire system so that it integrated into WordPress and WooCommerce. I didn’t want to create a ton of extra screens and write logic to tie orders to trips. It seemed like too much extra complexity. We decided to simply build the travel system onto (mostly) existing WooCommerce features.

So, after some deliberation, I decided that the best architecture of the plugin would be:

  • Tours would be built and managed by creating a WooCommerce Product; the Tours would be input as form entries into a meta box on the Add/Edit Product screen
  • A customer would buy a Tour, which would generate an Order (this is all part of the standard WooCommerce flow)
  • On checkout, the user would choose his/her starting location, as well as an available date
  • After that, the user could go to the Trip Planner (a separate page on the front end, requiring login) to add or remove dates from a given Trip.

The Trip Planner, shown below, would be the most important screen, since it would be the primary UI for customers to manage their tours. Here’s a screenshot of the final Trip Planner that we’ve settled on after a few iterations:

desktop-screen

Tour Manager

I started with building the Admin’s Tour Manager. It was the part of the plugin that would allow an administrator to create a new tour, add the locations, and add the dates for each location. It would also need a way for the administrator to set the number of seats on the bus.

The number of available bus seats would be critical, since we would never want to allow the buses to get overbooked under any circumstance. We wouldn’t want to leave customers stranded somewhere in an unfamiliar city, now would we?

After some initial wireframes (pictured below), we went right in to building the plugin on the backend. We realized pretty quickly that we’d need a way to dynamically manage the number of stops on a trip.

For example, in the early wireframe shown here, it’s easy to see that the UI could become crowded and difficult to manage if we had a tour with a large number of locations. My initial attempt, as shown in the wireframe, would be to have each tour support up to twenty locations. However, Marc and I weren’t very happy with this and sought out another solution.

product_editor_cropped

Luckily, I utilized a library called CMB2, for building the custom meta boxes, and CMB2 has the option of using a repeater field. This way, the administrator can dynamically add stops and remove them without having a bunch of empty form fields cluttering up the user interface.

I knew that, for a project of this size, an object-oriented approach would be best.  I wrote the following classes:

  • Bus – used to represent people sitting in seats; primarily to make sure we don’t overbook the buses
  • Tour – keeps information about the tours that the admin enters into the database
  • Reservation – manages the process of reserving seats on buses for customers
  • WooCommerce Utilities – various functions to interface with WooCommerce

Also, for a great user experience, I used AJAX wherever possible. Basically, this means that the page doesn’t have to refresh in between server requests because some JavaScript that I wrote (with a lot of help from jQuery) can exchange data with the server asynchronously.

Here is a current screenshot of the Tour Manager:

admin-screen

Trip Planner

The Trip Planner is the screen of the app where the customer would spend the most time modifying his or her tour. Since it would be such a heavily used part of the software, we spent a bit of time getting it just right.

mobile-screen

 

As you can see in the mobile screenshot, you can edit existing reservations, or create new reservations, from any device. This is a necessity for travelers who need to make changes while on the go.

Checkout

The user is presented with a lightweight version of the Trip Planner during the checkout process. We opted to do this so that they could secure seats on a tour right from the first purchase of the ticket. This would prevent a customer from buying a ticket and skipping the reservation process to some extent. We didn’t want the users to come back later only to find that all of the tour dates during their travel time were taken.

Printer-friendly Version

It was a small feature, but we used a pure CSS solution to create a Print Itinerary button on the Trip Planner. It’s pretty self-explanatory, but added a nice touch to the site’s user experience.

print-screen

Lessons Learned

This is a somewhat scattered list of things I learned while working on the project.

I had very hard time doing a refactor at one point. I struggled with refactoring my code from a one-customer-equals-one-ticket system to a system where one customer could buy multiple tickets (simply by increasing the number of items in his/her cart before checkout) and bring along his or her friends. It would have been helpful if I had kept my implementation of the Tours, Reservation, and Bus classes a bit more flexible/generalized so that this refactoring would have been easier.

Troubleshooting and testing my AJAX calls proved to be difficult. I typically use a combination of server logging and JavaScript console output while developing to aid with debugging, but this wasn’t exactly straightforward with my AJAX requests. I ended up using a tool called xdebug a lot so I could step through my code one line at a time if needed and following what was happening during the AJAX calls.

Also, I had a tough time handling dates. I had to pass dates back and forth between JavaScript and PHP. It was manageable with careful coding, but I did make the mistake of using a United States date format (MM/DD/YYYY) when almost everyone else in the world uses DD/MM/YYYY. As a compromise, we went back into the code and changed everything to be DD-MMM-YYYY, such as 23 Jul 2015 so as to clear up any confusion for our international users.

I should have written a test suite early on. This application ended up being quite complex, so introducing new features would often break features I had already tested. Having a set of regression tests would have given peace of mind and made adding new features less stress-inducing. I would still love to write tests at some point, but it’s much harder to fit into the development process now that we’re getting close to launch.

Moving Forward

It looks like the business will launch officially within the next couple of months. Marc is starting with tours available in Mexico, and he also has plans to expand operations throughout Central America. Marc and I also have plans to extend the plugin to add new features and make it better as the business picks up and we get feedback from customers.

It has been great working with Marc to help launch his company, and hopefully this is the beginning of a long business relationship!

Consider this

I’ve really enjoyed working on this project, and I’m always looking for more exciting opportunities like this one.

[gravityform id=”1″ title=”true” description=”true”]

You Shouldn’t Build a Mobile App for your Small Business

You probably shouldn’t build a mobile app for your small business

Why? A mobile website will cost less and be more effective in most cases.

The chances are that users aren’t going to ever download your app.

There are over 3 million apps available to Android and iOS (Apple) users according to Statista. Most users already have dozens of apps on their phones, and “a staggering 42 percent of all app time spent on smartphones occurs on the individual’s single most used app. And nearly three out of every four minutes of app usage occurs on one of the individual’s top four apps.”

We don’t want yet another app on our phones

As Benedict Evans, a mobile technology analyst from Andreessen-Horowitz, says: the best quick and dirty method of determining whether or not you need to build your own app is this: are your users likely to keep your app’s shortcut on their home screens?

The home screen is the screen of icons you see when you turn on your phone, not counting any screens that you can access by swiping left or right. I, for example, have about 22 app shortcuts on my home screen. It’s packed.

I really like my local veterinarian, accountant, and pizza restaurant, but their apps are just not going to get a spot on my home screen.

Getting on the home screen

homescreenThere are two key places where your business is on the home screen, even if indirectly. These places are in web search and the web browser. The web browser is usually installed by default on smartphone home screens. Also, and perhaps more important, is the web search bar at the top. I am just a tap and some typing away from finding your mobile website.

This isn’t quite the same as having your app on my phone, but it’s good enough unless you spend the thousands of dollars necessary to make a mobile app and your app is actually compelling or useful enough for me to use regularly.

Don’t rely on your users to download your app. Your website is always there and always on…just waiting for someone to visit your URL. There’s nothing to install, no permissions required to be set, no clutter to put on their phone. They just visit your URL, and they’re in.

Where I am wrong

“But wait,” you say, “don’t native mobile apps perform better? Aren’t they faster with generally better user experience?” Yes, almost always.

However, what benefit do you gain from a fast app with great UX that nobody uses?

Instead, do the smart thing and spend your mobile app budget on optimizing your mobile responsive site. For most businesses, this is where you’ll get the most ROI.

I’m sure there are exceptions and counter-examples. I’d love to hear your thoughts in the comments.

Mobile-Friendly Web Development

Mobile is a must

Mobile-friendly websites and apps are a must for the modern business. Yes…I said a “must.” If you have a website that looks terrible or loads slowly on a smartphone, it’s about time to have it redesigned using mobile-friendly web development techniques. Don’t be cheap or lazy on this; mobile is an increasingly important part of the way people use the web.

Woman using mobile device

Mobile-friendly, for this post, means primarily that your site:

  • Adapts its layout to different devices and screen sizes
  • Keeps performance in mind for devices that are likely to be on low-bandwidth networks
  • Has highly focused functionality, optimized for users on-the-go

Buzzword alert

It’s worth explaining the following concepts briefly before we move on.

Responsive design – Simply put, a design approach where your site or app has some code that tells the web browser how to fit the content of your site on the screen regardless of device size. For an example of excellent responsive web design, visit Apple’s site on your mobile device and laptop. Responsive design is the current best practice (thanks, Ethan Marcotte!), and it’s a brilliant idea that’s here to stay.

Mobile-first design – this isn’t really a particular technical definition…it’s more of a design approach. Mobile-first design urges you to think about the mobile experience before you do anything else. The constraints of mobile, such as small screens and potentially slow network speeds, can help you narrow your concepts down to a very tight focus. The basic idea is the following: if you get your mobile design right, it’s easy to scale up your design to work well on larger devices.

M-dot design – This refers to detecting users that are on mobile and redirecting them to a separate version of your site that is specifically designed for smaller screens…usually m.yoursite.com (hence the name “m-dot”). At the time of this writing, UPS is still doing this on its website. I don’t recommend this approach for a number of reasons. An m-dot site almost always means you have two different websites to build and maintain, which can increase your total cost of ownership by a factor of two or more. M-dot sites are also usually unattractive. This is probably because it’s an outdated design methodology, but m-dot sites, for whatever reason, usually are in the “kinda ugly” and difficult-to-use category.

I believe that users will start to avoid m-dot sites as they become more discerning.

“Mobile is eating the world”

mobile-device-on-tableAccording to Benedict Evans, a brilliant mobile and technology analyst from Andreessen-Horowitz, mobile technology is rapidly changing the way the world uses the web. More and more customers are visiting your site from their phones and tablets.

Current data from StatCounter, an organization that tracks several million sites globally, show that mobile traffic represents 36% of global internet traffic, and mobile traffic in the United States is about 27% and rising. All signs indicate that you should bet big on mobile.

Why? Because users are quick to abandon a site if it doesn’t adapt to their mobile device. Remember the last time you visited a non-mobile optimized site? All of the pinching-to-zoom and scrolling around the page? All of the squinting? All of the forms that didn’t work? Maybe the page didn’t load at all.

Ugh.

Naturally, the first thing most people do when they encounter one of these nightmares is go find another site that can help them find what they’re looking for without all of the “friction.”

Consider this

Also, for a growing percentage of people, their phone is their only way of getting online. This trend is increasing. If you have a crappy mobile experience, you’re effectively taking some percentage of your target market and making it hard (or impossible) for them to use your site or become your customer.

If you put together the growth in traffic and the growing intolerance for sites that aren’t mobile-friendly, you can conclude two things:

  1. Ignoring mobile design and development is costing you customers
  2. The loss of customers is accelerating

Granted, those are pretty pessimistic ways to look at it. If you’re convinced it’s worth a change, let’s review some of the positive aspects of a great mobile experience:

  • Great mobile experiences delight your customers. People can visit your site, read your blog, buy your stuff, or utilize your web-enabled services on-the-go.  The end result with a mobile-friendly site is that it will keep your users on your site longer, coming back more frequently, and potentially spending more on your products or services for every visit to your site.
  • This is often under-estimated, but doing a mobile-first design strategy means you get to focus on what’s really important for your site or app to do. Honing your site’s purpose and messaging is a must for good mobile design, so it’s often a great exercise to think about design in terms of mobile.
  • Also, if you have a website for your business, you probably would like for Google to feature you high on its list of search results. Since the 21st of April in 2015, Google has started favoring mobile-friendly sites over non-mobile-friendly sites in its search results.

So, if you’re still reading you may be convinced. It’s time to get mobile-friendly. You will most likely need to work with a code-savvy designer or a design-savvy developer to make your new mobile-friendly site work well across the plethora of available devices and browsers.

In conclusion

I strongly recommend building a mobile-friendly site now. If the only things you do are develop your site with mobile responsive techniques and a mobile-first design approach, you’ll be so far ahead of most business sites out there on the web.

Although it may be difficult, I urge you to think of it as a strategic investment in your business. Don’t get left behind as your customers, and the world, move on to a new paradigm of a mobile web.

I’ll leave you with this quote from comScore’s excellent report, titled Number of Mobile-Only Internet Users Now Exceeds Desktop-Only in the US:

…smartphones and tablets (particularly the former) are becoming — or rather, have already become — our primary access point to the internet. For the longest time, the desktop computer was that vehicle connecting us all online, but the convenience of being able to communicate on-the-go, 24/7, and with all of the world’s information in our pocket gave the smartphone certain technological advantages over the fixed web. These benefits coupled with advancements in 4G data speeds, smaller-but-more-powerful processor chips, and in effect, thinner and lighter phones, all enabled the smartphone to become the digital device of choice in recent years.