Breakpoints And The Future Of Websites

Advertisement

When the iPhone came out in 2007, the demonstration of its web browser by the late great Steve Jobs gave the not-so-subtle impression that Apple wasn’t too perturbed about its users pinching to zoom and swiping to scroll as part of the browsing experience. Responsive web design aimed to solve this problem by smartly applying flexible grids, fluid layouts and, of course, media queries.

However, responsive web design has turned out to be somewhat of a case study in the law of unintended consequences, with one of the perverse unanticipated effects being breakpoint paranoia. But even without the undue influence that media queries exerts on your selection of these breakpoints, it dawns on you after much introspection that these might not be the droids we’re looking for.

In this article, we’ll look at breakpoints beyond screen size and explore different possibilities and practical approaches to using them to create truly adaptive experiences on the web.

Threshold Dynamics

A threshold1 is the point or level at which something begins or changes. Thresholds can be found and felt virtually everywhere in the physical world: stopping at a traffic light, choosing skimmed milk over full cream, two sugars instead of three, uncouthly opting out of the teacup ride at Disney World, etc.

Thresholds define us because they define actions, and actions determine outcomes. Being able to identify the right thresholds sets you on a course for better outcomes, especially when you know exactly what needs to be done within each threshold. It’s akin to doing the right thing at the right time.

Our foresight to conceptualize — and enable — new thresholds where there were none will open up a new vista of actions vis-à-vis outcomes. The freedom and flexibility we acquire from this will only help to fulfill our innate desire for incremental awesomization, which will drive us to create even better websites that provide better user experiences.

Today’s Breakpoints

In web design today, the thresholds we fixate on the most relate almost exclusively to screen size. The major challenge over the last few years has been designing for mobile devices, and, with screen size being the obvious focal point, our primary intent has been to adapt the layout of our web pages to tally with the specific display characteristics of the target environment.

In responsive web design, the predominant method of defining these breakpoints is by setting media queries.

@media screen and (min-width: 240px) and (max-width: 320px){
   body { background: red; }
}

The markup above clearly identifies two thresholds (240 pixels and 320 pixels) that constitute a range within which an action will be triggered (in this case, changing the background color to red). It’s quite straightforward in concept.

Medusa Queries

“As we augment the abilities of people to accomplish their tasks, we should be careful not to needlessly curtail what they can do.”

– Jeremy Keith

Media queries, it turns out, are extremely rigid. Usually, you are forced to employ breakpoints in ways that are not exactly intuitive nor inline with your core design aspiration. In other words, you have to fit your design aspiration to its capabilities. So, you may have a vibrant imagination about your own thresholds, but more than likely media queries won’t let you apply them the way you envisage.

Defenders of media queries should understand that efficiency is what makes any effective effort laudable. Spending many minutes or even hours tweaking those pesky directives and then having to re-tweak them each and every time you want to make an adjustment is nothing short of a recursive nightmare. What’s so wrong with setting breakpoints based on broad categorizations of mobile devices (such as smartphone, tablet, etc.)?!

In the article “Designing for Breakpoints2,” Stephen Hay suggests defining breakpoints based on device classes. Spurred by a few assertions, I embarked on a mini-research project that I later converted into a blog post3 to prove this right or wrong. And in a recent poll that I conducted on whether media queries should target device classes4, about 54% of respondents said yes. But there’s no intuitive way to do this with media queries even if you wanted to.

In my humble opinion, from the web designer’s standpoint, the feature set of media queries is incomplete. And it is so because designers have an imagination and an appetite for many more breakpoints than media queries can currently provide (and probably ever will in future).

The New Breakpoints

As mentioned a little earlier, our ability to find and set new thresholds will determine our ability to conceptualize new actions that we can set a trigger to. By so doing, we can introduce more tweaks into an inherently static and inflexible environment.

Breakpoints in Contextual Web Design

The websites of tomorrow have to be more than responsive — they have to be contextual, too. These concepts of flexibility and fluidity have to transcend screen size. The age of the one-size-fits-all website will have to come to an end and be replaced by websites that also adapt to the needs and expectations of users.

To enable this feature, we have to conceptualize more thresholds, but first we need to find out what parameters to track. In Nick Finck’s insightful presentation on “The Contextual Web5,” he highlights four aspects of context in web design: user, task, environment and technology. Of course, all four are a treasure trove of extrapolations, but what should we really focus on?

We could ask literally hundreds, even thousands, of questions about users, their tasks, their environment and what technology they have access to. However, we have to base these questions on our current and overt abilities to obtain data on these four parameters. Some possible questions could be:

  • What are the physical abilities of the user?
    If the user is vision-impaired or hearing-impaired, we would need to add more accessibility features that would enhance their experience.
  • Where is the user’s general location?
    Knowing where the user is gives us a good idea of their culture, economic status, demographic, etc.
  • What time is it in the user’s location?
    People are usually creatures of habit and are probably more likely to perform certain actions at a certain time.
  • What is the user’s device?
    A phone is not a tablet, and a tablet is not a PC. Different devices have different capabilities and will be used for different tasks.
  • What does the user have an affinity for?
    What the user likes (and dislikes) will play a strong part in helping us to prioritize and deliver content.

There are ways to answer the questions above with the technology available in browsers today. And if not, then we really need to work harder to build them in, especially considering an issue as important as accessibility.

So, how would we design a website to be contextual? How would we visualize breakpoints in a contextual sense? Here’s one scenario.

Let’s suppose that it’s 6:00 in the morning, and your alarm goes off. You hobble to your kitchen to get some breakfast, before getting ready and heading out to work. You fancy eggs, but you open the fridge and there are no eggs. So, you settle on something else, but you want to order some groceries so that they’re ready to be picked up on your way back from work. You fire up the website of an extremely large department store chain from your Internet-connected refrigerator to get this done.

Are you impressed simply because this website is responsive? Is getting the best deal on electronics a priority for you at this point? Do you really want to be reminded that some of the few items you “recently viewed” on said website were Lincoln Logs and a Spider-Man toothbrush holder? I mean, it’s 6:18 am, and you’re browsing from a fridge. Does it take a rocket scientist to figure out that maybe grocery items should be a category worth prioritizing?!

I’m sure there are numerous other scenarios like this, and it’s easy for someone who isn’t familiar with web technology to get frustrated with how websites still seem to fall short of their expectations. But for those of us who do, should we still be making excuses, or should we be trying to push the envelope further?

The New Methods

“Media queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered.”

– Editor’s Draft, W3C (3 June 2014)

I was recently perusing the “Media Queries Level 46” draft specification to get a sense of where things are headed. I must say that I’m not very excited with the direction, and there just doesn’t seem to be much innovation here.

