Paper Space I

Likely the most confusing thing to get your early designer mind wrapped around is that your modelling software and the medium by which you present said model to anyone that is not you are widely different. One is a very capable tool with a lot of buttons that terrifies potential clients with its very business-like presence. Sorta how Xbox sold very poorly in Japan: it just didn’t look very elegant. The other is a piece of paper.

CAD makes the split literal: model space and paper space. Revit calls them views and sheets. Model space is where the building lives at full size: a 72-foot wall is 72 feet long. Paper space is the sheet, a fixed rectangle with a border, a title block, and a window onto the model placed at a scale, the ratio between inches on paper and feet in the building. At 1/8″ = 1′-0″, one printed inch stands for eight feet, which is 1:96 (8 feet × 12 inches). The model doesn’t change when you print it. The sheet decides how much of it fits, how big it reads, and what gets said around it.

When you’re rushing things to market, presentation is the last thing you want to think about, but it is the only thing that crystallizes the value of our product to stakeholders.

Unfortunately it all comes back to paper.

Efforts to automate the PDF feasibility report have left us with a PDF export that is used 33 times on average per day (some 12,000 PDFs annually). The copy-to-clipboard feature came in at 21, and a few other exports were used that I won’t get into (SKP / DXF / CSV). My suspicion is that copy current view to clipboard is simply being used to paste images into an email or other publication software. Either way, people are leaving the model to present it. Our automated PDF report doesn’t really give a whole lot of customization, but it is the most widely used report generator for site planning startups :). Here is the modal:

Right off the bat, the core problem I wanted to solve (relative to paper space in Revit or CAD) was to automate the scale of the geometry relative to the paper size the user has specified. Here that is “largest fit” on Tabloid. The app also makes an assumption, based on the user’s north arrow and the site plan geometry, about whether the sheet should be landscape or portrait. In the past I spent an inordinate amount of time setting up views following that logic, and automating it has served TF well over the last four years.

Largest fit is just arithmetic, which is exactly why a person shouldn’t be doing it. The study below uses a Tabloid sheet (17″ × 11″) and assumes a ½″ border and a 1½″ title strip, which leaves a printable area of 16″ × 8.5″. A 72′ × 48′ footprint at 1/4″ = 1′-0″ (1:48) would print 18″ × 12″: too big. At 1/8″ (1:96) it prints 9″ × 6″ (72 × 12 ÷ 96 = 9), fits, and fills 39.7% of the printable area. That’s the answer, and nobody had to open a viewport.

Standard scales come in halvings, so the fit is lumpy. A 256-foot-wide building exactly fills the 16″ width at 1/16″ (1:192, so 256 × 12 ÷ 192 = 16). Make it 260 feet and it misses by a quarter inch, drops to 1/32″ (1:384), and prints 8.1″ × 2.5″, which is 14.9% of the printable area. Four more feet of building cost the drawing half its printed width and three quarters of its printed area. Orientation is the other free decision. A 100′ × 150′ footprint at 1:192 prints 6.25″ wide and 9.4″ tall, taller than the 8.5″ available. Turn it 90° and it fits at the same scale, filling 43.1%. The study simplifies TestFit’s rule: it keeps a landscape sheet and turns the view, where TestFit picks landscape or portrait from the north arrow and the site geometry. Either way, it is a decision the software can make before it asks the user anything.

In the study, the sheet, border, title strip and the list of standard scales stay fixed. Drag the building’s width and watch the scale step and the occupancy jump. Notice that the percentage goes down as often as it goes up: the scale moves in steps, the building doesn’t.

The rest of the modal is about what the sheet adds that the model doesn’t have, and it is not that well thought out. We added “company” and “project” as basic customization, and gave the users the choice of keeping the basic tabulation or the more financially driven development one. Lastly we allow users to name custom views in 3D. If those are saved, they will show up here in this list. Once the report is generated, all views that are self-similar (like typical floor levels) are consolidated, so that information is never presented twice. That last bit is already a different problem than fitting one view, and I’ll come back to it.

Now, our customers think it’s time to take “autopaperspace” into the configurator age. After topography, paper is our most requested feature.

How we got here: I thought (incorrectly it seems) that sharing a link to a project was by far the most important thing. That web-functionality is frictionless. But that was making TestFit look good. It wasn’t meant to make our customers look good. And therein lies my own hubris. I’ll keep pushing for mobile viewing and sharing, but at the same time, will push our team to build a far better paper space solution: a PDF you want to send to your friends. All I can think of is a PDF with left and right scrolling to the same analysis of a different scheme.

I’ve seen startups (and large corporates) use tldraw to great effect. Perhaps some whiteboarding tool and customer branding will serve us well. Perhaps generate a massive grid and allow people to color on top of it with annotations.

So here is where one drawing lands: for one view on one sheet, scale and orientation are outputs, not settings. Compute them from the geometry and the printable area, and spend the user’s attention on what the sheet adds: whose name is on it, what it tabulates, which scheme it argues for.

One thing’s for sure: if we ever want to do DDs (design development drawings) or more, we will need to figure out a far more co-creative way of doing sheets and sheetsets. I’ll probably cover my thoughts on generating sets in a few months.