What happened to HTML export option?

#1

It used to be there, but I can’t seem to find it

#2

Hey @ldubya, thanks for bringing this up. We took out the CSS and HTML export when we rewrote the layout engine and we’ve been meaning to discuss with the community how it might be reintroduced.

HTML export is fairly straightforward—everything in Subform is contained within a tree hierarchy, which is just like the DOM.

CSS is trickier. CSS is an amalgamation of styles (borders, colors, etc) and layout (floats, absolute positioning, flexbox, css grid, etc).

Exporting styles is relatively easy… this is essentially what a tool like Sketch does when you “copy CSS attributes.” You’ll get something that looks like this:

/* Rectangle: */
background: #00C1FF;
border: 10px solid #979797;
box-shadow: 0 2px 4px 0 rgba(0,0,0,0.50);

There are some edge cases where this doesn’t perfectly map 1:1 with what you’ve created in the design tool: mulitiple borders are a good example. CSS doesn’t support multiple borders, so if you create them in Sketch, you get two conflicting style rules:

/* Rectangle: */
border: 10px solid #979797;
border: 5px solid #F11212;

Overall, though, we can execute this approach in Subform without too much difficulty.

Layout export is harder. Subform’s layout semantics—while similar to absolute positioning, flexbox, and CSS grid—aren’t exactly the same. This means we’d have to introduce some sort of translation tool or some pretty heavy hacks to get the layout output to appear correctly in the browser.

Like Sketch or Photoshop, it’s not our intent to make Subform a web IDE that exports a fully-formed website ready for production—that’s more the domain of tools like Dreamweaver and Webflow. So we’re reluctant to spend time on export features that chase perfect export fidelity to production web code.

Given that, we’d like to know more about your intended workflow and use cases for CSS/HTML export. Is HTML export (the markup structure) still useful for you? CSS styles export (a la Sketch)?

#3

What made the HTML (and CSS) export awesome was being able to quickly rig up and send a clickable, scrollable, prototype.

with the outputted HTML (and styles), you could hook up JS events to the elements and essentially take the artboards and turn them into prototypes that people can mess around with on their own device. You could get feedback and then get back to construction.

And I think it’s important to note that sending the Subform document to someone who has Subform wouldn’t quite accomplish this, since you can’t rig up events inside of your Subform designs. So the HTML / CSS export was not the output that I would necessarily send, but I could take it and add interactivity on top of it, and then I’d finally have what I want to send to others.

The HTML export would help, but without the styles it would still take a decent amount of time to get the prototype ready. And then if I make changes in Subform, which are very much liable to be breaking changes this early in the prototype phase, I’d need to go back and try to refactor the styles and it just wouldn’t be a quick workflow. So I guess rapid prototyping is the goal, so that I can get feedback quicker and iterate quicker, and have the best work ready for development.

I know that Subform is meant to be a better, self-documenting design tool, that can be handed off to developers so that the developers can get a better feel for what the designers intended (and the designers can get a better feel for the limitations that developers have)… And that’s extremely useful. But I think enabling rapid prototyping to work out some of the major ui/ux before a developer even writes any code would be useful as well.

#4

That’s an interesting use case, thanks for clarifying it. If responsiveness of layout isn’t a concern, it’s definitely more possible to accomplish this.

Before we’d implement something like this, though, I think we want to hear more feedback from folks on how they want Subform to integrate w/ prototyping workflows. It’s not clear to Kevin and me what the most useful feature set would be: if it’s more robust HTML/CSS export for quick-and-dirty JS prototyping… or if it’s better layer export integration into InVision or Framer or the like.

#5

I’d say that I’m not married to the HTML and CSS so long as I can rapidly prototype the functionality that I want to show. JS being a complete programming language gives the most flexibility compared to anything else, and being able to not have to use InVision or Framer or another subscription service to prototype is also a plus. But yep the end-goal in this scenario would be rapid prototyping.

#6

My thoughts on this topic are as follows:

  1. I think Subform is a tool for UI designers who don’t necessarily know how to code but need to communicate the complexities of a responsive UI system to stakeholders and specifically developers
  2. What deliverables will be possible from a Subform document have not yet been defined to my knowledge see my previous post
  3. More power to Subform and the community if it is possible to generate “non-production” code that can be enhanced with JS by capable Product Designers to create interactive prototypes, but Subform must allow designers at the least the ability to export layered files (PNGs, SVGs…) that can then be used in prototyping tools such as InVision, Framer and such. It would be even better if some sort of integration existed with the most popular prototyping tools that would allow the ability to change the properties of components exported from Subform within those prototyping tools (as is possible with Sketch and Principle and Kite Compositor).