From the abstract of the document, we get a clear definition of what media queries are as a method. However, I just can’t understand why there is no evolution of media features to reflect present — and possible future — realities.

What’s wrong with having device-class media features like phone or tablet? They seem like obvious choices, and, according to the poll referred to earlier, web designers want that feature set. Some would argue that those might not be “things” in the future, but that is hardly believable, given that cars, TVs, computers, refrigerators, watches and spectacles are still “things” that people find useful today. And when are we really going to see a resolution to the question of element queries7?

In my opinion, media queries (as a tool for web design in a multi-device world) simply can’t maintain any sort of equilibrium with the creative trajectory of contemporary web designers, and they are a morally indefensible standard for web design going forward. Maybe we should look at alternative approaches; I’d like to suggest a few. They’re not that complicated, and all we’d need are a HAT, a COAT and a TIE.

HAT Trick

We’re probably all familiar with CSS class selectors at this point. They are one of the most commonly used selectors in web design8.

.muttley .do_something {…}

What I don’t understand is why we don’t use these classes more than media queries to build mobile-friendly websites?

It seems to me that designing websites for many different situations would be so much easier and faster if browsers employed HTML attribute tagging (HAT). Basically, this would involve the browser placing specific parameters in the class attribute of the <html> tag (in the process of the page being loaded), which would enable the web designer to leverage these classes in their CSS markup.

Some of these parameters could include the following:

  • device group
    fixed, mobile, home, wear, auto, etc.
  • device class
    PC, phone, tablet, TV, fridge, car, watch, etc.
  • input device
    coarse, fine
  • bandwidth
    high, medium, low
  • orientation
    portrait, landscape
  • viewport width and height
    in device-independent pixels, to the nearest multiple of 40, with an alphabet prefix for compliance
  • local date and time
    in ddmmyyyy format for date, and 24-hour representation for time
  • time zone
    UTC offset9
  • general geo-location
    continent and country codes

More parameters could be added based on anticipated need. In addition, all parameters would be abstracted to the DOM window object to make them easily accessible via JavaScript.

So, suppose someone was using a Nexus 5 phone over a 4G LTE mobile network. The browser would add the relevant tags to the page, leaving us with this:

<html class="mobile phone coarse high portrait v360w v640h d07052014 t0900 utc_a af_ng">

And if they changed the phone’s orientation to landscape, the browser would statefully update the tag, giving us this:

<html class="mobile phone coarse high landscape v640w v360h d07052014 t0900 utc_a af_ng">

If this happened, the web designer would have a lot of options to quickly adapt their web pages across numerous logical breakpoints at literally the speed of thought. Let’s consider one working example.

I was recently testing a pricing table10 that is not unlike tables seen on a lot of SaaS websites these days. The table is three columns and is built using ul tags with floated li tags.

A multi-column pricing table.11
A multi-column pricing table. (Image credit: Restive.JS1512) (View large version13)

Below the pricing table is some FAQ content, also with a multi-column layout.

02-faq-content-opt-50014
Multi-column FAQ content. (Image credit: Restive.JS1512) (View large version16)

Obviously, these multi-column elements would not look as good on all mobile devices as they would on a desktop. So, in the spirit of responsive web design, we would have to adapt them to the dimensions of a smaller screen. And the way we would do this is by showing these two visual components in their full multi-column glory only when the web page is being viewed on a tablet in landscape orientation.

The logic behind this is that we would expect a tablet in that orientation to have enough screen space for the whole table to appear as intended. If those conditions are not met, then we’ll collapse the columns to be linear and vertical.

The basic CSS for our pricing table is this:

ul {
   margin: 0;
   padding: 0;
   list-style: none; }

ul li {
   float: left;
   width: 33%; }

So, leveraging HAT, we would implement these features using the following markup:

.mobile ul li {
   float: none;
   width: 100%; }

.mobile.tablet.landscape ul li {
   float: left;
   width: 33%;}

That’s it! Just disable the floated layout elements for all mobile devices, and then re-enable them for tablets in landscape orientation. Simple aspiration, simple solution. Do you want to try doing the same thing with media queries? Say hello to Dr. StackOverflow for me!

Clearly, employing this approach has benefits. Efficiency is one major benefit; you’d spend less time building websites because you wouldn’t be wasting ridiculous amounts of time crafting media queries, not to mention all of the testing of mobile devices that goes along with that. Secondly, maintaining your markup would be easier because everything would be inline and there would be no needless duplication. Thirdly, you would have the opportunity to explore many more use cases because there would be more parameters that serve as thresholds for more logical breakpoints.

COAT of Many Colors

Everyone seems to be fascinated by analytics. Website analytics programs, such as Google Analytics and MixPanel, all try to give a good picture of who has visited your website, how long they stayed, what websites they came from, what devices they used, etc. What this data won’t tell you is what content the visitors have an affinity for.

You could, of course, use cookies to track visitors to your website, but then you’d only be able to determine what they like on your website that day or week or month. You wouldn’t be able to accurately determine the specific content they care about, nor might you be able to do anything about it before they leave.

Tracking content affinity and adapting content to said affinity could really help us build websites that truly adapt to people’s desires. To really obtain this data, though, the data-collection mechanism needs to transcend any one website. That is, all websites would need to build this affinity profile in a collaborative and transparent way.

COAT stands for “cumulative and open affinity tagging.” It’s simply a shared method of understanding the things visitors have an affinity for and then building a profile of that affinity. Here’s how it would work:

  • Someone visits a bunch of websites regularly. Some are news websites, some are sports websites and some are blogs. Each web page would have a COAT meta tag.
  • The browser (via a COAT sub-engine) would read this meta tag and incrementally store its value in a reserved, protected and read-only localStorage variable (which could be named anything) in a comma-delimited format. So, for the websites that our user visits, the value might be news:info:1,sports:soccer:2,blog:tech:3.
  • If the person visits another sports-related website, the website would read (and update) their affinity tag from localStorage. It sees that the person is amenable to football, and so gives more priority to football content on the home page.

Armed with this insight, we could tweak a website’s home page to better cater to the different needs of users in a highly specialized way.

COAT data would comprise a single comma-delimited string in the following format:

{category_1}:{sub_category_1}:{popularity_1},…,{category_n}:{sub_category_n}:{popularity_n}

Here, category is the broad classification of a type of content; sub_category enables further classification; and popularity is a measure of the frequency of visits. So, if our user visited a tech blog 30 times a month and visited the football section of a sports website 5 times a day, then we would end up with this tag:

blog:tech:30,sports:soccer:150

This is merely an example; the classification system would be defined and maintained by the greater web community. A number of safeguards would be in place, too. For example, if a website didn’t define a COAT meta tag, then it wouldn’t be able to read one either. Also, if the user was browsing in private mode, then COAT would be disabled.

