KnowYourUser

Source: A List Apart

If you’re running a version of the ALA pattern library that’s more than a few weeks old on a public server, please update it right away. The script that powers the navigation in the pattern library was found to have a pretty glaring security issue that would potentially allow read access to any file on a public webserver, even outside of the web root. If you’re running the pattern library locally there’s nothing to worry about—but you should pull the latest from the repository just the same.

To view the patterns in isolation, a small PHP script checks for a path variable in the URL then uses include() to pull a snippet of code on the page. If that variable isn’t present, all the patterns are rendered instead.

Unfortunately, where this pattern library script had really only been used on internal projects, it operated on a certain level of trust—whatever was passed in that path variable would be included on the page, without restriction or filtering. This meant that a path pointing outside of the pattern library root—or even the web server’s public root—could be rendered on a public page. Permissions settings aside, this meant the potential for public access to any file on a server hosting the pattern library.

This issue has since been resolved, and any inputs thoroughly sanitized. We’re now ensuring that special characters are escaped, that the path variable can’t point to any parent directory, and that the file being included has an .html extension.

In terms of lines of code, this was a very small issue—resolved in about fifteen minutes, if even that. In terms of security impact, it meant largely unrestricted access to any file on any public-facing server that hosted the pattern library—a serious issue.

The lesson here is to always sanitize your inputs—even in code that isn’t meant to be released to the public, just in case.

Thanks to @linssen for pointing the issue out to us.

Read the full article

Source: A List Apart

Ever since @font-face was introduced, our web font choices have grown tremendously each year. Web font trend data can help us make sense of all those new choices—and give insight into which typefaces are working well on the web, and which might even be overused. Let’s explore where we can find data on what’s popular now, and how we can use that information.

Google Fonts

The most popular Google fonts can be sorted by total views. The drastic difference in pageviews of Open Sans is quite impressive: it’s viewed more than three times as often as any other font. Here are Google’s dominant three for the last 30 days:

1. Open Sans
2. Roboto
3. Oswald

Fonts.com

The Fonts.com blog updates monthly with its list of most-popular fonts. Trade Gothic was its top family for February 2014, moving up from the number two spot a year ago. Over the last year, Avenir Next has grown in popularity, while Din Next has declined. Fonts.com’s top three in February were:

1. Trade Gothic
2. Avenir Next
3. Neue Helvetica

Font Squirrel

Filtering by “Webfont” and sorting by “Popularity” will yield us Font Squirrel’s most popular for @font-face embedding. Its top three:

1. GoodDog
2. Quicksand
3. Open Sans

Typekit

Typekit doesn’t share the most popular fonts by view, but by most favorited. When it released the favoriting functionality in 2011, Adelle was the most adored, but has since dropped down a spot. Futura PT was number two and is now number five. Typekit’s most favorited three are:

1. Museo Sans
2. Adelle
3. Proxima Nova

Font Deck

Want to look at the most popular serif, sans-serif, or script? You can do that at Font Deck, along with sorting all font families by popularity. Its top three overall:

1. Proxima Nova
2. Apercu
3. Bliss

FontSpring

All fonts on FontSpring have web licenses available. Whether its list of popular fonts takes that into consideration is a bit unclear, but we see some common font friends that we’ve seen before. Its bestselling in the last 30 days:

1. Proxima Nova
2. Museo Sans
3. Museo

Webtype

Webtype has a nice advanced filtering section, including an “intended size” filter for finding your perfect small or large type sizes. Changing the default filtering from “Most Recent” to “Popularity” gives us these leaders:

1. Gill Sans
2. Benton Sans
3. Ibis

There are plenty of other choices for serving or downloading web fonts from, but you can see with a bit of digging, we can learn a lot about what’s been working well for others.

Using the data

How can we put this information to work? Here are some examples from my own experience.

I worked on a website in which using any paid third-party services was prohibited, but the team was hesitant to use free web fonts because appearing professional was critical. Looking at how popular the sans-serif fonts Open Sans, PT Sans, and Source Sans were on Google Fonts gave us the confidence to use one of those in production.

Another project started with the use of Futura, a font that is common to these popular lists and had been used in a few of my recent projects. I wanted to try something new, so I used those same lists for inspiration and tried out some of the fonts a little further down in the popularity numbers, and it helped refresh the design.

