Design Details: Drag and Drop

The technical underpinnings of drag and drop are provided by Apple in UIKit but much of how using it looks and feels is in the hands of app developers.

Ideally, experiences that users have in one app should stand to benefit them in others. As a community of developers and designers we should be looking to agree upon shared best practices to provide a consistent user experience. There’s an opportunity here to help users understand and embrace drag and drop as a powerful way to interact with touch devices, just as they have on the desktop for years.

Two weeks ago we released Castro 2.5 with its drag and drop integration. In his iOS 11 review, Federico Viticci wrote that our implementation feels great:

[It] convinced me that the feature is not a gimmick on the smaller screen; it can bring substantial benefits to any iPhone app. After getting used to drag and drop in Castro 2.5, I want it everywhere.

In this post I will dive deeper into some of the specific details of drag and drop in Castro, as a way to begin this discussion which I hope can continue elsewhere.

Although drag and drop on iPhone is limited to being used within a single application, we found that its multi-touch support and the direct manipulation it allows open up powerful new opportunities for batch actions and other features that were cumbersome before, and the lessons we learned on iPhone are relevant to iPad too.

If you don’t have Castro yet, download it on the App Store to try out these interactions for yourself.

Lifting

When a user long presses a draggable interface element it lifts up to indicate it can be dragged. By default the entire rectangular area of that element will be lifted but you can specify a clipping path that will be applied to the preview and this can help in lending a sense of physicality to your interface.

🚫

Drag Previews

When the user then drags their finger, a preview of the item or items that element represents is shown and sticks under their finger. By default this will be a snapshot of the preview that was shown when lifting. In some scenarios it may be sufficient to use that default representation but it will often be better to design a custom preview that represents the content more effectively.

In Castro we have episode cells that include a summary of the episode and various state indicators. Including this in the drag preview made it very cluttered. When dragging a single episode it covered too much of the screen and when dragging multiple episodes iOS scaled down the previews and the important content was too small to effectively convey what it represented.

🚫

We also have draggable elements that can represent multiple episodes. In those cases using a snapshot of the view where the drag started is definitely not sufficient. We wanted the representation of an episode to be consistent, regardless of where the drag originated from.

🚫

Drop Targets

There is no default way for indicating drop targets. In early betas of Castro 2.5 testers reported being confused as to where episodes could be dropped, so we made it a priority to be explicit about this.

This is particularly important in the absence of a standard way to cancel a drag on iOS. We need to try and help users feel confident that dropping at a particular point will perform an action so that at other times they know they can just let go to cancel.

Another challenge we faced was that some of our drop targets are small. Tab bar icons are easily tappable but when attempting a drop they are obscured by your finger so we needed to design a highlight that would expand beyond the bounds of the button and be visible behind a fingertip.

🚫

For entire views that are drop targets we looked to Finder on macOS for inspiration.

🚫

Drop Animations

iOS provides a default drop animation where the items you’re dragging scale down and fade to the point where you dropped them. On the tab icons in Castro this was too subtle, especially since your finger could still be obscuring the icon after you drop.

🚫

When inserting dropped items into a table or collection view based on where the user has dropped them it’s important to use the methods provided by those classes to animate the items smoothly into place. This helps the user get a clear understanding of exactly what has happened and lends to the overall physicality and sense of direct manipulation.

🚫

Reordering Multiple Items

Table and collection views on iOS 11 do not yet natively support reordering multiple items at the same time (rdar://33413316).

There is a workaround that involves telling a drag session you are capable of inserting items into rows rather than only between them (and then doing otherwise once the drop happens) but that leads to some pretty confusing drop animations, means space no longer opens up in the view to indicate where your items will be dropped, and the items you are reordering still take up space in their original positions.

The team who work on Springboard were able to get multiple apps reordering very nicely. Apps you are dragging leave their place on your home screen and then drop neatly into place when you perform the drop. That was the model for how we got multiple episode reordering to work in Castro, and hopefully an indication of how it might work in all table and collection views in the future.

🚫

Let’s Talk

We’re happy with the design solutions we found so far for drag and drop in Castro. Now however, it’s important for us as a community to have conversations about these details and hopefully agree upon some best practices. If we can do that, then users will be better equipped to harnass the power of drag and drop in all our apps.

If there are things you like about what we’ve done, or if there are aspects you disagree with, let’s keep this discussion going on Twitter.