#11

Thanks for the feedback, @wiredframe. (and welcome aboard!)

An inspector (a la Avocode, Zeplin, Sympli) is something we’ve had a lot of folks ask for, whether that’s integration with those existing tools—or building one into Subform. If we go that route, I think it can do a pretty good job replacing the old HTML/CSS export feature.

It’s relatively straightforward to translate Subform styles to CSS and display them in the inspector (as these tools will do with Sketch/Photoshop files). We can also list global style classes, so the development team doesn’t have to individually check each element to get CSS values.

Ideally, the front-end developers would also be able to inspect the tree hierarchy (equivalent to the HTML DOM) and layout rules of components and artboards. They can then decide how to translate those rules to production code: whether that’s Flexbox or iOS AutoLayout constraints, etc.

There are some unanswered questions about how exactly we’d implement this. Existing inspectors aren’t really equipped to show these layout rules or have resizable artboards, so integration might be tough.

Regardless, I agree that a means for more useful developer handoff is a big missing piece in the Subform story right now. It’s definitely on our list to tackle before we move out of the beta.

#12

Hey Ryan, Kevin,

So I’m a big proponent of making the layout model match the web layout’s behavior, so that you can have a 1:1 mapping. And I know that that’s a lot of work too, but hear me out:

  1. HTML & CSS export allows for, as @Idubya said, easy prototyping with just some minor JS additions. Especially with something as simple, clean and straightforward as UI Lang: http://uilang.com/
  2. More critical is that HTML, CSS and JS interactions are a lot better for complex prototyping than InVision is. A complex web interface can have many different panels that toggle, slide in & out, or otherwise behave independently of the screen as a whole. That kind of freedom in interactivity is a TON of work to do in InVision, but almost free in effort in JS.
  3. The focus of Subform doesn’t need to be “being a web IDE” but that doesn’t mean that the Web’s DOM and layout model is bad. Especially with the support of flexbox & grids, it’s now extremely capable for just about any interface possible (and that’s not to even mention Adobe’s CSS Regions stuff). It also translates really well for ReactNative, which allows devs to create interactive apps or simple prototypes directly for non-web platforms. That’s a huge gain that you get with HTML & CSS export that includes the layout.

So, here’s one more big vote for CSS layout support in export. :slight_smile:

(Could also always look at how ReactNative translates its layout rules to iOS etc.)

#13

I think these are good points. It seems like there’s a lot of frustration (particularly among front-end developers) around the fact that the myriad of prototyping tools don’t produce production usable artifacts and are essentially a duplication of effort. That said, we haven’t encountered an overwhelming amount of folks who are prototyping in HTML/CSS/JS.

In the near term, we’re not going to be building any prototyping tools ourselves—at least in terms of what’s widely-available on the market (animation, hotspot screen linking, etc.). Duly noted that your request for interop with a prototyping workflow is this sort of export. We’ll keep our ears open on this from other users/teams.

At a conceptual level, we think the flexbox and CSS grid layout models are pretty great! They’re capable of describing most layouts and are much less complex that constraint-solvers, especially for anything beyond the simplest layouts. Subform’s layout engine sticks pretty closely to those two models.

It’s funny you mention ReactNative, because it doesn’t actually use the CSS flexbox spec, it uses a custom-written layout engine from Facebook called Yoga. Yoga sticks reasonably close to the flexbox spec, but Facebook has said they don’t intend to keep it 1:1 where it doesn’t meet their needs.

One example is the addition of the AspectRatio property. AR is something that’s sorely missing from the flexbox spec—it’s one of the reasons Kevin and I moved away from 1:1 compatibility with flexbox in the early development of Subform. I suspect Facebook’s team went through the exact same learning/thought process.

So that’s a case where Subform’s layout engine is actually closer to ReactNative’s layout API than flexbox. :wink:

#14

I vote for some form of responsive export option too. Whether it be HTML/CSS, or some other function like a Subform-hosted UI presentation (a premium service option perhaps?).

#15

@subform7 Thanks for the feedback. Are your use cases similar to the above discussion? Would you use this for prototyping? Dev handoff? Something else?

#16

Prototyping indeed. The developers I work with would rather not have to open a UI app if at all possible. Give them a command line, cup of coffee, and some static mockups to go off of and they’re happy. They’ll let their frameworks do all the responsive thinking.

I’m investigating Subform as a better UI design tool to improve stakeholder adoption. Static mockups through InVision or Prevue help, but Sketch and Photoshop already do static mockups well. What we (I) need is a tool to prototype responsive mockups for remote clients to easily experience and approve products. If dependence on static presentations is still required, Subform’s responsive contributions to the design process are inhibited.

