Building a wicked fun deletion mechanism

Red Davis
Making Plum šŸ› ļø
5 min readJan 20, 2021

Plumā€™s users can create Pockets that they can use to segment their savings. For example; a user might be planning a trip to the Federated States of Micronesia. After their trip, they probably no longer have any need for a ā€œtrip to The Federated States of Micronesiaā€ Pocket. So they decide to delete it.

Generally, a deletion action would look something like this:

  • User taps delete button.
  • Plum displays an alert to confirm the action.
  • User confirms.
  • An activity indicator of some sort is displayed.
  • The user is told about the result (success or failure).

This is a rather boring and mediocre experience. Itā€™s also quite an anti-climax for someone whoā€™s just had a great holiday to the Federated States of Micronesia. So we thought this would be a good place to make our users smile.

On the other hand, there will be users who choose to stop saving and delete their Pocketā€™s. A simple delete button is like making your New Years Resolution to not eat chocolate but filling the cupboard with your favourite salted dark chocolate. Therefore, the aim of building an interactive deletion mechanism where the user destroys something they have created and contributed to will cause them a slight subconscious discomfort that will cause them to pause, contemplate and, hopefully, keep them saving.

The Card Burner

We thought it would be cool if the user could take part in the deletion of the pocket. Iā€™d be lying if I said I remembered how we came to the conclusion, but somehow we landed on the idea of lasers.

The general idea is that the user should be able to drag their Pocket into an extremely powerful laser to destroy it. Since the user always has control of the Pocket during the laser-ing, we thought it would be unrealistic, šŸ¤Ø, if the Pocket was partially inserted into the laser but was left intact. Therefore we decided it was very important for the Pocket to acquire some charring, BBQ style.

What we wanted

So, to give a short summary of what we wanted:

  1. User should be presented with their Pocket and a laser.
  2. The laser should be presented as if itā€™s being turned on. Think Lightsaber.
  3. The laser should be audible. It is a very powerful laser after all.
  4. It should be clear to the user what they should do ā€” Very important but often forgotten about.
  5. Charring should be left on the Pocket if the user has second thoughts.
  6. There should be some visual cue that destruction is happening.
  7. The user should be able to feel the laser destroying the Pocket.
  8. If the user completes the deletion interaction, the Pocket is deleted (this is why weā€™re doing this after allā€¦).

What we did

How we did it

Imma go through each cool component but firstly, letā€™s look at the view hierarchy.

Here we have:

  1. Instruction label.
  2. The Pocket.
  3. An arrow to provide a visual cue of what to do.
  4. The laser.
  5. 2 Trapezium views with a gradient fill. One going up and the other, down.
  6. The LaserDebrisView.

Laser debris

Hereā€™s a close up of the debris emitted from the laser.

If youā€™ve used an app in the last 5 years you have likely seen some sort of emoji cannon. We even have several in Plum. Why am I bringing this up? Well, we use the same ideas behind the emoji cannon for our laser debris.

CoreAnimation has a couple of useful classes for building a particle system: CAEmitterLayer and CAEmitterCell.

Here is our LaserDebrisView.

To give an overview of this class; it has a fire() function which initiates the emission of debris. The emission of debris is essentially a CAEmitterLayer that has itā€™s birthRate animated.

The magic is primarily in how we configure the CAEmitterLayer to have 3 emitter cells. Each cellā€™s content is a small red image of varying alpha values. CAEmitterCell has loads of configurable parameters, I eventually settled on the settings you see above.

Pocket charring

Charring works by adding a BurnView to the Pocket when it is retracted from the laser.

Our BurnView is a view that has been filled with an image that has been randomly generated by making each point black with a random alpha value (layered 3 times).

We choose to add the charring if the Pocket is in the laser and as soon as the Pocket goes down the Y-axis (remember iOS Coordinate system is upside down šŸ“ˆ). Weā€™re using a UIPanGestureRecognizer to handle the interaction with the Pocket. Within our gesture handler, on change, we have something that looks like:

Connecting it all together

As previously mentioned, weā€™re using a UIPanGestureRecognizer to handle the interaction with the Pocket. We use the gesture handler as the glue for all the moving parts.

On Change

While the gesture is in a changed state we move the Pocket along the Y-axis to follow the userā€™s interaction. If the Pocket intersects the laser and it is plunged into it, we trigger the debris view to fire, if the Pocket is being retracted we add a layer of burn šŸ”„.

You may also notice we are triggering a UIImpactFeedbackGenerator. Iā€™ve personally never destroyed a card with a laser, but I imagine it feels like triggering a heavy UIImpactFeedbackGenerator over and over againā€¦

On ended

When the userā€™s interaction with the Pocket has ended we determine itā€™s fateā€¦

If the user has passed over 60% of the card through the laser we animate the rest of the Pocket through and trigger the API call to delete the Pocket. If the Pocket has been spared, then we give it a layer of burn and return it to its starting position.

Fin.

Wish you could build Pocket destroying lasers? Weā€™re hiring. šŸŽ‰

--

--