Lag and what to do about large files?

#1

Specs
Mac OS X version 10.12.1
8 GB RAM
2.7 GHz Intel Core i5

Subform versio 0.0.0 8afa768 on Darwin 16.1.0

Question
So this is as much a question into other peoples workflows as it is about how Ryan and Kevin imagine Subflow to work with larger projects.

I've begun to notice slight lagging of the screen rendering as I'm scrolling around the artboard. That and also when typing new copy into a textfields or new datum. Now I've only got 1 artboard at the moment that's 1440 x 8000 in size.

What I'm working on at the moment is not a website page yet but a patterns library that I would then be able to use when creating other pages later – I'd be happy to share this file with you @Ryan and @kevin if it would help illustrate my work area at the moment.

So the problem is if it's beginning to lag now what would it be like once there's 20-30+ pages?

Our team found Sketch files also begin to get a bit slow (especially when opening) if there are lots of pages and symbols. A site we previously worked on had over 200 pages that needed to be artworked (due to there being numerous departments and stakeholders that all required visual sign off before build could commence - not the best workflow I know but it's how the company worked and we didn't have a choice).

So our solution to this was to create a patterns library file to act as a central library of components and then each page of the website was it's own sketch file after that. Since then we've also begun using the library function in Craft for Sketch for sharing components across files without causing conflicts.

I'm not saying it was the perfect solution, there's always issues of consistency even when there's a central library when working across a team but it's just how our team managed it at the time.

So the question is, how should Subform handle a situation such as this? Is it's aim to keep it all in one file? Or have a way of sharing components across files? Whether that's some sort of library you could link to much like an external dataset might be?

What do people think could work for their work flows?

#2

My design file currently has 11 artboards (most at iPhone 6 size or smaller) and I have also been noticing a lag. It seems to make scrolling laggy/choppy. It seems to affect the entire UI, not just the artboard viewport. For instance, there is a delay between when I click on elements in the hierarchy or the artboard and when they become selected in the UI. Also, typing in the command bar seems laggy. I opened a new project in another subform window while I have my big project open. The UI in the other window does not seem to be affected by lag and is quite snappy.

My specs:
Mac:Book Pro (Retina, 15-inch, Mid 2015)
CPU: 2.5 GHz Intel Core i7
RAM: 16 GB 1600 MHz DDR3
Graphics: AMD Radeon R9 M370X 2048 MB

#3

Definitely aware of the lag.

Before we can do anything about it, though, we need to get the semantics worked out for layout and components.
Partly that's just because of our limited resources (I'm the only developer), but also because any work done now to make things speedier would likely get thrown out as soon as, say, the layout engine changes, so the problems have to be tackled in order.

@toby_burkill re: separate pattern library file, I want component sharing to make sense from a workflow perspective, not to be a workaround for lag. It's TBD whether the lag is in rendering (just drawing a lot of stuff) vs. having lots of elements in the underlying data structures (regardless of whether they are being drawn).

Once we have a new layout system in and working well with components, I'll be able to take a deep dive into performance.

But yeah, it's definitely on our radar.
I appreciate your patience in the mean time.

#4

Yeh I fully appreciate that the speed would come later, and I hope you understand this post is not in anyway meant as a a slight on that. It was more a question of how do people currently work and after your reply I suppose depending on what is the cause of the performance impact (whether rendering or element data), how do people work with that? Like in my example, I imagine Sketch has a large development team by now and even that gets laggy when pushed to the limits with larger files / designs so there's only so much performance enhancing can do before it becomes more a limit of the hardware itself being used.

With this being an entirely new piece of software we can ask the question what is the ideal file structure/workflow? Like in my example, working with larger teams where files are often collaborated on. In the past there's been many spin off apps you can subscribe to in order to manage this but all of these are just workarounds for constraints of current design software. If we're wiping the slate clean and thinking about this from the ground up what would work best?

These are all big 'grey area' questions and I'm not expecting Subform to solve the dilemma of designing as a team. Just a bit of a discussion into how people think it could work better and out of that discussion are there any ideas (if anything) that Subform could implement that might make it easier?

#5

I think that's exactly right. Artboards and pages were really useful feature introductions in Sketch. But if you push them far enough (everything in one file!) you end up with performance issues and management issues (not being able to find the screen you're looking for), etc.

It's always a moving target, developer works hard to make things more performant, then users just cram in more artboards until it gets slow again.

Yeah, I think it's a great discussion to have. I'm interested in hearing more thoughts about this. Maybe we can sidestep a lot of development time around performance by just creating better systems to solve the problems that multiple artboards are currently used for.

Off the top of my head, I think having multiple artboards in a file serves a few purposes:

  • Searching: Where's x screen? I can zoom out and pan around until I find it.

  • Comparative designing: It's nice to see different screens or viewport sizes side-by-side while you're designing.

  • Component sharing: There are other ways around this (e.g. InVision Craft Library, as you mentioned), but the simplest way to share components across screens is to just keep everything in one file.

Of those, I think "comparative designing" is the most compelling. We might use libraries for shared components and better search for locating different screens, but comparative designing ultimately means seeing multiple artboards, probably full-size, on the screen at the same time.

But if that's the case, it would really be nice to have a 2-up or (3-up or 4-up) view of any screens on demand. Right now, artboards live in a physical position inside of the app's universe, so putting two side-by-side means dragging things around constantly. If you could quickly view any different artboard side-by-side, can we avoid making the computer render out 200 artboards simultaneously?

#6

I like the idea of the 2-up/3-up display, would be especially to see the multiple screen sizes simultaneously.

Reading your reply gave me an idea, what about if there was some form of project structure? Imagine something like Sublimes folder structure that could be expanded from the left of the screen. The components and datasets could apply across the whole folder of individual files. Then you could have the 2-up/4-up because it's just opening another file and splitting the viewport?

Screen Shot 2016-12-09 at 13.37.46.png2560x1470 238 KB

#7

Another purpose for multiple artboards to add to the list above:

  • Flow / Completion Tracking: What screens are needed for this product? Have I designed them all? Artboards in a single file can serve as a de facto system for tracking these things. Nick Daze's post Product Design has a process problem covers how he uses this in his own workflow with Photoshop linked smart objects.