#17

Are hotspot-style prototypes what you’re looking for? (Click/touch this area, go to next static screen mockup) Is the issue just that external stakeholders want to see the mocks sized appropriately for whatever device they’re using?

#18

Are hotspot-style prototypes what you’re looking for?

Invision’s options are pretty thorough, but yes, how do we get our clients to see their project sized appropriately for the device they’re using? Currently, nothing like this exists.

Invision is the best option out there for creating clickable mockups with Adobe XD a close second and closing in. XD is not only a prototyping tool but also a publishing platform but InVision’s hotspot controls are pretty powerful. Of Adobe and Invision, InVision may come out ahead however as they approach the launch of Invision Studio early next year with a tool that’s looking pretty robust as a responsive UI design tool. https://www.invisionapp.com/studio, and, coupled with their newly upgraded mockup presentation service it looks promising.

I guess I’m wondering how Subform is going to keep pace with InVision Studio in the end? I feel like Subform would have to ramp up its current offering quite a bit by the time Studio launches, because, if Invision’s sneak peeks are indicative of the launch product, it looks pretty solid. Ultimately, if Subform becomes the tool we all want it to be, and offers the unique capability to present responsive mockups to clients, it may stay at the forefront of my UI design dilemma.

#19

Just getting going with Subform and wanted to check on the issue of HTML/CSS export. In reading through other posts on the forum, it seems as though Subform is not looking to add the ability to export code that is ready to hand off to a developer who makes it production ready (optimize, add interactivity, etc.)

Would you the builders say that’s correct at this point? If so, my feedback won’t be terribly helpful here as our major use case is getting design to usable code quickly.

Thanks.

#20

I think it’s safe to say that, whereas time is a limited resource, any system that helps you get to your end-goal faster is a better system. (Whether one monolithic system or a stack of compatible smaller systems)

I think it’s also safe to say that things designed using subform will hopefully one day be scrapped entirely or wired up and go into production.

If Subform can make it so that we get from point A (design) to point B (working prototype? production app?) faster than the current best practices / tech stacks, then we can do away with any tool, no matter how dominant they are in the market. I don’t think we care for Photoshop or Invision or whatever, we only care for what they enable us to do (and of course, price fits in with this philosophy too, whereas “not making me/us go broke” is excellent functionality).

So, what can Subform do to get us from A to B faster than before?

And, what exactly is point B? Is it a working prototype? or is it a production app?

Maybe there’s a point C (usable code, as @emcdaniel puts it) that’s just as important as point B (usable prototype), and we’re trying to get from point A to point B as quickly as possible, and then point B to point C as quickly as possible. So we get to B (usable prototype), and get feedback and decide to 1) go back to A (design) or 2) scrap the whole project entirely or 3) continue from B to C (usable code).

The way that subform accounts for spacial relationships between objects and responsive design and component states, is revolutionary for a product design tool. Static designs have to be reasoned about in a way that designs that were never static to begin with don’t require. It’s what makes Subform interesting from a product design perspective. No more pushing pixels. Things will reflow to fit their containers and spacial relationships. That is pretty freaking magical. It expresses more design intent and reduces the amount of confusion, and so it ultimately saves time. Definitely a plus when doing A (design).

But that doesn’t necessarily mean that it helps us go from A (design) to B (prototype) as quickly as other tools. I feel like HTML+CSS export helps us get from point A to point B faster than there not being HTML+CSS export. And I think, with more and more designers learning scripting languages to express their designs better (framer), there may be a compelling case to learn a language that is much more capable (javascript) and useful outside of design. So someone who may build something and write code to make it interactive may choose to go with ([Subform’s layout engine] + [Javascript]) over ([Framer] + [their proprietary language that has literally no real-world application outside of the framer box and requires a monthly subscription to utilize]). It would be entirely possible to construct a javascript library that functions much in the same way as framer’s language to add movement and interactivity to your designs. I bet there are already some lightweight javascript libraries with a simple intuitive API that would enable us to handle all of the animations and state transitions that we’d use for prototyping. Could this be what @farukates mentioned earlier (uilang.com)?.

But what about going from prototype to development? Yes, there is an infinite amount of ways that developers like to work. However, developers like to have designs to go off of, whether they’re re-building from scratch or just integrating them. If a developer felt that the components of the prototypes are constructed in such a manner that it takes less work to take the components and use them than to re-build them from scratch, then he probably will choose the path of least resistance. And HTML+CSS export is a W here as well. But if they’re designing solely for native, using native lang, then they will have to build from scratch unless what is exported is in the same native lang, and also requires less effort to integrate than building from scratch requires.

