SCALABLE DESIGN

vs RESPONSIVE DESIGN

Julien Etienne

--

Once upon a time the standard computer resolution was 1024 x 768 pixels. Skipping a few chapters ahead vendors lost their minds and started developing 8K displays, and despite the human eye barely distinguish printed resolutions beyond 300 dpi, that doesn’t get in the way of 700+ ppi displays hitting the market. As you can tell, it’s a little disproportionate for all the wrong rea$ons. But never fear, we have CSS right?

Except…

Everything has scaled except the text

This is true for the web. Let’s compare apples with oranges just to conceive progression: With each video game consoles generation, gamers expect an increase in performance, texture detail, realism and so on. But the most important aspect of the web (textual context) for 20+ years has pretty much the same format.

What Are We Missing?

If I had to imagine how it should be: For the web you design a “template” (document), you design to one size only using geometry. Templating, events & touch are built into the interface. If all elements are bound to control points (intersections on an imaginary scintillating grid) then re-positioning and re-sizing elements is a simple process that can take a desktop design to any mobile format and fit any display size.

In that imaginary world, what you view on a 4K screen (with little to no modifications) should be approximate to what you see on a tablet with an XGA resolution (unless specified). And what you see on a smartphone would be similar but completely rearranged (with 100% of the features) to the desktop layout.

That’s Not Right

Yes, it is & vastly more intuitive, we shall confront some hypothetical arguments. The mobile first approach: Has more to do with the limitations of CSS than choosing mobile design over desktop design. If design, on the web was entirely fluid and scalable, developing for mobile would become inconsequential. The future of display systems is unpredictable but what we do know is the future prefers flexibility.

Breaking away from a fixed font size: Device pixels/ CSS pixels and media queries are our modern day vigilantes, but they do introduce a lack of freedom & control. Fortunately Scalable-design, is predominantly WYSIWYG. One purpose of scalable design is to reduce the number of presentation states we currently depend on with responsive design.

To sell this methodology from a business standpoint, tell your people that scalable design is more predictable, you know exactly what to expect on all devices.

Why Is CSS Incapable Of Scalable Design?

At the time of this article, here are some underlying reasons:

  1. The “Box Model” is out of date and restrictive,
  2. Text units on the web do not scale reliably,
  3. The market for native apps is monopolised, the web is co-incidentally (wink) slow paced,
  4. SVG (16 years of age) doesn't care and can do whatever it wants except conveniently wrap some text.

Viewport Units

Impractical bastards, and not entirely accessible considering page zooms, as well as having a few minor rendering issues which differ between browsers. They’re almost useless, it’s almost like someone was half way through a revolutionary idea and thought… f* it!

Media Queries

Unfortunately have no ability to variate values without a JS workaround, they only behave within boundaries but are necessities for cleaning up after the constraints of our current HTML formatting model.

Isn’t Responsive Design Good Enough?

Responsive Design is a workaround for outdated technology. Resolutions & pixel densities are stupidly on the increase, there’s only so much screen max-width can do. Device pixels/ CSS pixels appear to be more of a temporary patch that was sold into the happy-go-lucky responsive buzz word. People love buzz words, remember “Valid HTML”.

Why Care!

  • Because you want to spend more time creating and less time fixing compatibility issues. Trying to tackle every display size is trivial, if your web app scales you will in least know what to expect.
  • Scalable looks great: When someone lands on your app or site you want to take them into a new realm, or a unique interface. It’s 2015, your website should look more like something out of TRON, not South Park (i love SP). Bad analogy? Maybe but what I’m getting at is that…

The websites we see today are not out of choice they’re out of convention.

  • Future-proofing: Media queries are not scaling mechanisms. We need to start appreciating websites as a legacy resources, it’s hard to achieve that with current handicaps.
  • It’s not freeing: You can only design within roughly 80% of the constraints of CSS1, yes the constraints of a 21-year-old vampire heartthrob styling language that has re-lived through CSS 2.1, CSS3 & will also be a parasite of CSS4 in a new predictable sequel.

Scalable Design… Currently

At the time of this article, many are not aware or convinced that it is appropriate and rational to create user interfaces entirely out of SVG. Plenty of SVG tools exist for design, animation and cross browser support all the way to IE6. Just check out Raphaël, Snap.svg, D3, GSAP & svgweb.

D3plus handles SVG text wrapping impressively. You can also wrap text in shapes. Check it out but be warned, it’s heavy. (I believe some of the others may also handle wrapping).

SVG is ideal for scalable UI design. But for responsive & adaptive contextual formatting, HTML & CSS can be uses in conjunction with SVG and it really make no difference if you decide to include SVG within HTML or vice versa by use of let’s say the foreignObject container.

Inkscape

Inkscape 0.91

Unlike Adobe Illustrator, Inkscape is a vector design application based on SVG, and it’s open source [free]. It is maturing and has been around for about 12 years. Many prefer it over Illustrator, they both are essentially capable of the same things, but Inkscape is more at home with the web. Without being biased, I advocate for the use of Inkscape with SVG on the web not just for the fact that it is already SVG, but it is easy to learn and available on Linux, OSX & Windows. Even if you are not using SVG try it out & don’t be fooled, it is beyond the powers you may be expecting.

