I know that Subform can export PNG images and minified HTML/CSS (not production ready) but it is currently unclear to me how to communicate to collaborators the rich, detailed information included in the UI we design in Subform.
Are the imperfect HTML/CSS and static image exports from Subform more useful to the developers who will have to code the UI than the design specs generated by design handoff solutions like https://zeplin.io , or https://avocode.com ?
Best
Since it's all supposedly based on intent, it would be really cool if it would export an annotated set of screens at various sizes. Perhaps looking similar to Sketch Notebook.
Things like (this is super rough):
"The main navigation should always be 16px from the top of the screen and be centered 16px spacing on either side."
"Each switch toggle should have 4px padding and be at least 24px below the previous toggle switch."
"[The {box} || Each {class}] should [ have || {condition} be ] {parameters}" or something much more clever.
The other thing I see working well would be 'export modes': different export methods that would output completely different formats based on intent, i.e.:
Styleguide export = like the above, but with extra pages outlining typography, color, maybe even each component in detail.
Prototype export = rough html & css that's just good enough to demo or first draft an interaction. Bonus points if we eventually get the ability to do fixed positioning or link between artboards.
Static export = similar to how Sketch handles it, as a 'stack' of screen sizes and image formats to be generated all at once.
Any others you'd want to add?
Those are all valid and useful deliverables. I am sure this subject will be up for discussion at some point as @Ryan and @kevin have said on the two live streams we participated in. I think the key point is that there should be enough design handoff options in Subform to support the most common design-to-development flows while improving on what is currently possible with the existing solutions I mentioned above (and many more).
How about free Subform Viewer application?
Then you can give your files to whatever person you want and they will be able to see and measure everything they need.
@Ryan, @kevin, what do you think?
A lot of the individual designers and teams we've talked to over the last year are using Zeplin (or now InVision Inspect) to this effect. There are some strong advantages:
But building on what @nickisnoble wrote above, I think there are a few downsides to the Zeplin-style inspector approach:
They don't communicate design intent or relationships between elements. (e.g. This button text label is 20px from the left side of the button. Is that padding? Should the text center if the button gets wider? Should the button be allowed to get wider?)
This would maybe be solved by an inspector that allows the developer to resize elements and observe behavior, but that's still a pretty manual, slow process.
They aren't very good at detailing what exactly has changed over iterations. Zeplin, for example, will post an automatic Slack notification when something's changed. But the developer still has to hunt down that, say, the font-size spec for a label on 1 screen out of 200 was changed from 14px to 15px.
In general, we've found that developers would rather have design changelogs that look more like code and can be integrated into version control systems like Git.
They don't really document design systems. A style guide is a start, but these inspectors are still heavily based around the concept of individual screens. For smaller apps that don't change a lot, that's probably fine. But for more complex work, development centers more on systems than screens.
But what if it will be the full featured Subform (where you can see all of the layout settings and other properties), but without ability to add, remove or modify anything? It will inherit all of the Subform features like version control, etc. and will enable to see all of the layout, components and whatever else will be available.
I think this would still be like @Ryan said above, it would be very much a manual process where the developer resizes elements and observes the behaviour. I do like the idea of that however but not for the developers and instead for the clients.
As a developer, I can see a use case for both. Text is probably a better way to document design systems and track changes. The current HTML export is better than nothing but it's missing a lot of the semantics; layouts appear to be baked to fixed heights, so it doesn't seem that useful as a responsiveness spec. I would love to see a human-readable document that contains all the semantic concepts that are present within the internal model of Subform itself (essentially a text version of a .subform file.) So classes and components would be broken out, then artboards, showing a full list of children and properties as designed. It sounds like this is what the current plan is for "code export."
However I don't think this will be a full substitute for a visual inspector. Sometimes, you just gotta eyeball it. We have been using Zeplin at work and it's been great for allowing you to jump between detailed element specs while keeping an eye on the bigger picture.
Subform itself is almost there in terms of having the minimum feature set I'd want as a dev from a spec viewer application.
Better measurement tools would be nice, at least being able to measure space between two elements or an element and the artboard. Though this might be less useful than in more static comp-based workflows that we're used to, as they don't convey the responsive behavior.