2017.03.14 Status update

status-update
#1

Hi friends,

Quick status update:

Grids!

I mentioned in the last update that I was working on an article about our thought process for grids in Subform. It ended up being pretty long, so I broke it into two parts:

The first part, "Are grid systems still relevant in digital product design?", covers a brief history of grids and how their print-legacy doesn't always translate well to interface design:


The second part, "Better grid systems in UI design tools", looks more specifically at how Subform makes it easier to work with grid systems:


Kevin and I spent much of the last two weeks fleshing out a lot of this grid layout functionality. So the exciting news is that all of the demos in the second part were made using our latest internal build of Subform. Like this one:

dribbble.gif800x600 1.14 MB

As always, we'd love to hear your feedback on these ideas.

HUD

In addition to some clean-up work on the grid functionality, Kevin and I are focusing on the app's HUD (heads-up display) this week.

The layout engine's shaping up really nicely, but we've found that it's really helpful to have some contextual information about layout on the artboard. So, think of the HUD as "smart guides on steroids." (The grid scaffold overlays from the demos are an example of some of this HUD functionality)

Thanks for reading!

Ryan + Kevin

Any updates for mid March?
#2

I'm not sure how I missed this, but the updates are looking awesome! Love what you've got going with the grid layout functionality. I can see that padding (gutter) you added being a huge help down the line for products.

I'm excited to see how things progress when the next build comes out of dev!

#3

I have the Subform version 0.0.0+bb1f015 installed. Is this the latest version?

#4

Concerning grids, I've noticed in the article that there is a problem you seemed to avoid. Sometimes the best approach for responsivity is to reduce the number of columns. You have it in the problematic example in the article itself.
How would you go about it in subform? Creating a separate artboard?

Maybe there could be some way to index the blocks (modules) based on priorities and when you reduce number of columns they would get consolidated and sorted by this index. Zero would mean to discard the block.

Or having separated 'states' of the same element for different grids.

Thanks for consideration.

#5

@ondrej.rytir I think there are a couple of issues here, so let's unpack the problem a bit. (And if I'm misunderstanding your questions, please let me know.)

First is the tactical issue of removing columns from a grid in Subform: what happens when you delete a column (or row) that has content in it? Adding columns is pretty straightforward, everything just shifts over a little bit. But that doesn't work when you remove one.

Options:

  1. We could just prohibit this behavior. If there's content in a column, the app tells you that you can't delete that column.
  2. We could try to intelligently reorder the content based on the new column configuration, but it's pretty tricky to know the designer's intent. (more on this in a bit)
  3. We could just let the content in the deleted column stay as-is, thus overflowing (breaking) the grid container.
  4. We could throw an error on any elements that reference the now-deleted column. (This is what we do now in Subform)

None of these options are perfect. We picked #4 because:

  • Grid content not referencing the now-deleted column still displays properly
  • No content "breaks" the grid
  • Subform doesn't prevent you from doing something you might want to do
  • It makes it pretty obvious which element(s) need to be updated to fit the new grid configuration.

That said, you can only delete or insert columns or rows from the end of the grid right now. It's not hard to imagine wanting grids to behave a little like spreadsheets, where you can insert, delete, or reorder a column or row anywhere. But that adds even more complexity to reflowing content, so we're avoiding it for the time being.

Second is the larger strategic issue of defining multiple grid layouts for different device sizes. This relates to the breakpoints discussion. The designer ostensibly wants to specify two things: 1) how the grid configuration changes and 2) how the content inside of the grid on that particular screen adapts to the new grid.

Maybe there could be some way to index the blocks (modules) based on priorities and when you reduce number of columns they would get consolidated and sorted by this index. Zero would mean to discard the block.

So this relates to the aforementioned "We could try to intelligently reorder the content based on the new column configuration, but it's pretty tricky to know the designer's intent." Something like the priority weighting that you mention here could work, but it adds a lot of cognitive overhead to the designer. What happens when there are priority conflicts? Do you have to set priorities even when you have no intention of changing the grid configuration? Etc.

Priorities are one of the downsides of constraint-based layout solvers and we're been able to avoid them to good effect, so far.

Introducing this sort of conditional logic, in whatever form, is also something we want to avoid in Subform. It's very easy to end up with a complex set of rules that are hard to debug, hard to communicate to developers, can have unintended side effects, make it more difficult to work with components, etc.

At a certain point, we’re just making a lousy simulacrum of code—and that’s not the strength of a visual, direct-manipulation tool.

We think the best way to work is to just be explicit about different layout configurations. If there are three grid configurations then those should be specified separately, either as different states or artboards.

The nice thing about the layout engine is that you aren't designing to a specific device size, but rather a specific layout configuration. A 12 column grid will adapt to a 375px wide or 1920px wide artboard. In Subform, you can keep playing with sizes and determine where you think the layout stops working. (This is often referred to as "content-based breakpoints.") Then it's time to think about how the layout can work with a 8 column or 4 column grid, etc.

This extends not just to the grid, but the actual content of the design, as well. Rather than trying to codify conditional logic that tells a navigation to change when the viewport is less than an arbitrary width, the navigation should just have two states. The 4 column grid layout would then use the "condensed" state, for example.

#6

@Ryan Regarding this concept (which I agree is an acceptable solution for Subform), how do you envision the process of creating the additional "breakpoints" working exactly? Will we be creating a new artboard for each column configuration (breakpoint) or will we be creating different "states" of the same artboard with the different column configurations that load as you resize that artboard (like a responsive website is rendered in the browser using CSS breakpoints)?

#7

Aside from really wanting to avoid the pitfalls of conditional logic, my instinct isn't to be overly prescriptive about breakpoint workflow. I think both additional artboards and states can work... or a combination thereof. It's really just dependent on preferences of the designer (and how the developers prefer their deliverables).