COAT wouldn’t track any personal information. The intent is not to figure out who a person is and where they might be, but to get a broad picture of the kind of content they like (and how much they like it), so that websites are able to personalize their browsing experience.

TIE In

Let’s face the fact: JavaScript is awesome. It’s not very approachable to most web designers, but its capabilities are simply immense, and it holds the key to websites doing great things in the future, even as its contribution to website functionality today is not in question.

HTML and CSS are a great duo for building websites, having been so for quite a while now. However, only HTML seems to have been allowed to maintain a relationship with JavaScript. Granted, CSS is “a style sheet language used for describing the look and formatting of a document.” But as things stand today in a world dominated by web-enabled devices, a lot of the factors that determine the look and feel of a website have gone beyond the realm of CSS.

As a result, CSS needs to be allowed to “friend” JavaScript and ask for its help in performing certain tasks. There really should be a way to link Javascript functionality directly with inline CSS rules. One way would be via transcendent inline expressions (TIE). TIE would provide a mechanism of linking CSS rules with JavaScript expressions, opening up even more amazing opportunities for website functionality.

Let’s look at a simple example. Suppose we had a testimonials component in the sidebar of our home page:

A testimonials component in the sidebar of a web page.17
A testimonials component in the sidebar of a web page. (Image credit: Ian Storm Taylor18) (View large version19)

We want to drop this same component into the main content area of another page, somewhere where we have more width to work with:

Our testimonials component in the footer of a web page.20
Our testimonials component in the footer of a web page. (Image credit: Ian Storm Taylor21) (View large version22)

This is called modular design, and conceptually it’s a very simple idea. However, we’d have a pretty hard time implementing this in CSS (as Ian Storm Taylor found23), because there isn’t a straightforward way to apply CSS styles to the testimonials component based on the size of its container.

This scenario is what has sparked the clamor for element queries, the overriding need being a way to define reusable modules that adapt to the size of their containers. If CSS natively implemented some sort of TIE functionality, then we might be able to write a simple expression in CSS to make this happen:

.testimonial { … }
.testimonial[expr="if @parent:width less than 200px"] { … }
.testimonial[expr="if @parent:width between 200px and 500px"] { … }

For the first ruleset, we would style .testimonial as usual. For the second ruleset, the expression could mean that, when the width of the parent element of .testimonial is less than or equal to 200 pixels, then apply the corresponding declarations to that DOM element (i.e. the parent element). The same goes for the third ruleset, whereby the declarations are applied when the parent element has a width of 201 pixels to 500 pixels.

Basically, CSS would merely provide guidance on what to do, while JavaScript would do the heavy lifting that CSS isn’t well suited for. Instead of writing the CSS rulesets for styles and then jumping over to JavaScript to activate them, we would simply do both via an expression in CSS. Because we’re working on the same DOM element, it makes sense for there to be some easy and intuitive way to both style and activate it (i.e. the DOM element) directly from CSS.

Any such TIE implementation should be robust enough to enable web designers to implement features at virtually the speed of their creativity. In other words, if they can imagine it, designers should be able to achieve it — or something close to it — almost instantaneously.

Putting It All Together

Let’s consider a scenario that shows how all three would fit together when building a website.

By the time you read this, the World Cup will be on, and football fans from around the world will have gathered in Brazil to experience the thrills of the Copa Mundial. Let’s assume you are one of those fans and are in Sao Paolo, having brought your smartphone and Google Glass with you.

A popular online sports destination that happens to be covering the event would usually blanket its website with World Cup features at the expense of other sports events going on elsewhere in the world. The website will employ the three methodologies explained earlier in order to deliver a very special user experience.

After building various content components, the website’s developers should be able to do a few things without much stress:

  • Optimize the website exclusively for Google Glass, providing a simpler, slimmer interface for easier navigation. In addition, adapt the color contrast to the time of the day (i.e. switching to light text on a dark background at night), using the device-class parameters of HAT.
  • Provide more content on local attractions in different cities in Brazil (for example sports bars, other viewing centers, etc.) only if the access device is a smartphone or tablet and happens to be in Brazil (using the location parameters of HAT).
  • Lead with pre-game analysis, team and player profiles, and merchandise if the user visits the website within six hours of an upcoming match (using the time parameters of HAT in combination with TIE).
  • Lead with match highlights and post-game analysis if the user visits the website within 12 hours after a match ends. Provide different layout designs for match highlights on smartphones and tablets using the same code base (using the device-class parameters in HAT).
  • Lead with golf features in a more prominent location than football if we determine (via COAT) that the user likes the former more than the latter. But still display match highlights in a sidebar with a narrower pixel width (styled in a modular fashion using the TIE features in CSS).
  • Default to the regular format of content if we can’t determine whether the user prefers football or another sport.

As you can see, the permutations and opportunities of a highly personalized and carefully weighted user experience are abundant and easily implementable if all three methodologies are considered. We wouldn’t necessarily have to use them all, but it’s nice knowing that they’re there if we wanted to.

The Polyfill Way

“You can’t always get what you want. But if you try sometimes, you just might find, you get what you need.”

– The Rolling Stones

Where would the web design community be without polyfills? Even the best-intentioned technology doesn’t always work as intended, and sometimes it has gaps in functionality. “Just chill and polyfill” would be the operative mantra in these situations, and the last few years have indeed been a veritable polyfill-palooza24.

All of the features outlined so far in this article are merely ideas and are not earmarked in any upcoming draft specifications of CSS or media queries, so you couldn’t use them right now even if you wanted to. However, that doesn’t mean we can’t do something about it in the meantime.

Restive.JS

I mentioned earlier that I was using a plugin to build a website. Well, that would be Restive.JS25, a jQuery plugin that I developed about a year ago that embraces and implements the HAT principle. Using built-in options of breakpoints, classes and a special feature named turbo_classes, Restive.JS populates your <html> or <body> tag class attributes with values that make it easy for you to adapt a web page’s layout via inline CSS to more natural design cues.

Once you get the basic idea, using it to build new responsive and adaptive websites is pretty easy, as is adding said features to existing websites. I recently wrote a tutorial on “How to Make Any Website Responsive26,” which you can peruse at your leisure.

You can also learn more via Restive.JS’ documentation27 and from the GitHub readme28.

A Note on Tolerance

As creative and technical professionals, we need to be open to other people’s opinion. Often a crowd will move towards a position simply because of punditocratic consensus, without pausing to question the fundamental reasoning behind it.

Take device detection. Some say it’s a bad practice. My question is why? Is it because it is deemed unreliable? We can make it reliable. Is there a fear that it is not performant? Then we can cache data. Solving big problems should be an inclusive effort, and using the process of elimination to rule out methods could come back to bite us if someone is able to improve on that method.

