Other, Typography, UX/UI

Launched in 2003, Design Observer has been one of the most influential sources for design thinking and criticism on the web. It was founded by four outspoken design critics at a time before the web really cared about design, inspiring an almost cult-like following among many readers. Today it remains a cornerstone of the online design community.

Yet Design Observer has never been a model for web design, and until recently, it had the look and feel of a website a few years out of time. This week, Design Observer is rolling out a new design, which puts an emphasis on being mobile- and social media-friendly in an attempt to increase page views. Will it hold up to the gimlet eye of the design-savvy Internet that Design Observer itself helped to create?

“When we started Design Observer, we had this dream: what if everyone really cared about design and voiced those opinions and argued about them?” Design Observer co-founder and Pentagram partner Michael Bierut tells Co.Design. “To a large degree, that world has now come to pass. Everyone cares about design now.”

The fact that everyone cares about design now makes it harder than ever to ignore the fact that Design Observer looks decidedly dated. The most recent version of the site resembled an old-school blog even when it was released in 2009: a slim column of content sandwiched between two massive, link-heavy side bars. Traffic to Design Observer is up 45% since 2009. But that isn’t tremendous growth for such an influential site: over the past year, the site has only pulled in around 4 million page views. Modernizing the look, feel, and reach of the site was critical.

DESIGN OBSERVER HAD THE FEEL OF A WEBSITE A FEW YEARS OUT OF TIME.
“The way it looked up until now we felt was overwhelming and confusing,” Bierut says. “In this day and age, having a really dense, multi-channel site doesn’t really seem appropriate anymore.” The trick was to modernize and simplify the Design Observer while maintaining its focus on critical, long-form conversations about design. All while keeping the new design in-house.

The most obvious change is that the new look abandons the old design’s Pee Chee lemon color for a bolder blue design, while focusing the homepage from a river of blog posts into the three big stories of the day.

“We’re not trying to be always on,” says Bierut about the new homepage. “The role we want to play in our readers’ lives is that when our readers get up in the morning, come home from school, or read the site after dinner, there’s worthwhile new content for them. We want to establish real intimacy with our readers, with an expectation and respect for their times.”

WE WANT TO ESTABLISH REAL INTIMACY WITH OUR READERS, WITH AN EXPECTATION AND RESPECT FOR THEIR TIMES.
In addition to the new front page design, posts on Design Observer are now organized into mosaic-like portals of stories centered around certain topics, an approach to archiving that’s designed to make Design Observer more of a reference tool.

But the biggest practical change about the new Design Observer might just be the way it is doubling down on the community, and concertedly spreading the site’s tendrils into social media for the first time.

“One thing we learned recently was that Facebook and Twitter were not really the ancillary publicizing arms to Design Observer that we thought they were, but people’s primary entry into the site,” says Jessica Helfand, another co-founder. “I guess everyone else already knew that, but when we realized it, it was kind of a big moment.”

HELFAND WANTS TO TURN DESIGN OBSERVER INTO A SOCIAL MEDIA NETWORK OF SOME OF THE MOVERS AND SHAKERS IN THE WORLD OF CONTEMPORARY DESIGN CRITICISM.
To address Design Observer’s new social reach, the site is doing more than adding the ubiquitous social media buttons you expect from a modern site. They are also putting a new emphasis on the Design Observer community, allowing users to register to not only comment on articles, or link their own social media feeds and websites, but link their design influences as well, which Helfand hopes will prove an “interesting benchmark” that will turn Design Observer into a social media network of some of the movers and shakers in the world of contemporary design criticism.

Design Observer knows it will have it share of critics, but for his part, Bierut feels that that is just par for the course in a world where everyone cares about design. “I’m sure we’ll be criticized for continuing to favor a design that is beholden to the legacy of print,” Bierut says. “We live in a world where you can’t even redesign a logo without a pile-on. But I’m grateful to live in a world where at least now people who are thoughtful will figure out why they hate it.”

Helfand doesn’t seem to quite share his serene outlook. “There’s a part of me that really wishes I could just get out of the country for the week, maybe buy a ticket to the moon,” Helfand laughs. “I want to really dig my head in the sand. Democracy and design can be very strange bedfellows.”

