Hi, my name's Eugene. Nice to meet you!

One of the first reviews by Sean Halley from Guitar Tricks, 2016

A brief Tonebridge demonstration by Laney amps at NAMM, 2018

Walkthrough by Jamstack, 2019

After the release of the app we received various feature requests from the users. One of the most popular ideas was the ability to quickly switch between presets.

Tonebridge was mainly created for home guitarists, and such a feature would add unnessessary complications to the UI. Thus, we kept putting the idea aside. It was just one time when that I made a quick draft of it:

The horizontal design didn’t combine with the vertical layout of the app. The whole concept needed rethinking, and we wrote the design off.

However, we continued to get feedback from people who needed the feature for live performances. That finally seemed like a valid reason to give it a try. The first attempts to make the design vertical were not a success:

We aimed to keep Tonebridge simple and intuitive to use, and this was far from being simple. But then it hit me:

Guitarists use sound effects pedals all the time. To quickly switch between effects, they use a pedalboard—a board or a panel that serves as a container, patch bay, and power supply for the pedals.

I looked through the pedalboard designs and found one that looked the closest to what I’d expected:

Now it all was coming into place. The pedalboard concept was intuitive for the majority of guitarists. The layout was easily reusable. The pedal controls could remain the same. It was basically a multiplication of the single pedal layout. The ideas bound together very naturally:

With the design, we managed to maintain consistency across the app, and reduce the development cost. The only hard part was to create a layout that would use the most available space depending on the screen size.

Here are some of the ideas behind the design:

The pedalboard is designed to be obviously scrollable when the number of pedals is greater than the screen can hold.

The pedals fill the screen as effectively as possible, so an iPad will display more pedals an iPhone. And if the device is rotated, the pedalboard will resize accordingly.

Selecting a pedal makes it jump to the center of the screen. Along with looking aesthetically good, this makes switching the pedals easier, as the next pedal will always jump under the finger.

If a pedalboard is constructed out of pedals for the same song, the song parts will be displayed instead of the song’s and artist’s names.

By the user’s taste, the pedals can be rearranged right on the pedalboard or by using the standard system controls.

Since the feature launch, Tonebridge users have created thousands of pedalboards, making it one of the most popular features in the app.

This little 3D fella was a big journey for me and the team:

The pedal is a real 3D object that reacts to the device movement, making the illusion of depth and realism. Here is how we managed to do it.

In September 2016, Apple released iPhone 7, including their gorgeous jet black model. The product page showed a stunning photorealistic 3D animation of the phone with moving light and flares when scrolled:

These animations inspired us to improve the pedal in the application by making it alive. During the exploration stage, we realised that it might be hardly possible. First, the animation turned out to be a video, not real 3D. Secondly, the performance of the mobile devices at that time was not impressive. So, showing a realistic 3D model in real time seemed to be a wild goose chase. Thirdly, we had no idea of how to work with 3D.

Nevertheless, we found an experienced 3D artist and started working:

When the model was ready, the remained job was to build it into the app and adjust the materials, light and cameras. The artist had created the pedal in 3D Max and managed to make realistic photographic renderings, while in the app, the model had to be displayed in real time and on a low-performing device.

After a long struggle with SceneKit, we managed to integrate the model into the application, and the result disappointed us. The pedal turned out to be completely different from the beautiful renderings which the artist had sent us before:

We tried to make the pedal as realistic as possible by working with hundreds of the material properties, by figuring out right normals of the surfaces, and by finding the best angles for the light sources and cameras.

Changing a setting and then compiling a build for improvement was a time waster. So, we decided to display and adjust all the variables right in the app. The work went much faster:

Most of the visual work was done by me. After several weeks of working with textures, SceneKit bugs, countless attempts to befriend the 3D model with the album covers, we finally received an eye-pleasing image:

In comparison with the original, the 3D pedal turned out to look more realistic, because the materials and light were real unlike those made by hand in Photoshop:

The final touch was to make the pedal move. We linked its axes to the movements of the phone via the gyroscope data. This way, the pedal would slightly tilt in the direction opposite to the phone's movement:

P. S. Unfortunately, the pedal has been presented in the app for about 2 years. The release of iOS 12 brought a bug to SceneKit making the app freeze the device. So, we had to roll back to the original pedal.

In the video, I present the feature to the team and show two use cases: adding 1 person to a call and adding multiple people to a call.

Here you can try out the interactive prototype with Talk's main features: calling, signing in and out, parallel calls, conference calls, contacts, and call history.

Here you can try the messages feature that I made for talk.

Here you can try out the interactive prototype with Invoice Maker's main features: creating invoices, viewing invoices, clients, items, payment options, registering payments, and many more.

The app's main screen was designed to have everything at a glance. It brings immediate value and develops a healthy habit of periodical checks:

When user hasn’t sent any invoices yet, the app appears greyish. This helps to bring up the main button and keep the screen less noisy. After at least one invoice has been sent to a client, the app’s main screen starts to appear in colour.

The app provides a handful of angles to view one's data. All the clients, items, and documents are organized:

The app's sign in process does not require a password which makes it more secure and easier to sign in:

The “+” button is the entry point to anything the user might be willing to create—an invoice, an estimate, a new client contact, an item to sell, or a new payment method:

The “New Invoice” screen immediately suggests the user to add the most crusial information of an invoice—the client, the items, and the options to pay.

Additionally, the user might want to add images, a text note, or their signature which they can create right in the app as well.

Here's a more detailed view. This is a partially filled invoice—the big plus indicates that it lacks a client. Once a client is added, the invoice is ready to be sent:

And here is an invoice in its full glory with all the options filled in:

Once created, an invoice travels a certain path towards being paid off:

The app provides a set of organized lists for documents on various stages of their journey:

Once the user has been paid, they add the payment to the app:

Profiles of different entities are designed in a similar way to make it easier to understand the app's design as well as spend less time on developing it:

The app was planned to have a paid subscription model, so a sale screen was designed as well:

Thanks for watching!

MedcoVet provides lasers to veterinary clinics, and the clinics prescribe the lasers to the pet owners. The revenue from the prescribed lasers is split between MedcoVet and the clinic.

The pet owner makes a choice between two payment plans:

1. Rental plan: the pet owner pays weekly rental fee and is to return the device back to the clinic or MedcoVet after the treatment case is closed.
2. Purchase plan: the pet owner becomes the owner of the device.

The billing is managed by MedcoVet, but the practice owner may set up the prices for both plans. Before the redesign, the price settings looked like this:

We kept getting feedback from practice owners regarding the complexity of the screen. Some of the practice owners also asked for a flexible price control option, i.e. the ability to make discounts on certain weeks. So, we decided to redesign the screen.

The core idea was to clearly divide the two plans and their prices, and improve the rental price customization interface. I also wanted the practice owner to be able to see the clinic potential revenue calculation, so they could make better pricing decisions:

A price rule has been added:

Here’s how it looks in the UI:

The practice owner can see the potential revenue the clinic is going to get by renting or selling a device.

When a price rule is added, it gets the previous week’s price by default, so the tables won’t recalculate until the price is changed:

When the practice owner changes one of the prices, the revenue tables immediately recalculate the clinic’s income. If the first week price is reduced to $60...

...the table will update the revenue numbers:

The recalculaton happens with a small delay to be sure it won’t happen while the user is editing the prices.

There is no limit to the number of price rules. The rule titles and the clinic revenue table are automatically updated according to the added rules:

We also implemented some under-the-hood scripts that prevent setting a week number that is lower than the previous one, or a price that is lower than the allowed minimum. The dedicated textfield will change the entered information to the nearest valid value.

The interface also encourages the practice owner to avoid unreasonable pricing:

The clinic's price policies are then displayed for the pet owner in the MedcoVet satellite app:

At the bottom of the site, there is a form for submitting the essay text. The student may also decide to book an online class in addition to the offline check to discuss the comments online:

The problem was that the student might be anywhere in the world and have any time zone, so my father had to negotiate the lesson time with each student by email. It would often take 2-3 emails and several days to have the lesson booked.

It's much easier to work with the lesson schedule when the student's time zone is known. I decided that the best way to define the time zone is to guess the student’s local time and adjust the schedule accordingly:

And here's how it's done in the interface:

If the guess is good, the student selects “yes” and immediately sees the lesson schedule:

The site tries to guess the student’s local time by their IP and browser language settings. the method is not very reliable, so there must be a backup plan.

If the time is incorrect, the website prompts to specify their time zone. It’s not as simple as saying “yes”, but is still better than negotiation by email:

Let’s try to choose Chicago...

...and see that the lesson time in the schedule has changed from 8:30 PM to 12:30 PM:

And for last: the time schedule can be edited through Google calendar. To add or remove a lesson time, my father just opens his calendar, makes the changes, and the schedule is instantly updated.

We plan to add more automation by excluding the booked lesson time from the schedule. But that’s a story for another day.

The Comment Type section was designed to show the versatility of my father's comments:

Zoom in the page to see the details:

I've designed a format that would be eye-catching and show the main features of the app all at once:

The design allowed to create different variations of the ad in different languages to experiment with conversion:

Here's a demonstration of the app's main features that we made for Apple's App Store review team:

These are some examples of the guitar lessons that I created for the app.

For every lesson, I pulled the theoretical data, developed the tuition method, wrote the copy, created the script, ordered and managed the narration voice, directed the video production, and made the post-production editing.

Holding a guitar

Playing frets

Using the in-app tuner

Remembering chords with ease

Learning 5 basic chord shapes

Switching between the A and D chord shapes using the anchor finger technique

The application provides instand feedback to the user's playing. For the algorithms to work well and the feedback to be honest, the guitar must be tuned. Besides that, many users had send us complains about the assessment algorithm, and we realised that most of them simply had not tune their guitar before playing. We decided that the app needed a built-in tuner.

Since our users were mostly beginners, the tuner had to be easy to use and motivative, so the user would tune all the strings.

The tuner is one of the basic guitar gear, and it seemed like there was no reason to reinvent the wheel. However, the popular tuner apps at that time looked like this:

Most of the tuners were instantly repelling because of their complexity. Some of the apps looked better than others but required music theory knowledge or forced to select a string each to tune it up. None of the tuners motivated the user to complete the tuning.

I tried to eliminate all the shortcomings and came up to this concept:

The main idea was that when the user played any string, the tuner would automatically detect which string had been played and suggest if it's needed to tune it up or down. When the string was in tune, the tuner would mark it as tuned. The marks created a  gestalt that were to motivate the user to collect all the marks, i.e. tune all the strings.

Later the team decided that we needed the user to learn the notes of the strings. We put them in such a way that the notes wouldn't prevent the user from using the tuner but at the same time would help the user associate strings with their corresponding notes.

Here is how it looks in the interface. It all starts with a suggestion to play a string:

The tuner automatically determines which string has been played— we compare the frequency ranges of each string with what the user plays:

When the string is almost in tune, we slightly change the message, so the user would tune with more caution:

If we hear the correct pitch, we ask the user to let the string ring for a while: right after the stroke string usually sounds higher, and the tuner may mistakenly decide it's already in tune.

That's why we don't just follow the pitch one moment at a time, but rather accumulate the correct pitches to make sure that it's not the peak:

The string has been tuned:

The strings can be played and tuned in any order. When the last string is tuned...

...the tuner announces that the guitar is in tune.

Now the user can begin the next lesson or practice a favorite song.

See the tuner in action (0:06—0:26):