VW and VH support or alternative

#1

The problem
I'm trying to set a box's height as 50% of the screen height which works fine if the artboard is fixed to the size of a devices screen size but it doesn't work if say you're designing a web page with more content and requires scrolling.

Potential solution ideas
ability to scroll within artboard, or
abitlity to set device and artboard size as two different inputs. So iPhone 6 device so it knows to reference the vh as 667 but an artboard that's 2000px tall.

I'm sure there are better ways, those were just my first thoughts.

Screen recording

Em and Rem support
#2

Scrollable area is something that @kevin and I have discussed a bit.

On one hand scrollable areas are a common element in UIs, both on the web and in native apps. If design tools should reflect the medium you're designing for, it seems like scrollable areas should be present.

On the other hand, it opens up a lot of questions about expected behavior, usability, and performance:

  • Can only artboards have scrollable overflow? Or can any element have it?

  • Should scrollable area be allowed on both x- and y-axis? How will that affect the ease of working with the layout system? (e.g. easy to end up in a scenario where most of the design is hidden off screen; hard to understand/visualize how the layout is working)

  • Are scroll positions saved somehow? It's easy to envision setting up multiple artboards in different scroll positions and then being upset when you reopen your file and they're different.

  • Do scroll positions export? How?

  • How does it affect performance? (Multiple artboards, each with scrollable areas of thousands or tens of thousands of pixels.)

It also raises the question about delineation between visual design and prototyping. What's the effective difference between just making a 4000px high artboard and a 667px artboard that scrolls to 4000px? Is it just that you want to demonstrate behavior in the fashion of a prototype? Or are there UI design decisions (layout, styles, etc) that are impacted?

#3

@Ryan Wow, yeh there's a lot of implications to think about there.

I think to answer some of those the first one that needs to be answered is the last point between visual design and prototyping. My original suggestion for a scrollable areas isn't for prototyping/visualising reasons and it wasn't even intended as a request, just a thought as a potential solution. I'd be quite happy to just have 4000px long artboards as this is currently what I'm used to in Sketch. The issue arises though when elements of coding are introduced such as width and height being able to be set as percentages of the artboard which only works when the artboard remains roughly the size of screens — I doubt many phone makers will be making many devices with resolutions of 375 x 4000 any time soon :wink: The main point is what would the best solution be to solve that problem rather than how would a scrollable area work.

#4

Sure. Just to make sure I'm understanding your question correctly:

There's a scenario where you're designing a mobile version of a website. You start working at a relatively small artboard size, say an iPhone 6/7 @ 375x667px.

As the design takes shape, you expand the height of the artboard to accommodate the content further down the page. So you might end up with a 375x4000px artboard.

If you set an element's height to 50% of its artboard parent, that element just went from being 187px to 2000px when the artboard resizes. But that wasn't your intent—you wanted it to remain at 50% of the viewport, not the total content size.

Is that right?

#5

@Ryan Yes exactly that :thumbsup:

#6

Yeah, so we'll need to add that question to the list above:

  • Should the notion of an artboard and a viewport be different things? (i.e. your original idea of device size and artboard size being two different inputs)

In the short term, a hacky workaround using the example above: you could make a freeform container that acts as an effective viewport. Give it a top value of "0", stretched to "0/0" on the left/right, and with a height of 667px. A child of that container set to 50% height would stay at 187px, even if the artboard resizes. You'd have to change the height value to simulate different viewports, but that could be done via component state.

#7

Please consider supporting ALL CORE HTML UNITS. http://www.w3schools.com/cssref/css_units.asp
This tool will not be useful to me until it does.

#8

Subform is not going to be an web IDE and we'll never be able to support the full semantics of HTML/CSS.
If you need a tool specifically for web, you may want to take a look at Webflow, Dreamweaver, or just start reading the W3C specifications for HTML and CSS

Import CSS stylesheets to impact designs
#9

If that is the case, can I get a refund? I don't expect it to support everything but I do expect it to support core basics like units of measurement.

#10

I thought Subform was pretty clear that they're exploring a new approach to digital design; any tie-ins to HTML were just about reusing good ideas, not reproducing HTML wholesale. Where did you see Subform list core html unit support as a promised feature?

Lots of kickstarters don't even deliver. Few give you the chance to shape the product.

#11

Not all units are suitable for the screen. Though I do know there would be some use cases for using print based units when designing a web page with print media queries.


Src: https://www.w3.org/Style/Examples/007/units.en.html

#12

I think artboard and viewport should be 2 different things. SVG I believe works with a canvas and viewport which is explained really well here. https://sarasoueidan.com/blog/svg-coordinate-systems/

A viewport would allow something like vw + vh which should allow vmin + vmax (never thought of a practical use for those ones yet) with the min/max settings already in place. The underlying viewport data could then be used to also create fluid typography.

#13

Viewport and viewBox in SVG is a nice analogy, Wade.

That article surfaces the complexity in the model—it's pretty unintuitive and confusing when you're used to just dealing with artboards. On the other hand, it is more consistent with how UIs are actually built.

It's something we'll really have to think about deeply before implementing anything.

#14

It would indeed get complicated to design something which has multiple parts that can scroll independently. I think this is one of the reasons why UI design and prototyping are such separate disciplines in the current state of things.

However, here's an idea that just bounced in my head (I haven't fully considered all implications so forgive me if misguided): while building a design, all containers that are not freeform will expand to fit the size of their children, ignoring its predefined size. This applies to every level, including the artboard level: if you put a 1000px high rectangle into a 500px artboard, the artboard will expand.

However, there would then be a setting/toggle to make layers snap back to their expected or predefined size. At this point, any children that overflow their parent will trigger scrolling in their direct parent.

It makes sense in my head, but I can already see some shortcomings in the approach, if anything in the introduction of two different modes for the whole application. And modes aren't generally great to get to grips with.

#15

To play devil'a advocate however: most of the issues with defining scrolling behaviour can be solved with a thorough communication process between designers and developers. Maybe subform shouldn't try to fix communication shortcomings.