Correction: Based upon statements made during our interview with Michael Bierut and Jessica Helfand before the site was officially relaunched, the original version of this article incorrectly stated that the new Design Observer is fully responsive. That is incorrect. In keeping with the site’s idiosyncratic tendency to be a few years out of step with the rest of the design world, the new Design Observer is not responsive. The article has been edited to correct the error.

From FastCoDesign.com

Advertisements
Link
UX/UI, Web Design

I believe that most people are good. Most people really want to live up to their ideals. So why do companies fall short on living up to their missions, credos, mantras, or ideals?

For example, why does a company that says it supports local businesses jump at the chance to work with Walmart just to get a “big name” client on its roster? I have started to believe it is because they haven’t taken the time to clearly articulate company values and, more importantly, establish routines and practices that intentionally frame their decisions to factor in their values.

At our design firm, P’unk Ave, we decided to change that by developing a model for evaluating potential clients, giving us a practical, standardized way to make decisions that stay truer to our values. While it may seem like being picky about who we work with is bad for business, we’ve found the opposite to be true: the more we’ve stuck to our ideals, the stronger our business has become. In this article, I’ll show you how it worked for us—with the hope you can learn from it and do the same for your business.

Establishing your values

You can’t live up to your ideals until you have a clear grasp of them. If you have been in business for some time, you might be surprised to realize that they already exist and are just waiting for you to be more intentional about identifying and writing them down.

Set a timer

My partner and I began our process with some borrowed time on a layover heading back from a conference. We took out our journals, set a timer for 10 minutes, and began writing down our core values. The ideas took form quickly because they had already been part of our DNA. This allowed us to make a rough list of values that resonated with decisions we had made in the past—values like “innovation,” “trust,” and “responsibility.” We’ve since refined these somewhat general ideas using an exploratory process that includes all members of the team, but setting a timer during this early phase forced us not to overthink things, and helped us to get started with ideas that came more from the gut than from the brain.

Take inventory

Then we did a whiteboard audit of our current and past clients to look for trends and to test how our values applied (or not). We paid particular attention to those clients we were most excited about. Through this process we identified a pattern of partnerships with people who work to strengthen our cities (urban planning, local food, bicycle advocacy, waterfront improvement), create knowledge (universities, education initiatives), improve people’s health (advocacy, research), and enhance our quality of life through arts and culture (museums, photography collectives, arts organizations).

Get outside perspective

We followed this up with a workshop led by a friend, which allowed us to further explore our values, strengths, and goals. This led us to create a series of active phrases about our work, including we are part of a community and we dream. These phrases now form the basis of the P’unk Guide, which includes our shared values and principles to run the business we all want to work in. As part of our ongoing reflection, we have also evolved the guide to include “guiding metaphors.” One of those metaphors is based on the notion of sailing upwind: “The shortest distance is not always the quickest.”

Building a framework

Becoming more aware of our values helped us make more intentional choices with prospective projects, but it didn’t necessarily provide us with a framework for quickly evaluating potential projects and relationships. That came when we read the book Drive, by Daniel Pink.

In Drive, Pink talks about the principles of autonomy, mastery, and purpose as powerful motivational elements for modern workers. For Pink, jobs that require deep thinking and applied analytical skills are not easily simplified to an assembly line process, and measuring productivity within a certain time limit isn’t an effective way to track their success. Rather, people who have the freedom to work in the way they see fit (autonomy), who are constantly honing their skills (mastery), and who understand the intention of their work (purpose) perform best in these positions.

There was no turning back. We used Pink’s principles as a starting point to create our own framework for evaluating potential relationships with partners and clients: the AMP scoring system. Evaluating projects through our new lens of autonomy, mastery, and purpose helped us ask whether or not that relationship would motivate us to do good work and help us live up to our ideals of trust, innovation, and impact.

The AMP score

In considering a new project, we take the time to get to know the client, with the goal of determining whether we will we be truly pumped (or “AMPed”) if the project is a success—not because the project is done, but because of the impact it has on something we care about. Then we score it, using a series of questions in each of the three categories. Each category then gets a score from 1 to 5, and we total up the results at the end.

Autonomy

  • Will this client respect us?
  • Will they seek our counsel?
  • Will they give us the space to bring our experience and knowledge to impact the project positively?
  • Do they trust us?
  • Basically, will they let us do what we do best in service to their project?

