Blog | 1910 Design & Communication

[wordsby1910]

New Website.

New site, new projects, new everything! — http://weare1910.com

[wordsby1910]

On the Grid

Drawing icons is a big part of most digital design projects today. With the variety of screen sizes, resolutions, and devices these will eventually end up on, most of us tend to use vector shapes that can be exported in a number of sizes and formats depending on the application.

If the icons are a set, rather than a stand-alone app-icon for example, we also tend to use grids to guide our design and make the entire set look and feel consistent. Even if what we create is vector based and scalable, these grids are often based on pixels since it’s preferable to know exactly how the lines will render in different sizes.

Common practice when drawing icons on pixel grids seem to be to match the stroke width to full pixels to avoid unnecessary anti-aliasing and ensure lines are as sharp as possible. While this may sound good in practice it has a downside that we often find neglected. While straight lines does indeed look sharper, all curved or diagonal lines will still be anti-aliased and therefore create an inconsistent look of lines within the icon.

This will result in two things. Diagonal and curved lines will, because of the anti aliasing, look both thicker and lighter that the straight ones. Since not using anti-alias at all isn’t really an option, what we prefer to do is to use stroke widths of half pixels, to make sure all lines are anti-aliased and therefore rendered equal in terms of thickness and brightness.

Obviously all this won’t matter as much in a few years, when all screens have passed the retina border. But for the time being most people still use low resolutions screen on their desktops and laptops, which makes this relevant for some time still. As always feel free to discuss with us on Twitter!

[wordsby1910]

Your Logotype is Not a Story

A common request when working on identity systems for clients is a logotype that somehow explains the business – what it is or does. While this doesn’t have to be a bad idea, it’s by no means necessary for a brandmark to be successful. In fact, many of the worlds most iconic marks and symbols do not tell stories at all, but rather provide an easily recognizable signature to the story told by the brand as a whole.

The reason for this, as with all communication, is that the more we are asked to remember – the quicker we'll move on and forget all about it. Logotypes become iconic because they are quick to identify, simple to recognize and easy to remember, rather than because they are impressive narrative illustrations.

Think about any successful brandmark and you’re probably so familiar with it’s looks you could easily draw it on a piece of paper. While having been exposed to it thousands of times will undeniably contribute to this, chances are you would have been able to do it just as well the very first time you saw it. Simple things are easy to remember, and anything that can’t be quickly replicated with a few quick strokes is probably asking for too much.

Another factor to consider is that we'll have a much harder time filling a brandmark or symbol with meaningful association over time if the story is already told by the mark itself. Let your brand tell the story by delivering on what it promises, and it’s mark will as a result of this become a trustworthy sign of approval.

Providing your products and services are first class they will be remembered on their own merit. The logo and brand will help people recognize that it’s you, but will only ever be perceived as creative or trustworthy as the business behind it. It’s not about getting people to understand every part of your company. It’s about reminding them that you’re there, and what you actually bring to the table.

[wordsby1910]

Better Game UI’s in Less Time

Not long ago, user interfaces for games was something left until the very end of the development cycle. A month or so before shipping someone suddenly panicked and screamed: “We need to do the goddamn menu!”, after which a programmer (and if things were really lucky – an artist) were reluctantly assigned the task of “just doing something that works”.

Somewhere along the road things happened and around 2007, when ‘Colin McRae DIRT’ came out, most people in the industry started realizing that properly thought out and well executed UI’s were no longer a luxury but a necessity. Suddenly the need for specialized designers, programmers, and even dedicated producers was a fact.

Today, most AAA-studios have at least a few people working full-time with UI. Having been two of those for a large portion of our careers we’ve come to see the ups and downs of how UI-production is often handled. The following is, what we believe, a very simple way of getting better UI’s done in less time, and with a substantially happier team doing it.

Don’t start too soon.

The average development cycle of a AAA-game is somewhere around the 2-3 year mark. While there are games with highly complex multi-platform UI’s like Battlelog for Battlefield that without hesitation needs a considerable amount of time and people to get right, most games are actually pretty straightforward. What many studios do however, is to hire someone full-time on-site for up to three years working on something that could well have been executed in only a portion time.

The fact is that in most games, there simply isn’t much to design UI for before half of the production is done and the game mechanics and features have settled in. Sure, you can do some rough planning and visual concepts, but for the average title that  can be done in a month or two. This misconception leads to one of two potential scenarios. Either the UI team has very little to do for the first half of production, or they start forcing premature designs into the game that will have to be redesigned and re-implemented later on.

A better way of doing this is to accept the fact that most game UI’s aren’t really that complex. There is a menu with settings, perhaps a lobby, a shop and some additional screens, the in-game HUD, and maybe some intro and end credits, but this is by no means a three year effort. If you start too soon you’ll not only waste a considerable amount of time and money, but (even worse) you’ll end up with a team lacking motivation from having to repeatedly redesign and re-implement things that could have been avoided. Don’t start until the game is ready enough to actually design a UI for.

Budget for two.

Another benefit of waiting until around halfway though production before getting started is that, assuming you still have the full budget, you can use this on two people instead of one. The way it’s usually done is that the designer is tasked to work on the UI full-time, whereas the programmer is not. Many times a randomly assigned gameplay-programmer is split between their regular tasks and implementing the UI, which is  not optimal neither in terms of time or motivation.

Using half of the budget on hiring a dedicated programmer will not only ensure that there is enough resources for all implementation, tweaking and polish that is necessary to get the desired quality, but also that the entire process is much quicker and more rewarding for everyone involved.

Let them own it.

So, you’re halfway through production and the features and mechanics of the game work as intended. You’ve got a designer and a programmer. Now what? It’s actually quite simple. You leave them to it – letting them do their job.

What many people in the industry fail to realize is that UX- and UI-design is quite a specialized set of skills, very different from what is often falsely grouped together as just “art” or “graphics”. While the majority of 3d-artists, concept artists, and art directors are masters of shape, color and illustration, they often do not have the experience within usability, layout and typography that the UI designer has.

Obviously there needs to be discussions with the game designers regarding what is needed for the game, and with the art director regarding the general intent of style. There might also be initial planning laid out together with producers to set up a realistic schedule to work with, but letting the people with the right knowledge make the important decisions is as critical to a well functioning and good looking UI as letting the programmers actually program the game.

Then of course, you also get the added benefit of ownership, leading to higher motivation, better results, and a generally happier team as a bonus. So go ahead – save some time and money, make some people happier, and ship a game that works and looks better. We’re here to tell you it’s easier than you think.

Summary.

1. Don’t start too soon. Wait until the game mechanics and feature set have settled in.

2. Budget for two people during half of the project, instead of one person all the way through.

3. Let them own it. Results will be better and everyone will be happier.

—

Jonas Salvador and Stellan Johansson have worked in-house for EA Dice, Splash Damage, Grin, Starbreeze, and Epic Games, and as external UI & UX consultants for major game developers since 2006. They have worked on UI’s for 15+ games, like Bulletstorm, Syndicate, Battlefield 4, SNOW, and many others.

[wordsby1910]

Between the Lines

Since we wrote about grids and how we work with typography, a few people have asked us why we tend to place text between (or sometimes straight on) the baselines, rather that on top of them. There are two main reasons for this which we’ll quickly explain below.

The first reason is that if we want to keep a consistent vertical distance between objects above and below the text while still aligning those objects to the grid, placing the text on top of the lines would make this impossible, as shown below.

Placing the text between the lines instead will keep the vertical distances equal, or at even multiples of the baseline height, while still keeping all objects perfectly aligned to the grid.

The other reason is that if we use buttons or similar objects which contains text within the shape, we want both the shape itself and the text inside of it to align to the grid. By placing the text either between (or straight on) the baselines this can be achieved, as shown in the first column, while placing it on top of the baselines would either misalign the text from the button shape (column 2) or the button shape from the grid (column 3).

That pretty much sums it up! If you have any input on the subject, feel free to drop us a mail or give us a shout on twitter. The original article on grids from typography can be found here.

[wordsby1910]

A Typographic Approach to Email

In our on-going pursuit of trying to improve readability and usability of digital products and services, one thing that’s always struck us as odd is the way typography of email applications has been left untouched since the early days of the internet. Even modern applications released in the post-pc era mostly forget about this, focusing on new ways of managing your inbox, various forms of social integration, or on the appearance of a flat surface instead.

We believe that email is about two things. Reading and writing. And that focusing on these two is what would truly move email to where it deserves to be. What we propose here is not a redesign of any particular email application. Neither is it a suggestion as to how we think an email application should be visually styled. It’s an experiment of how email could be functionally improved through the use of better typography, based on the premise that structure is more important than surface.

Opening up most of todays email applications, desktop or web, will look somewhat like the image pictured below. Just as in the case of our previous article, the text here really isn’t optimized for comfortable reading. There was a time when 12 px fonts made sense because pixels were bigger and screens smaller, meaning text would render larger and lines would automatically break at somewhat appropriate lengths. But 15 years later the pixels are smaller, the monitors bigger, and digital typography needs to catch up with technology in order to be functional again.

Since we prefer to construct our grids based on typography rather than the other way around, we set out by defining the body with a 700 px wide paragraph set in Minion Pro 22 px. This gives us a perceived text size similar to that of a regular printed textbook, and a comfortable measure of around 12 words per line. We also add a simple baseline grid based on the leading of 32 px. The baseline grid will help us keep the vertical rhythm while adding the rest of the elements and buttons.

Secondly we start to add additional elements like reply, delete, and compose buttons, sender and date, to complete the functions of a basic read view while still keeping the actual text as the main focus area.

Going further we add a basic inbox to the left, following the same baseline grid and vertical rhythm. The top menu is separated from the rest of the UI, and the text view is horizontally centered with fluid margins on each side that would either shrink or grow depending on the screen size.

Putting our experiment in context, we quickly realize that without having sacrificed much, we are presented with an email experience that is highly familiar, yet more approachable and certainly much easier to read.

The write view uses the same open typography as the read view, staying clear of boxes and input fields and focusing completely on the words instead. Quoted text is automatically greyed out to not interfere with the rest of the text.

Readability is especially improved for longer texts who benefit even more from being properly formated. Scaling down the window would wrap the text to shorter lines. Making it bigger would not make the lines longer, but rather increase the margins, keeping the lines at 75 characters.

An approach like this could be applied to virtually any email application, native or web, and would work no matter what visual style was ultimately desired. Applications like iA Writer, and websites like Medium have already taken the first big steps towards bringing interactive type up to date with technology, and we can’t wait to see how other text oriented products and services will follow along, focusing on what really matters.

[wordsby1910]

Recommended Reading

We love to read about design and have earned much of our theoretical knowledge through books and online recourses. This list contains some of our favorites, that have in one way or another affected how we run our business or practice our craft.

On the Craft

- Logo Design Love (David Airey) - The Design Method (Eric Karjaluoto) - Thinking With Type (Ellen Lupton) - Graphic Design Referenced (Bryony Gomez-Palacio) - Graphic Design School (David Dabner) - Graphic Design Rules (Peter Dawson) - Less and More (Klaus Klemp) - Dieter Rams - As Little Design as Possible (Sophie Lovell)

On the Business

- How To Be a Graphic Designer (Adrian Shaughnessy) - How to Think Like a Great Graphic Designer (Debbie Millman) - Work for Money, Design for Love (David Airey) - Studio Culture (Adrian Shaughnessy) - Insanely Simple (Ken Segall) - Steve Jobs (Walter Isacsson) - Jonathan Ive (Leander Kahney) - Everything I Know (Paul Jarvis)

Online Resources

- Logos, Flags, and Escutcheons (Paul Rand) - A Reader First Internet (Paul Jarvis) - Responsive Typography: The Basics (Oliver Reichenstein) - Butterick’s Practical Typography (Matthew Butterick) - Thinking With Type (Ellen Lupton)

[wordsby1910]

A Readable Wikipedia

We love Wikipedia. The idea of a constantly updated knowledge base where everyone is welcome to read and contribute is staggering, and we dip into this great pool of content on an almost daily basis at 1910. However, having spent the last three years learning more about typography has made us aware of its limitations. While Wikipedia is great for learning, it simply does not provide the best possible environment to do this.

While big parts of the internet have gone through an amazing journey in terms of typography these last years, Wikipedia's reading experience is still stuck in the 90's. We wanted to take a few days and propose a direction through which Wikipedia could move forward, focusing on articles and reading without necessarily having to change too much of what it is and should continue to be.

We do realize that this humble experiment of ours is uninformed, and that what we propose here would have to be reconsidered if done for real, but for the sake of getting the point across we wanted to focus on one thing only – making Wikipedia readable.

Wikipedia Today

Wikipedia today is great in terms of content but not in terms of presentation. For a site with the core purpose of delivering articles to readers, the reading experience just isn’t what it should be. The text is too small, the lines are too long and the leading is too tight. Pictures are tiny and the general layout includes a lot of visual noise that distracts you from the actual reading.

Constructing the Grid

As always when constructing grids we like to start with the typography. We wanted to push the content to the center, use a readable text size, fix the measure at an appropriate length, increase the leading, make the images bigger, and provide a proper structure with adequate white space and an easy to follow hierarchy.

On desktop, we wanted to make room for the main text paragraph and an additional side-bar including images and tables to the right. We also wanted a design that could easily adapt from desktop, to tablet and mobile, without requiring additional apps or mobile versions of the site.

Starting with the text size (as described in detail here) we eventually ended up with an 8 column grid where the body would span over the first four. The grid would then scale down to 4 columns on tablets and 2 columns on phones, moving side-bar content below it’s corresponding paragraphs.

The Desktop

With the primary body column and side-bar already in place, populating the rest of the page was relatively straight forward. We wanted the header to focus on search and made the old side-menu horizontal and placed as a secondary header, not to distract you from the reading while scrolling down the page.

The rest of the elements were basically left unchanged apart from being adjusted to fit the new grid and structure. The typefaces and colors were left similar. The result is a page that still looks and feels very much like Wikipedia, but is much easier to read.

The Tablet

The tablet version scales the grid down to four columns, moving the side-bar content below it’s corresponding paragraphs. Other than that not much is changed. The second header menu is hidden and accessible from a menu button in primary header.

The Phone

The mobile version scales the grid down to two columns with shorter lines to keep the text at a readable size. Secondary sections are closed by default and oped by tapping the headline, to make articles less heavy to scroll through.

Conclusion

While these sketches are far from feature full, we do think they provide an insight into how big of a role typography and grid structure plays in making the web accessible today. This is the Wikipedia we ourselves would like to use, and we greatly look forward to see how Wikipedia will develop in the following years, in regards to making the site more pleasant to read.

[wordsby1910]

Purpose as Process

Approaching new projects we have a set of core beliefs guiding us through the process. We believe that design needs to pinpoint and focus on a primary goal in order to be effective. We believe that unnecessary distractions weaken the experience of a product and diminishes it’s perceived value. We believe that design needs to be structured from the ground up to serve a primary idea in order to become truly intuitive and long lasting.

Ultimately we believe that what’s best for the user is what’s best for the product, and that faithfully letting design focus on the single most important goal is the best way to achieve this. Following these beliefs, here is a simplified rundown of our basic process for approaching new projects at 1910.

1. Determine the function of the product from a user standpoint. This might not always align with what the client initially asks for so make sure to fully understand what actual value the service has to offer before automatically following the brief.

2. Remove or minimize all unnecessary elements, leaving only what’s vital to accomplish the essential goal. This might again not follow the initial brief so make sure to always explain and motivate why such a thing is important.

3. Construct a foundation (i.e. a grid) tailored to keep the essentials in focus and the path to accomplishment as short as possible. Removing steps means removing frustration and in the end, keeping users happy.

That’s really all there is to it. A happy user is a loyal user, and loyal users are what ultimately build brands. If you’d like to read more about how we go on constructing our grids you can do so here.

[wordsby1910]

Grids From Typography

Since we started 1910, we’ve developed somewhat of a standardized method around how we work with grids and typography for digital applications. Following is a brief summary of our process that is under constant development as we go along.

1. Text Size

The base premise is to let the content shape the grid rather than the other way around, so we usually start by deciding on a text size for the body copy. We approach this not as a visual or stylistic decision, but rather one based on functional requirements such as reading distance (between user and device) and type of application (webpage, desktop UI, console UI, etc.).

The idea is that since text is meant to be read, our task is to make the process of reading it as comfortable as possible. This means that whoever reading should be able to do so without straining their eyes or having to move closer to (or further from) the screen. Just as if they were comfortably reading a book from their favorite armchair.

To achieve this we need to make sure that the perceived text size (taking the viewing distance into account) rather than the metric text size makes sense. The further away from the screen, the bigger the text needs to be. Currently we find between 16 and 22 px to be reasonable for desktop webpages, 12 to 16 px for complex desktop UI’s, and 22 to 28 px for console UI’s.

If in doubt, just grab a camera and take a picture of the text from the desired viewing distance and compare this to a picture of a page from a regular textbook taken from 30 to 40 cm away. Alternatively hold the book somewhere between yourself and the screen while keeping one of your eyes closed. If the digital text is smaller than the printed one you’ll want to go bigger.

2. Measure

The second thing to do is deciding on a preliminary measure for the body. We’ll come back to set the exact value later (matching it to our columns), but before we can calculate the columns we’ll need to know roughly what kind of measure is desired. At least to the point of knowing if the text will span over one or more columns, or (in the case of certain user interfaces) if it won’t be running long at all, but rather consist of single words, buttons or labels.

For reference, optimal measure for running text is usually considered to be between 55 to 75 characters for one column, or between 40 to 50 characters for multiple columns.

3. Leading

When the text size and measure of the body is set we’ll go on to establish an appropriate leading and baseline height for the grid. Assuming we’re dealing with text longer than just a few words we’ll want the leading and baseline height to be somewhere between 1,25 to 1,5 times the size of the body copy.

The basic rule is that longer measures need higher leading. At an ideal measure of 65 characters we like the leading to be around 1,5 but parameters such as the x-height of the typeface will also affect how the leading is perceived. When working digitally it might also be a good idea to go for even pixels that are more easily divided.

4. Base Units

Following the baseline height we’ll reuse the same value to divide the grid into equal squares vertically. These base units will be hidden as soon as the grid is done and are merely helping us make sure that the columns and gutters are even multiples of the baseline height, and not some random value that would complicate things later.

Doing this, building the horizontal rhythm from the same value as the vertical rhythm, has many advantages. Gutters will be the same in both directions, and square or circular content sized to the width of a full column will automatically end up on the baselines as well, rather than between them which would offset the rhythm from the grid.

5. Columns & Gutters

The final step is to set the columns and gutters. Providing we know how many we’ll need (we usually aim for as few as possible without compromising the layout) we then use the base units as a guide to size them properly. Gutters are usually 1 or 2 base units wide and columns are sized to match our preliminary measure as close as possible.

Summary

This method of building grids from typography, and typography from viewing distance, is how most of our projects are structured. The same basic principles, letting the content shape the grid rather that the other way around, is equally applicable even when text isn’t the primary content type. In the end, it’s all about the content, and about removing barriers to maximize impact.