Why Skala won’t have artboards
Since publishing a progress update, quite a few people have asked for more details on why we think artboards aren’t a good fit for Skala.
Rather than incomplete, terse responses via Twitter or email, I felt we should provide more insight into why we’ve decided to not include artboards in Skala. I know I’ve said it before, but Skala’s fresh start means we’re not bound by legacy concepts. That’s a gift, but carelessly implementing features could have long term consequences, so everything is being considered in great detail.
What is the job to be done? #
For screen design, artboards get used for many things. They are a generic solution to a set of smaller problems.
- A way to view different versions of artwork side by side.
- A way to view different states side by side.
- A way to export regions of a document.
- A way to group related artwork.
All of those things can be achieved without artboards, in ways that are better than using artboards.
Zoom intent is impossible to know #
It’s not possible to hit a single keyboard shortcut and have the document zoom and position change to fit the current artboard to the window, in a reliable way. This is because it’s often hard or impossible to know which artboard the user wants to show.
Is it the artboard that is closest to the centre of the window? The artboard that has the most area in the window? The artboard that’s selected? What if no artboard is selected? The last artboard that was selected? What if the document was just opened and there is no selection history? The topmost artboard, if there’s a stacking order? If all else fails, use the first artboard? Or, disable the ability if you can’t be sure?
Complex logic like that will be perceived as unpredictable by the user, and I consider fit to screen to be an essential feature.
Device preview intent is impossible to know #
Realtime device preview is becoming a mandatory feature for design tools. Device preview typically sends, or tries to send, the current artboard. This has the same issues as zoom intent does. How do you know which artboard to send? It’s possible to guess, but that guess can not be correct all the time. Or, maybe you simply don’t make the device preview follow the canvas?
Overhanging objects #
Determining intent when moving artboards can be unpredictable, where objects overhang the artboard’s edges. Should objects that touch the artboard move?
Inversely, moving objects so they overhang the edge of artboard opens up many questions. Should an object be attached to an artboard if it is dragged into an artboard’s area? If you think it should, layer stacking order may be affected. If you think it shouldn’t, then it’s possible for objects to look like they’re contained within an artboard, even when they aren’t. Should you mask overhanging objects? If so, why? Would you then unmask them if they’re dragged completely off the artboard? If so, why? Should dragging with the mouse be treated differently to nudging with the keyboard? If so, why?
There is no behaviour for overhanging objects that seems acceptable and predictable.
Off artboard objects #
Typically, it is also possible to place objects outside artboards. This can cause further confusion — if an artboard is moved under the object, should the object then get assigned to the artboard? If you think it shouldn’t, then it is possible for an object to visually look like it is attached to an artboard, but it is not, and moving the artboard would not move the object. If you think it should, then there’s many situations where stacking order and masking could be broken, simply by moving an artboard.
Resizing many artboards at once #
Assume you’ve built a mockup for an app with many screens, based on the iPhone 5’s dimensions, and you want to change it to the iPhone 6’s dimensions. If you’re using artboards, it can be a lot of work.
This problem is solvable, but I’d rather cover it with inherent document behaviour.
Longer layer list #
If artboards are represented as special groups, and if the intention is to have many artboards to represent different versions or states, the layer list could get unwieldily very fast. Layer hierarchy is important in Skala, so we’re doing everything to ensure our layers view is clean and easy to navigate.
Skala’s performance would drastically suffer if we implemented artboards, due to a large increase in texture sizes. That’s not a deal breaker, but it does matter.
Coordinate space #
This isn’t a critical issue, but it is worth mentioning. Artboards typically have a localised coordinate space, meaning the coordinates of objects within the artboard are anchored to the top left of the artboard. And, an artboard’s position is anchored to the top left of the document. They’re in different coordinate spaces, and moving objects between different artboards or outside of artboards (into document space) means doing a coordinate space conversion.
This can cause issues with rounding and snapping — do you round to the artboard coordinate space or the document coordinate space? Do you allow artboards to be at non-integer positions? Do you just position objects in document coordinate space to avoid the issues above? If you do, are you okay with object positions being incredibly large when there’s lots of artboards?
Manual management of layout #
Typically, artboards need to be manually positioned. This can sometimes be a plus, but is more often a hassle. If you want to reorder or insert an artboard, you’ll have to do it manually. When you couple this with the strange artboard and object moving behaviour, it becomes a bit unpredictable. It’s time spent holding your design tool’s hand, rather than actually designing.
What is better than artboards? #
We have ideas, but not a complete solution yet. There’s broader workflow questions that need to be answered. I’m confident we’ll nail it soon, even if our solution doesn’t make it into early versions of Skala.
Published 20 April 2015. Updated 3 October 2016 to add device preview intent and coordinate space information.