It is always a good sign when a potential client is genuinely interested in understanding how you work. If they take the time to ask you about how and why you make decisions, they’re telling you that they respect your experience, and are seeking a partnership that is productive and valuable. It is an especially good sign—usually a 4 or 5 on the AMP scale—if they listen carefully and ask thoughtful follow-up questions, since it indicates that they are genuinely interested in working towards a relationship built on understanding and trust.

Mastery

  • Is there space to practice our skills and grow as craftspeople?
  • Is there time to do the project well?
  • Does the client value a job done well?

For example, if a client emphasizes how simple a project is by saying something like, “All we need is to code this page. It is simple. How long will that take? A week?” or “Do we have to do the research? Couldn’t we just copy the design of this website?” then they may not respect the work we do—especially if this perspective persists after we explain the value of a thoughtful and measured approach. In this scenario, we would rate the mastery score a 1 or 2, since they seem more interested in rushing than in allowing us the time to do thoughtful and considered work.

Purpose

  • Do we understand the purpose of their project?
  • Equally important, do they understand the purpose of their project?
  • What kind of impact will this project make?
  • Do we feel aligned with that impact?

For example, sometimes a webmaster at a larger organization contacts us, but is only interested in technology. This is common when an organization puts the management of their website solely in the hands of their technical or IT team, instead of seeing it as a communication tool for the entire organization. When this happens, we try to bring leadership into the process and educate them before signing an agreement—but if that cannot be done, the project would score low on the purpose scale. It is particularly difficult to walk away from an organization that is doing work we find interesting and aligns well with our values, but we have learned that when leadership isn’t involved, the project is not likely to be a success.

What does all this actually look like? Practically speaking, we post a message with details about all potential projects in Basecamp, and each member of the team has the opportunity to respond with their thoughts and personal AMP score for the project. Once everyone has weighed in, we compare scores, looking for a total of 12 or higher. We will consider lower scores, but not below 10.

This system creates a paradigm where we are asking ourselves if there is a compelling reason we should work with a client, rather than just looking for a reason not to work with them. That distinction may seem subtle, but it has powerful implications, supporting a proactive versus reactive culture.

Intentional projects are successful projects

This may seem one-sided and only to our benefit, and maybe an unsustainable business practice. However, being thoughtful and intentional in this way has turned out to be a great thing for our clients as well. Once we commit to a project, we are truly committed. We even share how this benefits them in our project proposals:

Most projects will hit bumps in the road that will require persistence and dedication to see it to a successful completion. With that in mind, our philosophy is to only work on projects where there is a strong alignment of values. We truly care and you can see the difference in that approach.

They get that. It resonates with them because anyone that has some business experience knows that unanticipated problems will inevitably rear their head at some point. Because we took the time to evaluate the project using the AMP score, we’ve already decided that we are committed to the success of the project, and any bumps in the road will be tackled with gusto and passion. This knowledge gives our clients greater confidence in working with us.

What’s good for the goose…

As a consultancy, much of our “everyday” revolves around clients and projects. This is the lifeblood of our company and sets the tone for our interactions. If we are not in sync with our clients, our lives can turn miserable pretty quickly.

We always cared about our work and had good relationships with our clients before, but intentionally pursuing projects that align with our business values has brought a higher level of investment and internal motivation from all members of our team. We have become true partners in the success of our clients’ projects.

A lucrative project that doesn’t align well with your values is like the siren’s call to start your day with a sugary doughnut. Of course, getting sidetracked is easy. Using a framework to evaluate potential business has become a way to stay on course—a way to make healthier choices.

When we made compromises in the past, it never resulted in great work and often had other unintended consequences, like burning out our team. The attitudes you develop working on a project you don’t care about can carry over into all of your work. Our framework has helped us stick to our guns and not work on even a single project where we don’t see an alignment of values.

Ideals are good for business, too

The AMP system has had a positive ripple effect throughout our company. Everyone knows that we make decisions based on our shared and agreed upon values. We have chosen not to pursue work that does not garner a high AMP score, and we have even stopped working with clients when they turn out not to allow us to live up to our ideals. In the short term, we may have turned down some potential business, but in the long term we have increased our revenue while working with clients we respect. That growth comes from our participatory culture, where everyone is invested in and focused on their projects—leading to happier clients and a lot more word-of-mouth referrals and opportunities.

