Jake Archibald digs into how bizarrely media queries can behave when embedded into a block inside the SVG itself and then used in a variety of different ways across different browsers. The results are spotty at best.
It would be nice to see this reined in, but I wouldn’t worry too much about it in general. Inline SVG doesn’t seem to have any trouble and I wouldn’t trust an do anything fancy like have internal media queries anyway.
Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers.
The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.
Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.
A Guide for New Web Developers, from a New Developer
Paper Planes
Spotify to Music Subscribers: Drop Dead
Is There a Design Mafia?
CSS Grid Layout: Going Responsive
40+ Creative and Beautiful Credit Card Designs
How to Design for SEO in 2016?
CEO-driven Design Doesn’t work
Check Out Affinity Designer’s Constraints
Pandora’s New Logo Is, Like, Totally ’80s-Era MTV
5 not so Obvious Tips to Get your Website to Rank Higher on Google [Infographic]
Apple May Bring Dynamic Keyboard Tech to MacBooks
Here’s How Much it Costs to Run Unsplash
Material Design Bootstrap
Spotify’s Design Lead on Why Side Projects Should Be Stupid
Workplace by Facebook – Enterprise Social Networking for the Masses
The Important Habit of Just Starting
A Decentralized Web Would Give Power Back to the People Online
Branding Once Meant Logos. Today, it Means AI
The Color of Music: Pandora’s New Look Reflects your Music Experience
Cat Ipsum – Litter your Copy with More Kitty
#FacesofFounders – Redefine Who is and Can Be an Entrepreneur
A Complete Guide to Getting a Design Job in 2030
InVision for JIRA
The Art and Science of Generating Great Ideas
Want more? No problem! Keep track of top design news from around the web with Webdesigner News.
Hey y’all! Welcome Miriam Suzanne. Miriam will be doing more writing around here soon, so we figured an interview would be a good way for you to get to know her first. She’s been working with the web for longer than I have, has created some pretty huge open source projects, and has a unique perspective on about everything. Let’s get to the chat!
Chris: How old school are you? Were you designing websites in tables for Netscape Navigator -3 and stuff? Or did you get into the web later?
Miriam: I built my first sites in the early 2000’s — so we were past Navigator 3 at that point. It was the height of the Netscape/IE browser wars, when sites all said “best viewed in” one or the other. CSS was just gaining real traction. I was taught to use tables in Dreamweaver, but I didn’t get excited about the web until I saw Eric Meyer’s CSS Edge site, and started coding by hand. I got my first job using tables on an insurance company website. I tried to rewrite their site in CSS, but they didn’t want it. I started freelancing right after that, and never used tables again.
I was slightly behind you I think. I don’t think I ever built a production site with tables, thankfully.
Kids these days. ?
Speaking of Eric Meyer, I think I first met you when you were also going by Eric Meyer. We met at a conference, through your involvement with Sass and being the creator of Susy and such. I seem to remember you saying that both of you had to re-direct people to each other when the contacted the wrong one. But now you’ve changed your name! Was that just a part of a larger identity change?
Well, if you remember, it happened in two stages. I changed my last name in 2013 to break up that confusion.
I had a sense at the time that I should be changing more than that — but I wasn’t ready to deal with it.
I finally changed my first name and started to transition last year.
It would have been easier to do both at once, but… Can we call it an iterative process?
A while loop
(Chris crawls under the table for making a joke so dumb it doesn’t even qualify as a dad joke.)
Exactly.
The final straw for breaking the Eric Meyer confusion involved a series of conferences. You got mixed up in that. ?
CSS Dev Conf gave you my hotel room after Eric Meyer had to cancel, and you took over as keynote.
Oh snort. I do remember that. Hopefully you didn’t have to sleep in the ghost tunnels.
(We were at The Stanley Hotel, which is known for being haunted and has freaky tunnels and ghost tours and stuff.)
They actually gave me a huge three-bedroom condo on the hill, 3 minutes away. I ended up hosting all the after-parties.
But earlier that year, I had a talk rejected at a digital-arts conference because the bio I sent them didn’t match the bio on Eric’s website.
Going backwards a little… your web career started with some insurance websites, then into freelance. And kinda staying in freelance? I know you and your siblings started OddBird almost a decade later.
It started building websites for my theater company. That’s why I learned web design in the first place. The insurance company mostly had me doing print design. They were so far behind the digital curve.
At one point my good-ol-boy boss called me into his office, probably because I was the youngest on staff, and said “We need a podcast. What’s a podcast?”
That was pretty much the atmosphere of the place.
I told him a podcast is like a radio show, but you have to go looking for it. So the first thing you need is content that people really want. “Oh, I don’t think we have that.”
yeah…
I took my first client when someone emailed asking if I knew any college students who could build a cheap website. I teamed up with a Drupal-building friend, and we built a few sites together. I quit my insurance job half way into our second client, and hoped for the best. That was 2006-2007. Carl and I started working together in 2008, and Jonny joined in 2009. That’s when we came up with the name, and decided to make a company out of it.
It’s still going today, right? What do/can people hire you to do?
Yeah, we have a team of seven now, and act like a legit company.
We’re mostly hired to build custom Django web-applications for mid-to-large companies. We’ll build their MVP, get them off the ground, and then hand it over to an internal team.
We do the full range of branding, content, architecture, design, code, and testing — integrated pretty tightly, because we have a small team.
Mozilla gave us our first big break in 2010, building their test-management system. I hear they are finally retiring that project next month.
There are plenty of agencies out there that do great work for clients. There are less that decide to build, open source, and maintain large software projects like y’all have. Were projects like Susy built for client needs? Or itch-scratchy? What’s the story there?
Susy didn’t come out of one particular client, but it did come out of our client work.
We wanted a consistent set of tools that we could take from one client to the next, without forcing every client into the same design patterns and layout techniques.
I was really inspired by the work Natalie Downe and Clearleft were doing, and modeled my approach on her CSS Systems talk.
It’s all about designing open, flexible systems instead of locking yourself into a particular library of CSS classes — a response to the existing grid frameworks back then. And a philosophy that matched my thinking perfectly.
But the math was repetitive and complex, until we found Chris Eppstein’s hour-long video introduction to Sass and Compass.
Susy was the first thing I built in Sass, and the whole reason we wanted Sass in the first place.
After I built a draft, Carl put it on GitHub. I didn’t know anything about open-source development at the time. He was the driver behind all of that. But I had to learn quickly.
Susy was one of the early Sass/Compass plugins, so Chris took a real interest and pushed me to improve it, and document it, and work for a wider audience.
Hmmmm so it’s possible to have good ideas and build cool things and participate in open source and not know everything about everything?
It’s possible without knowing anything interesting at all!
Now we think of open-source as a core of our process. We use existing tools where we can, making client work faster and more reliable — and then we contribute back into open-source based on our client work.
Does it make for decent marketing?
For most of our history, open-source work and client referrals have been our only real marketing — mostly coming through the Django community, where Carl is a core developer.
My Sass projects bring in a lot of traffic to our site, but it’s hard to say how much influence that has had on actual contracts.
I wonder if there’s a back-end/front-end difference there, or if it just comes down to project size.
We’re trying to be more intentional about our marketing now, but still building on what’s worked for us: being active in the community through open-source work, sponsoring conferences, and sharing what we learn through writing and speaking.
What interests you on the web these days?
I’m really interested in some of the new features that are coming to CSS, like @supports, grid layouts, and custom properties (variables).
Grids and variables particularly excite me because they represent fundamental shifts in how CSS works:
Grids shift how we think about “flow” in a document. All the previous layout techniques are 1-dimensional, relative to flow. Grids are two-dimensional, outside of the flow. I’m curious what that does to the ways we think about web design.
Variables and custom properties break the long-held belief that CSS should be purely descriptive. Now CSS is becoming an extensible language, with programmatic power. Hopefully that means we’re not always waiting for the w3c and browser vendors to solve new problems for us by adding new properties to the language. I’m excited to see how that plays out.
I also get excited about components and patterns, which are popular now. People are trying to represent design patterns in code more efficiently and meaningfully, and that’s a good thing. The virtual DOM is a really interesting step — but I think there are a lot of details still to work out.
Especially when it comes to balancing efficiency with accessibility and maintainability.
I think we can do better, and I think we will.
I’ve been looking at what worked and what didn’t in Sass, and wondering if those lessons can be applied to HTML templating languages…
It seems like you have plenty of interests outside tech. Music! Theater! Writing! And not just in a passive way, like you go see a band on Friday night. You are the band on Friday night.
(Before I even asked this question, we had to take a break in the conversation because she had to get ready for a gig that evening.)
I never expected to be a web developer. My training is in “devised ensemble theater” — a technical term roughly equivalent to “greenfield iterative web-development.” Instead of starting with a pre-written script, and using a waterfall process, you start with an idea and a team of collaborators — then iterate your way to a full production using whatever media help you get there. I ran a theater company from 2001-2006. I learned design in order to make our brand and marketing materials, and I learned code in order to build our first website. All the product-development skills translate pretty directly. Before long I had my first client, and things built from there. I don’t have a theater any more, but I have several multimedia novels and a successful band called Teacup Gorilla. We just finished underscoring two live theater productions, and now we’re going to work on a music video.
To me it’s all one thing. I like building experiences, using whatever tools are available. Building a show, or an album, or a grid system, or a web app — those are minor details.
Isn’t there a book in there somewhere too? Yet another kind of experience?
Yeah, my first attempt at a novel turned into 600 pages of full-color images. It cost me over $100 to print a proof at Kinkos. No publisher would take on a first novel like that, so I started putting it online, and adding animations. I never got very far, but it’s still out there. Maybe I’ll go back and finish some day, or maybe I won’t. I decided to keep things simpler for the second novel.
Riding SideSaddle* was published last year by SpringGun Press. It’s a story written on 250 note cards — a collection of memories that can be shuffled and read in any order. But don’t let the “experimental” format fool you: it’s a fast read, and the story is easy to piece together.
It’s based loosely on the greek myth of Salmacis and Hermaphroditus, who become merged into one person. It becomes a reflection on gender, sexuality, and queer communities.
That was also harder to print than we expected, but we made it work. My next novel will be a book. Let’s keep things simple. ?
I think I surprised a lot of people in my writing community when I started talking about “innovation budgets” and “user testing” for my novel. I’m pretty happy with the results, though. Glad I could bring my product-development experience into my art.
That’s both fascinating and scary to me
Scary how?
Like if all paintings were user tested there would only be paintings of sunsets
Well, user-testing doesn’t mean you only do what users ask for, right?
I started with my own goals, and what I wanted to communicate. But then I had to watch people interact with it to see if I was on the right track.
I don’t think well-done user-testing should ever keep you from innovating. It should give you the freedom to experiment, and then see what’s working and what isn’t.
In this case, the cards worked. As long as I added character names to all or most of the cards. People were happy to read the story out of order, as long as they had that handle to hold on to.
In my mind it’s mostly about trusting users to tell you what’s not working. But never trust them to tell you what will work. That’s where innovation and experimentation come in.
To say that a bit differently: for both art and product development, you have to trust the users and you have to trust yourself.
Your own communication/business/aesthetic needs are just as important as the user’s needs. But you only have a successful product if you can get the two lined up.
You also have to trust that users want to be surprised, and that’s not something they can ever tell you how to accomplish.
They can only tell you that they are bored with sunset paintings. ?
Well, I think we can wrap this up with a big ol Welcome Aboard! Everyone out there reading, stay tuned for upcoming writing by Miriam. Anything else you’d like to tell folks?
I’m looking forward to it! If anyone has any topic request for me, I’d love to hear them.
Every week we feature a set of comics created exclusively for WDD.
The content revolves around web design, blogging and funny situations that we encounter in our daily lives as designers.
These great cartoons are created by Jerry King, an award-winning cartoonist who’s one of the most published, prolific and versatile cartoonists in the world today.
So for a few moments, take a break from your daily routine, have a laugh and enjoy these funny cartoons.
Feel free to leave your comments and suggestions below as well as any related stories of your own…
Living in a fishbowl
Mouse with standards
No breaks
Can you relate to these situations? Please share your funny stories and comments below…
Over a few sessions, Matt mentioned that the string of text “Show more reactions” was being smushed together and read as “Showmorereactions”.
Turns out a popular technique for hiding content visually (but not hiding it for assistive technology) involved setting width: 1px; which was forcing words to wrap one-word-per-line with “line feed” breaks, which the AT didn’t treat the same as spaces.
Facebook had to update their accessible hiding class to:
A whole bunch of examples by Una Kravets of actually-functional things you might think of as needing JavaScript but can be done in HTML and CSS alone. You might of expect a bunch of “Checkbox Hack” stuff (and that’s in there), but it’s quite a wide range of techniques.
In 2016, it’s okay to build a website that doesn’t work without JavaScript.
The condemnation was as swift as it was vocal.
Response by Jeremy Keith:
That framing makes it sound like it’s a binary choice: either the website works or it doesn’t. That’s not what I’m suggesting. I’m advocating that the core functionality of a website (which can be as simple as reading some text) should be available without JavaScript (because, let’s face it, that core functionality doesn’t require JavaScript).
Sounds like most people, Nolan and Jeremey included, agree that progressive enhancement doesn’t have to put a website in position of “JavaScript is enabled and loaded, so it works, or not enabled or not loaded, so it doesn’t work.” It’s more nuanced and happens on a feature-by-feature basis of a site.
That’s easy middle ground to agree on. But I think this debate keeps popping up over and over is because “binary” is increasingly how things are done. Not fully loaded JavaScript = white page of nothing. Plenty of folks saying: yikes. Plenty of folks saying: meh.
As a designer you’re expected to make the impossible happen. Time and time again, you’re expected to take an incredibly complex process and make it easy, simple and beautiful. When it’s handled well, you feel like a rock star.
When we fail to live up to those heavy expectations, it leaves many of us feeling… deflated. Designers tend to be perfectionists by nature, we’re our own worst critic. We take those mistakes personally, as if we’ve somehow ruined everything.
But these discouraging moments, if you accept them, are incredible opportunities for growth and learning. Here’s a dirty little secret: most of the mistakes you make aren’t your fault. here’s the terrible part: you’ll be punished for them anyway.
What we’re missing is a knowledge of people
It’s not like designers start a new job or project with the goal of screwing things up. With most of us it’s actually the opposite. We obsess over the little details, the insignificant things most people feel don’t matter. Most designers realize the importance of attention to detail.
That isn’t the problem. It’s what we don’t know. The things we weren’t taught that make a huge impact on our work.
If you’re formally (or informally) trained, you’re encouraged to study your craft. You’re expected to learn and understand the principles of design, about communication, visual and color dynamics, color etc. But there’s something missing.
What we’re missing is a knowledge of people. Designers aren’t taught to study people in school. We know our craft and we understand aesthetics, but we’re never really given in-depth training on people.
Our lack of understanding creates a knowledge gap. This gap affects our designs, leading us to make some incredibly common but unexpected UX mistakes.
UX mistake 1: Assuming users understand more than they do
Designers are reasonable people. They spend a lot of time dealing with user interfaces so they have an intuitive knowledge of how things work on the web.
“That’s common sense!” they tell themselves. Only it’s not common sense. It’s common knowledge to you, the designer. You spend a significant amount of time in this environment, so you just get it.
You’re a professional. Users? Not so much. This is why these assumptions are so devastating. We assume the users:
Know which questions to ask
Understand the controls
Know what our icons, symbols and logos mean
Give us their undivided attention
Will read or follow the instructions we give them
Know how to find what they want
See the problem? These assumptions are reasonable. Most designers have made these assumptions. And therein lies the problem. These assumptions aren’t based in reality.
Some users are clueless
Some are seeing and using our controls for the first time
Others find our visuals confusing
A few are distracted multi-taskers who are short on time or resources.
Others refuse to follow your instructions
While most aren’t sure they know what they’re looking at
Your job as a designer is to direct and thin the herd. Sort out those who are right for you, move them through your process, and get them to the finish line. Everyone else should be shown the door.
UX Mistake 2: Designing for the user
Design for the user. Design for the user! Over the years this piece of advice has been beaten into our heads. We’re told to focus on the needs of the user, to design things for and around them.
It’s a terrible idea.
“Why?”, you ask? Because this advice is often handed out indiscriminately. Users aren’t synonymous with target audience. The users interacting with your design aren’t always the “users” you want.
Take Google for example. They focus the vast majority of their attention on their users. Who do they consider their “user”? Searchers. They focus huge amounts of their time and many billions of dollars on making things better for searchers.
Are those the only “users” they have? No, actually. As it turns out, they have several kinds of them.
Advertisers: Google knows advertisers will accept whatever they give them. They tell publishers and advertisers how they expect the web to be. Disagree with Google, do things your way and you’ll be punished for it.
Bots: Google aggressively blocks unusual traffic (bots) from their site. Which means millions of false positives, searchers being blocked.
Fraudsters:Google blocks deceptive websites; you know, the ones with those fake download buttons that install ransomware on your computer?
Searchers: Regular people searching for something, anything online. These people make Google their money. They click on their ads, they use their apps, they download their software. They’re Google’s target audience, their meal ticket.
Google goes out of their way to ruin the user experience for those who conflict with their goals.
Google’s user experience is focused almost entirely on their users. The user experience excludes, to a certain degree, the people (or bots) who aren’t on that list.
If you’re an advertiser spamming searchers, you’re removed. If you’re a bot scrapping content from their search results, you’re blocked. Google goes out of their way to ruin the user experience for those who conflict with their goals.
I know, I know, the intention behind “design for the user” was supposed to focus designer attention on their target audience. But that’s something many, many designers miss, which leads to…
UX Mistake 3: Not enough friction
When it comes to design, “friction” is a resistance to any element in the process you’ve laid out.
Designers are conditioned to believe user friction is bad. Users won’t do what we want them to do if we don’t design things properly. That tends to scare us a bit.
All websites need friction.
What do you do if you’re listening to music and it’s too loud? You turn it down, right? Same thing with friction. Friction is a volume dial of sorts. Turn it up or down to adjust the users you attract.
Here’s how other websites have used friction.
Craigslist: hates it when you re-post the same ad 50 times. They create friction with Ghosting. Create spam, re-post your ad too many times and your ad is quietly hidden from everyone else.
Google: wants you to treat them with respect. Abuse the site, attempt to scrape content from search results and you’re flagged for unusual behavior. Ignore the warnings and you’re blocked.
Quora: is a Q&A site. They have a simple policy. Be nice, be respectful. Those who ignore that policy are given a warning, blocked or banned. Their system is designed in such a way that it maximizes the user experience, ensuring Quora remains a safe place for others.
Friction is a problem for designers. They either don’t know how to adjust the dial to attract the users they want or they don’t know the dial exists. This means they’re either prone to overreacting or they’re chronically abused.
Asking for a user’s personal or financial information while doing your best to avoid showing pictures of your face, stating who you are, or anything about your story.
Friction comes in all shapes and sizes, but it’s something many designers struggle to wrap their heads around.
UX Mistake 4: Giving your boss what they want
Avoiding this UX mistake requires lots of courage. But it also requires something more important: a clear understanding of the goal.
That piece you’re designing, what is it supposed to accomplish? The website you’re developing, what’s the goal?
A clear, definitive answer to this question is mandatory
And the reason it’s mandatory? Your boss, the committee, a client, someone in charge is going to demand that you go against that goal. What’s worse is that you know what’s going to happen.
Your experience tells you this won’t end well. If you give them what they want things won’t go as well as it should. It may fail miserably. It’s easy to go along with the boss. “They’re the ones signing the checks, I just do as I’m told.”
It’s incredibly important that you speak up
It’s important that you fight for your boss, even when they refuse to fight for themselves. If they’re asking you for something that will hurt them, speak up. Deliver the bad news. Get them to understand the mistake they’re making.
A habit of not speaking up means your portfolio will be filled with mediocre work.
Most designers won’t do it. They’re afraid they’ll lose their job or hurt their career. Which is exactly what will happen if you say nothing. How do I know? Experience. Those mistakes are probably going to end up in your portfolio. A habit of not speaking up means your portfolio will be filled with mediocre work.
And the A-player employers, the kind you’d love to work with? They can tell. Make enough of these mistakes and it becomes difficult to hide.
What if there’s nothing you can do about these mistakes?
What if you’re part of a team where the planning and design decisions have already been made? Talk it over with others on your team. Make your case with solid evidence (e.g. research, reports, data, etc.). Then, make your case with decision makers. It feels impossible, but it’s definitely doable. Just start small and take it slow.
You’re a professional. You have the tools you need to find the UX mistakes others miss. You make the complex easy, simple, and beautiful.
Looking for a fast way to get a site online? Love tweaking designs, but hate setting up the basics? Maybe you just want to learn how neat code is put together? Whatever your reason for downloading, we’re confident you’ll love this free bundle of 6 HTML themes by KeenThemes.
Each theme is fully responsive, and built on Twitter’s popular Bootstrap framework. Designed with a minimal approach, the modern looking themes will complement any business’ branding.
aironepage
A one-page theme for selling products, or services, aironepage is a clean modern approach to layout.
acecv
Designed to display a résumé in a clean, professional manner, acecv is a one-page approach to summarizing your career to date.
aitonepage
A single-page design for the tech industry. Aitonepage is the perfect theme for tech companies, app startups, and any company that needs to look cutting edge.
aircv
Aircv is another résumé theme, a little more hipster than acecv. With aircv you can easily incorporate elements of your portfolio.
acidus
Perfect for blogs, reports, magazines, and any kind of content-heavy site, acidus is a beautiful minimal theme with delightful animations and a clear hierarchy.
asentus
Asentus features a huge, viewport-filling slider. Perfect for anyone who knows their project packs a visual punch. Architects and photographers in particular will love this theme.
Each theme comes with all of the HTML source code, and CSS files you need to deploy as a live website. The themes are free for personal and commercial use. Download the files below:
Please enter your email address below and click the download button. The download link will be sent to you by email, or if you have already subscribed, the download will begin immediately.
With new frameworks and libraries emerging, the tools we have at hand are constantly changing. But it’s not only our toolkit but also the way we write code that constantly evolves — new CSS conventions are developed all the time and the best practices to write JavaScript change at least every year.
But then again, we have to remind ourselves that we shouldn’t immediately jump to a new tool just because it’s available, to not rewrite the whole code of a project just because conventions have changed. No project will stop working because you’re using OOCSS instead of ITCSS or Backbone.js instead of React.js. If the project is an ongoing process and will be developed and maintained for another few years, you should evaluate to change tools from time to time, of course. But take your time. Better evaluate first, then reconsider, before you immediately jump on a train from which you don’t know where it’s heading.
