vendredi 27 février 2015
jeudi 26 février 2015
Google To Expand Mobile Friendliness As A Ranking Signal
via planetweb
ICANN .APP Auction, Winning Bidder Pays $25,001,000
via planetweb
Can Google's YouTube Ever Turn a Profit: Revenue Up From $3 billion to $4 billion
via planetweb
mercredi 25 février 2015
This week's sponsor: Proposify
Thanks to Proposify for sponsoring A List Apart this week! They know you don’t love writing proposals, so they built some tools to help your agency win more projects.
via planetweb
Google Tests AdSense Ads With White-Grey Striped Background
via planetweb
mardi 24 février 2015
Facebook Launches a New Ads Manager Mobile App, Says it has 2-Million Active Advertisers
via planetweb
Are links no longer important to Google?
via planetweb
lundi 23 février 2015
Server Farms IP Tracking Resource - February 2015
via planetweb
jeudi 19 février 2015
Rian van der Merwe on A View from a Different Valley: Managing and Making: It Doesn’t Have to Be One or the Other
We work in interesting times. We recognize and accept that if you want to move “up” at a company, you have to become a manager. So, to rise up in the ranks means doing less of the thing you’ll be more responsible for. For a design manager, this means more time in email and Evernote, less time in Sketch and Photoshop. That doesn’t make a lot of sense, but it’s the way it is.
I’m not saying we don’t need managers—we desperately need good ones. But I started thinking about our blind acceptance of this cornerstone of modern business, and I wonder if there might be a way to create a system that values doing as much as managing—while also improving the skills of both groups.
I moved into my first management role about six years ago. I can’t quite remember the motivation behind it, but it was some combination of company need and my desire to further my career (and a little bit of “I wonder if I can do it,” I guess). I also had the good fortune of having an excellent manager in one of my first jobs. It opened my eyes to the challenges and opportunities of management, and I wanted to contribute to that. It’s been a huge learning experience (I would say it was humbling, but hashtags have ruined that word forever) and I’m glad I did it.
But a couple of years ago something about being a manager started to bother me. At first it was just a a small voice in the back of my head: How can you be a good design manager if you don’t design any more? I tried to ignore it, but that voice grew louder over time, and eventually I had to deal with the question head on.
The problem is, if you’re a manager, you have career opportunities. Manager turns into Senior Manager turns into Director turns into Senior Director, and so on. If you’re “just a designer,” the path is less clear. Sure, there are Senior and Lead roles out there, but they’re very rarely equated with real career progress. And that’s a problem. It forces some individual contributors to become managers even if they prefer to let someone else take the lead, and it creates a management culture that can become extremely out of touch with day-to-day design activities.
So at the end of last year I made a change. Partly because I was tired, partly to test this theory, I stepped away from management and became “just a designer” again. At first it was weird. Where did all the meetings go? What is this flat surface that I get to sit and work at for most of the day? But then the weirdness subsided and it just got… enjoyable. I now spend most of my days designing products, talking about and helping teams implement those designs. I realized I fell behind on design skills a little bit, so I went into a learning phase, and it was fun.
What does this mean? Am I done with management? Is anyone who chooses a life of management doomed to heartache and despair? Absolutely not! If anything, going back to being an individual contributor has cemented my belief that good managers are as important as they are hard to find. And I certainly hope and plan to be in that role again in the future. Just not right now.
So here’s how all of this comes together. I think we need a career system that encourages people to oscillate between individual contributor roles and manager roles. Maybe we provide “manager sabbaticals” where a manager becomes an individual contributor on a team for six to nine months. Maybe when a manager goes on vacation, an individual contributor takes on their role for a period of time (or for the duration of an entire project). I don’t know exactly what this looks like yet, but I think it’s important for us to figure it out.
Being an individual contributor makes you a better manager because you understand the day-to-day frustrations of your team better, and it ensures that you keep your technical skills up to date. Being a manager makes you a better designer because you understand the needs of leadership teams better, which allows you to communicate more effectively. One feeds the other, so we shouldn’t be forced to “pick a track.”
There are, of course, caveats. People shouldn’t be forced into management by the stigma that only management = career advancement. Some managers have no desire to become individual contributors again, and they shouldn’t have to. It’s about choice. If we encourage (and reward) people to have the freedom to explore different kinds of roles, it can only be a good thing for our industry—and, more importantly, for users.
via planetweb
mercredi 18 février 2015
This week's sponsor: Harvest
Thanks to Harvest for sponsoring A List Apart this week! Check out their tools to help you spend less time tracking and more time doing.
via planetweb
Prioritizing Structure in Web Content Projects
Most web content projects have both structural and editorial aspects: for example, the information needs to be structured to support the new responsive design, and the current copy needs an update so it adheres to messaging and brand guidelines.
I’m often asked which is the best order to approach the work: structure first and then rewrites, or the reverse? I didn’t used to have a strong opinion, because it seemed to me like a chicken-and-egg problem. If the project starts with structure, I’m building content models off of bad information. If, instead, we start with rewrites, the writers don’t know what pieces we need to fill the models, because the models don’t exist yet. It felt like both directions were equally fraught, and I didn’t have any strong reasons to recommend one over the other.
(Note that I’m not talking about starting without the editorial foundations of a project: understanding the business goals, establishing a message architecture, and knowing what the work is supposed to accomplish are core pieces of any project. I’m talking instead about rewriting poor content—editing and creating new copy based on those foundations.)
Structure the content first, then do rewrites
I recently finished up the second phase of a project that we organized to focus on structure first, and reasons to stick with this approach piled up in my lap like turkeys going to roost. I think that a structure-first approach does make sense for the majority of my projects, and here’s why.
Content models are based on what content is for, not what it says
On this particular project, the existing copy was horrible. Jargony, clichéd, and almost stubbornly unhelpful. How could I build a useful content model off of bad content?
As I was working, I realized that the quality of the copy–even if it’s terrible–doesn’t really affect the models. I don’t build models off of the exact words in the content, but instead I build off of what purpose that copy serves. I don’t actually care if the restaurant description reads like teen poetry (sorry teens, sorry poets): it’s the restaurant description, and we need a short, teaser version and a long, full version. The banquet facilities should include well-lit photos taken within the last decade, and the captions should use the appropriate brand voice to describe how the rooms can be used. I don’t actually need to see decent photos or strong captions to build space for them into the models.
Structure decisions influence development and design direction
A complex content model will help inform all kinds of site decisions, from CMS choice to data formatting. Developers can make better architecture decisions when they have a sense of what kinds of relationships exist between content types, and designers can organize a pattern library that matches the granularity of the content model. The earlier the structure work is done, the easier it is to build integrated design and development plans.
Cramming bad content into strong models is an incredibly compelling argument for editorial intervention
When projects are focused on the structural aspects of the work—we want to recombine content for different channels, or make a clever responsive experience using structured fields—people often start out convinced that the current content is decent enough to do the job. “Sure, it could probably use some spiffing up, but that’s just not in the cards right now.”
I have never seen a more effective argument for the importance of editorial work than taking existing copy and seeing how inadequately it fills a model that we’ve already agreed meets our business goals.
A model I built recently had a content type for holding gushy snippets about the business’s amazing customer service. When we went to move the existing content into the new models, the only copy we could find to migrate amounted to “free ice water” and “polite employees.” We had already agreed that telling the story of the brand experience was a key job of the new website, and seeing how thoroughly their current content failed to do that was the kick in the pants they needed to find budget for an editorial assist.
Content models are easy to iterate
Waterfall isn’t a great match for content development any more than it is for design and code, so editorial rewrites often trigger adjustments to the content models. I may split one large field into two smaller ones, or the writers will find a place where I left out an important piece of content altogether. Refining the models is an expected part of the process.
On projects where editorial rewriting has been done first, though, I often end up with copy that, although now written beautifully, has no place in the model. In the course of structuring the information, we combined two pages into one, or are reusing the same description in three places, and so the editorial effort that went into fixing that copy is thrown out before it ever sees the light of day. That’s discouraging, and can lead to content creators feeling like I don’t value their time or their work.
What works for you?
It’s nice to have some strong reasoning behind my structure-first leaning, but of course my experiences may not translate to your project needs at all.
If you’ve worked on a project that organized structure work first, what advantages or drawbacks did that process uncover? From a design and development perspective, are there pros or cons to either direction that aren’t covered here?
If you’re a writer, does creating copy within a content model free or stifle your best work? If you prefer to start with editorial rewrites, what are the hidden benefits for the structural side of the project?
I believe there are real benefits to taking a structure-first approach to organizing content activities, and I’d love to hear how and if that works for your projects as well.
via planetweb
Yandex Seeks Russian Antitrust Investigation Into Google Search Bundling on Android
via planetweb
mardi 17 février 2015
Facebook Launches Product Ads
via planetweb
Twitter Rolls Out TweetDeck Teams
via planetweb
Bing Publishes "Understanding and Testing: Implicit Local Queries"
via planetweb
A New Way to Listen
To develop empathy, you need to understand a person’s mind at a deeper level than is usual in your work. Since there are no telepathy servers yet, the only way to explore a person’s mind is to hear about it. Words are required. A person’s inner thoughts must be communicated, either spoken aloud or written down. You can achieve this in a number of formats and scenarios.
Whether it is written or spoken, you are after the inner monologue. A recounting of a few example scenarios or experiences will work fine. You can get right down to the details, not of the events, but of what ran through this person’s mind during the events. In both written and spoken formats, you can ask questions about parts of the story that aren’t clear yet. Certainly, the person might forget some parts of her thinking process from these events, but she will remember the parts that are important to her.
A person’s inner thought process consists of the whys and wherefores, decision-making and indecision, reactions and causation. These are the deeper currents that guide a person’s behavior. The surface level explanations of how things work, and the surface opinions and preferences, are created by the environment in which the person operates—like the waves on the surface of a lake. You’re not after these explanations, nor preferences or opinions. You’re interested in plumbing the depths to understand the currents flowing in her mind.
To develop empathy, you’re also not after how a person would change the tools and services she uses if she had the chance. You’re not looking for feedback about your organization or your work. You’re not letting yourself ponder how something the person said can improve the way you achieve goals—yet. That comes later. For developing empathy, you are only interested in the driving forces of this other human. These driving forces are the evergreen things that have been driving humans for millennia. These underlying forces are what enable you to develop empathy with this person—to be able to think like her and see from her perspective.
This chapter is about learning how to listen intently. While the word “listen” does not strictly apply to the written word, all the advice in this chapter applies to both spoken and written formats.
This is a different kind of listening
In everyday interactions with people, typical conversation does not go deep enough for empathy. You generally stay at the level where meanings are inferred and preferences and opinions are taken at face value. In some cultures, opinions aren’t even considered polite. So, in everyday conversation, there’s not a lot to go on to understand another person deeply. To develop empathy, you need additional listening skills. Primarily, you need to be able to keep your attention on what the person is saying and not get distracted by your own thoughts or responses. Additionally, you want to help the speaker feel safe enough to trust you with her inner thoughts and reasoning.
There’s virtually no preparation you can do to understand this person in advance. There are no prewritten questions. You have no idea where a person will lead you in conversation—and this is good. You want to be shown new and interesting perspectives.
You start off the listening session with a statement about an intention or purpose the person has been involved with. In formal listening sessions, you define a scope for the session—something broader than your organization’s offerings, defined by the purpose a person has. For example, if you’re an insurance company, you don’t define the scope to be about life insurance. Instead, you make it about life events, such as a death in the family.1 Your initial statement would be something like, “I’m interested in everything that went through your mind during this recent event.” For listening sessions that are not premeditated, you can ask about something you notice about the person. If it’s a colleague, you can ask about what’s on her mind about a current project.
Fall into the Mindset
How often do you give the person you’re listening to your complete attention? According to Kevin Brooks, normally you listen for an opening in the conversation, so you can tell the other person what came up for you, or you listen for points in the other person’s story that you can match, add to, joke about, or trump.2
It feels different to be a true listener. You fall into a different brain state—calmer, because you have no stray thoughts blooming in your head—but intensely alert to what the other person is saying. You lose track of time because you are actively following the point the other person has brought up, trying to comprehend what she means and if it relates to other points she’s brought up. Your brain may jump to conclusions, but you’re continually recognizing when that happens, letting it go, and getting a better grip on what the speaker really intends to communicate. You’re in “flow,” the state of mind described by Mihaly Csikszentmihalyi.3 You are completely engaged in a demanding and satisfying pursuit.
It’s a different frame of mind. You don’t want to be this focused on someone else all the time—you have to do your own thinking and problem-solving most of the time. But when needed, when helpful, you can drop into this focused mindset.
Explore the Intent
Developing empathy is about understanding another human, not understanding how well something or someone at work supports that person. Set aside this second goal for a bit later. For the time being, shift your approach to include a farther horizon—one that examines the larger purposes a person is attempting to fulfill.
The key is to find out the point of what the person is doing—why, the reason, not the steps of how she does it. Not the tools or service she uses. You’re after the direction she is heading and all her inner reasoning about that direction. You’re after overarching intentions, internal debates, indecision, emotion, trade-offs, etc. You want the deeper level processes going through her mind and heart—the things that all humans think and feel, no matter if they are old or young, or you are conducting the session 500 years ago or 500 years in the future. These are the details that will allow you to develop empathy. Collecting a shallow layer of explanation or preferences does not reveal much about how this person reasons.
To remind the speaker that you’re interested in answers explaining what is going on in her mind and heart, ask questions like:
- “What were you thinking when you made that decision?”
- “Tell me your thinking there.”
- “What was going through your head?”
- “What was on your mind?”
If you suspect there might be an emotional reaction involved in her story that she hasn’t mentioned yet, ask: “How did you react?” Some people ask, “How did that make you feel,” but this question can introduce some awkwardness because it can sound too much like a therapist. Additionally, some people or industries eschew talking about “feelings.” Choose the word that seems appropriate for your context.
Avoid asking about any solutions. A listening session is not the place for contemplating how to change something. Don’t ask, “Can you think of any suggestions…?” If the speaker brings up your organization’s offering, that’s fine—because it’s her session. It’s her time to speak, not yours. But don’t expand upon this vein. When she is finished, guide her back to describing her thinking during a past occurrence.
Make Sure You Understand
It is all too easy to make assumptions about what the speaker means. You have your own life experience and point of view that constantly influence the way you make sense of things. You have to consciously check yourself and be ready to automatically ask the speaker:
- “What do you mean?”
- “I don’t understand. Can you explain your thinking to me?”
Keep in mind that you don’t have the speaker’s context or life experience. You can’t know what something means to her, so ask. It takes practice to recognize when your understanding is based on something personal or on a convention.
Sometimes, you will probe for more detail about the scene, but there’s nothing more to say, really. These kinds of dead-ends will come up, but they’re not a problem. Go ahead and ask this kind of “please explain what you mean” question a lot, because more often than not, this kind of question results in some rich detail.
You don’t need to hurry through a listening session. There’s no time limit. It ends when you think you’ve gotten the deeper reasoning behind each of the things the speaker said. All the things the speaker thinks are important will surface. You don’t need to “move the conversation along.” Instead, your purpose is to dwell on the details. Find out as much as you can about what’s being said. Ignore the impulse to change topics. That’s not your job.
Alternatively, you might suspect the speaker is heading in a certain direction in the conversation, and that direction is something you’re excited about and have been hoping she’d bring up. If you keep your mind open, if you ask her to explain herself, you might be surprised that she says something different than what you expected.
It’s often hard to concede you don’t understand something basic. You’ve spent your life proving yourself to your teachers, parents, coworkers, friends, and bosses. You might also be used to an interviewer portraying the role of an expert with brilliant questions. An empathy listening session is completely different. You don’t want to overshadow the speaker at all. You want to do the opposite: demonstrate to her that you don’t know anything about her thinking. It’s her mind, and you’re the tourist.
Sometimes it’s not a matter of assumptions, but that the speaker has said something truly mystifying. Don’t skip over it. Reflect the mystifying phrase back to the speaker. Ask until it becomes clearer. Don’t stop at your assumption. Teach yourself to recognize when you’ve imagined what the speaker meant. Train a reflexive response in yourself to dig deeper. You can’t really stop yourself from having assumptions, but you can identify them and then remember to explore further.
Another way to explain this is that you don’t want to read between the lines. Your keen sense of intuition about what the speaker is saying will tempt you to leave certain things unexplored. Resist doing that. Instead, practice recognizing when the speaker has alluded to something with a common, casual phrase, such as “I knew he meant business” or “I looked them up.” You have a notion what these common phrases mean, but that’s just where you will run into trouble.
If you don’t ask about the phrases, you will miss the actual thinking that was going through that person’s mind when it occurred. Your preconceived notions are good road signs indicating that you should dwell on the phrase a little longer, to let the speaker explain her thought process behind it.
Footnotes
- 1. If you’re a researcher, it helps to know that listening sessions are a form of generative research that is person-focused rather than solution-focused. Thus, it’s easy to remember to keep them from dwelling on how solutions might work for people.
- 2. This was my epiphany from the UX Week 2008 workshop (PDF) by Kevin Brooks, PhD. Sadly, Kevin passed away from pancreatic cancer in 2014.
- 3. Mihaly Csikszentmihalyi, widely referenced psychologist and author, Flow: The Psychology of Optimal Experience, New York: Harper Collins, 1991, and Finding Flow: The Psychology of Engagement with Everyday Life, New York: Harper Collins, 1997, plus four other book titles on Flow. Also see his TED Talk and YouTube presentations.
via planetweb
Microsoft adopts first international cloud privacy standard
via planetweb
vendredi 13 février 2015
Pinterest Pulls the Plug On Affiliate Links
via planetweb
LinkedIn Makes Significant Changes to its Developer Program
via planetweb
jeudi 12 février 2015
Facebook Advertisers To Get Ad Relevance Scores
via planetweb
Pinterest and Apple Team Up For "App Pins" For Easier App Discovery
via planetweb
This week's sponsor: Stack
Thanks to Stack for sponsoring us this week. Learn more about their task manager to bring your workflow and team together.
via planetweb
mercredi 11 février 2015
Google Adds Health Information to The Knowledge Graph
via planetweb
mardi 10 février 2015
At Home with the Robots: 2015 Edition
via planetweb
lundi 9 février 2015
A List Apart: On Air
We keep busy here at A List Apart: publishing articles, columns, and blog posts; sharing our forays into open source; and coming up with features like email notifications for new content.
Something was still missing, though.
We’ve always prided ourselves more on our focus on the designer and developer community than on our technical acumen. Anyone can help make a better website, but we consider it a unique privilege—and responsibility—to be able to help developers become better developers. So, we’re trying something brand new: community-focused events where our readers can get to know A List Apart’s authors and staff.
Our goal is to bring the feel of a local web development meetup to the web. We want to combine the best and brightest voices from ALA’s past with new voices and new perspectives on designing and building for the web. We want to discuss the events of the day—or hour. We want Q&A sessions where you ask us the tough questions; we want to know what questions don’t yet have answers, so we can figure them out with you.
If this piques your interest, well, I have some good news: we’re kicking things off right away. We’ve assembled some of the best minds in web performance to talk about every facet of building smaller, faster websites—from getting buy-in at every level of your organization to the steps we can incorporate into our day-to-day work.
Designing for Performance: Can We Have it All?
Thursday, February 26, 2015
1:00 – 2:00 p.m. EST
Building a faster, leaner web means contending with a number of challenges, not all of which are strictly technical. “But,” your CEO argues, “our massive, high-resolution images are worth the wait.” How do we manage those kinds of expectations? How do we get our teams—and our bosses—as excited about building performant websites as we are? Most important, though: where do we get started, and how?
Our panelists are here to answer all these questions for you, and then some.
Lara Hogan
Lara Hogan champions performance as a part of the overall user experience, and is the author of Designing for Performance (O’Reilly, 2014). She believes in striking a balance between aesthetics and speed, and in building performance into company culture. Lara speaks and tweets, and is currently senior engineering manager of performance at Etsy.
Scott Jehl
Scott Jehl releases projects on GitHub that focus on accessible, sustainable, and performance-oriented practices for cross-device development. He speaks at conferences around the world and recently authored Responsible Responsive Design (A Book Apart, 2014). Scott is a web designer and developer at Filament Group; his clients include the Boston Globe, LEGO, Global News, and eBay. He tweets early and often.
Yesenia Perez-Cruz
Yesenia Perez-Cruz is a Philadelphia-based designer working at Intuitive Company. She is also a speaker at international conferences, in demand for talks specializing in balancing performance with design, cross-team collaboration, and how to be flexible with your design process. She honed her design and user experience skills while working at Happy Cog for clients like Zappos, MTV, and Jose Garces. She also acts as an acquisitions scout for A List Apart.
And as your humble moderator, I’ll be doing my best to stay out of their way.
More events are in development, and we’ll be sure to keep you updated. We’re looking forward to talking with all of you.
via planetweb
jeudi 5 février 2015
Google Updates and SERP Changes - February 2015
via planetweb
Lyza Danger Gardner on Building the Web Everywhere: What Will Save Us from the Dark Side of CSS Pre-Processors?
Writing CSS by hand for a site or app of any considerable size seems quaint these days, in the way that shaping a piece of wood with an adze seems quaint. Admirable, perhaps, but even if it gives you a tangible connection to the exact outcome, the vestigial quirks, limitations, and tedium of that workflow make it feel archaic.
Until a few years ago, this direct method was our only real option. We managed CSS by hand, and it got complicated and crazypants. So when pre-processors started showing up—Sass, LESS, Stylus—we clutched at them, giddy and grateful like sleep-deprived parents.
Pre-processors to the rescue!
Their fans know that pre-processors do a lot of stuff. Variables, functions, nesting and calculations are part of the pre-processor assortment, but there’s often also support for concatenation, minification, source maps, output formatting. Sass feels like an authoring tool, framework, configuration manager, transform and build tool in one. They’ve become very popular—especially Sass, the juggernaut. Huzzah! Such power!
Pre-processors… to the rescue?
Yet as with other powerful things, Sass has a dark side. Its potential malevolence tends to manifest when it’s wielded without attention or deep understanding. In the recent article A Vision for our Sass , Felicity Evans points out some of the ways unmindful use of Sass can result in regrettable CSS.
Pre-processors have a way of keeping us at arm’s length from from the CSS we’re building. They put on us a cognitive burden to keep up on what’s evolving in CSS itself along with the tricks we can pull off specific to our pre-processor. Sure, if we’re intrepid, we can keep on top of what comes out the other end. But not everyone does this, and it shows.
Overzealous use of the @extend feature in Sass can create bloated stylesheet files bobbing in a swamp of repeated rules. Immoderate nesting can lead to abstruse, overlong, and unintentionally overspecific selectors. And just because you can use a Sass framework like Compass to easily whip up something artful and shiny, it doesn’t guarantee that you have any sort of grip on how your generated CSS actually works.
Pre-processors… FTL?
Diabolical output is one risk, and yet there are additional ways pre-processors can trip us up.
Working with a pre-processor means writing source in its Domain-Specific Language (DSL). (You could also pen your source using entirely vanilla CSS, but that would be pretty pointless, as the power of pre-processing comes from operations on variables, mixins, and other features written in their particular syntax.) You feed this source to the pre-processor and out comes CSS ready for browsers. You couldn’t take your source and use it in a browser. It’s not ready yet.
That means that the source is not entirely portable. So choosing a particular pre-processor may be a long-term commitment—Sass and other pre-processors can create a certain amount of lock-in.
On a conceptual level, the breadth of pre-processors’ scope is significant enough that it can insinuate itself into the way we think and design. In that sense, it’s not a tool but a system. And this can get under the skin of people—especially devs—who thrive on separation of concerns.
This is beginning to sound like an argument to ditch Sass and its brethren and return to the homespun world of handcrafted CSS. And yet that is a false dichotomy: pre-processors or nothing. There are other tools for managing your CSS, and I’m especially hopeful for a new (ish) category of tools called post-processors.
Post-processors to the rescue!
In contrast to pre-processors’ distinct syntaxes, post-processors typically feed on actual CSS. They can act like polyfills, letting you write to-spec CSS that will work someday and transforming it into something that will work in browsers today. Ideal CSS in, real-life CSS out.
You may already be using a post-processor alongside your pre-processor without being aware of it. The popular autoprefixer tool is in fact a post-processor, taking CSS and adding appropriate vendor prefixes to make it work in as many browsers as possible.
Many post-processors—especially those written with a plugin approach—do only one specific thing. One might polyfill for rem units. Another might autogenerate inline image data. You can pick and choose the modular plugins you need to transform your CSS.
Post-processors typically edge out their pre- brethren in build-time speediness.
And because they can be used as modular chunks, they can serve a balm for the aforementioned separation of concerns violations.
With this kind of authoring, we have a built-in necessity to stay current on the way new specs express themselves in actual CSS syntax, and that means post-processors’ transformations aren’t as inscrutable. Plugin authoring, too, is pegged to the same specs. Everyone is marching to the same, standards-driven beat.
This is starting to feel like outright post-processor boosterism, isn’t it?
Except.
Post-processors… to the rescue?
The case for post-processors isn’t entirely coherent. There isn’t even any consensus about the definition. The way I’m explaining post-processors is my own interpretation. Don’t take it as gospel.
Real-world implementations don’t help to clear the picture, either. Several modules written using postcss , a JavaScript framework for post-processors, involve custom syntax that doesn’t align with the definition I’m outlining here (valid CSS in, valid CSS out). By my definition, myth.io would be a post-processor, but is described by its maintainers as a pre-processor. Maybe post-processors aren’t even a thing, or only exist in my fevered, idealistic imagination.
Post-processors may hold more appeal to certain members of the web-building audience. The appeal of shaving some milliseconds off build has more clout with some than others. Modularity is one thing, but pre-processors can do so many things. It’s hard to wean from something that serves us so well.
Taking a path paved with lean, modular post-processing plugins involves sacrifices. No more nesting. Instead of an endless horizon of mixin possibilities, you may be bound to CSS spec realities, like calc or CSS variables. One promising framework for rolling out post-processing plugins is postcss, but it’s young yet and its documentation is in a correspondingly awkward adolescent phase.
Knowing your craft to the rescue!
Remember that thing I said earlier about false dichotomies? Gotta remember that, because pre- and post-processors aren’t mutually exclusive.
We happily use both in my office. Some of our more dev-y designers have taken a shine to the post-processing philosophy, while other designers remain pleased with the all-in-one, intuitive oomph Sass gives them. Both are right.
Though each camp might have a different approach to tools, the important commonality they share is a deep understanding of the CSS that comes out the other side. Neither set of tools is a crutch for ignorance. Know your craft.
Although there are different ways to get there, a thoughtful understanding of CSS is a prerequisite for continued success in building great things for the web. Whether you’re one to meditatively chip with an adze along a raw CSS stylesheet or you prefer to run it through a high-tech sawmill, you’re always better off understanding where you’re starting from and where you’re trying to go.
via planetweb
Twitter to show Tweets in Google Search Results
via planetweb
mercredi 4 février 2015
Google Reports on AdWords Bad Advertising Practices 2014
via planetweb
FCC Will Enforce Open Internet Protections, Including on Mobile
via planetweb
Style Guide Generator Roundup
Style guides are a living document of code that detail all the various elements and coded modules of your application. The term “pattern library” is often used when talking about these types of guides—Brad Frost has a great piece on differentiating between the various types of style guides. To learn more about creating style guides see either Creating Style Guides here on A List Apart or Front-end Style Guides by Anna Debenham.
In the past I’ve been quite old fashioned and done the HTML for style guides by hand, but with a new project I wanted to try out a style guide generator. Style guide generators bring at least some automation to the creation of your guide, so that you don’t have to do everything by hand. They may actually create the guide itself using a process built on a task runner, Node, or a particular language. My client requested something straightforward, something that would have some type of auto generation. So, off into the land of generators I went.
Because they generate portions of the guide itself, maintenance is hopefully easier. Generators aren’t a silver bullet, they’re not completely automated, but even just getting part of the process done for you can make life easier down the road.
There are a lot of different kinds of generators out there. Many of them are based on workflows or a particular tool, and some of them have been ported over to several different workflows, so I’m breaking these down by workflow, but you’ll see several mentioned in the various categories.
Node.js
There are several generators that run off of Node, so if you like Node, you have some choices. KSS has a Node version, and there’s also Pattern Primer, StyleDocco, and StyleDown.
Two of these, KSS for Node and Pattern Primer, are just ports of other generators that run on something other than Node. But StyleDocco and StyleDown both were written in Node.
KSS, StyleDocco, and StyleDown all use a combination of comments and markdown that are in your CSS files (or whatever files your CSS uses, such as Sass, etc.). For example:
/**
* Button:
* `.btn` - the main button style
*
* @example
* button.btn Button
*/
This is using StyleDown for the generation, just as an example—they all vary a bit in what you put into the files.
I found in my research that all of these were easy to get up and running, the most complicated being Pattern Primer, because you actually break up the HTML into partials, whereas the others use just the comments to guide what markup will be generated in the final file.
Some of these, such as StyleDown and StyleDocco, come with some nice out-of-the-box styling for the guide itself, so you can get something looking quite nice in very little time.
Gulp and Grunt
There are several style guide generators that can be used with Gulp or Grunt task runners to get up and going. Some of these are the very same as mentioned above using Node, so it is just versioned to work with the particular task runner.
So here’s a list of the ones I’ve already discussed, but just made for Gulp or Grunt:
- KSS (Gulp or Grunt)
- StyleDocco (Gulp or Grunt)
- Pattern Primer (Grunt only)
But there are some generators that are unique to Gulp or Grunt and one of them looks quite amazing. Fabricator creates a great looking UI toolkit, so I recommend checking it out if you’re looking for a robust solution and you use Gulp.
Grunt also has several generators that are not on Gulp, so here are some more to check out for that workflow:
Using a task runner, much like Node, can be great for a quick, lightweight solution. For certain projects, many of these could be a great solution, especially if you’re in client services and will be handing off the code at the end. These (or the Node solutions) would be fairly easy for them to get up and running as well.
Ruby
The generators using Ruby (or PHP for that matter) are often quite robust, generating something more akin to Fabricator, with navigation, nice styling, and flexibility. If you are already working on an app in Ruby, they make even more sense, but the style guides can be done as a stand alone as well.
Hologram was developed by Trulia and has become a great solution for generating guides. It relies on YAML and markdown comments in your CSS to generate a fantastic style guide. It has a great templating system with some basic styles and navigation that makes the generated guide easy to use.
KSS, mentioned above in the Node section, uses the views in whatever your framework of choice is to get the guide generated. Because it is a bit more wrapped up in the framework of the application itself, it may not be as quick to get it up and running, but once you’ve done the work, it could be a great add-on to your current application and help you keep your UI in order.
The Living Style Guide is another tool that runs off a Ruby gem, but uses just Sass and markdown to compile it all together. You write markdown partials of each module, which is then translated into the markup for the guide itself. The gem then takes all the markdown templates and converts it to HTML and creates the guide. It runs off a gem, but it doesn’t have to be used with a Ruby project, it can run in other projects as well and you can also integrate it into Rails.
There is a version of The Living Style Guide in Gulp as well, if you would prefer to try that instead of the Ruby version.
PHP
Unlike many of the other generators already discussed, for these you’ll need to have a local server running to put it all together and see it in action. But some of these solutions have been around for a while and used in great projects.
Barebones, is more than just a style guide generator, but does include one. Using partials and includes, the modules and components can get included on the style guide page.
Pattern Primer runs in a similar way to Barebones. The patterns are partials of HTML and then compiled into the main index page. One nice feature of the Pattern Primer is that the patterns are already in the GitHub repo, so you have a great starting point for all the various different elements you quite possibly would be using in your site or application. In addition, you may have already noticed this, but this concept has been ported over to several other workflows.
Pattern Lab generates a static site of the various patterns and modules used in a site and it is quite robust. It uses mustache templates, with JavaScript for viewing and PHP for building, but once it’s built, it’s static, which is really nice.
Style Guide Boilerplate is another PHP-based generator, but it runs on a server, much like Pattern Primer. There are some initial patterns to help you see how everything works and you can go from there creating your own snippets to include in your final guide.
That’s a lot of different choices for how to generate your style guide. I’m sure there are even more possibilities, so if I missed a tool that you really like, please let us know in the comments. You can also check out styleguides.io for even more information on style guides, and share additional generators or tools you use when creating style guides there via GitHub or on their form if you aren’t comfortable doing GitHub pull requests.
If you are just getting started with style guides, then you should definitely check out styleguides.io. There’s a lot of information there, but the resources with stars are a good place to start. It can seem daunting with all the information there is out there, but just getting started and creating your first guide will show you how wonderful they can be in a workflow—hopefully one of these tools will make generating your first guide just a bit easier.
via planetweb
mardi 3 février 2015
Twitter Promoted Tweets Now On Syndicated Sites
via planetweb
StatCounter: Google US Search Share, January, 2015, Falls Below 75pct
via planetweb