Backend interface: proposal for full "mobile-first" responsiveness

[DavidOliver]

I'm keen to have Symphony's backend interface work on a "content-first"/"mobile-first" responsive basis, where admins performing admin tasks and authors editing content get an experience suitable for whatever device they happen to be using.

This would mean that on smaller screens, users do not have to zoom in and pan around to read and do things but, instead, would be presented with, for example, a single-column layout, suitable navigation, and entry-editing fields that work well for them.

I've found the "mobile-first", media-queries-based-on-ems/content way of thinking and writing CSS to be excellent, and to help put focus where it should be: the experience the user has of the content/interface, not specific device types that may or may not be popular tomorrow. It takes a bit more time and consideration, but we can no longer assume a minimum size screen.

We want to appeal to folk on the basis of COPE, and maybe our extended take on this can be "CAPE": Create Anywhere, Publish Everywhere. (Or maybe Create Responsively, Anywhere Publishing.)

I also think a truly responsive backend interface would be a massive selling point to many developers choosing a CMS with their customers in mind in itself.

Thoughts?

[michael-e]

Create Responsively, Anywhere Publishing

LOL.

I agree with you. Imagine a responsive backend interface as a blueprint for developers to create a custom web app! Using the same core logic and XSLT snippets for frontend HTML!

[nilshoerrmann]

I'm all for it.

[brendo]

Yes. @nilshoerrmann work on making Symphony responsive is already great and building on it can only mean better things.

[nilshoerrmann]

@DavidOliver: Let's start over here – https://github.com/symphonycms/symphony-next/tree/static-ui

[DavidOliver]

Imagine a responsive backend interface as a blueprint for developers to create a custom web app! Using the same core logic and XSLT snippets for frontend HTML!

I like that. I like that a lot. It will be interesting to see how modular we can make it. I have a lot to learn on this.

To outline in a little more detail what I mean by "mobile-first":

• for the interface as a whole and for every element of it, we first consider how it will work at small viewport sizes, and subsequently consider how it will work at progressively larger ones;
• CSS is written on the basis of "no media query is your first media query", with, for example, subsequent em-based min-width media queries being used at appropriate breakpoints;
• neither mouse nor touch are ever assumed - whatever the screen size, the user could be using either, and/or a keyboard. (This one is not so much "mobile-first" as progressive enhancement, I guess.)

[nilshoerrmann]

With regards to size units, I really enjoyed working with rem recently (we use it a lot in Factory). As the size is always based on the root, you won't need long and complex size calculations when going down the cascade. The only issue is that media queries don't work with rem.

[DavidOliver]

I really like rem for font-sizing, too.

[designermonkey]

The only issue is that media queries don't work with rem.

Media quesries alwayd run at the base of a css file, so will always run the base font size for ems :)

[DavidOliver]

And if we respect the user's browser font-size setting and not override with something smaller (something I'll probably be for), this should work nicely.

[nickdunn]

rem ftw. I have always, and still do, code using px, so it's a joy to now just replace them with rem and know everything is scalable.