This is not something that can happen overnight. If you want to live up to your business ideals, you have to take the time to authentically identify your values, the things you care about. You also have to commit to the ongoing tending and cultivation of those values in your organization. It is not a “set it and forget it” scenario. At P’unk Ave, we think about this regularly, and especially during our quarterly “State of P’unk” and twice-yearly retreats. Building in those rituals, as well as creating tools like the AMP score, helps us stay on track in creating the kind of company we want for ourselves.

But the commitment is worth it. Once you have a framework for evaluating the kinds of people you want to work with, you have power: the power to say “no”—and the power to do the work you know matters.

 

From: A List Apart: The Full Feed

Link
UX/UI
Last year the digital agency I work for, Bluecadet, started a website redesign project for The Franklin Institute—a renowned Philadelphia science museum undergoing the largest expansion in its history. My colleagues and I were excited because not only were we getting to work with an iconic local institution, but the project represented an opportunity to incorporate a number of techniques into our responsive web design practice: atomic design, HTML wireframes, style tiles, element collages, and front-end style guides. We envisioned a series of quick prototypes that lent momentum to a harmonious back-and-forth between design and development. We felt like this was an opportunity to overhaul the way we created for the web, from start to finish.

And then we got stuck.

We couldn’t figure out where we would fit all of these new techniques into our preferred way of working. I don’t think we’re alone in this. The way we create for the web is changing so rapidly that if you’ve attended enough conferences or read enough books and blogs these last couple of years, you may feel like we did: excited but a little overwhelmed, and worried that your organization is the only one that hasn’t yet adopted the expert-approved way to create for a device-agnostic web.

There’s a seductive danger present whenever you see someone else outline their way of working, however. It’s easy to take their process as a rigid, universal truth. The trouble is, you and your team aren’t like everyone else—you have different strengths and weaknesses. Borrowing someone else’s process wholesale ignores the fact that it probably took them lots of fumbling to get to that point, and it’s going to take plenty of experimentation on your team’s part to figure out what works for you.

So perhaps the solution isn’t to transplant someone else’s guidelines in an attempt to fix the entire thing all in one shot. Maybe there’s a way to take the same iterative spirit of these new techniques and apply it to the overall workflow itself. To prototype your workflow, in other words. In some ways, it’s a mental trick—a way of giving yourselves permission to try things, even if you’re unsure of the outcome. It also lowers the stakes to a comfortable level: if we mess this up, we’re still okay.

What follows, then, isn’t a tidy recipe or a formula. It’s a collection of observations I hope will help you re-cast workflow change as an ongoing process of small, imperfect steps.

Technique is easy, talking is hard

It’s easy to get fixated on the benefits of specific tools and techniques, and to assume that those benefits are self-evident to everyone. But over the course of the past year, it’s dawned on us that meeting the demands of our multi-device web is less a problem of technique, and more one of communication. Sometimes people just need to understand why you want them to change how they work.

Prior to the Franklin Institute project, my colleagues and I had been pooling all of these new techniques, but we instinctively focused on pieces that affected our part of the process. Designers and developers were talking and dreaming—but largely within the echo chamber of their respective disciplines. So when it came time to kick off the project, we had to have some hard conversations about how new techniques would work for us as an entire team, and sometimes we were downright skeptical of each other’s suggestions. On more than one occasion we asked each other: “That’s great, and it works for that agency, but how would that work here?”

You will probably need to make your case differently for each person on your team, then. If you’re a designer, it could mean explaining to your developer teammate that you would like to start breaking things into a design system so that you don’t have to do 20 different iterations of the same page layout. For developers, you might have to convince your boss that a style prototype will be the best way to present a site to your client.

Whatever the rationale, realize that change represents a very real cost (at least in the short term) to your teammates’ time and comfort, and their skepticism may be their reaction to that cost, rather than to the less-immediate benefits you say will follow. Focusing on the why instead of how can help balance those two competing forces.

Limit your focus

As of this writing, Bluecadet has 22 full-time staff members. That’s just big enough to make it hard to work on intricate, shifting process details at a company-wide level. So we’re starting small, at the project level, instead of trying to craft a monolithic process that gets handed down from above.

