Photo Cropper Interfaces

By Dan Yoachim  ·   February 3, 2015  ·  6 minute read

Topics: Apprenticeship

Designing usable and intuitive interfaces can be challenging. Here I discuss some of the considerations I made in creating a photo cropper interface.

Dan Yoachim is Neoteric Design’s spring 2015 apprentice, researching topics on interactive documentaries, javascript driven user interfaces, and front end development. 


Most people have used a cropping interface at some point. Generally it takes the form of the image overlaid by a marquee selection. Click and drag to mark a selection then use the handles to tweak the size. 

​We’ve all been here.

For the most part it works well, especially for casual use cases like grabbing a headshot. The pixel dimensions of the crop are usually displayed too, which can be very useful information. For more in depth projects though, this setup still leaves us with some limitations.

The best way I’ve found to find these areas is looking to the use case it would frustrate me in. If I’m a photographer for instance, and my 4000px wide image needs a 150px crop, it will be difficult to get the accuracy I’d need. A scaled-frame at 1000px places that to just 37px wide. We could give that freedom, but pictures on the small end of the scale would allow very pixelated crops to be made. Not having the image display at natural size creates resolution ambiguity, but large images are difficult to work with at natural size. So how do we fix this?

We could just allow the user to crop anything and if the result is unsatisfactory they’ll quickly hit ‘undo’ and try again. Many go this route, and it’s not an unreasonable approach. There’s no risk of users feeling a loss of agency or unnecessary hand holding, but on the other hand more than one redo can quickly become annoying. There’s also a loss of reference in many programs where the crop replaces the original in the window wholesale. This also can potentially add overhead since the crop photo asset often must be created each time, especially in online cropping services like Cloudinary. 

Alternatively, we could create a spoofed preview of the image. Since we know the relative location of the marquee to the image, we can add a preview that selectively shows a section of the full image before the cutting ever takes place. Now our users can see their selection at a constant size in tandem with the crop tool itself. We’ve also reduced the chances of multiple assets being created and the overhead that entails without limiting the user. Awesome!

But there are a few issues with this approach too. It takes up space for starters. That may sound obvious, but screen real estate is valuable. It’s worth taking the time to consider adding this extra bulk to an interface. In a modal or new window this could bring a nice balance and sense of ‘completeness’ to the tool. Alternately, a page with many competing elements or one accessed on a small screen may just confuse things. 

You’ll also have to account for aspect ratios in either case. In instances where the aspect is known such as cropping for a user icon you can safely assume output size, but if users can switch between ratios or select freeform the preview must display accordingly. This can add complexity in development and in visual design of pages.

So dropping the preview for a minute, what else could we try? The obvious one is just zoom the image itself. Sounds simple in theory, but there are a lot of secondary questions raised by this path.

The first thing to note is we’ve now added dragging the image to the feature set. What use is a photo zoomed in halfway when its the wrong half? Dragging an element isn’t overly complicated, but there’s some overlaps we must consider. Previously dragging over the (unmoving) image would create a new selection, which now can’t be done at all.

Additionally, dragging within the selection will move it instead of moving the image, causing control ambiguity. Depending on the setup, the image could also potentially leave the selection area causing blank space or errors in the result. A common response to this issue is constraining the image to its frame, meaning you never see behind it. This plays well with a marquee selector, but also with using the frame itself as the cropper. Be aware of aspect ratios if you take the frame approach though, as you’re essentially locked in unless you really like page reflows.

Don’t let users do this.

Bound to the Frame, overflow set to visible

We’ve also introduced the need for zoom level controls. Buttons or a range input (slider) are the best choices here. You might be tempted to use scrolling for this control, but many argue it interferes with normal page navigation, and can often be triggered accidentally. Plus, you’re excluding mobile users from the offset.

Overall though, our interface is in pretty good shape. Users can zoom/move the image and resize/move the selector but are unable to crop out of bounds. We’re able to have varying aspect ratios without worry, and we could add a preview window if desired. We’ve achieved all our previous functionality, yet also minimized our risks and breaking points. Many croppers use this style, and its likely the best balance when time and resources are limited.

However, there are still some points that stick with me. Adjusting the selection isn’t as smooth as I would like. Because it resizes asymmetrically I’m forced to recenter my selection each time. In the cases I hit an edge resizing I must move the selection, resize it, then return it. I’m also required to mentally account for two objects positions and sizes relative to one another. For a contrived example, cropping the top corner and then the bottom corner of a zoomed image would require moving the image and the marquee (assuming you’ve bounded your image to the frame). There might also be a ‘flip’ of the selection when resizing negatively if a minimum size is enforced. Lastly, there’s an impression of running into ‘walls’ when the image hits a boundary. This abrupt stopping feels awkward and unnatural, especially when many other modern digital elements spring back when shifted too far.

To get around these limitations, I decided the best route was to always center the marquee in the frame, including resizing it symmetrically. This necessitated constraining the image to the marquee itself instead of the frame. Previously this would have meant the image chasing the selector, but with a fixed marquee it now means centering in the frame, a nice bonus. With animation, the image balancing allows the user to drag the image as far as they like, but gently ‘instructs’ the photo must remain in the marquee. By also limiting the marquee to the shorter dimension of the image, we can keep most of our ‘idiot proofing’ quietly behind the scenes. 

This change also means users only have to keep track of the marquee size, image zoom level, and image position. We’ve lost no ability to select, but have limited the cognitive load greatly. Our previous top and bottom corner crop now only takes dragging the photo, a much simpler action. We can even limit the marquee handles to width, height, and one diagonal, as they’re now growing from both sides. Not to mention all those micro-frustrations like re-centering after a marquee resize or flipping a minimum selection disappear.