Jul
31
Source: A List Apart
Do you manage many Drupal sites at once? The pros don’t use Multisite for that anymore. Learn how what they do instead to streamline workflows when you download this ebook. “I Can’t Believe It’s Not Multisite,” featuring 6 case studies from top agencies, companies, and universities.
Jul
30
Source: A List Apart
The stream—that great glut of ideas, opinions, updates, and ephemera that pours through us every day—is the dominant way we organize content. It makes sense; the stream’s popularity springs from the days of the early social web, when a huge number of users posted all types of content on unpredictable schedules. The simplest way to show updates to new readers focused on reverse chronology and small, discrete chunks, as sorting by newness called for content quick to both produce and digest. This approach saw wide adoption in blogs, social networks, notification systems, etc., and ever since we’ve flitted from one stream to another like sugar-starved hummingbirds.
Problem is, the stream’s emphasis on the new above all else imposes a short lifespan on content. Like papers piled on your desk, the stream makes it easy to find the last thing you’ve added, while anything older than a day effectively disappears. Solely relying on reverse-chronology turns our websites into graveyards, where things pile up atop each other until they fossilize. We need to start treating our websites as gardens, as places worthy of cultivation and renewal, where new things can bloom from the old.
The stream’s focus on the now isn’t novel, anyway. Old-school modes of publishing like newspapers and magazines shared a similar disposability: periodic updates went out to subscribers and were then thrown away. No one was expected to hang onto them for long.
Over the centuries with print, however, we came up with a number of ways to preserve and showcase older material. Newspapers put out annual indexes cataloguing everything they print ordered by subject and frequency. Magazines get rebound into larger, more substantial anthologies. Publishers frequently reach into their back catalogue and reprint books with new forewords or even chapters. These acts serve two purposes: to maintain widespread and cheap access to material that has gone out of print, and to ensure that material is still relevant and useful today.
But we haven’t yet developed patterns for slowing down on the web. In some ways, access is simpler. As long as the servers stay up, content remains a link away from interested readers. But that same ease of access makes the problem of outdated or redundant content more pronounced. Someone looking at an old magazine article also holds the entire issue it was printed with. With an online article, someone can land directly on the piece with little indication of who it’s by, what it’s for, and whether it’s gone out of date. Providing sufficient context for content already out there is a vital factor to consider and design for.
You don’t need to be a writer to help fix this. Solutions can come from many fields, from targeted writing and design tweaks to more overarching changes in content strategy and information architecture.
Your own websites are good places to start. Here are some high-level guidelines, ordered by the amount of effort they’ll take. Your site will demand its own unique set of approaches, though, so recombine and reinvent as needed.
Emma is a travel photographer. She keeps a blog, and many years ago she wrote a series about visiting Tibet. Back then, she was required to travel with a guided tour. That’s no longer the case, as visitors only need to obtain a permit.
The most straightforward thing to do is to look through past content and identify what’s outdated: pieces you’ve written, projects you worked on, things you like. The goal is triage: sorting things into what needs attention and what’s still fine.
Once you’ve done that, find a way to signal their outdated status. Perhaps you have a design template for “archived” content that has a different background color, more strongly emphasizes when it was written, or adds a sentence or two at the top of your content that explains why it’s outdated. If entire groups of content need mothballing, see whether it makes sense to pull them into separate areas. (Over time, you may have to overhaul the way your entire site is organized—a complicated task we’ll address below.)
Emma adds an <outdated> tag to her posts about her guided tour and configures the site’s template to show a small yellow notification at the top telling visitors that her information is from 2008 and may be irrelevant. She also adds a link on each post pointing to a site that explains the new visa process and ways to obtain Tibetan permits.
On the flip side, separate the pieces that you’re particularly proud of. Your “best-of” material is probably getting scattered by the reverse-chronology organization of your website, so list all of them in a prominent place for people visiting for the first time.
I hope that was easy! The next step is to look for old content you feel differently about today.
When Emma first started traveling, she hated to fly. She hated waiting in line, hated sitting in cramped seats, and especially hated the food. There are many early blog posts venting about this.
Maybe what you wrote needs additional nuance or more details. Or maybe you’ve changed since then. Explain why—lead readers down the learning path you took. It’s a chance for you to reflect on the delta.
Now that she’s gotten more busy and has to frequently make back-to-back trips for clients, she finds that planes are the best time for her to edit photos from the last trip, catch up on email, and have some space for reflection. So she writes about how she fills up her flying time now, leaving more time when she’s at her destination to shoot and relax.
Or expand on earlier ideas. What started as a rambling post you began at midnight can turn into a series or an entire side project. Or, if something you wrote provokes a big response online, you could gather those links at the bottom of your piece. It’s a service to your new readers to collect connected pieces together, so that they don’t have to hunt around to find them all.
Hopefully that takes care of most of your problematic content. But for content so dire you’re embarrassed to even look at it, much less having other people reading it, consider more extreme measures: the act of culling, revising, and rewriting.
Looking back: maybe you were completely wrong about something, and you would now argue the opposite. Rewrite it! Or you’re shocked to find code you wrote one rushed Friday afternoon—well, set aside some time to start from the ground up and do it right.
Emma started her website years ago as a typical reverse-chron blog, but has started to work on a redesign based around the concepts of LOCATIONS and TRIPS. Appearing as separate items in the navigation, they act as different ways for readers to approach and make sense of her work. The locations present an at-a-glance view of where she’s been and how well-traveled she is. The trips (labeled Antarctica: November 2012, Bangkok: Fall 2013, Ghana: early 2014, etc.) retain the advantages of reverse-chronology by giving people updates on what she’s done recently, but these names are more flexible and easier to explain than dates and timestamps on their own. Someone landing directly on a post from a trip two years ago can easily get to the other posts from that trip, but they would be lost if the entries were only timestamped.
If the original structure no longer matches the reality of what’s there, it’s also the best case for redesigning and reorganizing your website. Now is the time to consider your content as a whole. Think about how you’d explain your website to someone you’re having lunch with. Are you a writer, photographer, artist, musician, cook? What kind? What sorts of topics does your site talk about? What do you want people to see first? How do they go deeper on the things they find interesting? This gets rather existential, but it’s important to ask yourself.
If it’s really, truly foul, you can throw it out. (It’s okay. You officially have permission.) Not everything needs to live online forever, but throwing things out doesn’t have to be your first option when you get embarrassed by the past.
Deploying the internet equivalent of space lasers does, I must stress, come with some responsibility. Other sites can be affected by changes in your links:
Everything we’ve done so far applies to more than personal websites, of course. Where else?
Businesses have to maintain scores of announcements, documentation, and customer support. Much of it is subject to greatly change over time, and many need help looking at things from a user’s perspective. Content strategy has been leading the charge on this, from developing content models and relationships, to communicating with empathy in touchy situations, to working out content standards.
Newspapers and magazines relentlessly publish new pieces and sweep the old away from public view. Are there opportunities to highlight material from their archives? What about content that can always stay interesting? How can selections be best brought together to generate new connections and meaning?
Museums and libraries, as they step into their digital shoes, will have to think about building places online for histories and archives for the long term. Are there new roles and practices that bridge the old world with the networked, digital one? How do they preserve entirely new categories of things for the public?
No one has all the answers. But these are questions that come from leaving the stream and approaching content from the long view. These are problems that the shapers and caretakers of the web are uniquely positioned to think about and solve.
As a community, we take pride in being makers and craftsmen. But for years, we’ve neglected the disciplines of stewardship—the invisible and unglamorous work of collecting, restoring, safekeeping, and preservation. Maybe the answer isn’t to post more, to add more and more streams. Let’s return to our existing content and make it more durable and useful.
You don’t even have to pick up a shovel.
Jul
30
Source: A List Apart
Interactive user interfaces are a necessity in our responsive world. Smaller screens constrain the amount of content that can be displayed at any given time, so we need techniques to keep navigation and secondary information out of the way until they’re needed. From tabs and modal overlays to hidden navigation, we’ve created many powerful design patterns that show and hide content using JavaScript.
JavaScript comes with its own mobile challenges, though. Network speeds and data plans vary wildly, and every byte we deliver has an impact on the render speed of our pages or applications. When we add JavaScript to a page, we’re typically adding an external JavaScript file and an optional (usually large) library like jQuery. These interfaces won’t become usable until all the content, JavaScript files included, is downloaded—creating a slow and sluggish first impression for our users.
If we could create these content-on-demand patterns with no reliance on JavaScript, our interfaces would render earlier, and users could interact with them as soon as they were visible. By shifting some of the functionality to CSS, we could also reduce the amount of JavaScript needed to render the rest of our page. The result would be smaller file sizes, faster page-load times, interfaces that are available earlier, and the same functionality we’ve come to rely on from these design patterns.
In this article, I’ll explore a technique I’ve been working on that does just that. It’s still a bit experimental, so use your best judgment before using it in your own production systems.
To understand how to accomplish these design patterns without JavaScript at all, let’s first take a look at the role JavaScript plays in maintaining state for a simple tabbed interface.
See the demo: Show/hide example
Let’s take a closer look at the underlying code.
<div class="js-tabs">
<div class="tabs">
<a href="#starks-panel" id="starks-tab"
class="tab active">Starks</a>
<a href="#lannisters-panel" id="lannisters-tab"
class="tab">Lannisters</a>
<a href="#targaryens-panel" id="targaryens-tab"
class="tab">Targaryens</a>
</div>
<div class="panels">
<ul id="starks-panel" class="panel active">
<li>Eddard</li>
<li>Caitelyn</li>
<li>Robb</li>
<li>Sansa</li>
<li>Brandon</li>
<li>Arya</li>
<li>Rickon</li>
</ul>
<ul id="lannisters-panel" class="panel">
<li>Tywin</li>
<li>Cersei</li>
<li>Jamie</li>
<li>Tyrion</li>
</ul>
<ul id="targaryens-panel" class="panel">
<li>Viserys</li>
<li>Daenerys</li>
</ul>
</div>
</div>
Nothing unusual in the layout, just a set of tabs and corresponding panels that will be displayed when a tab is selected. Now let’s look at how tab state is managed by altering a tab’s class:
...
.js-tabs .tab {
/* inactive styles go here */
}
.js-tabs .tab.active {
/* active styles go here */
}
.js-tabs .panel {
/* inactive styles go here */
}
.js-tabs .panel.active {
/* active styles go here */
}
...
Tabs and panels that have an active class will have additional CSS applied to make them stand out. In our case, active tabs will visually connect to their content while inactive tabs remain separate, and active panels will be visible while inactive panels remain hidden.
At this point, you’d use your preferred method of working with JavaScript to listen for click events on the tabs, then manipulate the active class, removing it from all tabs and panels and adding it to the newly clicked tab and corresponding panel. This pattern is pretty flexible and has worked well for a long time. We can simplify what’s going on into two distinct parts:
Trying to replicate event binding and class manipulation in CSS and HTML alone would be impossible, but if we define the process in broader terms, it becomes:
In our HTML- and CSS-only solution, we’ll use radio buttons to allow the user to manipulate state, and the :checked pseudo-class as the hook to re-render.
The solution has its roots in Chris Coyier’s checkbox hack, which I was introduced to via my colleague Scott O’Hara in his morphing menu button demo. In both cases, checkbox inputs are used to maintain two states without JavaScript by styling elements using the :checked pseudo-class. In this case, we’ll be using radio buttons to increase the number of states we can maintain beyond two.
Using radio buttons to do something other than collect form submission data may make some of you feel a little uncomfortable, but let’s look at what the W3C says about input use and see if we can ease some concerns:
The
<input>element represents a typed data field, usually with a form control to allow the user to edit the data. (emphasis mine)
“Data” is a pretty broad term—it has to be to cover the multitude of types of data that forms collect. We’re allowing the user to edit the state of a part of the page. State is just data about that part of the page at any given time. This may not have been the intended use of <input>, but we’re holding true to the specification.
The W3C also states that inputs may be rendered wherever “phrasing content” can be used, which is basically anywhere you could put standalone text. This allows us to use radio buttons outside of a form.
So now that we know a little more about whether we can use radio buttons for this purpose, let’s dig into an example and see how they can actually remove or reduce our dependency on JavaScript by modifying the original tabs example.
Each radio button will represent one state of the interactive component. In our case, we have three tabs and each tab can be active, so we need three radio buttons, each of which will represent a particular tab being active. By giving the radio buttons the same name, we’ll ensure that only one may be checked at any time. Our JavaScript example had the first tab active initially, so we can add the checked attribute to the radio button representing the first tab, indicating that it is currently active.
Because CSS selectors can only style sibling or child selectors based on the state of another element, these radio buttons must come before any content that needs to be visually manipulated. In our case, we’ll put our radio buttons just before the tabs div:
<input class="state" type="radio" name="houses-state"
id="starks" checked />
<input class="state" type="radio" name="houses-state"
id="lannisters" />
<input class="state" type="radio" name="houses-state"
id="targaryens" />
<div class="tabs">
...
Labels naturally respond to click and touch events. We can’t tell them how to react to those events, but the behavior is predictable and we can leverage it. When a label associated with a radio button is clicked or touched, the radio button is checked while all other radio buttons in the same group are unchecked.
By setting the for attribute of our labels to the id of a particular radio button, we can place labels wherever we need them while still inheriting the touch and click behavior.
Our tabs were represented with anchors in the earlier example. Let’s replace them with labels and add for attributes to wire them up to the correct radio buttons. We can also remove the active class from the tab and panel as the radio buttons will be maintaining state:
...
<input class="state" type="radio" title="Targaryens"
name="houses-state" id="targaryens" />
<div class="tabs">
<label for="starks" id="starks-tab"
class="tab">Starks</label>
<label for="lannisters" id="lannisters-tab"
class="tab">Lannisters</label>
<label for="targaryens" id="targaryens-tab"
class="tab">Targaryens</label>
</div>
<div class="panels">
...
Now that our labels are in place, we can safely hide the radio buttons. We still want to keep the tabs keyboard accessible, so we’ll just move the radio buttons offscreen:
...
.radio-tabs .state {
position: absolute;
left: -10000px;
}
...
:checked instead of .activeThe :checked pseudo-class allows us to apply CSS to a radio button when it is checked. The sibling selector ~ allows us to style elements that follow an element in the same level. Combined, we can style anything after the radio buttons based on the buttons’ state.
The pattern is #radio:checked ~ .something-after-radio or optionally #radio:checked ~ .something-after-radio .something-nested-deeper:
...
.tab {
...
}
#starks:checked ~ .tabs #starks-tab,
#lannisters:checked ~ .tabs #lannisters-tab,
#targaryens:checked ~ .tabs #targaryens-tab {
...
}
.panel {
...
}
#starks:checked ~ .panels #starks-panel,
#lannisters:checked ~ .panels #lannisters-panel,
#targaryens:checked ~ .panels #targaryens-panel {
...
}
...
Now when the tab labels are clicked, the appropriate radio button will be checked, which will style the correct tab and panel as active. The result:
See the demo: Show/hide example
The requirements for this technique are pretty low. As long as a browser supports the :checked pseudo-class and ~ sibling selector, we’re good to go. Firefox, Chrome, and mobile Webkit have always supported these selectors. Safari has had support since version 3, and Opera since version 9. Internet Explorer started supporting the sibling selector in version 7, but didn’t add support for :checked until IE9. Android supports :checked but has a bug which impedes it from being aware of changes to a checked element after page load.
That’s decent support, but with a little extra work we can get Android and older IE working as well.
:checked bugIn some versions of Android, :checked won’t update as the state of a radio group changes. Luckily, there’s a fix for that involving a webkit-only infinite animation on the body, which Tim Pietrusky points out in his advanced checkbox hack:
...
/* Android 2.3 :checked fix */
@keyframes fake {
from {
opacity: 1;
}
to {
opacity: 1
}
}
body {
animation: fake 1s infinite;
}
...
If you need to support IE7 and IE8, you can add this shim to the bottom of your page in a script tag:
document.getElementsByTagName('body')[0]
.addEventListener('change', function (e) {
var radios, i;
if (e.target.getAttribute('type') === 'radio') {
radios = document.querySelectorAll('input[name="' +
e.target.getAttribute('name') + '"]');
for (i = 0; i < radios.length; i += 1) {
radios[ i ].className =
radios[ i ].className.replace(
/(^|\s)checked(\s|$)/,
' '
);
if (radios[ i ] === e.target) {
radios[ i ].className += ' checked';
}
}
}
});
This adds a checked class to the currently checked radio button, allowing you to double up your selectors and keep support. Your selectors would have to be updated to include :checked and .checked versions like this:
...
.tab {
...
}
#starks:checked ~ .tabs #starks-tab,
#starks.checked ~ .tabs #starks-tab,
#lannisters:checked ~ .tabs #lannisters-tab,
#lannisters.checked ~ .tabs #lannisters-tab,
#targaryens:checked ~ .tabs #targaryens-tab,
#targaryens.checked ~ .tabs #targaryens-tab {
...
}
.panel {
...
}
#starks:checked ~ .panels #starks-panel,
#starks.checked ~ .panels #starks-panel,
#lannisters:checked ~ .panels #lannisters-panel,
#lannisters.checked ~ .panels #lannisters-panel,
#targaryens:checked ~ .panels #targaryens-panel,
#targaryens.checked ~ .panels #targaryens-panel {
...
}
...
Using an inline script still saves a potential http request and speeds up interactions on newer browsers. When you choose to drop IE7 and IE8 support, you can drop the shim without changing any of your code.
While our initial JavaScript tabs exhibited the state management between changing tabs, a more robust example would use progressive enhancement to change three titled lists into tabs. It should also handle adding all the ARIA roles and attributes that screen readers and other assistive technologies use to navigate the contents of a page. A better JavaScript example might look like this:
See the demo: Show/hide example
Parts of the HTML are removed and will now be added by additional JavaScript; new HTML has been added and will be hidden by additional JavaScript; and new CSS has been added to manage the pre-enhanced and post-enhanced states. In general, our code has grown by a good amount.
In order to support ARIA, particularly managing the aria-selected state, we’re going to have to bring some JavaScript back into our radio-controlled tabs. However, the amount of progressive enhancement we need to do is greatly reduced.
If you aren’t familiar with ARIA or are a little rusty, you may wish to refer to the ARIA Authoring Practices for tabpanel.
First, we’ll add the role of tablist to the containing div.
<div class="radio-tabs" role="tablist">
<input class="state" type="radio" name="houses-state"
id="starks" checked />
...
Next, we’ll add the role of tab and attribute aria-controls to each radio button. The aria-controls value will be the id of the corresponding panel to show. Additionally, we’ll add titles to each radio button so that screen readers can associate a label with each tab. The checked radio button will also get aria-selected="true":
<div class="radio-tabs" role="tablist">
<input class="state" type="radio" title="Starks"
name="houses-state" id="starks" role="tab"
aria-controls="starks-panel" aria-selected="true"checked />
<input class="state" type="radio" title="Lanisters"
name="houses-state" id="lannisters" role="tab"
aria-controls="lannisters-panel" />
<input class="state" type="radio" title="Targaryens"
name="houses-state" id="targaryens" role="tab"
aria-controls="targaryens-panel" />
<div class="tabs">
We’re going to hide the visual tabs from assistive technology because they are shallow interfaces to the real tabs (the radio buttons). We’ll do this by adding aria-hidden="true" to our .tabs div:
...
<input class="state" type="radio" title="Targaryens"
name="houses-state" id="targaryens" role="tab"
aria-controls="targaryens-panel" />
<div class="tabs" aria-hidden="true">
<label for="starks" id="starks-tab"
class="tab">Starks</label>
...
The last bit of ARIA support we need to add is on the panels. Each panel will get the role of tabpanel and an attribute of aria-labeledby with a value of the corresponding tab’s id:
...
<div class="panels">
<ul id="starks-panel" class="panel active"
role="tabpanel" aria-labelledby="starks-tab">
<li>Eddard</li>
<li>Caitelyn</li>
<li>Robb</li>
<li>Sansa</li>
<li>Brandon</li>
<li>Arya</li>
<li>Rickon</li>
</ul>
<ul id="lannisters-panel" class="panel"
role="tabpanel" aria-labelledby="lannisters-tab">
<li>Tywin</li>
<li>Cersei</li>
<li>Jamie</li>
<li>Tyrion</li>
</ul>
<ul id="targaryens-panel" class="panel"
role="tabpanel" aria-labelledby="targaryens-tab">
<li>Viserys</li>
<li>Daenerys</li>
</ul>
</div>
...
All we need to do with JavaScript is to set the aria-selected value as the radio buttons change:
$('.state').change(function () {
$(this).parent().find('.state').each(function () {
if (this.checked) {
$(this).attr('aria-selected', 'true');
} else {
$(this).removeAttr('aria-selected');
}
});
});
This also gives an alternate hook for IE7 and IE8 support. Both browsers support attribute selectors, so you could update the CSS to use [aria-selected] instead of .checked and remove the support shim.
...
#starks[aria-selected] ~ .tabs #starks-tab,
#lannisters[aria-selected] ~ .tabs #lannisters-tab,
#targaryens[aria-selected] ~ .tabs #targaryens-tab,
#starks:checked ~ .tabs #starks-tab,
#lannisters:checked ~ .tabs #lannisters-tab,
#targaryens:checked ~ .tabs #targaryens-tab {
/* active tab, now with IE7 and IE8 support! */
}
...
The result is full ARIA support with minimal JavaScript—and you still get the benefit of tabs that can be used as soon as the browser paints them.
See the demo: Show/hide example
That’s it. Note that because the underlying HTML is available from the start, unlike the initial JavaScript example, we didn’t have to manipulate or create any additional HTML. In fact, aside from adding ARIA roles and parameters, we didn’t have to do much at all.
Like most techniques, this one has a few limitations. The first and most important is that the state of these interfaces is transient. When you refresh the page, these interfaces will revert to their initial state. This works well for some patterns, like modals and offscreen menus, and less well for others. If you need persistence in your interface’s state, it is still better to use links, form submission, or AJAX requests to make sure the server can keep track of the state between visits or page loads.
The second limitation is that there is a scope gap in what can be styled using this technique. Since you cannot place radio buttons before the <body> or <html> elements, and you can only style elements following radio buttons, you cannot affect either element with this technique.
The third limitation is that you can only apply this technique to interfaces that are triggered via click, tap, or keyboard input. You can use progressive enhancement to listen to more complex interactions like scrolling, swipes, double-tap, or multitouch, but if your interfaces rely on these events alone, standard progressive enhancement techniques may be better.
The final limitation involves how radio groups interact with the tab flow of the document. If you noticed in the tab example, hitting tab brings you to the tab group, but hitting tab again leaves the group. This is fine for tabs, and is the expected behavior for ARIA tablists, but if you want to use this technique for something like an open and close button, you’ll want to be able to have both buttons in the tab flow of the page independently based on the button location. This can be fixed through a bit of JavaScript in four steps:
display: none to take them out of the tab flow and visibility of the page.buttons after each label.button and trigger clicks on their neighboring label.Even using this process, it is highly recommended that you use a standard progressive enhancement technique to make sure users without JavaScript who interact with your interfaces via keyboard don’t get confused with the radio buttons. I recommend the following JavaScript in the head of your document:
<script>document.documentElement.className+=" js";</script>
Before any content renders, this will add the js class to your <html> element, allowing you to style content depending on whether or not JavaScript is turned on. Your CSS would then look something like this:
.thing {
/* base styles - when no JavaScript is present
hide radio button labels, show hidden content, etc. */
}
.js .thing {
/* style when JavaScript is present
hide content, show labels, etc. */
}
Here’s an example of an offscreen menu implemented using the above process. If JavaScript is disabled, the menu renders open at all times with no overlay:
See the demo: Show/hide example
Let’s take a quick look at how you might create some common user interfaces using this technique. Keep in mind that a robust implementation would address accessibility through ARIA roles and attributes.
See the demo: Show/hide example
See the demo: Show/hide example
See the demo: Show/hide example
See the demo: Show/hide example
See the demo: Show/hide example
As long as the interaction does not depend on adding new content to the page or styling the <body> element, you should be able to use this technique to accomplish some very JavaScript-like interactions.
Occasionally you may want to manage multiple overlapping states in the same system—say the color and size of a font. In these situations, it may be easier to maintain multiple sets of radio buttons to manage each state.
It is also highly recommended that you use autocomplete="off" with your radio buttons to avoid conflict with browser form autofill switching state on your users.
Is your project right for this technique? Ask yourself the following questions:
If the answer to either of those question is “yes,” you probably shouldn’t try to integrate radio control into your project. Otherwise, you may wish to consider it as part of a robust progressive enhancement technique.
Most of the time, you’ll be able to shave some bytes off of your JavaScript files and CSS. Occasionally, you’ll even be able to remove Javascript completely. Either way, you’ll gain the appearance of speed—and build a more enjoyable experience for your users.
Jul
30
Source: A List Apart
“Just put it up on a server somewhere.”
“Just add a favorite button to the right side of the item.”
“Just add [insert complex option here] to the settings screen.”
Usage of the word “just” points to a lot of assumptions being made. A few months ago, Brad Frost shared some thoughts on how the word applies to knowledge.
“Just” makes me feel like an idiot. “Just” presumes I come from a specific background, studied certain courses in university, am fluent in certain technologies, and have read all the right books, articles, and resources.
He points out that learning is never as easy as it is made to seem, and he’s right. But there is a direct correlation between the amount of knowledge you’ve acquired and the danger of the word “just.” The more you know, the bigger the problems you solve, and the bigger the assumptions are that are hiding behind the word.
Take the comment, “Just put it up on a server somewhere.” How many times have we heard that? But taking a side project running locally and deploying it on real servers requires time, money, and hard work. Some tiny piece of software somewhere will probably be the wrong version, and will need to be addressed. The system built locally probably isn’t built to scale perfectly.
“Just” implies that all of the thinking behind a feature or system has been done. Even worse, it implies that all of the decisions that will have to be made in the course of development have already been discovered—and that’s never the case.
Things change when something moves from concept to reality. As Dave Wiskus said on a recent episode of Debug, “everything changes when fingers hit glass.”
The favorite button may look fine on the right side, visually, but it might be in a really tough spot to touch. What about when favoriting isn’t the only action to be taken? What happens to the favorite button then?
Even once favoriting is built and in testing, it should be put through its paces again. In use, does favoriting provide enough value to warrant is existence? After all, “once that feature’s out there, you’re stuck with it.”
When you hear the word “just” being thrown around, dig deep into that statement and find all of the assumptions made within it. Zoom out and think slow.
Your product lives and dies by the decisions discovered between ideation and creation, so don’t just put it up on a server somewhere.
Jul
26
Source: A List Apart
The Digital PM Summit is the event for folks who manage digital projects. Attend the Summit October 6-7 in Austin, TX.
Jul
24
Source: A List Apart
Håkon Wium Lie is the father of CSS, the CTO of Opera, and a pioneer advocate for web standards. Earlier this year, we published his blog post, “CSS Regions Considered Harmful.” When Håkon speaks, whether we always agree or not, we listen. Today, Håkon introduces CSS Figures and argues their case.
Tablets and mobile devices require us to rethink web design. Moused scrollbars will be replaced by paged gestures, and figures will float in multi-column layouts. Can this be expressed in CSS?
Paged designs, floating figures, and multi-column layout are widely used on mobile devices today. For some examples, see Flipboard, the Our Choice ebook, or Facebook Paper. These are all native apps. If we want the web to win on these devices (we do), it’s vital that designers can build these kinds of presentations using web standards. If web standards cannot express this, authors will be justified in making native apps.
Over the past years, I’ve been editing two specifications that, when combined, provide this kind of functionality: CSS Multi-column Layout and CSS Figures. I believe they are important to make sure the web remains a compelling environment for content providers.
In this article, I will demonstrate how simple it is to write CSS code with these specs. I will do so through 10 one-liners. Real stylesheets will be slightly longer, but still compact, readable, and reusable. Here are some screenshots to give you a visual indication of what we are aiming for:
The starting point for my code examples is an article with a title, text, and some images. In a traditional browser, the article will be shown in one column, with a scrollbar on the right. Using CSS Multi-column Layout, you can give the article two columns instead of one:
article { columns: 2 }
That’s a powerful one-liner, but we can do better; we can make the number of columns depend on the available space, so that a narrow screen will have one column, a wider screen will have two columns, etc. This is all it takes to specify that the optimal line length is 15em and for the number of columns to be calculated accordingly:
article { columns: 15em }
To me, this is where CSS code morphs into poetry: one succinct line of code scales from the narrowest phone to the widest TV, from the small print to text for the visually impaired. There is no JavaScript, media queries, or expensive authoring tool involved. There is simply one highly responsive line of code. That line is used to great effect to produce the screenshots above. And it works in current browsers (which is not yet the case for the following examples).
The screenshots above show paged presentations, as opposed to scrolled presentations. This is easily expressed with:
article { overflow: paged-x }
The above code says that the article should be laid out as pages, stacked along the x-axis (which, in English, is toward the right). Browsers that support this feature must provide an interface for navigating in these pages. For example, the user may reach the next page by making a swiping gesture or tilting the device. A visual indication of which page you are reading may also be provided, just like scrollbars provide a visual indication in scrolled environments. On a tablet or mobile phone, swiping to the next page or document will be easier than scrolling.
Adding images to the article creates some challenges. Lines of text can easily be poured into several columns, but if figures are interspersed with text, the result will be uneven; because images are unbreakable, they will cause unused whitespace if they appear at a column break. To avoid this, traditional paper-based layouts place images at the top or bottom of columns, thereby allowing other text to fill the whitespace. This can naturally be expressed in CSS by adding top and bottom to the float property. For example:
img { float: bottom }
The bluish harbor images in the screenshots above have been floated to the bottom of the page with this one-liner. CSS is used to express something that HTML cannot say; it is impossible to know how much textual content will fit on a screen in advance of formatting. Therefore, an author cannot know where to insert the image in the source code in order for it to appear at the bottom of the column. Being able to float figures to the top and bottom (in addition to the already existing left and right) is a natural extension to the float property.
Another trick from traditional layout is for figures to span several columns. Consider this newspaper clipping:
In the newspaper article, the image on the left spans two columns and is floated to the bottom of the columns. The code to achieve this in CSS is simple:
figure { float: bottom; column-span: 2 }
HTML5’s figure element is perfect for holding both an image and the caption underneath it:
<figure>
<img src=cats.jpg>
<figcaption>Isabel loves the fluffy felines</figcaption>
</figure>
The newspaper article also has a figure that spans three columns, and is floated to the top right corner. In a previous version of the CSS Figures specification, this was achieved by setting float: top-corner. However, after discussions with implementers, it became clear that they were able to float content to more places than just corners. Therefore, CSS Figures introduces new properties to express that content should be deferred to a later column, page, or line.
To represent that the cat picture in the newspaper clipping should be placed at the top of the last column, spanning three columns, this code can be used:
figure { float: top; float-defer-column: last; column-span: 3 }
This code is slightly less intuitive (compared to the abandoned top-corner keyword), but it opens up a range of options. For example, you can float an element to the second column:
.byline { float: top; float-defer-column: 1 }
The above code defers the byline, “By Collette Jackson”, by one. That is, if the byline would naturally appear in the first column, it will instead appear in the second column (as is the case in the newspaper clipping). For this to work with HTML code, it is necessary for the byline to appear early in the article. For example, like this:
<article> <h1>New rescue center pampers Persians</h1> <p class=byline>By Collette Jackson</p> ... </article>
Advertisements are another type of content which is best declared early in the source code and deferred for later presentation. Here’s some sample HTML code:
<article> <aside id=ad1 src=ad1.png> <aside id=ad2 src=ad2.png> <h1>New rescue center pampers Persians</h1> </article>
And here is the corresponding CSS code, with a one-liner for each advertisement:
#ad1 { float-defer-page: 1 }
#ad2 { float-defer-page: 3 }
As a result of this code, the ads would appear on page two and four. Again, this is impossible to achieve by placing ads inside the text flow, because page breaks will appear in different places on different devices.
I think both readers and advertisers will like a more page-oriented web. In paper magazines, ads rarely bother anyone. Likewise, I think ads will be less intrusive in paged, rather than scrolled, media.
The final example of content that can be deferred is pull quotes. A pull quote is a quote lifted from the article, and presented in larger type at some predetermined place on the page. In this example, the pull quote is shown midway down the second column:
Here’s the CSS code to express this in CSS:
.pullquote#first { float-defer-line: 50% }
Other types of content can also be positioned by deferring lines. For example, a photograph may be put above the fold of a newspaper by deferring a number of lines. This will also work on the foldable screens of the future.
Pull quotes, however, are an interesting use case that deserve some discussion. A pull quote has two functions. First, it presents to the reader an interesting line of text to gain attention. Second, the presentation of the article becomes visually more varied when the body text is broken up by the larger type. Typically, you want one pull quote on every page. On paper, where you know how many pages an article will take up, it is easy to supply the right number of pull quotes. On the web, however, content will be reformatted for all sorts of screens; some readers will see many small pages, other will see fewer larger pages. To ensure that each page has a pull quote, authors must provide a generous supply of pull quotes. Rather than showing the extraneous quotes at the end of the article (which would be a web browser’s instinct), they should be discarded; the content will anyway appear in the main article. This can be achieved with a one-liner:
.pullquote { float-policy: drop-tail }
In prose, the code reads: if the pull quote is at the tail-end of the article, it should not be displayed. The same one-liner would be used to extraneous images at the end of the article; authors will often want to have one image per page, but not more than one.
The studious reader may want to consult the CSS Multi-column Layout and CSS Figures specifications. They have more use cases and more knobs to allow designers to describe the ideal presentation of figures on the web.
The easiest way to play with CSS Figures is to download Opera 12.16 and point it to this document, which generated the screenshots in Figure 1. Based on implementation experience, the specifications have changed and not all one-liners presented in this article will work. Also, Prince and AntennaHouse have partial support for CSS Figures—these are batch formatters that output PDF documents.
I’d love to hear from those who like the approach taken in this article, and those who don’t. Do you want this added to browsers? Let me know below, or request if from your favorite browser (Firefox, Chrome, Opera, IE). If you don’t like the features, how would you express the use cases that have been discussed?
Pages and columns have been basic building blocks in typography since the Romans started cutting scrolls into pages. This is not why browsers should support them. We should do so because they help us make better, more beautiful, user experiences on mobile devices.
Jul
24
Source: A List Apart
When I recently read Geoff Dimasi’s excellent article I thought: this is great—values-based business decisions in an efficient fashion. But I had another thought, too: where, in that equation, is the money?
If I’m honest with myself, I’ve always felt that on some level it’s wrong to be profitable. That making money on top of your costs somehow equates to bilking your clients. I know, awesome trait for a business owner, right?
Because here’s the thing: a business can’t last forever skating on the edge of viability. And that’s what not being profitable means. This is a lesson I had to learn with Bearded the hard way. Several times. Shall we have a little bit of story time? “Yes, Matt Griffin,” you say, “let’s!” Well OK, then.
At Bearded, our philosophy from the beginning was to focus on doing great web work for clients we believed in. The hope was that all the sweat and care we put into those projects and relationships would show, and that profit would naturally follow quality. For four years we worked our tails off on project after project, and as we did so, we lived pretty much hand-to-mouth. On several occasions we were within weeks and a couple of thousand bucks from going out of business. I would wake up in the night in a panic, and start calculating when bills went out and checks would come in, down to the day. I loved the work and clients, but the other parts of the business were frankly pretty miserable.
Then one day, I went to the other partners at Bearded and told them I’d had it. In the immortal words of Lethal Weapon’s Sergeant Murtaugh, I was getting too old for this shit. I told them I could put in one more year, and if we weren’t profitable by the end of it I was out, and we should all go get well-paid jobs somewhere else. They agreed.
That decision lit a fire under us to pay attention to the money side of things, change our process, and effectively do whatever it took to save the best jobs we’ve ever had. By the end of the next quarter, we had three months of overhead in the bank and were on our way to the first profitable year of our business, with a 50 percent growth in revenue over the previous year and raises for everyone. All without compromising our values or changing the kinds of projects we were doing.
This did not happen on its own. It happened because we started designing the money side of our business the way we design everything else we care about. We stopped neglecting our business, and started taking care.
“So specifically,” you ask, “what did you do to turn things around? I am interested in these things!” you say. Very good, then, let’s take a look.
Besides my arguably weird natural aversion to profit, there are plenty of other motivations not to examine the books. Perhaps math and numbers are scary to you. Maybe finances just seem really boring (they’re no CSS pseudo-selectors, amiright?). Or maybe it’s that when we don’t pay attention to a thing, it’s easier to pretend that it’s not there. But in most cases, the unknown is far scarier than fact.
When it comes down to it, your businesses finances are made up of two things: money in and money out. Money in is revenue. Money out is overhead. And the difference? That’s profit (or lack thereof). Let’s take a look at the two major components of that equation.
First let’s roll up our sleeves and calculate your overhead. Overhead includes loads of stuff like:
In other words: it’s all the money you pay out to do your work. You can assess these items over whatever period makes sense to you: daily, weekly, annually, or even by project.
For Bearded, we asked our bookkeeper to generate a monthly budget in Quicken based on an average of the last six months of actual costs that we have, broken down by type. This was super helpful in seeing where our money goes. Not surprisingly, most of it was paying staff and covering their benefits.
Once we had that number it was easy to derive whatever variations were useful to us. The most commonly used number in our arsenal is weekly overhead. Knowing that variable is very helpful for us to know how much we cost every week, and how much average revenue needs to come in each week before we break even.
So how do we bring in that money? You may be using pricing structures that are fixed-fee, hourly, weekly, monthly, or value-based. But at the end of the day you can always divide the revenue gained by the time you spent, and arrive at a period-based rate for the project (whether monthly, weekly, hourly, or project length). This number is crucial in determining profitability, because it lines up so well with the overhead number we already determined.
Remember: money in minus money out is profit. And that’s the number we need to get to a point where it safely sustains the business.
If we wanted to express this idea mathematically, it might look something like this:
(Rate × Time spent × Number of People) - (Salaries + Expenses) = Profit
Here’s an example:
Let’s say that our ten-person business costs $25,000 a week to run. That means each person, on average, needs to do work that earns $2,500 per week for us to break even. If our hourly rate is $100 per hour, that means each person needs to bill 25 hours per week just to maintain the business. If everyone works 30 billable hours per week, the business brings in $30,000—a profit of 20 percent of that week’s overhead. In other words, it takes five good weeks to get one extra week of overhead in the bank.
That’s not a super great system, is it? How many quality billable hours can a person really do in a week—30? Maybe 36? And is it likely that all ten people will be able to do that many billable hours each week? After all, there are plenty of non-billable tasks involved in running a business. Not only that, but there will be dry periods in the work cycle—gaps between projects, not to mention vacations! We won’t all be able to work full time every week of the year. Seems like this particular scenario has us pretty well breaking even, if we’re lucky.
So what can we do to get the balance a little more sustainable? Well, everyone could just work more hours. Doing 60-hour weeks every week would certainly take care of things. But how long can real human beings keep that up?
We can lower our overhead by cutting costs. But seeing as most of our costs are paying salaries, that seems like an unlikely place to make a big impact. To truly be more profitable, the business needs to bring in more revenue per hour of effort expended by staff. That means higher rates. Let’s look at a new example:
Our ten-person business still costs $25,000 a week. Our break-even is still at $2,500 per week per person. Now let’s set our hourly rate at $150 per hour. This means that each person has to work just under 17 billable hours per week for the business to break even. If everyone bills 30 hours in a week, the business will now bring in $45,000—or $20,000 in profit. That’s 80 percent of a week’s overhead.
That scenario seems a whole lot more sustainable—a good week now pays for itself, and brings in 80 percent of the next week’s overhead. With that kind of ratio we could, like a hungry bear before hibernation, start saving up to protect ourselves from less prosperous times in the future.
Nature metaphors aside, once we know how these parts work, we can figure out any one component by setting the others and running the numbers. In other words, we don’t just have to see how a specific hourly rate changes profit. We can go the other way, too.
One way to determine your system is to start with desired salaries and reasonable work hours for your culture, and work backwards to your hourly rate. Then you can start thinking about pricing systems (yes, even fixed price or value-based systems) that let you achieve that effective rate.
Maybe time is the most important factor for you. How much can everyone work? How much does everyone want to work? How much must you then charge for that time to end up with salaries you can be content with?
This is, in part, a lifestyle question. At Bearded, we sat down not too long ago and did an exercise adapted from an IA exercise we learned from Kevin M. Hoffman. We all contributed potential qualities that were important to our business—things like “high quality of life,” “high quality of work,” “profitable,” “flexible,” “clients who do good in the world,” “efficient,” and “collaborative.” As a group we ordered those qualities by importance, and decided we’d let those priorities guide us for the next year, at which point we’d reassess.
That exercise really helped us make decisions about things like what rate we needed to charge, how many hours a week we wanted to work, as well as more squishy topics like what kinds of clients we wanted to work for and what kind of work we wanted to do. Though finances can seem like purely quantitative math, that sort of qualitative exercise ended up significantly informing how we plugged numbers into the profit equation.
Figuring out the basics of overhead, revenue, and profit, is instrumental in giving you an understanding of the mechanics of your business. It lets you plan knowledgeably for your future. It allows you to make plans and set goals for the growth and maintenance of your business.
But once you know what you want to charge there’s another question—how do you charge it?
There are plenty of different pricing methods out there (time unit-based, deliverable-based, time period-based, value-based, and combinations of these). They all have their own potential pros and cons for profitability. They also create different motivations for clients and vendors, which in turn greatly affect your working process, day-to-day interactions, and project outcomes.
But that, my friends, is a topic for our next column. Stay tuned for part two of my little series on the money side of running a web business: pricing!
Jul
22
Source: UXMatters – By Baruch Sachs
Published: July 21, 2014
“All too often, organizations miss opportunities to integrate User Experience into projects effectively, preventing the success of User Experience on large, digital-transformation software projects.”
In my last column, I wrote about the challenges of undertaking a truly transformative software development project within a large enterprise and how it’s sometimes a struggle for User Experience to find the right role within an organization. All too often, organizations miss opportunities to integrate User Experience into projects effectively, preventing the success of User Experience on large, digital-transformation software projects. Thus, UX professionals are left simply managing the UX component, instead of providing the right blend of value and influence.
Now, in Part 2 of this series, I’ll offer guidance on three specific UX activities that should be part of a transformative software development project.
Don’t Just Manage, Transform! Part 2
Jul
22
Source: UXMatters – By Traci Lepore
Published: July 21, 2014
“We work in such collaborative environments. We follow agile or lean methods. So the strength of our work relies heavily on the strength of the team. As the UX people on any team, we play a critical role in bridging different sides of the story together.”
We’ve all experienced some negative moments—when we don’t think we can achieve some goal or a challenge seems too hard to take on. Or maybe, we just feel like we’re in a slump and are finding it hard to stay motivated. It’s easy to let moments like these get the best of us. Sometimes, our first reflex in such a situation is just to say, “No!” The problem, when that happens, is that our attitude can quickly spread to everyone around us. And that kind of negative attitude is destructive to any team.
“Attitude is a little thing that makes a big difference.”—Winston Churchill
The Power of Attitude and Tone: Why “Yes, and” Matters
Loading tweets...
Recent Comments