Look at the projects you have on the horizon. Think about the portions of your workflow that you want to improve, and pick just one of those things to introduce into your project. Why just one? It allows you enough space to experiment without endangering your project.

A mentor of mine once told me that programming (and especially programming for the web) boils down to reducing the number of “unknowns” on a project to a manageable number. One is fine, two is a stretch, and three is asking for trouble. If you think exploring HTML/CSS wireframes could have a positive impact on your work, introduce just that one thing. Most projects have enough built-in friction without adding or changing multiple processes at the same time.

For the Franklin Institute project, we ended up deciding that the added wrinkle would be a front-end style guide. It wasn’t the biggest thing, but it was one small step that we thought could have a big benefit without affecting our schedule.

We made this decision based on two factors—factors that might be helpful as your team thinks about what that “one thing” could be:

  • A good idea that didn’t quite work in the past: we had created a static style guide for a previous project that had quickly become outdated and was ultimately discarded. But we still thought the idea had merit. So when you gather as a team, think about past good ideas that might have stalled, and whether they could work if you approached them differently.
  • (A little) experience mixed with (a lot of) enthusiasm: a new front-end developer joined our team, and he had already been experimenting with different style-guide generators like Barebones and Pattern Lab. More importantly, he was excited about building one. Does someone have something they’ve been testing on a personal project, or that they’ve used successfully at a previous job? If so, you’re already halfway there—you might just need to figure out how to make space for it.

Align your tools and techniques with your team

One of the recurring discussions we have at our studio is: “Should our designers learn markup and start doing some of this design in the browser?” We’ve heard a lot of persuasive arguments for it, but in the end, we decided that the main focus should be how to get our designs into the browser earlier in the process, instead of who should be doing that work.

This led us to try pairing designers and developers early on in a project, and having the developer create markup that “waterskis” behind the designer’s sketches and Photoshop explorations. We’ve found that doing it this way takes advantage of our team’s individual strengths. It also means that our developers are providing feedback that makes it into design iterations while they are still malleable.

We’re currently in the middle of a redesign project for a literary magazine, and we’ve found that the rough HTML/CSS mockups created by our developer helped us pose the right questions to our team’s designer. Giving our designer a specific problem to solve (“These titles take up too much space at narrow widths”) allowed her to judge the problem in the context of the entire design. She could then explain what she was trying to accomplish visually, and even find solutions that extended beyond the immediate issue we were trying to solve. She’d look at the screen while we squished the browser back and forth, and then say something like, “If you move the titles below the photos this whole problem goes away.” Stepping away from dogmatic ideas of who should be doing what allowed her to focus on doing what she did best, which was solving visual problems.

Distinguish between internal and external needs

When you start moving things around, you may start producing deliverables that are important, but only for an internal audience. That might be because they’re of limited use to the client, or they simply may not be mature enough. Managing expectations is as important as trying a new technique, so if the client is going to see something new, you’ll have to invest time preparing them for what they will receive—especially if it’s not how they’re used to working.

For a current project we are producing HTML/CSS wireframes to get an idea of how long they actually take to make. Since we don’t know (yet), the first rounds of client deliverables are still going to be static wireframes done in Photoshop. If we feel like the HTML/CSS prototypes are mature enough, we will introduce them to the client in the final round.

As you work, then, give yourself enough room to adjust: what if it takes twice as long to produce that wireframe? What if the client is resistant to parallel wireframe and design conversations? What if the thing you’ve produced has value, but only if accompanied by other deliverables?

Focus on products, not presentations

One of the things we’ve had to do was clarify the ultimate goal. This seems obvious: “We’re making a website.” But if your process is anything like ours, you actually spend a lot of time making anything but a website. Mostly you make pictures of a website.

Recently, while working on a beta build of a website, we found out that the majority of our client’s team members were using older versions of Internet Explorer and Firefox. Those people were surprised to see something that differed from the comps they’d been presented earlier in the process.

That experience taught us a lot. Setting client expectations is one way to avoid those surprises, but we’re also slowly agreeing as a team: the browser is the final arbiter of what we do, so let’s stop shoving it to the end of the line. The components of our process need to support the final product at every step of the way.

Put your process prototype on the agenda

It’s easy to nod and agree on something: “We’re going to do this!” But when you get immersed in detail work, it’s just as easy to forget that one new thing you all agreed to put in the mix. So task someone with making sure that you revisit your process prototype repeatedly. This might mean you start meeting more frequently. We’ve found it helpful to have official meetings, but our hope is that eventually we start doing this in a less-structured way, choosing to meet informally when we feel the need to discuss something.

If you’re working on a project-based team, remember to share what you’re doing with other groups. For example, on a recent project, we implemented modular content blocks that could be reordered as needed, inspired by a post by Christopher Butler of Newfangled. We then showed what we were doing to a colleague, and she integrated some of what we learned into her next project. She also had some incisive questions for us that helped us improve the content-authoring experience for our client.

By sharing with others, everyone wins: your colleagues will pick up your new skills, and you’ll be forced to clarify your goals and assumptions.

Iterate your workflow (play the long game)

When you’re reworking your process, it’s good to keep a running log of the things (both good and bad) that you encounter with each new change you introduce:

  • Did something take more (or less) time than you expected?
  • Were there people who were negatively affected by the change?
  • How did the client react? If you’ve worked with them before, were they receptive to change?

By breaking things into focused pieces, you’ll be able to evaluate how effective they were. You can keep the stuff that worked, and refine (or throw away) what didn’t. Having a forum to share those pieces is important, too—at Bluecadet, we’ve made sharing lessons from completed projects with one another a regular part of our monthly all-staff meeting.

Over the course of three separate projects, we’ve now field-tested:

  • Atomic/modular content and layout
  • Front-end style guides
  • HTML/CSS wireframes

Here’s the thing: each of those things that we tried? We’ll probably do them just a little bit differently the second time around, because of all the data we gathered from the first go-round. If we had sat around until we were sure about The New Way of Doing Things, well, we’d still be sitting around today.

One of the things I’m most proud of is that by working piece-by-piece, we’ve pushed our workflow forward while being honest with our clients. One of our internal guidelines is that our clients shouldn’t be bankrolling our workflow remodeling project—our fine-tuning should result in tangible internal benefits for us, but, more importantly, a better product for our clients.

Try something new, now

As I finish writing this, we’re trying out yet another thing that we hope to add to that list: HTML/CSS prototypes as a design deliverable. Maybe they will replace static comps, or simply accompany them—we don’t know yet. But it’s okay that we don’t know. By the fall, we’ll probably be building things far differently than we are right now, informed by the experimentation we’re doing piece-by-piece along the way.

I hope that this encourages you and your team to take some small steps, too. Get together and talk about the parts of your workflow that can be improved, pick one thing to try together, and figure out where you can make space for it. Like us, you’ll probably never be able to draw a line on the calendar and say, “That’s when we started doing things the right way.” But you’ll find yourself much further along—one thing at a time.

 

From A List Apart: The Full Feed

Link
UX/UI, Web Design

Today, at the Super Bowl for Google news, Google I/O, the company rolled out the latest version of its mobile OS, Android L, which is almost entirely predicated around the final step in its amazing design evolution: a formalized, unified design language across all their products, platforms, and devices called “Material Design.”

Last year, we realized that Google had unofficially embraced the humble index card across their apps. This year, under their Material Design thesis, they’ve taken this idea to extremes. Cards are no longer just generic windows that fit inside any interface. Cards are the interface, sewn together like an elastic, patchwork quilt. They appear on screen with depth (thanks to liberal, but tasteful, use of drop shadow), and enable constant, seamless transitions to anything you want to do. Tap an email, a card grows. Tap it again, a card shrinks. And on top of all this virtual paper, Google has constructed precanned animations that sprinkle another layer of color and physics wherever you touch.

Matias Duarte on Stage at Google I/O 2014

As Android lead designer Matias Duarte demoed it on stage, he explained that it moved with the physics of card stock, but also splash with your touch, like “ink rippling in a pond.” He clearly put it better than I can, though I’d add that Android‘s core UI has long been cleanly designed, but was always a bit cold. Material Design adds a bit of human warmth back to the equation.

