@devinelston, with regards to editing elements and the placement of controls, at this time at least we won’t be looking at any sort of re-mapping. The current way things are mapped is due to a couple of factors:
- The process to actually go in and map controls to an element is insanely time-consuming, so to mitigate this in different ways we have different types of control “mixins” we can add into various elements (i.e. groupings of common controls). This works at different levels…at a very base level, we have controls like Padding or Margin which include the 4 unit sliders along with the lock toggle. Some mixins are groupings of controls many different like all our typography options as these are typically always implemented together. At a very high level, sometimes mixins include common control groupings across elements. Without some of these abstractions…it’s very possible we might lose our minds keeping up with the minutiae of getting everything in place correctly in all the right spots, haha.
- Another more practical facet of this was at the time of implementing the current mapping scheme, our philosophy was that of trying to keep various aspects of an Element grouped together. Take a Button, which is quite multi-dimensional as it can contain an optional graphic, optional text (two layers), optional particles, et cetera. So we didn’t want to have say an option to add a graphic at the beginning of the button that is variably bringing controls in/out towards the end of the Element that you’re not seeing. With the content and styles grouped, you at least can see that adding a graphic adds in a bunch of additional controls right there that you can now style. I realize this brings up some friction as you mentioned, but it’s a bit of a give and take.
These things aren’t to say that at some point we wouldn’t be open to streamlining this in some way, but to your other points perhaps there are aspects of inline editing we can improve, et cetera. Hopefully that helps provide a little more context at the moment, but the main factor for this right now is that it simply wasn’t part of the scope of this release initially, and we’re working hard to keep it tight and focused so we don’t keep pushing the goalpost, but we certainly hear the feedback here.
As for the editors, we hear you all loud and clear and our idea at the moment is to make these work more like a floating workspace moving forward. The thought is they will be able to be resized on both the X and Y axis to work best for your flow and placed anywhere on the screen.
The idea of a “+” for adding an element is interesting and I can see the pain-points of switching to the Elements tab, adding something, and it switching to Inspector if you’re just trying to add a bunch of things really quickly. While I can’t say for certain if this is something we can get in on this cycle, it’s definitely an interesting candidate for the revamped toolbar at some point. I’ll think some on the idea of a timeout as well as a stopgap perhaps…my only concern is that it might feel “unexpected” for some users. Perhaps another stopgap would simply be a preference: “Do you prefer to stay on Elements or goto Inspector when adding an Element?” That would give some more control over the workflow.
@strobley and @michaelbourne, as for this release, we will likely not be doing anything regarding images simply due to the fact that it was not part of our initial timeline to begin with. We absolutely hear you all though that it’s a big piece to bring in and it has been noted to be part of a more substantive discussion for a future release.
@Misho and @RubberDuckers, with regards to colors, I’m not sure that getting in some type of hierarchical management will be possible at the moment, but I’ll speak with @alexander more about this next week. The idea of at least organizing colors coming in from a template into something different is interesting, but there’s more to discuss there and see any potential downsides. As for bringing in ready-made Elements with colors and things doubling up, one thought there on a strictly procedural level is to simply omit any color palette assignments to colors for these types of “library” Elements in your personal collections. This would keep them from polluting the space you’re importing to, and from personal experience, I know that sometimes I want to assign / organize my colors for various Elements differently For example, in some projects I might want my button text to be a specific Button text color based on their design, but in other projects I might want my Button text to match the headline text used on the site, et cetera. This way you can per project bring in a Button from your library that has the general layout and style you want, and then assign it the appropriate color context based on how you wish to style that project. Just a thought for management moving forward as I’m not entirely sure how doable getting in palettes will be at this moment, but we certainly plan to bring more parity between the styling of the manager and picker, add tooltips to help with selecting the appropriate color, et cetera.
@michaelbourne, We’re looking into some potential ways to allow users to either define the site as “Desktop Down” or “Mobile First.” This isn’t definitive yet, but @alexander and I did have a really great brainstorming session on this the other day where we had an a-ha moment on this. We understand that while Mobile First is ostensibly a better way to develop a site, in the context of a builder there’s some nuance to it and how those styles get applied, and this might prove confusing to more inexperienced users. Ideally, it’d be interesting for users to be able to “pick their path” so to speak. None of this is ironed out yet, but we have had a few breakthrough thoughts on the matter. As for breakpoints, similarly…we’d love to give you all the option to set them, there are just a lot of implications here. We have some ideas, still working through them…but nothing is set in stone as we are just beginning this cycle.
As for asset management, more longterm this is still the goal, but part of it is getting in more of the features from this cycle like the Layout Builder, responsive styles, et cetera. We will review this more after this cycle.
Accessibility is important to us as well and we have many important features in already with various WAI-ARIA roles and state management, et cetera, but we realize there are more items to address. It’s not part of this cycle, but we hear you.
As for defaults carrying across Theme Options as you’re mentioning, that is again something that doesn’t really fit into this cycle. We’re trying to keep this discussion tight on the items mentioned above. We have some general ideas for this moving forward down the road, but for now we’re wanting to keep this discussion focused on the items at hand.
Thanks guys!
I could do this programmatically if they were separate. But you could also go fancy with a purge-css like functionality based off features and elements actually used in the builder 
Definitely looking forward to seeing some of these changes and improvements take place! Some really awesome ideas going around and great to see that Themeco is so involved with the users and asking for feedback. Really glad we got the unlimited pro license after reading all that is to come with Pro.
