I love An Event Apart conferences, and I bet you would too.
It's where ideas like responsive design and mobile first were launched, and where this year's attendees are already learning how grid layout, CSS shapes, and other advanced techniques will fundamentally change…well, everything.
San Francisco is coming up November 2-4. If you can't make that, they just released the 2016 schedule with cities all over the U.S., including a first-time visit to Nashville and an extra-special Orlando event at Disney.
I have a sneaking suspicion you'll be seeing a bit more of Dave Rupert and I doing things like this.
Speaking of in-development software targeted at screen design. Also check out the videos in Khoi Vinh's post. The repeat grid demo is pretty compelling.
We're all familiar with debt, right? It's that concept where an amount is owed from one person (the borrower) to another (the lender). We often use it to describe financial situations. For example, I borrow money from a bank. I now have debt with them in the amount of how much money they lent me (plus interest!) and expect me to repay it.
Debt isn't always about money. In fact, we run into it as front-end developers all the time and may not even know it. We call this term technical debt and will be exploring what that means in this post.
BoxBox is a design app that’s currently under development and the designers, Kevin Lynagh and Ryan Lucas, have written a series of articles describing their thoughts that led to its creation. First, they outline the problems with the current state of applications:
We’re still primarily using legacy print design applications to create modern, responsive software interfaces. This has created a unique set of challenges that plague the UI design workflow.
Later, they delve into the serious lack of responsive design features of applications like Photoshop and how these limitations affect the design decisions we’re making:
Perhaps the biggest danger is that these tools lie by omission: They present your design at a single size with fixed rulers and exact pixel values, even though the final application needs to live across many screen sizes. This is akin to designing a sailboat without considering the densities of wood and water until “implementation time.”
This series of articles goes a lot further than defining the problems of our design tools however; they make a lot of useful suggestions, too. They tackle the difficulties of designing reusable components and the need for naming, editing and modifying these objects. Interestingly enough they also discuss the benefits of using code to detect changes over the lifecycle of a design, instead of static mockups.
Paul Irish and Paul Lewis describe a way for us to think about web performance: RAIL (Response, Animation, Idle and Load). It's designed to break up each moment of a user’s experience into actions which can then be specifically optimized.
Very few of us have unlimited time to throw at optimization work, far from it, and we need criteria that help us decide what’s important to optimize (and what’s not!). When all is said is done, we want and need clear guidance on what “performant” means to our users, because that’s who we’re building for.
Working on web performance is a combination of obvious best practices (optimize assets), very tricky decisions (what can I defer loading on and what can't I?), and nuanced choices (which animation technique is the most appropriate?).
Tiffany B. Brown breaks down what stacking contexts are in a very quick and understandable way. First, what makes a new context, then:
Children of a stacking context are painted from bottom to top in the following order.
- Elements with a negative stack level, typically elements with
- Elements with a
- Elements with a stack level of 0, typically positioned elements with a
- Elements with positive stack levels, e.g. a positioned element with a
A bonafide CSS trick by Franklin Ta. Position the images on top of each other at 50% opacity and inverted colors. Or, as Bennett Feely pointed out, use
background-blend-mode: difference; if they are background images.
You know about responsive images. It's about the image syntax in HTML. If you give it the right information in the right syntax, you can get the browser to download just exactly the right image it needs, without giving it too much or too little image data. It's fantastic for performance.
You know that to get the most out of responsive images you should polyfill it with Picturefill. You download it, you include it on your page.
You have …Watch Video →