Creativity is an insatiable hacker. As long as imagination continues to spur the industrious, then the best tools and methods will eventually give way to better ones. Maintaining a clear and tight focus on the task at hand — and its successful completion — shouldn’t prevent us from being robust with our toolset. As the great Abraham Maslow said, “If all you have is a hammer, everything looks like a nail.”

In Closing (But Moving Forward)

More of everything isn’t necessarily a good thing. But, when it comes to breakpoints, “the more the merrier” does ring true. As humans, we take actions based on specific triggers between specific thresholds. Defining more of these thresholds would open up opportunities to create websites that adapt in so many ways beyond screen size, and that exploration will turn out to be instructive.

However, as we open up new frontiers with new breakpoints, we should do so in a way that is both user-friendly and efficient for the web designer; the robustness of our methods shouldn’t make us less nimble. With the way web standards work, we’re probably going to have to polyfill our way to the promised land. But that shouldn’t stop us from building awesome websites that work on every device and in numerous user scenarios.

Front page image credits: Restive Blog29.

(al, ml)

Footnotes

  1. 1 http://www.merriam-webster.com/dictionary/threshold
  2. 2 http://alistapart.com/article/designing-for-breakpoints
  3. 3 http://blog.restive.io/posts/8460953/device-classes-as-breakpoints
  4. 4 http://polarb.com/176083
  5. 5 http://www.slideshare.net/nickf/contextual-web
  6. 6 http://dev.w3.org/csswg/mediaqueries4/
  7. 7 http://www.smashingmagazine.com/2013/06/25/media-queries-are-not-the-answer-element-query-polyfill/
  8. 8 http://ejohn.org/blog/selectors-that-people-actually-use/
  9. 9 http://en.wikipedia.org/wiki/List_of_time_zones_by_UTC_offset
  10. 10 http://restivejs.com/sandbox/pricing-table.html
  11. 11 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-pricing-table-opt.jpg
  12. 12 http://restivejs.com/sandbox/pricing-table.html
  13. 13 http://www.smashingmagazine.com/wp-content/uploads/2014/06/01-pricing-table-opt.jpg
  14. 14 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-faq-content-opt.jpg
  15. 15 http://restivejs.com/sandbox/pricing-table.html
  16. 16 http://www.smashingmagazine.com/wp-content/uploads/2014/06/02-faq-content-opt.jpg
  17. 17 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-testimonial-content-opt.jpg
  18. 18 http://ianstormtaylor.com/posts/media-queries-are-a-hack/signup.jpg
  19. 19 http://www.smashingmagazine.com/wp-content/uploads/2014/06/03-testimonial-content-opt.jpg
  20. 20 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-testimonial-footer-opt.jpg
  21. 21 http://ianstormtaylor.com/posts/media-queries-are-a-hack/pricing.jpg
  22. 22 http://www.smashingmagazine.com/wp-content/uploads/2014/06/04-testimonial-footer-opt.jpg
  23. 23 http://ianstormtaylor.com/media-queries-are-a-hack/
  24. 24 https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills
  25. 25 http://restivejs.com
  26. 26 http://speckyboy.com/2014/04/24/make-any-website-responsive/
  27. 27 http://docs.restivejs.com
  28. 28 https://github.com/obihill/restive.js
  29. 29 http://blog.restive.io/posts/8460953/device-classes-as-breakpoints

↑ Back to topShare on Twitter

Obinwanne Hill is the Founder and CEO at Restive Labs, an ideation and development company working on practical concepts and user-friendly tools to help make the Web instinctively Fast, Responsive, and Contextual. You can reach him on Twitter, Google+, or LinkedIn

