Tag Archive / CSS

  • A Brief Note on Responsive Design and Constraints

    (In response to Adam Silver’s Stop using device breakpoints)

    There are two points that I like to add –

    The relationship between Constraints, Content, and Context

    Content

    Content will always affect Constraints (i.e. breakpoints) and vice versa.

    What I do is a) use the familiar set of breakpoints as initial guesses and b) treat them as assumptions that need to be tested and verified.

    If you’re getting more breakpoints, maybe you need to reconsider your initial ones. Some may just need to be:

    1. Moved or
    2. Removed completely

    Experience

    This is probably more a developer than designer problem(?) but depends on your background. It comes down to hands-on knowledge of various devices.

    1. Don’t assume the device you have on hand is the one [definite] solutions. Just because you have an iPhone doesn’t mean everyone else does…sounds sensible but you’ll be surprised how many people don’t follow that advice. I have experience because most of my work involved non-American clients (more likely to see a Samsung than an iPhone).
    2. Comes back to testing on multiple devices – using BrowserStack (or other simulators) helps testing for both iOS/Android devices or just get a few old/borrowed devices on hand.

    The idea here is to get use to the idea of breakpoints as initial guides, not fixed points.

  • Future Imperfect

    As I’m writing this, it’s a rainy morning in Vancouver, Canada. Nothing new. Spending time with friends that I don’t see but once a year near my birthday. In this case, I’m here to attend the IA Summit conference this week. This is my first non-US conference since IxDA Interaction 13 in Toronto.

    Looking back at that conference there were a number of things that stood out. A number of them became influential years later. One of them was a short lecture by a designer named Nate Archer called “Beyond Responsive”.

    Nate Archer: Beyond Responsive from Interaction Design Association on Vimeo.

    Well, four years later, those words seem prescient right now. The world has been filled with all sorts of devices that we access the web. More than just the trio of phone/tablet/desktop. Basically, any device that has access to the web is an access point – from watches to 4000K TVs. But there is another way of looking at this. Instead of “devices”, let us consider going in the direction of “inputs”. Responsive design appeared not just with mobile devices but devices which are also touch-enabled. Now, mobile devices are as ubiquitous as any household device, front-end developers like myself have to deal with coding for interactions that take place on touchpad as much (or even more) than mouse/keyboard. (Though we could be doing a better job at the keyboard then we are currently doing.)

    [Note: touch-enabled devices are not necessary phones/tables and doing feature support for touch is still a bit tricky]

    In some respects, the beautiful lie of responsive design is that the constraints are visual, via breakpoints and media queries? But what if those constraints aren’t visual. CSS has hidden artifacts describing inputs – media types. If one would look at the specs (https://www.w3.org/TR/CSS21/media.html#media-types), the following types are supported:

    screen, print, speech/aural, handheld, tty, etc.

    Screen is the most familiar with print/speech following. But there’s tty? From the spec, tty refers to devices like terminals and teletypes. The later was a telecommunication device that has long since disappeared with the advent of email. But back in the day, it was considered important enough to be considered in the W3C CSS spec. Now think about the future. Someday, will we may consider mouse/keyboard interactions as obsolete as teletype?

    Now, we are seeing the advent of AI interfaces – sophisticated interfaces that allow access to the same information like we do with mouse/keyboard and touch.

    Which comes back to the conference I’m attending, IA Summit. This year’s topic is artificial intelligence and information architecture. The main job of a front-end developer is building interfaces for acquiring information. Obviously, things will change in the next couple of years. But change into what?

  • A Brief Note on Container Queries and RWD

    Well, while making the first steps in writing my next lecture about responsive design, I came upon a Tweeter discussion last week. Ethan Marcotte, author/mastermind behind RWD, talked about container queries and his support for them. Very interesting read.

    Ethan Marcotte “On container queries.”

    I’ve heard about container queries before during the last year or two. But I decided to read this article with much more intent because of topic relevance.

    To describe container queries, you need to think about web apps/sites as a system. Changes via media queries are macro, that is, applied to the whole system. It’s what we been doing for years. We build the base (preferable mobile first but any sort of initial state we want) and apply changes at certain breakpoints. So when we write the following media queries:

    @media (global conditions/breakpoints #1) {

    … some changes here...

    }

    @media (global conditions/breakpoints #2) {

    … some changes here...

    }

    etc..

    what we are doing is

    Global Media Queries (Ottawa Model)

    Even though these changes are to certain areas such as footer/header/etc.., these are applied as if the whole app is one big container.

    But with container queries, we are applying changes at the micro level. Instead of the previous example, we are applying changes to local containers. The queries will be influenced by the container conditions, not by the overall viewport. So now instead of the previous model, we have the following:

    Container Media Queries (Ottawa Model)

    and with each part

    Container Media Queries - Expanded (Ottawa Model)

    we are applying changes on the local level/containers. These media queries are not global and [could] be different from other containers. You could have a combination of global and local conditions in this system as well (don’t know if this would happen but you never know):

    Container/Global Media Queries (Ottawa Model)

    As for the talk/lecture, nothing had really changed. The main focus of the talk is the “why’s” of what we do in terms of RWD. However, it is obviously something to think about further.

  • The Secret Life of Forms

    CSS Dev Conference 2016 - San Antonio, Texas

    Slides – http://www.slideshare.net/IvanWilson3/the-secret-life-of-form-67435952
    Lecture – https://cssdevconf2016.sched.com/event/7Q0d/the-secret-life-of-forms-secretforms

    One of the highlights of the year was lecturing for the first time at a conference. In this case, CSS Dev Conference at San Antonio, TX. Basically, I decided to take some advice and take a chance. After sending my proposal, I was shocked and thrilled to be selected via anonymous vote in July.

    Of course, getting the talk ready was even harder than the waiting. It took months of writing and editing and practice. But I was able to get it together and delivered it a small audience at the conference on October 17, 2016. This talk was about UX, coding, and forms. However, it was peppered with things that I’ve done during the last ten years at CDG/Innate.

    That said, I want to thank my fellow co-workers – including Lisa Crotty for her advice, Brian Schlansky for his time and his ear while prepping the talk, and Scott Adams (company CEO) for letting me do one final practice in front of the company for a much needed warm-up.

    I also want to thank the other speakers at the conference in helping me not only relax but also giving me advice for speaking not just for the first time but also their experiences in giving lectures as well.

    And finally, I want to thank Christopher Schmitt, Ari Stiles, and Elizabeth Moore in helping me make my first-time experience as a lecturer a wonderful and memorable one. It means so much when for years I was attendee, to be not only speaking but giving back to the community that I respect.

    Thank you all 🙂

    Lecture - The Secret Life of Forms, left - notebook, right - presenter pass

  • Happy Anniversary, Project Ottawa

    Last year, prior to going to Jonathan Snook ‘s inaugural SMACSS workshop in Ottawa, Canada, I was thinking. There was something that I was on my mind for the past year. Then, [place lightning description here], I got inspiration from looking at some of my old linear algebra books from college.

    What did I do next? I announced it on Twitter:

    I spent whatever free time, post-workshop, working on this in my [first] Moleskine notebook. The early sketches look more like algebra proofs that the visual model that exists today.

    IMAG0433

    However, these sketches and some rules that I wrote down became the basis of the project’s First Draft.

    Preview - New Project

    And as they say the rest is history.

    Though currently on hiatus, I am planning a few more sketches and notes in the current year.

    Hopefully, this project will still be around for year two.

    Happy Anniversary, Project Ottawa!

  • Gesture-Based CSS Selectors

    [This is a short, informal proposal of a concept, with a more extensive version in the near future. However, this should be enough for starting discussion on its value/implementation.]

    What are Gesture-Based Selectors?

    Gesture-based CSS selectors are a combination of the current set of CSS selectors/pseudo-selectors to include new set of gestures currently being used in mobile (tap, tap hold, swipe, etc.). The main goal is to give basic interactivity to elements without JavaScript support.

    The closest analog would be the same sort of relationship with CSS3/JavaScript animation. In the current methodology:

    • CSS3 – basic/simple animations, removing the need for JavaScript resources
    • JavaScript/JavaScript Library via Events – complex animations, requiring more functionality beyond CSS3 animations

    Initially, this was just focused to touch gestures. However, this can be also be extended to other "gestures" such as the current JavaScript events "click", "mouse(over/out)", "key(up/down)", etc. This will allow for non-touch gestures → keyboard, voice/speech, inputs from any other devices, etc.

    CSS/Gesture Selectors Format

    The concept is to have these represented in CSS code by the following selector (in two versions, using the mobile gestures swipe left and tap hold as examples):

    1. selector:gesture-(gesture name)

      Similar to :hover, :focus pseudo-selectors (using current

      Examples:
      div:gesture-swipeleft { CSS code }
      a:gesture-taphold { CSS code }

    2. selector[gesture=”gesture name”]

      Similar to attribute selectors, introduced in CSS 2.1 but in use more with CSS3

      Examples:
      div[gesture=”swipeleft”] { CSS code }
      a[gesture=”taphold”] { CSS code }

    Constraints/Problems

    At this point, three initial problems appear:

    1. New Devices/Platform w/ Gestures – some sort of path/procedure needed for recognization of new gestures that is open and flexible. I recommend the following for an initial path:

      Device/Platform Support → JS event support → CSS/gesture selector available

      This will allow for the availibility for selectors mention above. However, there is the problem of device-specific gestures, which could mean that certain selectors will be available for only those devices. Currently, the touch events are only available on touch enable devices. If a [front-end] developer was writing code for a non-touch enabled device, the JS support would be non-existant -> no CSS/gesture support

    2. Gesture Uniformity – if a gesture gains support across platforms/devices, the related CSS selector should never be prefixed as we currently have for CSS3 features like animations or tranforms, ie "-iphone","-android", etc. I recommend this because unlike CSS3 features, these are OS based issues ("native"). The selectors will be device/platform "neutral" – let platforms/devices be solely responsible for interpretation.
    3. Computer Processing – if this gets implemented, how does this effect processor/power usage. How does the current set of CSS3 features (transitions/animations) deal with different computer processing power (hardware accelerators?)

      If this gets added to the current set – will there be a bigger demand for hardware processing? What would this mean for small, less powerful devices? (the drive behind iPhone design and construction).

      Overall – This is an issue that will need to be taken up post-proposal, with people more knowledgeable than me.

    In summary,

    1. Creation of CSS/gesture selectors to allow for basic interactivity, without the need of JS events
    2. Providing a “path” to allow for more gestures, not just current but for future devices/platforms and be platform/device independent.

    Flickr – Scans of hand-written notes from Polaris notebook