Sign up Sign in Samples Blog contact support
separate styling for "theme" and "layout" (in UX)




Right now, all CSS is lumped under a "Skin".  But choosing things like whether you put the sidebar on the left or the right should probably not be conflated with the kind of choices typically determined by Bootstrap themes (colors, font, spacing, etc)





1. rename *layout to *webpage

CSS (*style) and JavaScript (*script) have sensible Setting names.  HTML (*layout) doesn't really, since much of what is usually meant by "Layout" is governed more by CSS than HTML.  Perhaps "*page structure" or even just *webpage (which would acknowledge in someways that this is a format-specific rule).

Going to go with *webpage for now just as a working name.

2. add more *webpage options, like "two column", "three column", etc.

We should work to keep the actual as simple as possible (perhaps even adding in some Bootstrap wrappers and classes with JavaScript.

3. update *style rule editor interface

You should no longer choose just a Skin.  You will choose a Theme (most of what is in the current skin) and a Layout (separate CSS that governs sidebars, headers, footers, etc)




....or something like that?

--Ethan McCutchen.....2015-05-21 06:05:23 +0000

Good to have some sense of organization with styles. Even more would be better. Style use patterns that could lead to a more user-friendly semantic way of editing layouts, themes and styles would be great.

--Gerry Gleason.....2015-05-23 15:28:59 +0000

Have you looked at the bootswatch skins? There are a lot of good patterns for theme-building there.


This particular idea is not about editing CSS; it's mostly about making things approachable for those who don't want to go there. If we want to make CSS editing better, that strikes me as more about edit help text and inline commenting than about rule organization.

--Ethan McCutchen.....2015-05-24 19:57:46 +0000

I guess I'm a little confused. This ticket is about organizing CSS, and isn't the point of separating these things so editing makes more sense?


If you mean the part of my comment about 'semantic' editing, then I think I agree. Just like an advanced link editor and WQL generator are for people who don't want to go there. The raw styles are actually very unfriendly for developers much less wagneers.


I figured there was (themable stuff) in what we have recently added, but the point is we need to expose that structure in an accessible way. Have some example themes that can be customized further by the community. We'll want an interface where they can pick from independent menus of themes and layouts, right?

--Gerry Gleason.....2015-05-25 02:41:13 +0000

I guess it depends on what you mean by "editing layouts, themes, and styles". If you mean editing CSS, that's not really what this ticket is about. If you mean choosing them (without necessarily even knowing what CSS is), then that's exactly what this is about.

--Ethan McCutchen.....2015-05-26 04:45:57 +0000

The connection is when trying to wagneer a new theme. In principle, you clone the cards that are themes and customize the clones, then make the clones part of new style cards. Then add the new components to the choices. Maybe you are also saying that you can do a lot of this with bootswatch and very little cloning?

On another level, this is about not having such a hard line between the simple choosing mode, and wanting to tweak some style element. Without any guidance and organization, we are really telling them "don't do that if you want support". We don't need anything close to discoverability, but with nothing to go on, it's hard to justify or maintain even small tweaks.

And, it isn't directly on-topic, more stuff to think about as we get towards 2.0. What's the minimum we can do to address these issues?

--Gerry Gleason.....2015-05-30 15:36:10 +0000

>On another level, this is about not having such a hard line between the simple choosing mode, and wanting to tweak some style element.


Well no, that's not what this ticket is about. It's about making it easy for people who just want to choose. That's the common case: choose only, no tweaking. I talk to a LOT of people who just want that. I wouldn't want any of the editing/tweaking stuff to get in the way of folks who just want to choose.


I definitely do think it's valuable to support a smooth entry for those who do want to tweak / create / extend (that's just not what this proposal is about). In general, I don't see much value in "cloning", by which I assume you mean something like copy and paste; I would want to be able to reuse existing stuff wherever possible. If you study how we've implemented the bootswatch, you'll see we've done a lot to make things reusable; we just haven't done much to make any of this discoverable. All good fodder for a separate Idea

  --Ethan McCutchen.....2015-05-30 23:38:12 +0000

We agree. This ticket is more specific, but it does blend into the other issues at some point.

I think the connection is the process of organizing all of this better so the transition from simple stuff (just choosing) and basic customizations not so stark. I didn't mean to digress here, just to point out that this organizing is welcome for other reasons too.

I also need to figure out what you've already addressed with components that aren't so discoverable yet.

--Gerry Gleason.....2015-05-31 13:07:19 +0000

+relevant user stories