KnowYourUser

Source: A List Apart

With over three years of responsive web design in our collective portfolios, we now have a solid set of design patterns for making websites work on small devices. But what about larger screens?

It’s become common for sites to employ a liquid design for smaller breakpoints, which allows the content to expand and contract as necessary to make the most of the available screen width. At the opposite end of the spectrum, however, many of those same sites have a maximum width of 960 pixels or so, which can leave a lot of unused pixels on a contemporary desktop display.

Designing for the big screen can be complicated—negative space, scale, density, and layout devices such as grids, modules, and columns can be factors in managing hierarchy and emphasis.

Large screens are also generally shaped in a wide landscape orientation, a poor fit for the traditional vertically scrolled webpage. As with smaller screens, there are a wide variety of screen sizes and resolutions—but in the case of larger screens, the differences are often magnified, ranging from ultra-light 11-inch laptops to 30-inch desktop monitors.

Given these conditions, it’s not surprising that many desktop layouts (like this one) are designed to suit a 1024×768 resolution. It’s a leftover from an earlier era, when designs were constrained to the screen resolution that was most prevalent amongst users. Today, with the majority of desktop users on screens that are wider than 1024 pixels, a maximized browser window can turn that carefully considered 960-pixel layout into a monolith in a field of whitespace.

More people are accessing the internet with a mobile device every year, and so it makes sense to concentrate budgets and timelines on creating good user experiences for smaller screens. Mobile layouts can be perfectly usable on larger devices, but the same cannot always be said for desktop layouts viewed on small screens.

But by embracing large screens, designers have the opportunity to work within a larger fold, presenting the user with more content simultaneously, lessen scrolling on longer pages, and create a richer, more expansive user experience. And by using the same practices we developed to adapt layouts to smaller screens and identifying some common patterns for large screens, we need not necessarily introduce extra cost or time to our projects.

Content challenges

As with any design, the first consideration when approaching larger breakpoints is content. Long- and short-form writing, photography, ecommerce, video, or web applications may benefit from different approaches in different ways.

Photography, search results, and other content presented in grid format are easy candidates for wide screens. Showing as much content as the screen can accommodate allows a user to quickly scan and compare results.

On the other hand, long-form reading is a challenge for wider breakpoints. Long line lengths can make it difficult to follow the text from line to line, while short line lengths can introduce a sense of jumpiness or acceleration, breaking a reader’s rhythm and pacing.

To make reading more comfortable, a designer needs to balance the width of the text column (the measure) against the size and line-height (leading) of each line of text. Classically, an appropriate count for a single column of text is seven to 10 words (Josef Muller-Brockmann) or 45 to 75 characters (Robert Bringhurst). Taken another way, Bringhurst also notes that the measure of a conventional book column is about 30 times that of the type size used, but that this number may also range from 20 to 40 times the size of the type.

Wider columns can use more line-height to make it easier to follow the text from line to line, but too much line-height can cause lines to drift apart, resembling a college research paper. Similarly, as the text size in a column grows larger, the number of lines that can be presented vertically on the screen grows smaller, increasing the need for scrolling and breaking the reader’s immersion. Simply scaling the text for larger breakpoints is a limited solution.

Working with long reads

The Great Discontent demonstrates how a site can use art direction to adapt to larger screens without necessarily filling every single pixel in the browser window. Each article expands its feature art at the top to fill the viewport, resulting in a striking full-bleed effect upon first viewing. The main content of each article is set in a relatively narrow main column, but sidebars, pull quotes, and inline art expand beyond the central column. Breaking the content out of the main column creates an asymmetrical shape which complements the full-width artwork at the top—creating the illusion of a full-window experience without compromising legibility. Large images like these can come at a cost, though, as a balance between image quality and the overall page weight needs to be considered.

The recently relaunched Roger Ebert site deals with large breakpoints by simply scaling up the maximum width of the page and the page elements proportionately. In theory this might work, but the execution is not entirely successful. Elements such as headers scale up vertically as well as horizontally, meaning the amount of content displayed within the fold is drastically reduced. Inexplicably, main body copy on the more text-heavy pages does not scale up in proportion to the other page elements, so it seems dwarfed in comparison, in addition to being set in a size that is too small for the main column measure.

Using the extended margins of larger screens for related or tangential content, such as Medium’s comments layout, is another idea that seems well suited for long-form publishing. When the main content column is maximized on smaller screens, it moves aside to reveal the comments area; on larger screens, the comments are revealed in the available margin space.

I’ve also always liked Grantland’s use of the lower right column for footnotes, which takes advantage of wider screens while maintaining focus on a readable central column. Photographs, figures, asides, quotes, and other related content can be extended out into the margins of wider viewports. This allows a designer to extend the vertical grid outward to create variety while preserving the flow of the main text.

Newer CSS features like columns and regions could be useful tools to enhance long-form reading on wider screens. CSS-based columns are now supported across most new browsers, and could be deployed within sections of an article to maximize screen usage while maintaining a good measure for text readability. If you have a large screen, for example, see my column-based demo of this article.

As a progressive enhancement measure, older browsers that do not support these features could be restricted to a single column of appropriate measure.

Chunking content on large screens

Breaking content into chunks allows users to quickly and efficiently process information on content-heavy pages, and it’s a natural fit for responsive designs, because it allows content to be easily stacked hierarchically or arranged in columns for different breakpoints.

The advantage of this technique for large screens is that each chunk or band of content can use a different layout to optimize for legibility or impact. A good example of this approach is the Manchester City Council site, which uses different groups of modules in restricted widths together with a full-width photography chunk to create impact and emotion. The layout adapts fluidly to different viewports while retaining an appropriate width and layout for the content of each chunk.

Juliana Bicycles uses a more visual approach to content chunking, combining horizontal bands with flexible tiles to create a rich and compelling responsive site that also scales to large screen widths. Navigation is recast as a full-window carousel with rich background photographs. Content is presented in modular blocks, and gutters that appear between tiles are removed in tablet and mobile screen sizes. A paper texture background fills in empty tile spaces and also helps fill out the screen at the largest breakpoint. Using image-based modules in this way can be expensive from a bandwidth perspective, but is a great way to get the user to navigate quickly by showing rather than telling.

Tiling modular content

The obvious advantage of a big screen is the ability to see a lot of content at one time.

With collection-based content such as photos, tiling can be an effective way to to fill large screens. We see this every day when searching Google Images—the results spread out to fill the viewport, presenting a large variety to choose from in a single scan.

Pinterest also uses a tiling layout for images, with the addition of text and whitespace to mitigate what could be an overly busy layout. On larger screens the image preview modules seem to tile indefinitely. For a collection site, where the user experience is about quickly collecting and marking favorites, filling the viewport with thumbnails makes it easier to scan and creates a satisfying sense of fullness.

Uniqlo uses a wide, tiled-image layout that also looks well-designed and spacious. Items are chunked together with large headers acting as bumpers between sets to add breathing room. Tiling the products across a wide area allows shoppers to quickly compare items visually. At the same time, the whitespace, model photos, and variety in scale add refinement to the overall look and feel and help reinforce the point that design is an important differentiator in Uniqlo’s product line.

Neither Pinterest nor Google Images are responsive or adaptive sites—they both employ a separate site for mobile users. Uniqlo is also only adaptive to larger screens; small screens get the narrowest desktop layout. While these sites may not be complete models for responsive design, we can look at them as examples for expanding this type of content.

Graphic techniques

Another interesting technique for larger screens is based more on classic print design, rather than restructuring or manipulating content to fill the browser.

Institut Choiseul confines the content of each page to a structured grid in the center of the window, but effectively stakes out a large screen presence by extending a field of color from the logo and main page content outward toward the left edge of the viewport. The Back to Top link appears in the lower left corner of the viewport when the page is scrolled, a small touch that stakes out the entire window for the page. The strong grid and large fields of color give the site a sober, logical tone that evokes the International Design style of the 1950s and 1960s.

Kanselarij der Nederlandse Orden has a similar style, with asymmetrical bands of color that provide the background to a centered flexible grid. Because the grid expands as a percentage of the total window width, the content also plays a part in filling the screen, but the boxy color fields add a level of sophistication to what is otherwise a fairly ordinary layout.

Small effects such as a color tone or texture in the background, or removing boxy lines from the edges of a layout, can go a long way toward creating a sense of completeness in the maximized window. Creative use of asymmetry instead of skinny, tower-like layouts can also keep readers from drowning in white margins.

Finally

By simply extending common techniques for adapting content to smaller breakpoints, we can see plenty of opportunities for larger breakpoints as well. Sites that use a strong grid will have an easier time of it, as a well-structured grid should have no problem expanding into a wider space.

Obviously the most important consideration in any design is the content, and so that must be the basis for any effort to expand a design to fill a wide screen. For long reads, it’s more important to create a good rhythm and flow so that the text can be read without distraction. For photographs or graphics, space and scale contribute directly to impact. Government and service-oriented sites must provide easy access to tasks and information. Ecommerce sites need to make it easy for consumers to evaluate and purchase products. A layout’s density should reflect the site’s tone—more density for a more active experience, less for a slower, more thoughtful tone. Much like framing a photograph, filling out the viewport can make a design seem bigger and bolder, just as framing a design in generous whitespace can make it seem more elegant or precious.

It may be true that desktop users have the luxury of resizing the browser window if all that whitespace makes them uncomfortable, unlike users of smaller devices. It may be also be true that not all desktop users browse with large or full-screen windows. But as with mobile, we shouldn’t make assumptions about which devices are used to view our content now, and especially in the future. Large screens, in some cases, can provide both enhanced usability for users and a richer palette for designers. It’s up to us to take advantage of these expanded borders.

Read the full article

Source: A List Apart

When it comes to building apps, we often assume our users are very much like us. We picture them with the latest devices, the most recent software, and the fastest connections. And while we may maintain a veritable zoo of older devices and browsers for testing, we spend most of our time building from the comfort of our modern, always-online desktop devices.

For us, a connection failure or slow service is a temporary problem that warrants nothing more than an error message. From this perspective, it is tempting to think of connectivity, mobile or otherwise, as something that will solve itself over time, as we get more network coverage and faster service. And that works, as long as our users stay above ground in large, well-developed—but not overly crowded—cities.

But what happens once they descend into the subway, board a plane, travel over land a bit, or go live in the countryside? Or when they stand in the wrong corner of a room or simply find themselves part of a huge crowd? Our carefully constructed app experiences become sources of frustration, because we rely so fully on that ephemeral link back to the servers.

This reliance ignores a fundamental truth: Offline is simply a fact of life. If you’re mobile, you’ll be offline at some point. It’s okay, though. There are ways to deal with it.

Taking stock

Web apps used to be completely dependent on the server: it did all the work, and the client just displayed the result. Any disruption in your connection was a major problem: if you were offline, you couldn’t use your app.

That problem is solved, in part, by richer clients, where more of the application logic runs in the browser—like Google Docs, for example. But for a proper offline-first experience, you also want to store the data in the front end, and you want it to sync to the server’s data store. Happily, in-browser databases are maturing, and there are an increasing number of solutions for this—like derby.js, Lawnchair, Hoodie, Firebase, remotestorage.io, Sencha touch, and others—so solving the technical aspects is getting easier.

But we have bigger, and much weirder, fish to fry: designing apps and their interfaces for intermittent connectivity leads to an abundance of new scenarios and problems.

There are of course a few precedents for offline-first UX, and one of them is especially prevalent: your email inbox and outbox. Emails go into your outbox, even when you’re offline. Once you’re online, they get sent. It’s simple and unobtrusive, and it just works.

For incoming email, the experience is similarly smooth: once you reconnect, new emails from the server appear at the top of your inbox. In between, you’ve got a more or less complete local copy of all your emails up to this point, so you’re never stuck with an empty app. All three scenarios (client push fails, client pull/server push fails, availability of local data when offline) are well handled.

Emails, as it turns out, are easy. They’re un-editable, easily listable, text-based, and conflict-free, and the notion of having local copies is already well established with email users. But there are so many more possibilities. How do we handle these scenarios, for example, in a collaborative drawing app? What if we’re not dealing with immutable items like email, but map markers with changing attributes, midi tracks, issues, tasks, or actions? The browser is the new application runtime of choice, and if we take Atwood’s Law into account (“Any application that can be written in JavaScript, will eventually be written in JavaScript”), what other previously unheard-of things will we be doing in browsers in a couple years? Do we really still want to treat offline as an edge case and resort to failing features, irritatingly empty templates, and panicky error messages?

The experience of using a website or app when offline should be a lot better, less frustrating, and more empowering. We need the UX equivalent of responsive web design: a strong catalog of guides and patterns for a disconnected, multi-device world.

The connectivity lifecycle

Most web apps have two connectivity-related points of failure: client push and client pull/server push. Depending on what your app does, you might want to

• communicate or explicitly hide the connectivity state and its changes (for instance, a chat client would inform users that any new messages typed are not sent immediately);
• enable client-side creation and editing features even when offline, and reassure users that their data is safe and will eventually make it to the server (think of a photo sharing app that lets you take and post pictures under any circumstances); and
• disable, modify, or possibly even hide features that cannot work offline, instead of letting people fail at using them (imagine a “send” button that knows when to turn into a “send later, when online” button).

Other issues arise when the connectivity state changes during use, e.g., the server wants to push a change to the object or view that the user is currently looking at, or even editing. This would require you to

• notify the user that newer, possibly conflicting data is available; and
• give the user a pleasant conflict-resolution tool, if necessary.

Let’s take a look at some real-world examples.

Problematic connectivity scenarios

Losing local data

Going offline while using Google Docs in a browser other than Chrome can be quite frustrating: you can’t edit your document. And while reading is still possible, copying parts of it isn’t. You can’t do anything with your text or spreadsheet—not even copy it to another program to continue working there. And yet, this is actually an improvement over past versions, where a large overlay would notify you of the offline state and prevent you from even seeing your work.

This is a common occurrence in both native and web apps: data you’ve only just accessed suddenly becomes unavailable when you lose your connection. If possible, apps should retain their last state and make their data available, even if it can’t be modified. This requires keeping local data to fall back to if the server can’t be reached, so your users are never stranded with an empty app.

Treating offline like an error

Stop treating a lack of connectivity like an error. Your app should be able to handle disconnections and get on with business as gracefully as possible. Don’t show views you can’t fill with data, and make sure error messages hit the right tone. Take Instagram: when a person can’t post a photo, Instagram calls it a failure—instead of reassuring the user that the image isn’t lost, it’s just going to be posted later. No big deal. You might even want to reword your interface depending on the app’s connection state, such as turning “save” into “save locally.”

You might sometimes need to block whole features completely, but more often, you won’t need to. For example:

• If you can’t update a feed, show the old feed and a corresponding message. Don’t throw out the old data, then attempt to fetch the new data, fail, and end up with an empty, useless view.
• If your app lets users create data locally, let them do so, and inform them it will be saved and sent later. Optionally, ping them for confirmation before you do send it. Again, Instagram comes to mind: it knows where a photo was taken, but, when offline, can’t ask Foursquare what the place is called. Instagram could, however, ask users to come back to a picture and pick the Foursquare location once they’re online.

Handling conflicts

If your app offers collaborative editing or some other form of simultaneous use on multiple devices, you will likely create conflicting versions of objects at some point. We can’t prevent this, but we can provide easily usable conflict-resolution UIs for people who might not even understand what a sync conflict is.

Take Evernote, whose business is heavily based on syncing notes: conflicts are resolved by simply concatenating both versions of the note. On anything longer than a couple of lines, this requires an inordinate amount of cognitive effort and subsequent editing.

Draft, on the other hand, has managed to make conflict resolution between collaborators simple and beautiful. It shows both versions and their differences in three separate columns, and each difference has an “accept” and an “ignore” button. Intuitive and visually appealing conflict resolution, at least for text, is definitely possible.

Detailed change-by-change resolution isn’t always necessary. In many cases you just need to provide a nice interface for highlighting differences and allowing the user to choose which version wins in this specific conflict.

There are other types of conflicts awaiting us, however, and many of them won’t be text based: disputed map marker positions, bar chart colors, lines in a drawing, and endless other things we haven’t even thought of yet.

But not all technical problems need technical solutions. Consider two waiters with wireless ordering devices in a large, multi-story restaurant. One is connected to the restaurant’s server. The other is on the very top floor, where his connection fails temporarily. Both wait tables that order the same bottle of rare, expensive wine. The offline waiter’s device cannot know about this conflict. What it can do, however, is be aware of the risk of conflict (low stock number, its own offline state) and advise the waiter to give an appropriate reply to the table (“Oh, exquisite choice. Let me see if that’s still available”).

Preempting users’ needs

In some cases, apps can preemptively take low-overhead action to give users a better experience later. When Google Maps detects I’m on wifi in a different country than usual, it could quickly cache my surroundings for the likely case of later offline or roaming use.

In many cases, however, content is too large to preemptively cache it—for example, a video from a news site. In these cases, users must make the explicit decision to locally sync, which would require them to download the video to their device and view it in a different application. Any context that video had online—like related information or relevant comment threads—is now lost, as is the opportunity for users themselves to comment.

Refreshing chronological data

All of these examples were client push, but there’s the server push aspect as well: what can we do when the server updates a user’s active view, and pushes data that can’t conveniently be added to the top of a list? Chronological data often causes this problem.

For example, if you use iMessage on several devices, messages are sometimes displayed out of chronological order when syncing. iMessage could sort them in the correct order—they are timestamped, after all—but instead it shows them in the order in which they arrived on the device. This makes them highly noticeable, but is also terribly confusing.

Imagine the more intuitive way of doing it: messages are always shown in chronological order, regardless of when they arrive. This sounds more sensible at first, but means you may have to scroll back in time to read a message that just arrived, because it was sent in response to something much older. Worse, you might not even notice it, since it pops into existence somewhere you’re probably not looking.

If you display data chronologically and the sequence of the data itself is meaningful, like in a chat (as opposed to email, which can be threaded), offline capabilities pose a problem: the most recently transmitted data is not necessarily the newest, and may therefore appear somewhere users won’t expect it. You could maintain context and sequence, but your interface also needs to let users know where in time the new content is.

Preparing for diverse data types

Many of these examples are text based, and even if they aren’t (like a map marker), some of them could conceivably have a text-based helper (like a list of map markers next to the map), which can simplify sync-related updates and notifications.

However, we know the amount, diversity and complexity of web applications will continue to increase, as will the types of data that are handled by their users. Some will be collaborative, most will be usable on multiple devices, and many will introduce new and exciting syncing issues. It makes sense to study them, and to develop a common vocabulary for offline scenarios and their solutions.

Offliners Anonymous

As we started asking developers from all over the world about these issues, we were surprised at how many people suddenly opened up about their tales of offline woe—realizing they’d had similar problems in the past, but never spoken to others about them. Most battled it out alone, gave up, or put it off, but all secretly wished they had somewhere to turn for offline app advice.

We don’t need to be anonymous, though. We can look to John Allsopp’s call, 13 years ago, to embrace the web as a fluid medium full of unknowns, and to “accept the ebb and flow of things.” Today we realize this extends beyond screen sizes and aspect ratios, feature support and rendering implementations, and holds true even for our work’s very connection to the web itself.

In this even more fluid and somewhat more daunting reality, we’ll all need each other’s help. We should make sure that we, and those who follow us, are equipped with reliable tools and patterns for the uncertainties of the increasingly mobile world—both for the sake of our users and for our own. Web development is complicated enough without wasting extra time reinventing wheels.

To help each other and future generations of designers, developers, and user interface experts, we are inviting you to join the discussion at offlinefirst.org. Our eventual goal is to create an offline handbook that includes UX patterns and anti-patterns, technology options, and research on user’s mental models—creating a repository of knowledge to draw from and contribute to, so our collective efforts and experiences don’t go to waste.

For now, we need to hear from you: about your experiences in this field, your knowledge of tools, your tips and tricks, or even just your challenges. Solving them won’t be easy, but it will improve our users’ experiences—wherever and whenever they need our services. Isn’t that why we’re here?

Read the full article

Source: A List Apart

Today is a great day. A new potential client has come knocking on your door, and they’d like to consider you for a project. Thrilling as it may be, your excitement quickly turns to anxiety as you realize that the next thing they want to know is “how much will it cost?”

Here begins the great struggle of web business development. You need to know what you’re building before you can know how much it costs to build it. But accurately mapping out the scope of a project could take weeks of focused effort. That’s probably not something you can give away whenever you get a request for a quote. So what do you do? Make up numbers and hope you’re on target? Undershoot and you may land a job that cripples your business. Overshoot, and you may unnecessarily send that new client packing.

Fortunately, it doesn’t have to be this way. Defining the challenges, solutions, and strategies for the project to come is some of the most valuable work you will do for your client. Not only is that time worth paying for, but the resulting deliverables will be critical to the success of the project, regardless of who they hire to complete the next phase.

Let’s look at how we can structure a pre-project research phase that will ensure that—on completion—everyone’s ready to hit the ground running with design and development. By the end, our new client will know more about their organization and web project than ever before, and you’ll be able to create a much more accurate budget for subsequent work.

Let’s do it! What are we doing?

So there it is. That unread email with the subject line Fancy Organization Request for Proposal.

It’s a website redesign: no surprise there. And, wait—oh miraculous day—they even told you their budget. They have $100,000, which is enough money to do some real stuff. But what stuff do they want? Poring over the pages, you realize quickly that it’s not so clear. Some of the requirements they state, in fact, seem vague, strange, or misguided. As much as these folks are hoping you can take their RFP and give them a precise quote and a plan of action, you know in your bones that you need more clarity—and clarity rarely comes easily.

Smaller is better

So instead of putting together their requested $100,000 proposal, what do I do? I put together a $20,000 one. This, my friends, is unexpected. Gutsy, even! This is not what they’ve asked for. The gall. The nerve. The chutzpah!

Alright, let’s acknowledge this right now: there is risk involved in this approach. If I turn in something that looks entirely different from what the client is requesting, they cannot compare apples to apples with the other proposals. This may not fit into their (potentially rigid) RFP process. Our proposal may get tossed out in the very first round, just for being different.

On the other hand, this may be exactly what makes us stand out. Rob Harr from Sparkbox has a terrific line that I’ve started using myself: “I’m going to embrace the fact that I’ll know more about your project tomorrow than I do today.” For some clients, that may be a refreshing dose of honesty and creative thinking. And I don’t know about you, but those are the clients I really want.

One caveat: though we’re holding off on producing an accurate second phase budget until later, we still need to address the general cost of future work in some way. It’s a good idea to take a stab at a ballpark range for the second phase, with the understanding that it’s a bit of a shot in the dark. That way everyone will at least have a sense of the magnitude of a second phase, and can plan accordingly.

So what are we actually pitching in this smaller project? Well, it’s the first part of the bigger project, naturally. Depending on the nature of the project, it may require different tasks and deliverables. But we’ll likely include things like meetings, interviews, information architecture recommendations, branding analysis, a copywriting style guide, a content audit, wireframes, and style prototypes/style tiles. Whatever we end up doing, we’ll compile all of the research and conclusions we draw in the specification document, which is the central deliverable we provide at the end of the phase.

When putting together a standalone research phase, the trick is to focus on work that will help you more clearly define the project. That way you’ll have a well-formed plan for a second phase, and can provide the client with a much more accurate budget for that subsequent work.

What does everyone get out of this?

In all likelihood, I don’t need to sell you on research. Understanding what we’re going to design and build before we begin means we can create better things, more efficiently. But why, when we have the opportunity to sign a big contract, would we opt to sign a small one? Why, indeed!

It’s good for clients

You know what’s scary? Handing a big wad of money to a stranger. That’s what a big initial contract is like for a potential client. A smaller introductory research project lets a new client wade in ankle-deep before the big plunge.

Not only are they making a smaller commitment of time and money but—by the end of the project—they’ll know if you’re a good fit for them. If everyone decides to part ways at the end of this phase, they’ll still have valuable deliverables to help them jump-start the project with a different team.

It’s good for you, too!

And this goes for you, too. There’s nothing worse than signing on for a year-long project with a new client, and then realizing a month in that it’s a bad match. The pre-project project lets you assess the relationship in a low-risk environment, and decide if it’s worth continuing.

From a business development perspective, this initial research project has a lot of appeal, too. Sure, you’re not landing a big ticket contract just yet, but bear with me on this one.

Proposing is time-consuming

If you’re a small company like ours, you likely don’t have a dedicated sales person. This means that responding to RFPs is costly, and before long you’ll have to start making some hard decisions about which proposals you can afford to write, and which you can’t.

The nice thing about research phase proposals is that they tend to be very similar from project to project. By definition, these proposals don’t include very much about the specifics of the work being done, so a chunk of well-written boilerplate in your proposal gets you a lot more mileage. Investing less time with each proposal means that you can respond to more proposals. Wider net, less effort—without sacrificing quality. Yay!

Your feet, their door

In my experience, when you don’t have a proven track record with a client, selling a $10,000–20,000 project is a lot easier than selling a $100,000–200,000 project. This little research project helps you get a foot in the door with that new client, and prove your worth without resorting to something devaluing like spec work.

A clearer future

As this phase is nearing completion, you’ll be able to create a much more accurate budget for phase two. Because your research has generated a well-informed project definition, there will be much less guesswork, and a far greater understanding of the project’s requirements. In effect, you’re getting paid to write the best proposal ever. And you should be! The insight into the project and organization you’re providing is vital work that ensures that no one will be jumping into the project blindly and simply hoping for the best. That’s because now you’ll have something that every project desperately needs, but surprisingly few actually have. You’ll have a plan.

Read the full article

Source: A List Apart
» Device RAM and image megapixel limit

Andy Clarke experimented with the max decoded size for images on iOS and found that file size isn’t the only thing to keep an eye on.

Read the full article

Source: A List Apart

Typekit changes the way you design websites by making it easy to use stunning, real fonts—no more browser defaults. Add a line of code to your pages, and choose from hundreds of quality typefaces. It’s simple, reliable, and makes for a more beautiful web. Try it out for free.

Read the full article

Source: A List Apart

One of the many beauties of working with Sass is how easy it is to get organized. In the past, importing different CSS files wasn’t good practice and in fact made for more HTTP requests. With Sass, you can have many different partials which allow you to isolate styles in a logical way.

What is a partial? The Sass Documentation explains it pretty well:

Organizing Sass files in this way, then allows you to create a sort of “table of contents” with a global.scss. I create about 13 partials; one for forms, icons, type, mixins, images, etc. Each partial has only the styles that belong, making styles easily findable.

stylesheets/
  _bits.scss
  _forms.scss
  _icons.scss
  _images.scss
  _mixins.scss
  _type.scss

Once you’ve created your files, you then import them into your master stylesheet. I like putting comments to remember what each partial is doing.

/*
VARIABLES
---------------
Setting up variables. Bringing in Colors and Spacing.
--------------- */

@import "bits";

/*
BASE STYLES
---------------
Setting up the base. Bringing in Type, Images, Forms, and Icons.
--------------- */

@import "type";
@import "images";
@import "forms";
@import "icons";

Organizing yourself like this can be difficult to adopt at first, but I can’t tell you how much time I’ve saved. On large projects, knowing where to look is half the battle. Gone are the days of 3000 line stylesheets. Instead we can work in small, specific, and more importantly, manageable files.

Read the full article