There’s no one way to look at this data, though. Maybe the top fonts are popular because they have fabulous font hinting, or maybe because they’ve been used on influential sites. It’s up to you to interpret the trends in the context of your project’s needs and goals—but watching them can help inform your next font choices.

Read the full article

Source: A List Apart

My 2014 started with noble plans: not biting my fingernails anymore, learning actual math. One of those plans was to analyze, publicly—here—the divergent and dissonant definitions of our industry’s adjectival darling, “responsive.”

Alas, I was beaten to the forum by Jason Grigsby, whose recent blog post, Defining Responsiveness, explores some of the very same questions around the term that have dogged me lately.

There’s a timeliness to this confusion over responsive-ness. Questions are being asked. Brows are furrowing. Blog-comment diatribes are taking on an almost doctrinal tone. Topical conference speakers are mobbed post-presentation by attendees who shout questions with the hopeful intensity and desperation of reporters outside Supreme Court hearings: But, look, look at this site! Is it really responsive? Can you tell me? Can you help? How do you know if it’s responsive?

As if there are authorities who can divine every nuance of our pooled sense of responsive, or that there exists somewhere an immutable stone carved with its meaning, accessible only to the elect. Or perhaps, do we hope because we feel so lost?

Even in a more prosaic and realistic sense, these discussions often presuppose several things:

• There is a single, correct definition for “responsive” (and perhaps a nucleus of leaders consciously invented it)
• We have control over this definition and should seek to rally the web community around it
• We all mean the same thing when we say “responsive”

I’d gently argue against each of these premises. Instead, I believe the definition of “responsive” to be evolving, an abstract concept that eludes direct semantic policing. It’s as yet too nascent and amorphous to have a universally-accepted meaning; it’s a word whose genesis lacked unified intent. However, I do think that we are moving toward meaning the same general thing when we say something has the quality of being responsive. And therein lies hope for eventual clarity.

The one, true “responsive”

First, let’s distinguish between Responsive Web Design and “responsive.” I’m rattling on here about the latter, the adjectival form, the descriptive, little-r responsive as contrasted to Ethan Marcotte’s big-R Responsive Web Design techniques.

Ethan has consistently maintained that the definition of Responsive Web Design is constrained to the three specific techniques for making sites that adapt well across many browser environments: fluid layouts, flexible images (and media objects), and media queries. One, two, three.

As defined, then, Responsive Web Design doesn’t leave room for a lot of ambiguity (though, believe me, we have created a lot of it anyway). It’s a mechanical concept, the brainchild of a single person, based on finite, specific elements.

But RWD’s impact has been greatly informed by the conceptual notion of designing and building usable, broadly supported sites and apps now and in the future, now that we have all of those pesky devices to deal with.

Grasping around for a way to talk about this approach toward these bigger goals, we gravitated back to that seminal technique for accomplishing them. And so emerged an abstract modifier (“responsive”) from a concrete, technical noun phrase (Responsive Web Design). This isn’t surprising when you think about it—we didn’t have many other terms available on which to hang our proverbial hats.

But, as Jason and others have noted, there’s no consensus about what “responsive” means. I can tell you how to do Responsive Web Design. How we make things “responsive” is up to us. All of us.

Controlling the definition

Unlike Responsive Web Design, which is concrete and single-origin, the advent of “responsive” as describing web design was profoundly distributed. No identifiable individual first breathed life into the word; it is owned by all of us and none of us at the same time.

Language evolves, always and inexorably. In our rarified web world, it can evolve even faster. Head-spinningly fast. And the evolving meanings continually take influence from myriad, organic sources of input. So if pinning down the definition of “responsive” is hard enough, controlling it is futile.

What are we trying to say, anyway?

So what does “responsive” mean, already? At the risk of tilting toward pedantry, I’ll suggest that it means what we (collectively) think it means.

Language components—in our example, words—carry something like a tiny implicit covenant, a tacit community agreement about what each means.

Where we can go wrong here—that is, commit actual language errors in the linguistic sense of the term—is when the parties involved in communications have a different understanding of the semantic payload (and “different understanding” can include one party not knowing what something means at all). Wires get crossed, connections missed.

