2017.02.27 Status update

status-update

#1

Hi friends,

Some quick status updates on Subform development:

Typography

In the last update, Kevin mentioned that we hadn't determined how far to take typography in Subform. I've since done a deep-dive on potential typography features (helped by your feedback). We've discussed the complexities and implications for the layout engine and culled the list into a rough set of priorities.

For the next release, we're sticking to the basics. Kevin has implemented a proper font family and weight picker, alignment, line-height, and coloring controls. No more CSS to set these! Yay!

(As an aside, if you haven't yet, check out Vincent De Oliveira's article on how CSS handles font metrics and line-height. It surfaces a lot of the details and decisions that we have to wrestle with when dealing with font rendering.)

Images

The current release of Subform only supports background images, which is less-than-ideal. Kevin and I originally had more traditional image handling in the app ("insert image" or drag-and-drop), but removed it due to unanswered questions about what exactly image types are, and how they should work in conjunction with the layout engine.

Many beers and coffees later, we've got image handling feeling pretty natural and consistent with the layout of boxes. Background images are gone and replaced by a single image type. Drag-and-drop is back in and we've added aspect ratio controls that are really, really awesome. In addition to generally preserving an image's native aspect ratio, you can make an image act as a background for its parent, or always fit inside of its parent. (similar to CSS' background-size: cover and background-size: contain properties)

File format / linked images

As a part of figuring out image handling, we've had to make some decisions about where to store the images that you add to a Subform file. After experimenting with a few different ideas, we've settled on images being store externally next to the .subform file in the file system. (Dragged-and-dropped images are automatically copied over.)

We like storing images externally, as opposed to embedded, for few reasons: smaller file sizes, less binary information in the .subform file, assets can be managed in the file system, and they're easier to check into versioning or replace. This generally similar to how Adobe's InDesign handles assets.

That said, there are still some complexities and unanswered questions around the user-experience of external images. We'll probably be asking y'all for some feedback on this soon.

Grids and direct manipulation

Last but not least, I've been working on an article that covers some of our design decisions around grid layout and has lots of fun lil' demos. I'll be interested to hear everyone's thoughts about grids in Subform before we finalize out the feature set. Look for the article in the next week or two.

Thanks for reading; have a great week!

Ryan + Kevin


2017.03.14 Status update
New Ui for Subform on its way anytime soon?
#2

I like your article about flexible grids and thoughts on it, that would be a nice change for grids!
I'm glad you're thinking about it early in the development, because it's a crucial thing for designing!

it would be a nice-to-have feature to be able to lock a grid, so I don't accidently drag the grid instead of an element, also because if I want my artboard to be wider, I could lock my grid and adjust artboard size. on websites I often want some whitespace on the left and right to be more representative, and I guess I'm not the only one who does that!


#3

Thanks for the feedback, Daniel!

I agree that accidental direct manipulations of the grid are something we need to avoid.
We're playing with some ideas around that as we speak.

On your second point, that's as easy as just embedding the grid in an element that's not the artboard. If you want the grid to always be centered in the artboard up to a max width, that's not a problem.