How Should Scalable Design Work?

A guess would be that that a horizontal scale would be more favourable & familiar, of course with vertical dimensions auto constrained (you can already do this in CSS but not reliably with text).

What if you want to scroll down content?” We need to detach from that way of thinking to understand what is capable beyond traditional websites. Consider future apps resting on an infinite plane, creative navigation shouldn’t compromise accessibility if we have sufficient attributes to define what we are trying to accomplish, and we do already.

The misconceptions of accessibility is another topic that needs to be addressed so we can be great at our jobs without being boring and nerdy as hell. Ugh!

How Can We Make CSS Scalable

Good question, maybe we shouldn't. Design is about true geometry, colors, metrics, abstraction, freedom and most importantly exposure.

But if we must here’s a simple but thorough proposal:

  1. Propose fluid text units that scale to either the containing block or the initial containing block that satisfies the Zoom factor.
  2. Replace the Box Model, with something simple: There are many ways to do this without breaking the web. Simple foundations are more powerful.
  3. Introduce a scintillating style grid: (Not a responsive grid) Elements should be able to adhere to a virtual grid, snap, center, fix, slide. Similar to traditional vector design, with guide-lines etc. In theory, this grid should be visible only during development.

You don’t need to differentiate a hyperbola from a parabola to be considered a designer but, it is evident that the web design world is lacking a paradigm or two from the beauties of traditional design. Hopefully some day more APIs and features will focus on scalable content & true geometry rather than doing what we do now which is the equivalent to putting tiaras on Chihuahuas ;-)

“To the rescue, here I am…

Scalable Design, SVG 2.0

So there is light at the end of the tunnel, you didn’t just read or skip through all that noise because some idiot wanted to regurgitate all over a 21 yr old web specification that many important people devoted tireless hours to improve.

SVG 2.0 === SCALABLE DESIGN

This was a terrible game:

Before we dive into a tiny bit of SVG 2.0 lets quickly get some myths out of the way in regards to SVG in general:

SVG content is SEO friendly, SVG can scale to full window-width/ height or to any container, appropriate SVG images & designs are usually lighter in file size than jpg or png equivalents, SVG has reverse cartesian coordinates = CSS coordinates but in reverse. SVG has layers that are in order of declaration. SVG is not HTML, it is in the XML format, you can style SVG via CSS. Scalable Design requires basic understanding of the SVG viewBox & viewport.

Scalable Text; Because, AUTO WRAP

In SVG 2.0 the text element can become a text content block element. Similar to the containing block of the P element in HTML except it’s all rendered within SVG 2.0. This enables the capability of pre-formatted and auto-wrapped content. The scalable aspect is irrelevant, as everything in SVG preserve to the defined aspect ratio.

I took an example from w3 and modified it a bit:

<svg width="50%" height="50%" viewBox="0 0 1000 500">// A rectangle to indicate the break   <rect x='240' y='250' width="200" height="100" fill='green'/>

// Our auto-wrapped text element
<text x="240" y="450" extent="200" font-size="45" > This text wraps at 200 units. </text></svg>

Auto-wrapping is achieved by specifying a content-area via the text tag, by including the extent attribute or shape-inside property. Yes, the last one means you can fill up a circle with text. With a defined path, you could imagine doing something similar to this…

…without stressing about how proportions retain whilst being viewed on a retina display or tablet. I say not stress because even if you are not intuitive or resourceful enough to weigh out font sizing in accordance to the physical screen size, it’s perfectly fine because the user will still be able to access the content as a single visual, (in theory without seeing the cross-browser glitches we fear so much with HTML & CSS due to the user-agent style sheet dilemma).

Scalable Design may also enable designers and developers better, whom lack the resources to test against hundreds of devices adequately. Predictability is a great development benefit.

Really & truly, SVG is not a justifiable definition of Scalable Design as a complete methodology for web design. To make it complete the viewport must scale and everything within must adhere. As it’s all vector design, we do not expect visual artifacts during resizing & scaling.

Scalable Design is Responsive Design, but Responsive Design is not necessarily Scalable Design, within both methodologies is the choice of adaptive design. We also know there are known unknowns, that is to say, we know there are some things we do not know. But there are also unknown unknowns…

tl;dr — yes of course we still need media queries.

The big question is:

WHEN?

SVG 2.0 has been a working draft since April 2015 (this year) and is not currently supported via any browser. However, the roadmap seems to suggest that we shall soon encounter partial browser support hopefully this year. All the fancy stuff is irrelevant, first we must take an interest to the text tag as a content block element or equivalent (sometimes things change).

Another relative technology on the rise to take over after the decapitation of SMIL is the Web Animations API which is a stupidly confusing name and also a working draft that you can play with now. But like anything it’s all about demand and supply, the more enthusiasm that we have for these game changing technologies the faster and more likely we can expect to see these things implemented. And hopefully the Edge team at Microsoft will be less hesitant this time round to stay on par with their counterparts.

Tony Stark === SVG 2.0

Be constructive

Cheers!

--

--