The nice thing is that Subform doesn't require a completely separate set of semantics to define breakpoints—like, say Axure's adaptive views. Anything can be a state, artboards can be resized at will, you're not forced to make decisions about pixel widths before you're ready, etc.

That said, I'm sure there will be ways that we can make the process easier to manage (and handoff to developers more organized). We're super open to feedback and ideas on it.

#8

Giving designers options with their workflow is a great mindset to have, and if the layout engine is flexible enough to allow the two options (using multiple artboards or states to demonstrate changes in the layout at different screen sizes), I'm cool with that. :sunglasses:

I don't think I can give any more feedback on this subject before a test drive. When will we have a chance to get our :raised_hands: on the latest version of Subform?

#9

Thank you for the elaborate answer.

Regarding column operations, I agree that the intent is not clear. Maybe asking the designer would be the best solution. Something like a prompt "Delete the content or detach?", or just detach a select the elements for easy deletion afterwards. An error message doesn't seem very helpful but I would have to try it out myself, maybe I don't understand fully.

Also switching columns seems pretty straight forward and would be very useful in some cases.

I agree that different states are the more practical a simple way to go. The only thing I'm worried about is a translation to css. I always imagine a future when a design tool will be also able to create perfect css representation. I was hoping Subform would be on this path. So I guess these states (or artboards) could translate to css media queries?

Finally there is the issue of maintaining the same content across these multiple states. I guess this can be solved best with your components/symbols, if they are easy enough to use for this.

#10

We've touched on this in some other topics, but our goal is for Subform to be a platform-agnostic UI design tool, not a web IDE. We've made decisions in the layout engine, for example, that prioritize expressiveness and coherence over CSS compatibility. (Sketch also runs into this, to some extent. You can set multiple borders in Sketch, but the exported CSS ends up just being list of conflicting border rules.)

If 1:1 CSS compatibility/export is an absolute requirement, I'd suggest IDEs like Webflow, Espresso, or Adobe Muse.

My experience is that most exported CSS ends up getting refactored anyway—styles get put into preprocessor languages like Sass, broken out into React components using projects like Tachyons, and so on. Every development team has a different stack and workflow.

What's most important isn't perfect export, but rather that the front-end developer(s) have easy access to the style attributes from the design files. There are multiple ways to accomplish that—and it's something we'll be working on more deeply in future releases.

#11

@Ryan I'm sure this isn't news, but I'm quite giddy to try the updated software, now with many things Grid. It's officially been 1 month since the last update. Any news on either when the next update will be, or better yet when you and Kevin will release the latest version for us to experiment with?

#12

We just posted an update, sorry for the wait! We get heads down on work and it's easy to let them slip. Thanks for keeping us accountable.

We don't have an exact date on the next release yet, but we're getting close and eager to ship. As soon as we can. :slight_smile:

#13

Thanks for the clarification.

I understand the platform agnostic point of view, but it's hard to appreciate when web is such a massive (and also multi-platform) medium. I would imagine it's the predominant interest of this community. Maybe I'm wrong, I'd love to see the data.

To be frank, the argument about the need of refactoring sounds like a status quo bias. It doesn't need to be this way. If we can get web export right, we'll gladly forgo the coder's job entirely and be all better for it. Then more emphasis will be put on the declaration of intent among designers. From my experience it will be hard to convince my colleagues to spend more time 'drawing' a prototype, when it doesn't save significantly more time elsewhere. We'd rather work on the final product and not worry about the coder doing a good job afterwards, doing circles of reviews, revisions and so on. This broken process is with us so long that I feel frustrated even by thinking about it. :sweat:

Webflow seems closest to usable right now, but for the design process it was just too slow for us. Freeform manipulation felt like a second class citizen. I was hoping to find a middle ground in Subform.

Thanks for any further thoughts on this topic. I feel like we're talking about the future of the whole web building industry here.

#14

Sure. The thing is, even the web's not a static target. The web today isn't the same as the web 5 years ago and it won't be the same 5 years hence. W3C standards change, browsers change, technology stacks, libraries, etc. Right now, we're really just focused on getting the fundamental abstractions right. If we do that, we haven't backed ourselves into a corner because, say, all of the sudden the CSS Grid spec changes massively. (This happened with flexbox... three times.)

I know, I know—we're right there with you! And this is what we're working to make less painful, we just don't think the web IDE approach is the right one.

The closer you get to code, the less direct manipulation freedom will be available. There's just no perfect middle ground where the tradeoffs go away, you're always sacrificing somewhere. Code integrity, code manageability, expressiveness, ease of use, etc.

It reminds me a little bit of 3D modeling: lots of industrial designers will use surface modelers at the ideation stage, because surface modeling can be more expressive in terms of form and less strict about what's possible. But surface models don't translate well to production: they don't describe actual solid objects with volume. Some really helpful design tools, like parametric features, just aren't possible to implement in surface modelers. You gain expressiveness, but sacrifice manageability.

The reality is that industrial designers use both types of modeling. Different tools are suited for different tasks and product types. Switching back-and-forth is often necessary.

Some products don't need the expressiveness of surface modeling, so the designer might just start with a solid modeler. (This is loosely analogous to designing a simple website in the browser.)

Surface models can be relatively easily translated to solid models once major form decisions are made, and that's the zone where the mechanical and electrical engineers and the industrial designers can all collaborate.

To extend this imperfect analogy, I think that we're rapidly moving to a world where we can more easily translate design decisions between a surface model (direct manipulation, visual design) and a solid model (code) bidirectionally. That's going to be a more sustainable approach than trying to cram everything into one "Swiss Army knife" tool.