Even though there’s only 16 posts here, this thread is in the top 10 view count wise (release-threads aside), so we’re definitely interested in seeing how this feature develops. Time is money and I think saving time is the key to figuring out the right implementation of this feature. We have to figure out what exactly we spend a significant amount of time on, and if Subform can make it so that less time is spent doing that to achieve the same outcome.

#21

@emcdaniel Welcome to the forum and thanks for writing!

To avoid burying the lede: The upcoming release (in a week) will have CSS style and non-responsive HTML export, with more planned over the next few months.

Your question is quite timely —the past few months Ryan and I have focused on ergonomic features like drag and drop, clipboard interaction, and image import, since a design tool needs to feel fluid and flexible enough to let you explore ideas.

But design ideas can really only be tested in the production medium: on a real device, hooked up to realistic data, interactions, animations, etc.
Some tools let you play with toy simulacra — Adobe XD duplicates rows of “data” when you resize a table, “hotspot” prototypes, and even Subform’s “stateful components” — but these simulacra are all quite limited.
They can never capture the generality, power, and specific capabilities of a given production medium.
What’s worse, these painstakingly constructed simulacra can’t be easily translated into production, so they often end up to be a waste of time.

The only sustainable approach is for Subform to integrate directly into the production workflow, so that you can get an idea into production faster, where it can be tested and iterated.

There are a lot of details to figure out, since production is complex:

  • Do implementors want to see compositions (artboards) or just the reusable pieces (components) listed out separately?

  • How do we handle semantic differences? The upcoming HTML export is non-responsive because Subform is more powerful than HTML/CSS right now.
    We could compile Subform designs to flexbox if we add a ton of extra containers — but does anyone want that? For production? For prototyping?

  • Should we have an option for Subform to “disallow” constraints like aspect ratio that cannot be translated easily onto the web?

  • Should we ship the Subform layout engine as a runtime dependency of the final app, similar to what the React Native folks do?

We have some ideas for a path through these questions, but much of it depends on what folks’ production workflows are and the problems they’re trying to solve.
I’d be happy to chat with you and/or your implementation folks to learn more about your use cases and see if we can build some features into Subform that give you the capabilities you need.

Feel free to private message me on this forum, or email me directly: kevin@generalreactives.com

#22

@kevin thanks a lot for your response and for listing your thoughts and reasoning behind your decisions up to this point. For the various reasons you mentioned in your reply there is yet no tool out there that accomplishes all of our wishes (intuitive design tools, realistic responsive behaviour, interactivity and a fluid handover to production). From my personal experience with large design teams were we work with sketch files and shared libraries, do stakeholder alignment and feedback in linear and very limited Invision prototypes (at least there is an inspect mode to read measurements and deliver assets) and finally endure endless rounds of iterations due to missing interactivity, the strongest missing link is still the native experience on devices to discuss design decisions and get approval from clients or stakeholders.
I have not yet met two dev teams which have the exact same workflow and implementation mode. So while you guys are building a design tool with amazing capabilities the ability to produce production ready code would require to tackle all the dev related problems with your technology. If I were to decide whether I should focus on integration of interactivity or on export of production code I would always choose interactivity.

Looking forward to the next few months and all the magic you guys have up your sleeves. :mage:t2:

Btw. lets not forget the size of the teams that work at Invision or Adobe compared to your team. So keep doing your thing guys. This is for sure gonna be the real deal one day. Just a gut feeling. :slightly_smiling_face:

#23

@adamwallat Thanks for writing and the kind words.

I’m a bit confused, though — you say

but isn’t the only way to get a native experience on device to…build the app with code?

Put another way: It’s not clear to me how to enable something better than Invision’s limited prototypes without embracing the power/complexity of the production medium.
(If there is a better way, why isn’t Invision doing it?)

Right now it seems like the strongest tool for enabling designers to build complex interactions/prototypes is Framer, and they do it by helping designers learn to code.

Of course, I may be missing something. Definitely open to ideas/suggestions/references to specific features that you think could form a “middle path” between these two options.

#24

@kevin sorry if my thoughts were a bit confusing. I totally agree that the best way to build a native experience or at least a web based preview of some kind is to embrace the complexity of the medium.

I was just trying to say that I would rather focus on being able to prototype the interactions and Navigation of a an app or web experience than delivering production ready code.

So if on top of the current features of Subformapp I can link all my screens together and trigger state changes and transitions without a timeline (like you can do in framer) then I would only use a vector tool (not really important which one) to build assets.

The middle path then later could be something like an inspect mode or a code review mode for devs to make sense of it all.

Anyway I am sure you guys are cooking up some wild ideas! :lion: