Jordan Moore MembershipRSS

A Browser is a Phoney Phone

15th November 2013

The Chrome development team proudly announced that they addressed one of the most common complaints from responsive designers about their browser - Chrome now let’s you resize your browser down to 320 pixels wide1.

While it’s nice to resize down to the width of some popular mobile device screen widths it reminded me of some of the issues with relying on resizing a browser to test responsive designs.

Limitations with testing in a desktop browser:

There are more reasons, these are just the ones that spring to mind first. I’m not saying you should stay away from desktop browsers altogether for responsive design testing, in fact I find a narrow browser window a great foundation for making a start on responsive layouts — it’s part of my workflow.

Generally I find that using a desktop browser is good for quick layout tests — for example if something is badly broken it might be quickest to diagnose on a desktop browser, fix and test on real devices. It’s quick, it allows for page source inspection — it would be foolish not to make use of these tools.

The point I’m making is that there are testing limitations that you wouldn’t face with a suite of real devices2.


  1. If you haven’t been docking your browser window to the right you’ve been missing out on resizing your browser window below the 320 pixel mark. 

  2. Hat tip for Mr Stuart Robson for reminding me about this 


Markdown: Beyond the screen

15th November 2013

Markdown is great for a number of reasons. It helps people unfamiliar with HTML write in a way that will render as valid, structured HTML with the appropriate tools behind the scenes that the writer doesn’t need to worry about.

Another thing it’s great for is formatting in the absence of visual formatting. You’ll notice this in plain text editors like Sublime Text or in content management systems that lack WYSIWYG formatting tools. We have been spoilt recently with applications that give us the best of both worlds — tools like iA Writer and Editorially that allow us to see an inline preview of the Markdown-formatted text as well as maintaining the Markdown syntax.

Editorially’s beautiful editor shows you inline previews of Markdown-formatted text. The best of both worlds!

I have a scenario where Markdown is a huge help in the absence of formatting — handwritten notes. It’s something I have been playing with for the last few months, and unsurprisingly it works very well.

The problem with handwritten notes is that formatting is substituted for spacing which sometimes isn’t enough to clearly read a handwritten document with sections and headings. Before I started using Markdown to take analogue notes, I would have trouble differentiating between a heading or a very short, isolated paragraph.

Markdown thrives in plain-text environments where it is the only visual reference for formatting which makes it ideal for pen and paper. By using hashes for headings, it provides a quick visual clue for section breaks on paper.

It’s also useful for emphasising text. I used other techniques in the past like retracing the letters (can be messy and time-consuming) and underlining text (can lead to accidental line-throughs when writing quickly), but Markdown’s asterisk-wrapping is quick and easy to write and provides a great visual anchor when scanning notes.

If you find yourself struggling to create a visual hierarchy in handwritten notes I suggest giving Markdown a try. Where formatting is absent Markdown excels at providing you with a great formatting framework for helpful visual reference points.


Articles that changed the way I work

12th November 2013

Our Twitter streams and RSS feeds are flooded with valuable new articles every day. Some I get time to read, some I don’t, some of the ideas within stick and some ideas simply don’t — that’s just the way it is with writing on the web as with any advice in life.

Here are the articles that have stuck with me and influence how I make things for the web:

Mindset

A Dao of Web Design by John Allsopp (2000)

It goes without saying that this article should be on any web designer’s list. It’s 13 years old but it’s just as relevant to today’s web.

Responsive Web Design by Ethan Marcotte (2010)

Ethan Marcotte started a shift in design thinking that I feel is on par in terms of scope with the web standards movement. This turned my approach to web design on its head and encouraged me to look at things from a new perspective much in line with John Allsopp’s vision of the web.

Mobile First by Luke Wroblewski

Designing and building for mobile first keeps my design decisions in check ensuring they are focused and that anything I add to a page holds value and isn’t there for superfluous reasons.

There Is No Breakpoint by Ben Callahan (2013)

In the absence of element-based media queries, Ben’s approach to responsive web design is one that I have also adopted. I couldn’t go back to forcing all my design decisions into a handful of media queries.

Typography

Compose to a Vertical Rhythm by Richard Rutter (2006)

Richard’s timeless piece on vertical rhythm is as relevant today as ever. In small screens your vertical rhythm is exposed and under the microscope more than any other device.

More Perfect Typography by Tim Brown (2011)

Okay it’s not an article but I simply couldn’t leave this out. I was lucky enough to be in the audience when this talk was delivered. Any decisions I make regarding typography and spacing is informed by the takeaways from Tim’s talk.

Fluid Type by Trent Walton (2012)

This wonderful piece by Trent Walton taught me about the importance of typographical fluidity as well as how to maintain it regardless of screen size.

Colour Theory

Never Use Black by Ian Storm Taylor (2012)

Because using #000 would feel wrong now.

Content

Made to Measure by Allen Tan (2012)

If you ever intend on working with a CMS, you need to read this. It covers editorial design, responsive design and content strategy all in one rousing article.

Content Choreography by Trent Walton (2011)

This article changed my thinking about layout and content composition and how things should fold, rearrange and realign when the design has to break.

Philosophy

Atomic Design by Brad Frost (2013)

Brad’s analogy of breaking down the components we have at our disposal and knowing them at an atomic level ultimately leads to a greater understanding of their usefulness.

Of Bears, Bats and Bees: Making Sense of the Internet of Things by Scott Jensen (2012)

For understanding where we look at our products in a philosophical sense on the web.

Update: Alex Carpenter has put together a handy Kindle bundle of all the above articles.


Potential use cases for script, hover and pointer CSS Level 4 Media Features

11th November 2013

Having recently covered the luminosity media feature, I thought I’d take time to document the potential use cases for the other new media features in the CSS Level 4 Media Queries module. Note that at the time of writing these features don’t exist in any browser yet, so the following use cases are theoretical.

Introducing Script

The script media feature does largely the same job as existing feature detection methods albeit on a more limited scale (browsers that support CSS level 4 media queries). It checks to see if ECMAscript (commonly in the form of JavaScript on the web) is supported in the current document. That means if a user has JavaScript enabled or disabled in their browser, we can detect its state and make appropriate formatting adjustments in CSS.

There are certain limitations to what the script media feature can detect. If JavaScript is switched off and a page is loaded, the media feature will correctly report a value of “0” and it will report a value of “1” when JavaScript is enabled. But what happens to the media feature result when the user switches JavaScript off whilst viewing the page depends on the individual browser’s behaviour — it may or may not report a value of “0”. It also can’t be used as a way of providing a fallback if JavaScript errors cause something to break1 because the browser will correctly say that the current document is capable of showing scripts and return a value of “1”. The specification hints at future levels of CSS being able to provide fine-grained results of which scripts are allowed to run on a page2.

Use cases for script

Using the “not” keyword in a script media query would allow us to style fallbacks where JavaScript isn’t enabled. It could also be used for progressive enhancement where the presence of JavaScript isn’t taken for granted.

Here is an example of a script media query written with progressive enhancement in mind (assuming we have a JavaScript-powered carousel):


@media (script) {
    .carousel-links {
        display:inline-block;
                padding: 0.3em 0.6em;
                ...
    }
}

Introducing Hover

Similar to the script media feature hover returns a basic on/off (1/0) result depending on whether the primary pointing system on the device can hover3. Although touch-based devices may have the potential for hover capable input devices like a mouse, this media query will still report a value of “0” before any peripherals are attached.

The hover media feature solves a very common problem. Some UI elements that require a hover interacting like mega drop-down navigation menus often appear on touch-based devices that aren’t capable of hover functions. Their appearance is usually triggered by media queries based on screen dimensions which is not a reliable method for knowing if a device is capable of touch and/or hover inputs.

Currently the user agent on a touch device mimics a hover in some cases on the first tap of the hover menu item which seems to apply some sort of :hover and :active state. The point is — it’s not that reliable or user friendly. It takes a bit of guess work for the user to know a single tap activates hover. Thankfully the hover media query can help us fix this issue — as you’ve probably guessed, it detects the device’s ability to hover.

Use cases for hover

Upon detection of a hover-capable input device we could format our markup to enhance interfaces for such devices (e.g. drop-down menus, tooltips etc).

If we wanted drop down menus to only appear on devices that have hover input devices connected, then we would write:


@media (hover) {
    nav ul ul {
        display:none;
                /* Hide the sub menu and position absolutely to the parent li for a CSS-based hover drop down menu */
                ...
    }
        nav ul li:hover ul {
            display:block;
            /* Show the menu on hover of the parent li */
        }
}

Introducing Pointer

Pointer was generally thought of a way to differentiate between touch and other peripheral-based inputs. The media query produces 3 different values: none, coarse and fine — the assumption being that when implemented a non-touch or mouse-based device (like the 4th generation Kindles) would report “none”, an iPhone and iPad would report a value of “coarse” and a desktop machine would report “fine”.

Coarse means that the pointer limited accuracy. According to the spec4, that means that at a zoom level of 1 (your default zoom level) the pointing device would have trouble accurately selecting several small adjacent targets.

Inputs that would give a value of fine would likely be a mouse, a trackpad or even a stylus.

I have a couple of reservations about the pointer media feature and I can see potential misuse or misunderstanding of it.

A potential limitation might be when peripherals are used after the page load. For example would the media query update it’s values if I decided to switch to a stylus during browsing? Also the spec notes that for accessibility reasons some user agents may report a value of “coarse” in an environment where the input would normally be reported as “fine”.

The takeaway from all of this? Don’t rely on a coarse pointer to mean touch. Loading touch UI elements based on the accuracy of the input device is trying to solve a problem with the wrong tools. We should take pointer accuracy at face value — it can only tell us how accurate the input device is, therefore our formatting changes within a pointer media query should only make adjustments to for accuracy rather than input type. If you want to write CSS for touch enabled devices use Modernizr to detect touch capabilities because relying on the pointer media feature is like relying on a width media query to definitively say “this browser is a mobile phone”.

Use cases for pointer

The specification provides a good use case where you could theoretically enlarge tricky targets like radio buttons based on the accuracy of the pointer. Perhaps “coarse” would be a good default to work from - if we assume that the device is inaccurate then we can progressively enhance for accuracy.

The following code demonstrates how we could potentially improve accuracy on UI elements for devices with inaccurate pointers and reduce their size for devices with accurate pointers:


@media (pointer:coarse) {
  .btn {
        padding: 1.2em 2em;
        font-size: 1.6em;
  }
}

@media (pointer:fine) {
  .btn {
        padding: 0.6em 1em;
        font-size: 1em;
  }
}

The new media features offer great opportunities to progressively enhance our designs. I don’t think any of them should form the foundation for a design, nor do I think that they were ever intended to be used in such a way. What they do provide is a way for us to finesse the details. Make sure to check PalmReader to see when the new media features arrive on your device.


Web Design as a Craft

6th November 2013

Until recently I would have insisted that web design isn’t a craft. Perhaps I felt terms like “handmade” and “handcrafted” were inappropriately used as an afterthought to add the suggestion of value to a product or service. Therefore I dismissed the notion of making things for the web having any association with craft.

When you think of craft, immediately you think of something made with materials from natural elements like wood and stone. We imagine forging an object, something useful, built to last and beautifully simple.

When I look at handmade goods, I am usually met with several impressions — if the goods are handmade then there mustn’t be that many in existence therefore each one is unique and holds a certain degree of value; if the goods are handmade then that must mean a human has inspected the process of making the item, not a pre-programmed machine, therefore the build quality is better.

Both situations can apply to and justify web design as a craft. Just because we don’t work with tangible materials of the earth doesn’t mean we aren’t making something useful, beautiful and built to last. Our raw materials are elements like typography and colour.

The build quality of our digital goods ultimately define us as craftsmen and craftswomen of the web. Machine code and templates are often easily distinguishable from that of code built from scratch, adjusted, refined and tested by human hands. Keyboards and mouses aren’t our real tools — they are simply the physical link between our hands and the digital tools we use to produce digital goods.


Interview with Kevin Suttle

5th November 2013

Recently I caught up with one of my good internet friends Kevin Suttle. While he’s currently a designer, developer, writer, and presenter currently based in Cincinnati, Ohio, he’ll soon be joining the rebuilding of IBM Design in Austin, Texas as a Senior Product Designer. He’s got some interesting stories to share, so I thought I would share them with you too.

This is a small preview of the Transcripts interview series. You should definitely sign up to receive new issues from the world’s best design thinkers along with other benefits

Jordan Moore: Describe your path to becoming a designer.

Kevin Suttle: My path to becoming a designer has always had an interwoven relationship with hacking. By “hacking” I mean, ‘getting something to function in a way other than that which it was originally designed’, not the more nefarious, stereotypically-Hollywood definition. For example, I remember a professor in college showing me how to view the HTML source of the Apple’s Trailers site and save h264 files. I had another instructor show me how to edit a .plist file in the package contents of iDVD so I could adjust the length of DVD menu music to play a full song instead of the default 30 second loop. I’ve always been driven by getting things to function the way I feel that they should have all along.

Frustrated by a lack of creativity and poor usability on the web, I opened up Illustrator and began designing my own UIs. A friend showed me that you could draw image maps and export HTML directly from Illustrator, and that felt awesome, because I could draw what I wanted to use. At the time, I didn’t know how to code, so this was a great bridge.

Eventually though, I had to get my hands into a code editor, because honestly, I needed the money. I had lived in the Philippines for awhile after college and was pretty much broke upon return. I got a couple of freelance contracts doing Flash for my alma mater, the University of Cincinnati, where I designed and built interfaces for classroom simulations.

A couple of years later, I found myself so frustrated by the lack of thought in the software I was using, and once again, I decided to do something about it. That was a major turning point in my career, as I was quickly enveloped into various circles of Adobe and other large-scale software companies, beta and alpha testing many of their products.

Through the constant process of testing, bug reporting, documenting, and designing features, I found that I seemed to have a knack for writing, and others enjoyed reading what I had to say.

In 2010, I decided to turn my articles into blog posts, and I began speaking at several top UX, tech, and design-oriented conferences. The overwhelmingly positive responses to my writing and presentations has been a catalyst in the progress of my career.

Each word I’ve written or spoken about design has led me to this point, where I’ll soon be joining IBM Design as a Senior Product Designer.

JM: Who has had an influence on your path to becoming a designer?

KS: Over the years, I’ve had several people influence my path, but while the default expectation may be that I’ll rattle off names like Saul Bass or James Dyson, I think the people who have had the biggest influence in my path have been those that have given me opportunities along the way. I know it may sound a bit sacchrine, but really, people like Steve Weiss and Rich Tretola from O’Reilly Media, who gave me the opportunity to become a published author, and Shawn Pucknell, who always accepted my presentation proposals and let me speak among creative visionaries (including a surreal event in San Francisco where I spoke on the same day as Scott Hansen, a.k.a. Tycho/ISO50, one of my favorite recording artists and designers.) So, I guess there’s one. Others include Cameron Moll, who heralded the importance of mobile well before it become iFashionable, and Don Norman, whose gentle nature and uncanny knack for reducing the complex down into stunningly digestable terms made me want to design the world over again. From Steve Krug, who made me fall in love with testing my way to better products, to Jef Raskin, who guided me through the depths of cognetics and applied behavioral psychology in interface design, and Bret Victor whose ground-breakingly radical ideas rekindled my vigor for interaction design. Each one of these people left a deep impression on my outlook of design as it relates to the smallest experiences in our everyday lives.

Really though, every day, something inspires me to push interaction and experiences just a little bit further, to add that extra bit of detail. Whether it’s the feel of a handle on a cabinet drawer, or watching my 1 year-old son play with his toys, I’m constantly reminded that there can always be more humane designs. That’s what gets me out of bed in the morning, and keeps me up at night. I don’t sleep much.

JM: I know the feeling. I don’t set an alarm clock anymore, my kids are louder and wake me up more effectively than any app could. What do you do in your free time beyond the web?

KS: These days, I’m not overwhelmed by large amounts of free time, but when I do get some, I spend it at my local CrossFit/MMA gym, teaching Muay Thai kickboxing. I’m undefeated (1-0!) and love the mental and physical challenges it brings each time I step onto the mat. When you’re training with someone, or even sparring/fighting, you have to be creative. You need to constantly be evaluating and predicting what your opponent’s next move will be, all the time planning yours, and looking for under-defended areas. It’s more art than science, obviously, which allows for free-flowing creativity and a splash of personal style, all within a set of constraints. That’s the very definition of design, isn’t it?

JM: Why does design matter?

KS: Design matters because, at it’s essence, it’s only about one single, solitary principle: communication. Nothing else. Pick any aspect of any discipline across the range of design studies and it will inevitably boil down to communication. Color communicates mood, cultural relevance, information hierarchy, etc. Alignment communicates typographic order, conveys structure, defines relation, etc. and so on.

As humans, the vast majority of human interaction is visual/non-verbal, whether it be through facial expression, body language, or gestures. We possess the capability to conceive staggeringly elaborate language systems, each containing thousands of inflections and tonal cues. Yet, as we’ve adapted and evolved through the Information Age raising purely digital, born-online generations, we’ve learned to visually express ourselves by way of emoticons and gifs. You may chuckle in derision, but think about all those IM or SMS conversations where you’ve chatted entirely in reaction gifs or memes. The way we’ve been knit together as humans reflects the ultimate goal of good design—to communicate simply, beautifully, and naturally.

JM: Let’s talk about how you work. What tools do you use?

KS: For me to be effective, my tools and workflow must be as responsive as the work I product. The goal is to to use the best tool for the job while keeping pace with updated best practices.

That being said, my current software setup looks like this:

iTerm2 (Zsh shell), Git, GitHub, Tower (Mac GUI client for Git), Sublime Text 3, Chrome DevTools, Sass (SCSS flavor), Dropbox, and Evernote. Everything except some of the tools themselves is stored in DropBox or on GitHub. That way, I can automate setting up new machines, and instantly be productive. User experience isn’t just limited to apps and websites.

My personal work mostly involves hacking on my dev environment, as well as contributing to and improving exisiting open-source projects.

JM: Let’s change gear a bit, what drives you to keep going?

KS: What drives me to keep going is what got me here in the first place: the human race is responsible for a poorly-designed world. Traffic, browser support, the DMV—these are all problems we’ve burdened the world with. Thankfully, we’re finally in a place to do something about mending our self-inflicted wounds. Whether it be signs and iconography for maps/wayfinding, or providing “divine light”, there are literally billions of design problems in the world that affect the daily lives of people. It’s easy to forget the human element in our increasingly-digital existence. We’d do well to remember that. It’s the most important motivation there is.

JM: What’s next for you?

KS: I’ve had several projects up in the air for a very long time, and I’m starting to normalize my schedule so I can get back to working on them. What’s really exciting about these projects to me is that a few of them involve collaboration with some notable folks in our industry—designers and developers that I have a great deal of respect for. Many of them involve areas that are new to me publically, so it will be good for me to showcase my interests and skills in areas outside the ones I may be known for.

Writing is also a major area of focus for me now. I’ve got several large-scale publications under way, including one piece that’s taking shape at Smashing Magazine, (that you were of great help in reviewing). My Evernote is densely-packed with article stubs and topics that I’ve been meaning to write about, which will be publishing in the very near future.

I’m also incredibly excited to begin my journey to Austin, and my role at IBM Design. It still feels like a dream, and I can’t wait to get started.

JM: What legacy to you want to leave behind?

KS: When I look back on my life in the year 2111, I’ll want to have memories of my professional legacy that reflect the fervor and empathy I weave into every bit of my designs. One major pillar of my personal brand that I am hoping to reinforce is that code is a design tool.

There are so many designers who can remember how to apply complex, layered blending modes and can recite RGB values from memory, but are simultaneously petrified by the mention of the dreaded “command line”. Maybe it’s the fact that I’m a hybrid, but I inititally only learned to code so I could make my interfaces interactive. Later, I learned to program to make my code fast, responsive, and clean—these are not the same thing.

On the opposite end of the spectrum, developers can also learn a lot about design from beautiful code. A well-considered package structure and naming convention lends itself equally to thoughtful information architecture. Ensuring code is performant and accessible to various user interactions is also a goal of great user experience design.

The larger point I’m trying to make is that you’ll never learn as much as you can by working inside a box with blinders on. Comfort is great, but it when have any great design breakthroughs been comfortable to those who happen upon them?

Also, I’ve always found that getting away from the computer once in awhile and learning an analog skill can sometimes translate and make me a better designer. Working with my hands makes me more personally confident, which in turn makes me less afraid to try new things when I’m back in front of a screen.

I want my legacy to be the bookmark for the time when the term “hybrid” started to fade away, and being a “designer” implied that you could build what you drew. I want designers to own their products, and no longer be limited by “technical challenges”, the terminal, or even hardware. I want to help usher in a new era of multi-dimensional designers and polymaths. I want to inspire the current and future generations of designers to learn by hacking, and using tools like code, to make better designs.

Technology is shaping design, and design is shaping technology. It’s time for us to use both to the future.

This site is supported entirely by its members. Membership starts at £9.99 per year with some awesome benefits including the Transcripts interview series


Getting to know Safari 7’s (Mavericks) developer tools

4th November 2013

I can only speculate why Safari hasn’t been widely adopted for web development — maybe it’s because Safari isn’t an overly popular browser, or perhaps it’s because it hasn’t been too developer friendly in the past. Safari’s web developer tools always felt like they were playing catch up with Chrome and Firefox, they seemed clunky and cumbersome by comparison. Thankfully the same can’t be said for Safari in Mavericks.

This is by no means a comprehensive overview of the powerful web development tools at our disposal — just the ones that I (as a front end developer) encounter every day.

Yikes, 1MB? Looks like I’ve got some optimising to do.

As far as web inspectors go Safari’s UI easily beats the competition in terms of look and feel (and that’s a pretty grim beauty contest). It’s an adaptive UI too — the labels beside the icons in the toolbar disappear when space is scarce, and if you keep resizing the activity bar drops a few items too.

The activity bar itself is great. It shows the number of resources on the page right beside the page weight which is good for performance budgets. It’s nice to see a persistently juxtaposed value sitting there while you work so you don’t lose track of how much weight your page is gaining — a huge problem for sticking to a performance budget.

What really sets Safari apart from Chrome and Firefox is writing and editing CSS rules in the sidebar. Writing new rules just feels better. Chrome’s auto-complete is intrusive whereas Safari’s auto-complete stays out of the way. Values can be incremented and decremented by pressing the option key and up or down respectfully. My favourite thing about writing CSS rules in Safari is that when disabling a rule by either toggling the checkbox or pressing Cmd + / it wraps the CSS rule as a comment. The Safari team have really observed web design workflows here — because the rule is commented when disabled, you can copy the block of rules into your code editor and the disabled rule remains disabled after transition. With Chrome and Firefox, you need to remember which rule or rules you unchecked when copying and pasting it into your code editor and then remove them afterwards.

Rules that are disabled via the checkbox or by hitting Cmd + / are wrapped in quotes meaning when it is copied into a code editor, the disabled rules stay disabled

One of Safari’s most powerful features is allowing you to access and manipulate the code on iOS devices when plugged in via USB. Inspecting and editing this way is noticeably faster than other methods like Weinre, Edge Inspect and other similar techniques. That’s great if you’re just building things for Apple devices, which you shouldn’t be — you’ll still need to test on other devices the old fashioned way.

I do have a few gripes with Safari’s developer tools, albeit quite minor ones — docking. Docking the web inspector on the right hand side is something I use heavily in Chrome — the option is present in Safari but Apple seem to care a great deal about the appearance of their inspector to the point of it having a ridiculously large minimum width. It takes up half my screen on a 13” MacBook Air leaving little room to resize the screen. Toggling between docked tools on the right and the bottom isn’t as easy as it is in Chrome. You need to completely undock the web developer tools window, then use the corresponding icon to dock it into the position you want.

But that shouldn’t stop you from giving Safari a try as your web development browser. The noticeable improvements in writing CSS rules and the emphasis on improving performance was enough to encourage me to try it for a while.


Responding to environmental lighting with CSS Media Queries Level 4

2nd November 2013

Media Queries Level 4 builds upon the existing media queries specification that many of us use when we build responsive designs today. The Media Queries Level 4 specification introduces four interesting new media features: script, hover, pointer and luminosity. At the time of writing the specification has yet to be implemented in a browser, but that shouldn’t stop us from exploring the potential use cases.

The luminosity media feature has garnered interest from the web community, it will allow developers to make CSS adjustments based on changes in the ambient lighting in which the device is used. The user’s device must be equipped with a light sensor to trigger this new media feature.

The most obvious use case for the luminosity media feature is to adapt a design depending on whether the user is reading the page during the day where ambient lighting is brighter or during the night where ambient lighting is darker. We already see this behaviour in a few native apps.

Digg Reader on iOS can change its theme depending on the brightness of the environmental lighting

The thing about designing for the web is we don’t have the same prior knowledge of the destination device that designers for native apps do. The light sensor’s sensitivity on an iOS device might be different than an Android device, and the light sensor’s sensitivity on an Android device might be different to the light sensor of another Android device, so we would need to be careful with the degree of change we make as it could be jarring to devices that have an overly keen light sensor.

The code looks something like this:

@media (luminosity: normal) {
    body {
        background: #f5f5f5;
        color: #262626;
    }
}
@media (luminosity: dim) {
    body {
        background: #e9e4e3;
    }
}
@media (luminosity: washed) {
    body {
        background: #ffffff;
    }
}

A normal luminosity level represents the screen being viewed in ideal lighting conditions. I would recommend working from this level as your default — and rather than wrapping those styles in a media query targeted for normal luminosity levels it would probably be best to leave those styles unwrapped so browsers and devices that haven’t got the capability of seeing the luminosity media feature can see the page in it’s ideal condition. You can then use the dim value to make adjustments for darker environments and washed to adjust styles for brighter environments leaving the default styles accessible to all devices whether they are equipped with a light sensor or not.

I mentioned earlier about the potential differences in the light sensor hardware sensitivity — I think this is a key reason not to go over the top with the changes we make within luminosity media queries. Can we definitively say that a cloud passing on front of the sun will not trigger the dim luminosity media feature? The last thing I’d imagine the user wants is a harsh change between light and dark designs that is too easily triggered.

Potential stylesheet changes from dark to light environments (left to right). Subtle changes in contrast are key for avoiding a jarring user experience when environmental changes occur

As with other facets of web design, we should strive to stay out of the user’s way when they are trying to enjoy our design. The luminosity media feature has the potential to be the most annoying media query at our disposal, it could be responsible for ushering in a new era of glow in the dark websites — let’s just be careful with it when it arrives.


xScope Review

1st November 2013

I have been using xScope for about 6 months, and I’m quite late to the party. It has been around for years and has long been the web developer’s Swiss Army Knife. It is a suite of tools that help make designing for the web a lot easier.

xScope was made and maintained by the Iconfactory (the guys responsible for Twitteriffic) and will cost you $29.99 (or £20.99).

xScope comes with 8 powerful tools that float above all your open windows and they really help you smooth out the rough edges of your designs:

I keep my most frequently used tools (Dimensions, Ruler, Loupe and Guides) in the menu bar

xScope genuinely makes my web development easier. I don’t use all of the tools, but the ones I do use help immensely. Take Guides for example — possibly my most frequently used tool — I can draw multiple guides over my screen to check things like horizontal and vertical alignment and adjust values in the browser to try and align elements to the guides. The Guides tool comes with additional features like displaying the distance in pixels between two guides along the same axis.

I keep the Ruler close to hand too for measuring elements — although sometimes I’ll alternate between the Ruler and the Dimensions tool to achieve the same goal. Dimensions gets the result quicker because it’s automated, but sometimes I just like manually measuring with the Ruler for things like the spacing between elements.

The Loupe tool is a powerful colour picker. It helps make super precise selections by showing you a zoomed preview window equipped with optional grid and centerlines. The Loupe can also save the current selection to your clipboard for pasting into your favourite text editor or graphics editing package.

The Loupe is one of the most powerful tools in xScope. It comes with an array of useful options for capturing colours and saving them to your clipboard

The Mirror tool is pretty useful too. You need to install the universal companion app for iOS which is only $1.99 — a small price to pay for the wealth of extra features it unlocks. You can do things like view a file on your iOS device, view a portion of your screen remotely, or lock a window on your iOS screen. I use this mostly for testing responsive designs on retina displays — it takes a while to resize my Google Chrome window to the exact dimensions of the iPad, then lock it in xScope Mirror on iOS, but once that’s done then I am free to develop and preview changes.