Advertising
  1. 1

    I must confess I have not finished reading the article yet but felt the need to comment on the section regarding “contextual breakpoints” (E.g. “What time is it in the user’s location? … What the user likes (and dislikes) will play a strong part in helping us to prioritize and deliver content.”).

    CSS is surely all about presentation. The questions that are being asked here are certainly worthwhile but perhaps they are content and functionality issues rather than presentational ones – best tackled with server-side code rather than front-end development.

    14
    • 2

      Exactly my thoughts. And, although some of the classes mentioned are valid, others, such as dates and times should be added as data attributes, not CSS classes. Otherwise, you are just adding non-sensical gibberish that can change way too often and has almost no bearing on the presentation layer.

      Really, half of everything this article complains about can be done by using RESS instead of straight responsive. Reorganizing content by device, user traits, or time of day? Completely server side.

      5
    • 3

      Obinwanne Hill

      July 9, 2014 4:28 am

      Yes, CSS is about presentation, but the fact that there are other factors today that determine how the layout of a web page is styled will mean that CSS might need to incorporate some scripting functionality going forward. I haven’t studied the Spec in depth, but Media Queries Level 4 has some ‘Scripting’ bits in it so it appears there is some buy-in on this from a Web standards viewpoint. In my opinion, it’s arguable whether Context is best tackled on the Server-Side…I think certain elements can be very well dealt with on the Front-end [which is way more prodigious than it was just a few short years ago]

      1
      • 4

        Why not – isn’t this a part of evolution – who could have thought that JavaScript can do server side stuff? So incorporating content or functional capabilities into css is need of the time, especially when design and presentation is becoming a very important factor for the success of a website/app etc…

        0
        • 5

          “who could have thought that JavaScript can do server side stuff?”

          Node.js had the same effect than AJAX had. It changed the way people used a technology that was already there for years.
          The first book I’ve read about Javascript had a few chapters about server-side Javascript. I think it was in 2001.

          0
  2. 6

    RE: “Hat Trick”:
    … We can detect alot of this already via javascript, there’s no need to petition browser vendors to add this functionality. Plus, while it sounds useful on the surface, it would probably be more obtrusive and annoying if browsers kept injecting classes into your HTML.

    RE: “Coat”:
    … This is a pretty creative/novel idea, but I can forsee the COAT meta tag being abused by website owners who are more interested in reading then sharing (e.g. adding a BS value or non-related value simply to read the users COAT data). Not to mention some people might not like the idea based on privacy concerns, having websites “spying” on what you like and sharing it with the world. There would have to be a setting of some sort that the user could enable/disable to share this COAT data. (Similar to the “this website would like to use your device’s location” popups we see now).

    RE: “Tie In”:
    … Javascript expressions in CSS were actually supported before in older browsers, but it was removed for a few reasons: (a) It wouldn’t execute if javascript was disabled in the browser (although this is arguably no longer an issue), (b) It had huge performance issues, as the expression wasn’t simply run once, but constantly as the user interacted with the page, and (c) it meant you had to check files other than .js files to debug javascript errors.

    Even though I think the proposed implementations might not work out as intended, I like that you are thinking outside of the box when it comes to the future of the web. A contextual based approach to responsive websites is something I can envision becoming “web 3.0″.

    3
    • 7

      Obinwanne Hill

      July 8, 2014 9:06 pm

      Thanks for your comments, Andrew.

      HAT has worked very well for me (via Restive.JS), and it is very quick to use in CSS when you have true/false certainty e.g. isTablet, isPhone, and/or isLandscape, etc. However, it doesn’t quite work so well when you only have range certainty because CSS doesn’t natively enable this kind of computation [apart from media queries, which has very specific parameters]. I’m currently working on an a more advanced implementation of this [that also incorporates TIE as well] that will be a framework that will enable this.

      Regarding the COAT implementation, I have some of the same reservations you have regarding ‘spying’, that’s why it will only work if there are safeguards that are implemented at the browser level, and probably a periodic verification mechanism that makes sure the tags on your site match the content on an ongoing basis. If done right, I think it would be beneficial for Websites that receive a lot of traffic but have virtually no information on the user’s affinity so they end up serving same content to everyone.

      Regarding TIE, I’ve seen no performance issues within the implementation I’m working on right now [the framework I mentioned earlier]. Still, I will take what you’ve said under advisement.

      Cheers.

      0
      • 8

        Obviously you never heard of HeadJS. Combined with the Responsive Grid System (NOT! responsive-gs) this has so far proven as the best approach to that “breakpoint debacle” ;)

        One ponders thou, how to implement a “bandwidth” option. Yet another bloat for the browser, which also would not be available immediately. And even if it was some kind of internal device API the browser’d access, it’d prolly would be extremely unreliable, because it’d change all the time.

        About the COAT approach: Yeah, let’s annoy the crap out of the user, by forcibly setting “favorites”. Take away the choice, and do the same that Google already does: Favoring specific data, while disregarding others, so one has an “individual” search result. Which is “very” user-friendly. As much as the current usability situation in Gnome is.

        About the “spying” topic – yeah, right, as if anybody actually WOULD NOT want to abuse that. As a matter of fact: If resp. features and techniques are there, THEY WILL BE ABUSED. For the most trivial reasons. Lets do some name dropping: Edward Snowden. Nuff said.

        cu, w0lf.

        0
  3. 9

    leonard eshuis

    July 8, 2014 3:49 pm

    What time is it in the user’s location?
    6 oçlock in the morning could be someone who just woke up,
    but can also be someone who just finished a night shift?

    time also needs to be in context

    6
    • 10

      Obinwanne Hill

      July 9, 2014 3:53 am

      Yes, you’re absolutely right. I think those two valid scenarios are an opportunity to improve the content, rather than what we have today. Thanks.

      0
  4. 11

    Very interesting article with excellent approaches! But maybe the third step after the next one from today’s point of view.

    For me as a web developer I would be glad if I just knew in addition to what I already know:

    - bandwidth (would make “responsive images” a lot easier)
    - input device (touch, keyboard, mouse) for adjusting and optimising clickable elements

    Shouldn’t be too complex for vendors to make queries such as “@media screen and (max-width: 1024px) and @input (device: mouse) and @bandwidth (speed:cable)” available.

    0
    • 12

      What do you do with a Windows 8 tablet or laptop that has all three inputs, and can be used at anytime with any of them?

      Bandwidth, however, I am completely agreed with. But if you have read up on it, it is pretty darn flaky. I personally live in a rural area with a wireless (not cell towers, something a bit faster that is closer to the spectrum of radio and needs line of sight to the towers), where signal can be anywhere from 10mbps+ to <1mbps depending on the amount of people and weather. So, how do you detect my bandwidth?

      0
    • 13

      Obinwanne Hill

      July 8, 2014 9:13 pm

      Hi Lars,

      I personally think there should be a lot of parameters to play around with so Web designers/developers can choose which ones to work with based on the task at hand. As we are all different and have very different ways of working, as well as different project requirements, it would be great to have as many as possible. Bandwidth is definitely a big one being that there is so much disparity with mobile networks across the globe. The More the Merrier I’d say.

      2
      • 14

        The user bandwidth size has only consequences on the media itself, resp Images, Video or Sound.. So filtering at css level the bandwidth drives to select different versions of the same media.. And so the need to create a matrix of medias.. That’s heavy.

        I believe that new progressive media formats are better. By ex you would have 1 high resolution picture called, but based on the client bandwidth it will be loaded during 500 ms resulting a custom resolution.

        0
  5. 15

    With this methodology, specifically your COAT example, you run the risk of second guessing what the user wants to do with a *very* simple set of criteria.

    Companies like Google are investing a massive amount second guessing based on an incredibly complex set of criteria.

    Profiling with broad strokes is a bad idea.

    You are doing the same thing with the concept of adding device specific classes – broad strokes. The problem with this is not every ‘.tablet’ or ‘.mobile’ is going to have the same capabilities.

    You are also breaking the idea that the data served should be completely device agnostic – which isn’t good.

    I expect to be able to view the *same* data regardless of device. It may be presented in differing formats, but I want to see *all* the information I get on my desktop, on my mobile phone. There’s no reason not to.

    In short, whilst I appreciate the thought you’ve put behind this article, I view it as a step backward.

    6
  6. 16

    The problem with a context-sensitive web (though I agree it’s where we’re heading to) is that as you add additional factors, it becomes exponentially more difficult to develop a solution that can address all those issues.

    If we have A and B, then you can have A- B-, A- B+, A+ B-, A+ B+. 4 possibilities. Add just 1 more issue to be aware of and then you go from 4 possibilities to 8. Another and we’re at 16 permutations. This type of growth has an associated cost with it, and no project is without its budget.

    My current problem with the development process is that we’re seemingly focused on dispelling how we USED to do things, and I feel that’s a step in the right direction; but when someone asks, “OK, well then how are we supposed to be doing it?”, the answers that are given are so contextual and piecemeal, that we begin to not even expect an absolute answer, but instead information that is just relative to one possible instance of an answer. Our field moves fast, but I think we need to be somewhat less focused on change for the sake of being the person who can coin a new phrase or methodology in design, to finding a more finite, sustainable solution that takes our current problems and puts a more tangible resolve to them.

    Even when we propose a solution that is amicable to everyone, we then have the ever-lasting battle of awaiting implementation and market share to warrant a definitive measure in the solution.

    0
  7. 17

    The more I reflect on your hat trick, the more I ponder why they should be CSS classes. Instead of adding all these things to the class attribute of the HTML tag, why couldn’t there be an entirely new syntax for accessing these? Maybe something like device["width"] or device["type"] = mobile? Obviously the syntax could use some work, but you get the idea.

    Same concept as your hat trick, just less cluttering the html tag and making weird class names.

    0
    • 18

      Obinwanne Hill

      July 9, 2014 1:20 am

      I can appreciate your concern, but if you have true/false certainty then classes are the way to go. If I want to do something with a tablet in landscape mode then writing something like “.tablet.landscape #tag-id {}” is the easiest possible way to go. The only challenge would be if I’m targeting a range e.g. between 2am and 5am, then classes would not work so well. Still, a TIE implementation would solve this and I’m working one at the moment.

      0
      • 19

        All I am saying is replace classes with a syntax similar, but not the same as. The idea is that you can then avoid collisions and ugly code. Right now, classes do not contain reserved names, much like you would want to make. This lack of reserved names is one of the things that keeps the CSS easy and accessible to newer users. If you had the browser automatically using .tablet, and a person then added their own .tablet elsewhere, this could cause unwanted side effects. So, instead of your “.tablet.landscape #tag-id” it could be “^tablet^landscape #tag-id”. Obviously someone would need to standardize the syntax and make it easy to expand as new devices and/or contexts arise.

        0
  8. 20

    Two questions:

    1. What is the difference between a user on a 1024 x 768 (or larger) tablet and a user on the same size notepad with touchscreen? What’s the difference between a user on a 1024 x 768 tablet and a smartphone of the same size?

    2. Why do you want to force me to use your website/app in the way you have foreseen it for a given device? For instance, I use my smartphone much like a portable computer and if a website doesn’t offer the same capabilities for phones and desktops, I’ll often just leave, never to return. It’s one thing to emphasize different parts of the website based on the platform, it’s something else to just hide parts because the designer has decided that a certain type of user will not want or need them.

    Frankly, there is one simple truth to responsive design today: the vast majority of it is incredibly bad. For instance, there’s one local company that are supposed to be “masters of modern design”. Yet when I checked them up, I almost had a heart attack. The user ends up with Chinese letters on Android 2.3 for their homepage, misplaced paragraphs and images that cover the heading in iOS7, menu that works on touch release, which means you can’t fix a miss-click without opening the link and a grand total of about 15% of viewable height on iPhone 5 in landscape mode.

    Why? My guess is, whoever is coding their design (Chinese? :D) is doing it in Chrome’s Emulation tool, never bothering to check the real deal. Then when you test it out on real devices, it’s a horror story come true. And don’t even get me start it on their code – I wouldn’t touch it with a two yard stick.

    In my opinion, people really need to stop thinking of breakpoints in terms of “here ends one device and another starts”. Instead, the breakpoints should be “here the current layout no longer works. Let’s modify it.” Don’t get me wrong, I’m all up for device specific CSS such as one type of interaction for touch and one for click – as long as it doesn’t pigeonhole users into specific niches. One web, one code, one content.

    5
    • 21

      Obinwanne Hill

      July 9, 2014 1:07 am

      Hi Andrej,

      1. I want to assume by asking “What’s the difference between a user on a 1024 x 768 tablet and a smartphone of the same size?” that you are referring to screen resolution not physical size? As you know, most phones that are of that resolution get there as a result of pixel density i.e. device-independent pixel size will not be 1024 x 768, but rather a divisor. The difference with the Notebook and Tablet of same size would depend on mode of usage i.e. if the notebook screen is detached from the keyboard, it becomes a tablet, and the pointer dynamic switches from ‘fine’ to ‘coarse’.

      2. It isn’t so much hiding items as it is a consideration of suitability of form-factor and context of usage. Do you want to edit a spreadsheet/calendar if your phone was 240 x 320 pixels? How do you scale things down, if possible at all? Images are easy, components not so much. The designer/developer has to make some kind of call, and it’s incredibly difficult to implement even after you decide what you want conceptually.

      “One web, one code, one content” is easier said than done…as long as we have “Many devices, many use cases, many types of UI components” that is. It’s not always about your layout no longer working, you sometimes have to make a call on a device class level i.e. How is this going to look-and-feel on a Smartphone [as a broad device class]?! I know a lot of designers work this way.

      If the tools we had at our disposal [e.g. Media Queries...and even CSS in general] were much more robust, it would enable any Web designer/developer to make these adaptations as the need dictated.

      1
  9. 22

    I think there are some great ideas here.

    HAT would solve many problems we currently have with responsive design. I recently looked into how to detect if the user’s device had the ability to make a phone call so that I could add a “call us” button to a website. You’d think it’s would be simple but the only solutions are hacky. Similarly detecting a user’s bandwidth (even vaguely) would be incredibly useful. I’ve also tried to detect if the device “has a mouse pointer but no touch ability” so that I can disable swipe events. This is also WAY harder than it needs to be. The browser could know all of this and your solution of using CSS classes means that you can make these changes without even employing any javascript!!!

    TIE is also something I’ve been thinking about recently. The ability to use expressions in CSS would solve many, many common CSS problems. Off the top of my head – Element queries, equal height columns, maintaining aspect ratio on a DIV, changing header layout on scroll position, etc. etc.

    Of course, you can currently do all of this using plain old javascript, if you want to go through the hassle of setting up a setInterval and polling the scroll position, or handling the resize event to recalculate box sizes, but it’s never easy to get right and it’s often jerky of flat out breaks on some devices (e.g. iOS doesn’t fire scroll event until scrolling finishes). TIE would make all of this a walk in the park.

    Great work.

    0
    • 23

      Thanks for reading, Jon. And I appreciate the compliments as well.

      I’m often perplexed how conceptually simple Web design is, but it just falls flat a lot when it comes to implementation. True creatives who aren’t into the technology can’t understand why you can’t just make certain things happen on a Web page. Hopefully, in the near future, the tools become much more robust so building a Website can be more fun.

      2
  10. 24

    David Gilbertson

    July 9, 2014 4:02 am

    My two cents:
    Basing breakpoints on device ‘type’ is just wrong. No one saw the iPad coming. No one thought humans would hold 5″ phones up to their head in public, and I for one don’t know what’s coming next.
    Breakpoints should be based on content. If your body content and your sidebar fit snugly side-by-side in 714px but not less, then there’s your breakpoint. If at 951px+ you reckon you can fit in comments down the right too, then bam, another breakpoint! If one breakpoint makes sense, you have one, if six makes sense, you have six. This is what’s best for the user.
    On a more positive note, I like using classes HAT style as a kind of shortcut for media queries. Tidies up the CSS nicely.

    9
    • 25

      Obinwanne Hill

      July 9, 2014 6:19 pm

      Thanks for the feedback, David.

      I don’t agree with your ‘Device type is wrong’ assertion because not everyone designs Websites the way you have just described, and I think we should respect the workflow of those that don’t. Personally, I usually look at Web design from a Device Class perspective i.e. I want my Website to work on a Smartphone, a Tablet, and on a traditional Desktop by default. That’s 5 possible breakpoints: Phone-Portrait, Phone-Landscape, Tablet-Portrait, Tablet-Landscape, and Desktop; and I can use 3 or 4 or 5 depending on what I’m trying to accomplish. That was my starting point for the Restive.JS website…and I didn’t even use Media Queries at all. You can’t tell me that a Web designer won’t feel the need to do something on a Tablet in Landscape orientation, and not have that same thing happen on a Smartphone?!

      My point is: Let’s make the tools super-robust and give the Web designer/developer the onus to decide what is best for their project. If a new Device class comes along, you’ll know if it goes mainstream and you can decide to target it specifically with a little more code, or scale an existing layout if the dimensional changes/ratios are inconsequential.

      -2
    • 26

      Yes, we should focus on device capabilities instead of device type to be future-friendly, as feature detection instead of User Agent sniffing.

      Choosing the right CSS unit (%, em, px) for each breakpoint is also essential. An arbitrary value of 714px may depend on the default font size and browser zoom value.

      0
  11. 27

    Really fascinating article.

    0
  12. 28

    σχεδιασμός ιστοσελίδων

    July 9, 2014 6:15 pm

    Very interesting article. Nice work!
    Many thanks from Greece

    0
  13. 29

    Good read. Love how you’ve tied it all together. Glad to see more people are trying to tackle the context problem. :-)

    Don’t agree on the device type thing though, I feel the device landscape is getting way to broad for using devices types as identifiers, also binding to a device type is anything but future proof (what brings the future?). When new device types enter the market you would have to add those types (to your js lib and to your css files) which turns into a maintainability nightmare.

    The only negative about media queries is that they function on window level and not element level. They do their job well and offer the required device abstraction.

    Instead of fixed widths, start small and base your media queries on amount of characters per line. More than 12 to 13 words, it’s time for a breakpoint, scale up and tweak your CSS.

    2
    • 30

      Well, if you’re happy with Media Queries as it is [except for No Element Support of course] then that’s fine. Personally I’m not, I don’t use them, and probably never will. The good thing is that even though two Web designers can have two different approaches to building the same Website, they can still build a pretty good Website. It’s not about Right or Wrong Way, it’s about Done and Done Well.

      Regarding, Device Landscape I think it’s unlikely that we will see a proliferation of class-less devices. A device class must appear to have mainstream potential before it is widely adopted by designers, which is why there probably aren’t too many Websites offering a unique Google Glass experience (even though it does deserve one). But if it [Glasswear or iGlasses or whatever] does go mainstream, it would be a let down if all we can offer is a Media Query-laden Website.

      -2
  14. 31

    “that media queries exer” should be expert?

    0
  15. 32

    The start of this article is very misleading. It makes it sound as if Media Queries only exist because of Apple bringing out the iPhone, which simply isn’t true. The first Media Queries specification was written back in April 2001, 6 years before the iPhone existed, and used a very similar syntax to what is in use today. The only thing Apple had input into Media Queries is the viewport Meta tag which, when first introduced by Apple, went against the W3 specification for mobile devices. At this point developers were forced to use this invalid Meta tag in order for their websites to look okay on Apple’s devices – and it was only a few years later (2010 I believe) that this Meta tag was featured in one of the specifications.

    For reference, here is the original Media Queries specification: http://www.w3.org/TR/2001/WD-css3-mediaqueries-20010404/

    0
  16. 33

    Hi, thanks for great article.

    Device detection is cool feature, but do we really need >60kb library + jQuery to interpret UAString?
    I’m currently using – https://github.com/matthewhudson/device.js and works fine for me (most important things only – device type and screen orientation)

    0
    • 34

      Thanks for reading. It’s about 60Kb total (JQuery + Restive.JS) if you GZip. Also, you’ll find Device and Orientation Detection a lot more accurate on Restive.JS

      0
  17. 35

    Very interesting article with some excellent thoughts!

    However, I see two key problems that will stand in the way: autonomy and privacy.

    IMO, people tend to be displeased by overly limiting or guessing interfaces that try to provide an optimal user experience, whatever that may be. Google Now, for example, sometimes drives me crazy! As someone posted before, 6:00 am could mean waking up or coming home from work. Opening a fridge could mean search for food or for medicine in a hospital. I don’t see how any number of brilliantly tweaked “breakpoints” can compete with carefully set up settings.

    Also, I can imagine people turning of several features and APIs of their devices to keep some privacy. Maybe I don’t want my fridge to know what I need?! Privacy is a sensitive topic these days.

    I understand that you exaggerated with your example, but those points also apply to things like the GeoLocation API. I guess what I’m saying is that we should use new techniques and APIs gently and only where is appropriate and adds value for the user.

    2
  18. 36

    Interesting article.

    I build RWD sites for a living. Not a hobby, I’ve done several 40hours/week frontend code.

    My experience is : quite frankly, media queries plus css naming convention get the job done. The most time consuming thing is the numerous screen sizes, and mq basically solve it. Just add a little server side detection for the edge cases. Throw in some JS, just do not require it.

    Bandwidth isn’t a problem if you set yourself a performance budget on every page.
    Retina images have been solved by srcset and picture thanks to the RICG work.

    The HAT trick looks like a maintenance nightmare to me. This is just my opinion.

    2
    • 37

      Thanks for your contribution, Laurent.

      In my case, I haven’t found HAT to be a maintenance nightmare, in fact quite the opposite, especially when you compare it to Media Queries. The CSS markup is inline with your existing CSS, and not in seperate media query directives, so it’s bound to be easier to maintain. But that’s my own experience so far.

      0
  19. 38

    A hot topic to debate I am sure however the “HAT Trick” we can do this today with CSS and JQuery there is no need to annoy the W3C to perform to your wishes to bloat out an already defined standard.

    CSS is for pure presentation and nowt else, please for the love of God leave it that way; if you wish to perform something more, to the tastes of the user [of said website] then utilise the proper tools, such as JQuery.

    As for COAT [?} that is not going to happen, not by the W3C; as mentioned above there are privacy issues, but do we really deserve another series of meta tags, do we really I ask?

    Look at your "a typical" commercial website today and you'll more or less see over a dozen meta tags, all for different sources; we have some for search engines to index content; we have some for social media; we have some specific to industries; etc etc.

    No more please, we are busy little .... already, and personally I want to retain my sanity and some time [for what little time I do have] with my loved ones.

    0
  20. 39

    I’ve heard many criticisms of the approach to Responsive Web Design, but for me, ignoring the type of device, and rather focusing on the size of the screen makes perfect sense to me. At least when we’re talking about laying out elements and deciding sizes and proportions.

    One thing I do see as very useful, though, is the ability to check for “touch”. If this could be easily targeted, it would be so easy to cater styles and behaviours to touch devices, giving the ideal experience.

    1
    • 40

      Hi Adrien,

      Thanks for your contribution.

      I’m not trying to mess with anyone’s workflow, just broaden the toolset to give a lot of different options.

      Some Web designers who are comfortable with JavaScript might need access to ‘touch’ in that environment, and still some who are not might need to enable a DIV using the same parameter in CSS. It helps when you have access to something robust like an SDK so you can a lot of things based on your goals.

      Some day maybe.

      0
  21. 41

    Great article Obinwanne, found it very useful & will start testing out your Restive program in my websites tomorrow! Thanks.

    0
  22. 43

    Appreciate your thoughts, but I believe this approach is wrong, for most of the same reasons others already articulated. I’ve built many responsive sights. It’s not an issue. The issues arise when “designers” cannot envision the site as a whole, and are not familiar with designing with responsiveness in mind. This is not a problem with media queries or RWD in general.

    If you really understand your HTML and CSS, and how to architect it, then RWD can be done with minimal trouble and minimal extra code.

    Further, your example about modular design and moving DIVs around … solved easily – again, if you know what you’re doing. The DIV is 100% no matter where it is – and its container size changes depending. Then, no matter where you put that block of code, it fills the space you’re trying to fill. No extra CSS needed. Very easy.

    1
  23. 44

    Good job Obinwanne Hill, I really appreciate your thinking and probably it’s more from front-end developer prospective view. From all of these unique classes I can handle a lots of conditions just via css.

    I don’t understand why people are screaming about hardcore js?

    But yeah, all these classes should be optional, developer should allow to choose what conditions they wanted to check (same like modernizr).

    Expect to have this kind of plugin very soon!

    0
    • 45

      Thanks Jimba,

      I feel being able to interact to use CSS rules based on complex segmentations will significantly shorten development time and give Web designers the ability to adapt layout and content based on these specific thresholds. You don’t have to do them all in one day too, you can do it iteratively.

      At the end of the day, it’s kind of like an SDK; there might be tons of functions, but you get to choose which ones to work with based on your specific project or circumstance.

      I’m currently working on a Joint HAT/TIE Framework, and I’m taking my time to make sure it’s super-simple to understand so stay tuned to SmashingMag for more on this.

      Cheers.

      0
  24. 46

    i think your ideas are good, but i really don’t like the way the internet is going to be in the near future. i don’t want, a website suggesting me, what i want to read / buy. i hate it currently when google and amazon serving search results generated from my historic searches.

    maybe we can stop thinking to know what the single visitor looks like and what are his/hers interests are and concentrate on more / better structured websites so he / her can find faster what he / her is searching for.

    so we all won’t became lazier to use our own brains.

    0
    • 47

      Kurt, I had penned a long post (pressed the the wrong key sequence & poof it was gone :-( ) – which you have neatly summarised it, and Eli Pariser in a Ted talk on “info bubbles” discussed this issue. As a high school teacher it annoys me that I can craft a question that I know will return good results (kids are lazy & just type in the question) , but when the kids do the query they get back a vastly different set of results.

      At the risk as being marked a heretic, the other trend that makes me think changing the standard to incorporate responsive design is fighting the last war. Many sites I now go to offer me an app before allowing me to view the content (I always refuse – my RAM is precious) – Remember the angst about gradients and radius’d corners – we get them & the world goes flat and square.

      I would suggest true responsive design would allow me on a site by site basis decide to choose what content (images and video) I want. I am interested in politics – on political sites I don’t need to see photos of Obama or Hillary or the front of the IRS building or the Capitol – I know what they look like – the photo and in 99% of cases video which autostarts (a pet hate of mine) is just noise, whereas I would want images on design sites or tutorial like this as they ARE often the story

      I especially hate the “noise” and when mobile resent mb of download that exists only to determine what my device is so I can get the “optimal” experience. Having an ipad air means I will get the highest resolution image – why not give me the option to say give me the low res – I will ask for the high res when I want it.

      Sorry if this sound like a rant, but I think real users are more forgiving than we realise – badly broken is one thing (whereis.com.au used to have an image of a kid with its fingers in his ears saying we cant here you ie we don’t like your browser) little glitches meh !

      0
    • 48

      Hi Kurt,

      There’s really no way to escape suggested content. The information you already read on Websites, as well as the products you see on online stores, are already someone else’s suggestions of what they believe you’ll like/need/buy. It’s up to us to discern what we deem important from the mass of information out there.

      Still, there’s really no way to satisfy everyone, but I think there is some merit in prioritizing content that you have a stronger affinity for above things that might not exactly appeal to you. This would be more valid for those who disseminate content on a lot of categories e.g. an ESPN in Sports, a CNN in News, etc. GolfDigest or Politico? Maybe not so much.

      0
  25. 49

    Vince Caregnato

    July 25, 2014 10:56 am

    I love how you’re thinking so outside the box. What I just don’t agree with is your view on device-specific media queries. You seem to be selling them as ‘the way forward’.

    Device-specific MQs might be great for rigid bootstrap-like websites that don’t need to be very flexible. But they’re not a good idea for the non-grid websites or more artistically created websites. You should always be catering for a range of devices, not just pick just one and work with that. There are new devices coming out every day. Bigger phones, smaller tablets, notepads, … Are you going to be updating your media queries every time a new device comes out?

    I agree with you in some way and see where you’re going with this. The HAT trick for one, seems to me to be a splendid idea, but only used in combination with existing media queries to enhance the browsing experience of the user. First make your website responsive, then add your HAT classes.

    I see this being used to inflate some buttons on a mobile device, to load high res images on a high bandwidth, to paint the website black at night, …
    Beside that, I don’t feel like you’re going browsing the web on your fridge or your smart watch. These devices need to facilitate something native to work with.

    I’d be great to have HAT in the HTML as just a meta-tag because I see Javascript using HAT as much as CSS would. Device detection is a pain in the ass in Javascript and I’d be great if we could just read a meta-tag instead.

    COAT seems to be a great idea but there would be security issues. Denying that would be naive. TIE on the other hand would make CSS way too complicated and I’m sure performance issues would arise.

    In general, the article isn’t actually about breakpoints, the title’s somewhat misleading. The title should’ve been something like ‘Improvements for future UX’. I liked you outside the box thinking, not everyone can make something original into a practical solution. This reminded me of this article I read yesterday: http://www.helloerik.com/no-one-said-they-wanted-faster-horses-they-wanted-less-horseshit

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top