What’s potentially most interesting about Material Design is that Google is opening up all of these tools and animations in their new Android L software development kit. That means, not only is Google using these cards for their apps like Gmail, any developer can adopt this interface technology into their apps. Elements like Android’s buttons will now have rippling ink effects built right in.

Material Design in L Preview

And furthermore, Duarte teased that Google’s software was smart enough to intelligently rearrange text and photo interfaces you may have already built, padding out white space, clarifying text, and even creating a UI color palette based around a company’s logo or photos an app contains–and then rearrange all of this UI appropriately for a phone, tablet, Chrome browser, or smartwatch. (Though, it’s worth noting, when Google actually showed off an Android Wear smartwatch on stage, a lot of the more beautiful card animations were missing, probably in favor of devices that have less graphics processing power than your phone or laptop.)

The software is just being made available to developers today as a release preview, and will be available to the masses in the fall. So just how smart Google’s design algorithms are, and how flexible Google’s Material Design thesis proves to be across apps beyond Google’s, is still unclear.

Gmail App, before & After

But one thing is certain: Google’s thesis on design is finally coming together. And even though Jon Wiley–lead designer for Google Search–told me that Google wouldn’t be presenting a design thesisfor all developers to follow at I/O, that appears to be exactly what they’ve done.

To Google, Material Design is the new way to design.

 

Original Article from fastcodesign.com

Link
UX/UI, Web Design
Video games have come on miles since the days of perching at the end of the sofa in our living room avidly clutching a Playstation control and racing Crash Bandicoot repeatedly down the same strip of the Great Wall of China. They’ve come on so far in fact that the kids of today don’t even need controls, apps, or to download any software. They don’t even need to be kids, for Pete’s sake!

The revolution I’m referring to is Racer, the game which has just won gold at Cannes Lions, which allows you to race cars across multiple screens – be they androids, iPhones or tablets, without any faff whatsoever. It’s pretty innovative, relying solely on the internet and the use of the Chrome browser to provide smooth playing. With music by Giorgio Moroder and beautifully slick visuals, it looks to be the new Crash Bandicoot. Watch the behind-the-scenes video below for all of the real techy lowdown.

  • 1

    Racer (still)

  • Racer-2

    Racer (still)

  • Racer-1

    Racer (still)

Link
Other, Typography

License: All Rights Reserved. 

I share a workspace with Pat Snavely of Partly Sunny and we talk about soccer. A lot. Leading up to the World Cup we’ve been wondering how many lunches will be spent at a bar. We looked up game times online, used the ESPN FC app, flipped through World Cup magazines, and searched for charts that show all of the matches together. But most are overwraught and don’t deliver the pertinent information immediately. For example, seeing match times in the context of Groups isn’t helpful at all.

We needed something that we could post on the wall and easily reference. Time and day, that’s what matters. Except for one game, the Group Stage is based around four start times — for us in Seattle it’s 9am, 12pm, 1pm and 3pm. So they’re the boldest element on the page. The rest is straightforward; the Groups are there for reference, and room was left to fill in scores by hand. This was designed for Tabloid (11×17) and fits well on Super B (13×19).

Titling Gothic was chosen because it has 49 styles, something that is extremely helpful for schedules and charts. And sure makes it easy to whip up something like this at the last minute. Here I used 4 widths: Condensed, Narrow, Normal, and Wide. As well as 4 weights: Light, Regular, Medium, and Bold.

This is available for download, with four time zones included (PDF, EDT, UTC/GMT, and CET). If you see any errors, let me know and I’ll update it. After the Group Stage, I’ll make a schedule for the Knockout stage.

Now excuse us, we have some soccer — football — to watch. And some beers to drink.

License: All Rights Reserved. 

License: All Rights Reserved. 

 

 

Original Article

Link
Other

Prototypo is an open-source online typeface editor: start shaping a complete typeface using sliders, then refine spacing and outlines.

The project still has 14 days to go on Kickstarter at the time of writing this article, and it has already been funded.

In my opinion, the main problem with this project is that it looks a bit too promising and will probably end up to be disappointing (I hope I’m wrong though). The other problems, the legions of horrible typefaces that will be designed with the tool it it’s that simple to use.

9b68713e0badbda679d4743f989

3e474fd062480d047b6e5b25d62

7b7c074747c56ca59d7d0ba4569

Link