In essence the xScope Mirror app is a replacement for previewing design assets on mobile displays — some like to use techniques like saving files to Dropbox so they can open on their device — this is simply a lot quicker, it’s $1.99 for a vast improvement to your workflow.

There aren’t many notable drawbacks to xScope, nothing that should stop you from buying it. I noticed that over multiple monitors some of the tools get a bit buggy, for instance if I connect my MacBook Air to an external monitor, I can only ever seem to summon the Guides tool on my MacBook Air. I suspect this is a new issue since Mavericks was released. Also one or two of the tools seem a bit unnecessary — I’ve barely used Frames properly yet because it seems like watered down Screens tool (albeit an adjustable one), and I have yet to find a use for the Crosshair tool. These minor quibbles can’t diminish the fact that this is truly an essential app.

xScope is free to try and you should if you haven’t used it before. Like a good Swiss Army Knife, you will become comfortable with the indispensable tools in the set quickly and keep them ready for use when you need them, the other tools may not get as much use, but they’ll be ready when you need them too.


Design for the sake of design

1st November 2013

Until recently this very blog you are reading sported a dashing, large, full-width image atop each article. It took a considerable amount of time to trawl through all of my previous articles and match them with a suitable image so each article adhered to the new template design.

Then I got rid of them.

The images occupied over 600 pixels at the top of my articles before you even got close to the content. The content that held the real value sat below this unnecessary distraction — an obstruction. They added little to no real value to my writing — under scrutiny the trend-conforming strip might as well have been a decoration — design for the sake of design.

Dribbble is great for measuring design trends. A search for “home page” returns a lot of similar looking layouts

The vast majority of Medium posts contain similar page headings. I don’t like picking on Medium1 because it’s an easy target — it’s successful, lots of people use it, lots of people read it and lots of people who use it feel cheated when people don’t read their work on it, and lots of people write anti-Medium posts complaining about the conundrum.

Medium’s gorgeous editor begins with asking if you want to add an optional header image. I’d wager most people fill this space because they feel they have to, that it would look un-Medium-like, or that it might scupper their chances of having their post featured. The problem is where the headers are populated for the sake of putting something there, the overall value of the post suffers. Sometimes the connection between the content and the image is so vague it goes unnoticed or sometimes it’s just plain irrelevant2.

It’s not that I think large header images are useless — in fact, when they are done well with relevant content they are like book or magazine covers for the web — a preface to the content. When the content of the image is tangibly linked to the content throughout the page, they compliment each other and the page reads like a single harmonious piece.

The Great Discontent is the perfect example of using this space to add value through beautiful, relevant imagery that sets the tone for the article

This layout works best when used within constraints — in the Great Discontent’s case, their stunning header images feature interviewees and act as a high quality magazine cover that adds value to the overall piece. It is clear that the content comes first and considered decisions were made afterwards to produce a beautiful record of industry interviews.

The problem that a lot of the websites that attempt to emulate this layout face is when the template dictates the shape of the content and it becomes a game of shape sorting. I’d go as far as to say that it harms the user experience when they are asked to scroll past a pointless piece of content with no intrinsic value — in such circumstances, the image might as well be a banner ad. The effort involved with scrolling past a meaningless piece of imagery before the content is released to you is akin to the behaviour of parallax scrolling websites where you are made to feel like a hamster in a wheel powering a lightbulb with your scrolling rhythm.

It’s not difficult to spot the difference between those who are simply conforming to a style and those who put value before aesthetic.


  1. I have a Medium account. I have yet to commit a piece of writing to the service, not out of distain for the service, but it’s low in my pecking order of where I have time and the desire to publish my work. 

  2. This is exactly the same situation I ended up in with this blog. Sure it looked nice but it was merely an obstacle. 


← Newer Articles Older Articles →

About Jordan Moore

Jordan is a web designer passionate about responsive web design and content choreography. He as a penchant for typography having worked previously with the Typecast team.

He writes occasionally for .net Magazine and Smashing Magazine and currently works for Eyekiller in Bangor, Northern Ireland. You can follow him on twitter @jordanmoore

Available for freelance projects in early 2014

Membership

By becoming a member you will help support my writing and the growth of this site as well as receive the Transcripts newsletter with interviews from the web's finest makers and Tickertape

Site ambassadors