I think when Jason suggests that people might use “responsive” to imply certain qualities like adaptive, accessible, or device-appropriate, he’s on to something. Though consensus is nowhere near solid, there’s a tugging momentum in the term that suggests its increasing use to convey the bigger picture of the things we’re doing right while building things for the pan-device web.

Will “responsive” become redundant?

So that raises the possibility that we’re using “responsive” in certain cases to communicate…well…web design, done thoughtfully.

Think about it for a moment. Guy Podjarny’s recent research indicates about 12 percent of the top 10,000 sites are responsively designed, according to his current responsive metric (fluid layouts, primarily). That number actually blows me away, and at the least promotes responsive out of the experimental. It sort of feels like that moment when you no longer need to use a vendor prefix for a CSS property. Training wheels: off.

In any case, I think we will continue to coalesce around a greater consensus on what makes something responsive, even if it’s not the meaning we had in mind for it originally. There are common undertones to the word, even if we still skirmish over the particulars. Its meaning already seems to be drifting a bit toward describing a site or app, versus providing a strict recipe for building one.

Does that mean “responsive,” whatever the heck it means, is poised to take over the world (well, our version of the world, anyway)? Will it achieve such dominance that the adjective itself will fade over time and disappear like a vestigial tail, leaving us simply…web design?

Read the full article

Source: A List Apart

Webydo is home to 53,000 designers creating code-free websites. The online design studio&mdashby designers, for designers.

Read the full article

Source: A List Apart

If there’s one phrase in client services that irritates me, it’s “what the client expects.” Clients come in a variety of shapes, sizes, and types of experience. If a client has previously worked with a designer, then they’ll likely base their expectations on that process. If a client hasn’t worked with a designer, they may base their expectations on the second-hand experiences of friends and colleagues. In both cases, the process may not be the same this time around.

During a project, we build relationships with our clients while we learn how best to work together. Through talking to them, we establish what might be the best deliverables to help them understand our mutual goals in the design process.

It’s difficult to decide upon the most appropriate deliverables before the process begins. The concepts may become easier to describe in different ways at different times. You may want to create a document in lower fidelity when sharing rough ideas with a client. Or you might want to show design work in higher fidelity to help a client visualize exactly what you intend. They’re working documents, part of a working process.

“The client expects PSDs/wireframes/templates”

It’s part of our job to decide the most appropriate way to share our work with a client. If the client has already established what they believe to be the “right deliverables” based on their work with a previous designer, it’s our job to respectfully nudge them in the right direction, while explaining our reasons behind those decisions.

We can’t sit still and wait for clients to dictate the best process to us. The web is not a constant, and the solutions we offer are continually evolving. Some projects might require a working prototype so we can show a client exactly what we mean. Some areas of a project might just need a quick sketch to convey the basic idea to the client. We can’t expect to keep up with changing technology if we’re keeping our processes, and the work we create, exactly as we and others have done before.

Setting out specific deliverables in estimates and proposals

Detailing “I will deliver 1x Photoshop file as a final design” in your estimate or proposal is setting yourself up for failure. We can’t ever know how many deliverables we’ll need to convey our ideas effectively, or what fidelity will work best at each step of the design process. We need the flexibility to create the deliverables that best convey our ideas whenever we need them. Without creating deliverables as needed, and sticking to a pre-defined schedule and structure, we run the risk of wasting our time and the client’s budget by creating deliverables just for the purpose of fulfilling the proposal, and without any real meaning or value.

Design is the journey

In web design, the deliverables we create are rarely the final product; they’re rarely the thing we’re going to “put live” to any users. They’re throwaway documents, a history of the design work that evolved into that final product.

Often designers speak about their Photoshop documents, wireframes, or prototypes as if they are the “designs”—but they’re not. They’re a form of communication between us and the client. The act of creating these deliverables is the design. The decisions we’re making, the solutions we’re lining up and checking off, selecting and rejecting: this journey is the design. The deliverable is just a vehicle.

We need to stop acting as though deliverables are the be-all and end-all of web design, and treat them as the communication tool that they are. If designers are seen to be just the producers of design artifacts, we’ll be treated as technicians, not as the professionals that we are.

Read the full article