I need to say a few words about woodchucks. (First let me pause while you say the rhyme to yourself. Go on, you know you want to. Get it out of your system. Good.) I never understood what the word “chuck” was supposed to mean in the rhyme. Chuck isn’t often used as a verb; when it is, its most common meaning is “to throw” (as in, “Chuck that AOL CD in the trash”). This is naturally not the type of thing we expect a woodchuck to be capable of (as indicated by the counterfactual nature of the question in the rhyme). So the real question is why anyone would have given this animal such a nonsensical name in the first place.
(As an aside, woodchuck isn’t the only nonsensical name this animal has. It’s also called a groundhog. Oddly enough, “groundhog” is a fairly literal translation of the Dutch word aardvark, even though aardvarks don’t look anything like hogs. Woodchucks (Marmota monax) are rodents, or more precisely marmots, and are not even distantly related to either aardvarks or hogs. The most salient similarity among the three species is a propensity for burrowing.)
Gimme a W
The name woodchuck is derived from a word in one of the Algonquian languages spoken by Native Americans—either the Cree word otchek or the related Ojibwa word otchig. The English-speaking settlers in North America found these words hard to pronounce, so they substituted syllables that sounded more familiar and yet approximated the original sound; hence “woodchuck.” The process of consciously or unconsciously changing the shape of a word to reflect the existing morphemes (minimal units of meaning) in a language is known as folk etymology. This process frequently occurs when one language “borrows” a word from another and the speakers of the borrowing language mishear, or misunderstand the origin of, the original word.
English has many examples of folk etymology. Cockroach comes from the Spanish word cucaracha. As with woodchuck, the Spanish word was transformed into English by substituting similar-sounding morphemes: cock (as in rooster) and roach (which at that time was simply the name of a type of fish). There wasn’t anything about a cockroach that suggested “rooster” or “fish,” of course; it’s simply a matter of the sounds fitting. The same thing happened with the word polecat (from French poule chat, a cat that feeds on poultry) and ten-gallon hat (from Spanish galón, a braid). English speakers also mistook a napron for an apron, and even an ewt for a newt.
Begging to Differ
Closely related to folk etymology (or even, according to some people, a subset of the phenomenon) is a process called back-formation. Back-formation occurs when speakers remove a portion of a word, incorrectly assuming it’s a suffix, to form a new word. For example, the word pea was pease in Middle English, but that sounded like a plural, so the “s” sound at the end was dropped to make a false singular. Similarly, the word emote is mistakenly assumed to be the root of emotion, which is logical enough since -tion is a common suffix in English. But in this case, the word dropped whole from French (émotion) into English, so that derivation is erroneous. Other words in English that have been mistakenly created by back-formation include liaise, enthuse, laze, and evanesce. Some back-formed words, however, after enough time in circulation, become generally accepted: donate, sculpt, and even beg (from beggar) fall into this category.
A postscript about the woodchuck: The Algonquian words from which “woodchuck” was derived actually refer to the fisher (or wejack), a carnivorous mammal (Martes pennanti) that bears only a superficial resemblance to the woodchuck. So woodchuck turns out to be not only folk etymology, but a misnomer at that. —Joe Kissell
I set out to find a simple answer to a simple question: Why is there no meat in mincemeat? It was going to be a tidy tale of how a misnomer was born. Look up a few Web sites, collect a few facts, wrap them in a nice story, and on to the next project. As so often happens, however, my research took a rather circuitous path as I kept discovering connections and facts that I’d had no inkling of when I started out. The story of mincemeat is more interesting—and convoluted—than I ever imagined.
Mincemeat is, I must confess, a topic about which I have never felt much passion. In my family, mincemeat pie was simply one of a half dozen standard Christmas dessert choices. I rarely had room for more than two, and in my personal hierarchy of dessert preferences, mincemeat ranked well below Johnny Bull Pudding and blackberry pie. On the occasions I did eat mincemeat pie, it made no particular impression on me other than provoking a vague curiosity at its name, since whatever the filling was, it clearly did not contain any meat.
One explanation for the name could be that in Old English, the word meat had the more generic meaning of “food,” whether or not it happened to come from the flesh of animals. Thus, a mincemeat pie would actually have been a “minced food” pie, which could have been anything. However plausible this may sound, however, this explanation turns out to be incorrect (or at least misleading).
A Pie Fit for a King (or Two)
Centuries ago, mincemeat was so named for the very straightforward reason that it contained minced animal flesh (and in fact sometimes still does—more on this later). Beyond that, the details of its provenance and development are hazy. I have read a few unsubstantiated reports stating that mincemeat pie was served at least as far back as 1413, at the coronation of King Henry V of England, and that further, it was a favorite of Henry VIII. There is no record of the composition of these early dishes, but recipes dating from the early 17th century list a variety of wild game, plus eggs, fruit, spices, and sweeteners. According to some accounts, early mincemeat pies were small, like tarts; according to others, they were immense, weighing as much as 220 pounds (100kg). In any case, meat and fruit were invariably included among the ingredients.
Going back even further, however, there are some who believe mincemeat pie is based on an ancient pagan tradition of serving coffin-shaped cakes representing Osiris—the Egyptian god who, according to legend, died and was resurrected each year. This ritual took place on the winter solstice, December 21, and this very festival was later co-opted by Christians looking for a convenient date to celebrate Christmas (and stamp out pagan influences in the process). Along with the Yule log and the evergreen tree, the mincemeat pie is arguably a remnant of the original pagan celebrations that persisted when the holiday was refashioned.
Mincemeat’s Second Coming
One person who believed this argument was 17th-century Puritan leader Oliver Cromwell. Cromwell felt that Christians had no business observing the birth of Christ by eating, drinking, and merrymaking—certainly not on a pagan holiday, and using pagan symbols. So he abolished Christmas in England in 1657. Two years later, he prevailed upon authorities in Connecticut and Massachusetts to ban Christmas celebrations there too. The prohibition specifically disallowed mincemeat pies, which were characterized as being sinful both for their symbolic origin and their inherent richness. But Cromwell’s attempt to put the last nail in the coffin of mincemeat failed; it rose again. Within two centuries the ban on Christmas had been all but forgotten, and mincemeat was once again a staple in both Christmas and Thanksgiving celebrations. But over those years mincemeat had undergone a change in character. Perhaps as a way of obeying the letter of the law while maintaining tradition, some people had begun to leave out the meat in mincemeat, replacing it with nuts, apples, and raisins…along with brandy or rum. That, in short, is why the name doesn’t always match the ingredients.
This leaves the question of why anyone would think to mix meat and fruit in a pie in the first place. This notion seems to elicit “yuck” responses from many people, but I don’t see why. Sweet and sour pork contains pineapple; some curried meat dishes contain raisins. There’s nothing unnatural about mixing meat and fruit. It’s just not common to see them together in baked goods (though I have frequently said that the idea of chicken cinnamon raisin cookies sounds good to me). One commentator opined that the mixture was simply a method of preservation, as the combination of the acids from the fruits and the heat from baking inhibited the growth of bacteria in the meat. That seems vaguely plausible, though I prefer the simpler explanation: it just tastes good.
Today, a few recipes for mincemeat (and some brands of jarred mincemeat) do indeed contain meat, but of those that don’t, most of them still contain suet, the hard layer of fatty tissue surrounding the kidneys of cattle. To be sure, this doesn’t sound like an appetizing dessert ingredient. And yet, it turns out to be one of the main ingredients (again, along with raisins) in Johnny Bull Pudding, the dessert I customarily ate on Christmas instead of mincemeat pie. There’s just no escaping tradition. —Joe Kissell
I’ve never regretted the decision I made a few years ago to live without a car. After all, if I walk down the hill a few blocks from my home, I can catch a subway, streetcar, or bus to take me nearly anywhere in San Francisco I may want to go. But every now and then, that “nearly” part causes me grief. There are certain spots in the city I can reach via public transit only by taking a subway, a streetcar, and two buses—and then walking for 20 minutes. The prospect of all that waiting and transferring, especially on weekends or when buses are running late, tempts me to take a taxi (which gets quite expensive) or rent a car (forcing me to worry about parking and traffic). Even in a compact city such as this one, getting from place to place quickly, inexpensively, and safely can be difficult. Owning a car can help in some ways, but for many of us, it would be more trouble and expense than it’s worth.
It’s a Bird, It’s a Train, It’s a…Taxi?
Several articles here on Interesting Thing of the Day have mentioned ways of addressing the urban transportation problem: car sharing programs, carfree cities (including Arcosanti), and personal flying machines, for example. A while back, a reader suggested I check out an innovative urban transportation system called SkyTran. Later, another reader wrote to tell me about a different urban mass-transit solution called the RUF (Rapid Urban Flexible) system. Although the two differ significantly, they are both monorail transit systems designed for cities. As I began reading about these, I discovered that they are just two among many similar proposed designs. Clearly, this was a meme worth investigating.
The beauty of elevated monorail-based systems is the relative ease with which they can be retrofitted into an existing urban environment. Unlike subways, they require an absolute minimum of disruptive street closures (and no digging). Unlike streetcars, monorails don’t have to compete with cars and pedestrians for space on the roads. And unlike conventional elevated light-rail train tracks, monorails can be constructed quickly and inexpensively. Seattle already has a (very short) monorail line, as do some other cities. But some proposals currently being advanced call for much more elaborate and pervasive systems—with some interesting innovations that could make them much more efficient than buses or trains. These systems are known generically as Personal Rapid Transit (PRT). Unlike conventional mass transit, PRT replaces large vehicles with small cars that hold only two to six people—and therefore use very small and inexpensive tracks as well.
Packet-Switching Meets Mass Transit
The SkyTran is one such PRT system. Its designer proposes to install a network of tracks that can take riders within a few blocks of any location in a city, using a flexible point-to-point scheme rather than a fixed route. The cars can travel much more rapidly than a train or bus, and a sophisticated computer system prevents collisions and congestion. In theory, there would always be at least one car available at each stop; after you board, the car zips from the station’s bypass track onto the main track, where it picks up speed and takes you directly, without stopping, to your destination. This seems to combine all the advantages of a taxi with the advantages of a subway—and then some. Similar designs include the SkyWay Express, the ATN (Automated Transportation Network), and the ULTra (Urban Light Transport) system, which is being developed in the U.K.
If you want to avoid any walking—or be able to travel outside the immediate area served by the transit system—you might prefer another variant of PRT. The RUF (Rapid Urban Flexible) system being developed in Denmark is an example of a hybrid that uses specially modified electric cars that can operate automatically when riding on the tracks or manually on the road. Use your car around town as usual, but when you want to travel farther or faster, drive into a station where your car is guided onto a special monorail track. From there, allow the computer to drive you to your destination stop, where you drive off the track and resume manual control. RUF requires much less track than SkyTran and provides passengers with greater independence; on the other hand, the cars themselves are much more complex and expensive.
Proponents of PRT systems invariably point out that the cost of installing a citywide monorail system of this sort would be comparable to the cost of installing a traditional light-rail line; the additional efficiency should make it so cost-effective that it’s a no-brainer. Municipal governments are understandably hesitant to sink tens or hundreds of millions of dollars into unproven technology—but this is a chicken-and-egg problem; until one of these designs is actually put into large-scale use somewhere, there’s no telling how well it will live up to its promises. There’s another source of hesitation too: however flawlessly such a system may work, the question remains whether the teeming masses will like it and trust it enough to give up their cars. But as more urban dwellers go carless anyway (out of choice or necessity), PRT systems look increasingly appealing. —Joe Kissell
As everyone knows, a lot of scientists are extremely concerned about global warming. Evidence suggests that the high levels of so-called greenhouse gases produced over the past half-century or so will result in higher temperatures worldwide over the coming decades. The additional heat could melt polar ice and raise the level of the ocean, causing flooding and eroding coastlines; it could also lead to more severe climate change with potentially devastating effects. Other scientists say that worries about global warming are overblown—that the temperature will not rise significantly (at least, not due to human activity), and that in any case, the results of a slightly increased average temperature would be mild rather than disastrous.
But no one disputes that the air has become quite polluted—you can verify this easily by looking out your window. One major component of air pollution is carbon dioxide (CO2), which is produced as a waste product when fossil fuels are burned. The level of carbon dioxide in the atmosphere has risen markedly since the beginning of the industrial age, and even if that change is not completely attributable to human progress, it’s not a good thing. Whether or not human-generated CO2 contributes to global warming, it clearly causes other problems.
Convincing the people and governments of the world to reduce the use of fossil fuels is essentially a lost cause, so the latest trendy approach to dealing with all that excess CO2 is capturing it as soon as it’s created and then disposing of it somewhere. Equipment installed at power plants and other major industries can separate the carbon dioxide from other waste products and liquefy it for temporary storage; finding a long-term home for massive amounts of the gas is the real problem. The process of storing carbon dioxide permanently in such a way that it cannot escape back into the atmosphere is known as carbon sequestration (or, sometimes, carbon dioxide sequestration). Broadly speaking, there are two places one might put large quantities of unwanted carbon dioxide—in the oceans or underground. Techniques for getting the CO2 to its putative final resting place (and keeping it there) are in varying stages of experimental development.
Ocean Storage
The world’s oceans already absorb unfathomable amounts of CO2; some researchers believe they could hold a great deal more with a little help. The upper part of the ocean typically has a fairly high concentration of CO2 (absorbed directly from the atmosphere), but at greater depths, the concentration is much lower. So one way to dispose of CO2 is to inject it into deep ocean water. At depths over 3,000 meters or so, liquid or solid CO2 is denser than the surrounding water, meaning that it could sink all the way to the ocean floor. Closer to the surface, it will dissolve into the water. Dissolved CO2 makes the water acidic, with unknown (but likely detrimental) effects on marine life. Liquid CO2 on the ocean floor may react with minerals there and form solid precipitates—or it may simply kill off organisms already living there.
Geological Storage
Merely burying CO2 is not good enough; in order for it to stay put, it has to be stored very deep in the ground, and somewhere that the gas cannot escape into the atmosphere. Some possibilities include:
Saline Aquifers: An aquifer is a porous layer of rock that holds a large quantity of water—often saltwater. Inject CO2 deeply enough into an aquifer, and the surrounding pressure keeps it in liquid form. Meanwhile, an impermeable layer of solid rock above prevents the gas from being released back into the atmosphere. Although aquifer storage is expensive, it is likely to have less impact on the environment than ocean storage—and the CO2 can remain safely underground, theoretically, forever.
Oil and Gas Reservoirs: If you can put carbon dioxide into an aquifer, you can also put it into a depleted gas or oil well. In fact, the technology to deliver CO2 into such wells has been in use for decades; pump CO2 into an oil well, for instance, and you can push out extra oil that would otherwise be unreachable. As long as the CO2 is stored deep enough, it will remain as a liquid.
Coal Seams: Most of the world’s coal deposits are located too deep in the ground for mining to be practical. When CO2 is injected into coal seams, the coal absorbs the gas. Meanwhile, in a manner similar to enhanced oil recovery, the process also pushes out methane gas, which can be used as a fuel.
And then, of course, there’s a natural CO2 storage apparatus: forests. Trees are incredibly effective at absorbing carbon dioxide and creating oxygen, so planting (or replanting) millions of acres of forest could go a long way toward solving the CO2 problem—no drilling or high-tech research required. This is not technically sequestration, as you wouldn’t manually inject previously collected carbon dioxide into a tree—but it does have essentially the same net effect.
Politicians hope carbon sequestration—of one kind or another—turns out to be a magic bullet that can appease consumers, energy companies, and environmentalists alike. Although all the potential terrestrial CO2 storage spots show some promise, the safety, capacity, and long-term effectiveness of carbon sequestration is ultimately unknown. At best, it will address only a small portion of the world’s pollution problem; at worst, we may find that something we thought we buried comes back to haunt us. On the other hand, we certainly take a lot of carbon out of the ground. Putting some back in just may balance the scales a bit. —Joe Kissell
Several years ago, a friend of mine gave me a book for my birthday called Thought Contagion. I had not heard of the book or its subject matter, the science of memetics, but I was fascinated by what I read. Author Aaron Lynch explained, concisely and convincingly, how some of the most significant beliefs in society came to be as popular as they are. By the end of the book I felt I understood, for the first time, a great many things that should have been obvious all along. I was even more surprised to discover that the things Lynch was saying were considered novel, and even somewhat controversial. What he described, simply and elegantly, is a compelling theory about the way beliefs spread.
What Memes May Come
The fundamental term in memetics is meme, which means a self-propagating idea. The term was borrowed from sociobiologist Richard Dawkins, who coined it in his 1976 book The Selfish Gene. Roughly speaking, memetics applies the principles of evolution by natural selection to beliefs. In conventional evolution, genes that improve an organism’s ability to survive endure in future generations and spread throughout a population; those that hinder survival eventually disappear. By analogy, memetics says that ideas are subject to natural selection as well; those that most effectively promote their own survival multiply and spread, while those that don’t, don’t.
In memetics, it is misleading to think of a person as having a belief; instead, it is more accurate to think of beliefs as acquiring people. Memes propagate from person to person in a manner analogous to the way viruses spread. A meme is passed from one person to another through one form of contact or another, and in some cases must mutate in order to continue surviving and spreading. Thus memetics is sometimes described as an epidemiology of ideas, investigating them in much the same way as a researcher might study the way a disease spreads throughout a community. This is not to say, of course, that all ideas that spread are negative ones, as the analogy to disease might suggest. Memetics itself is neutral with regard to the value of beliefs, and the principles apply equally to positive, useful beliefs as to destructive ones.
Being Fruitful and Multiplying
Just as a virus can spread by floating through the air, by skin contact, or through exchange of bodily fluids, there are a number of different mechanisms whereby beliefs spread. One of the most common and effective means of spreading a meme is simply having children, because children more often than not serve as hosts for the same memes as their parents. Thus memes that encourage procreation directly (“your biological clock is ticking”) or indirectly (“abortion is murder”) serve to propagate themselves to the children of the meme’s host. Similarly, memes that make it more likely that parents will pass a belief on to children (such as “children should respect their parents”) encourage their own propagation.
Another common mechanism of meme propagation is proselytism. Consider the meme “those who do not believe in Religion X will spend eternity in hell.” This meme aids its own propagation, because holding the belief increases the likelihood that it will be transferred to other hosts. A person who considers belief in Religion X crucial to eternal happiness will be motivated to influence its adoption by friends and even strangers (not to mention offspring). This meme also illustrates other methods of propagation, such as discouraging hosts from dropping the belief (persistence of the belief, especially at the time of death, is regarded as crucial to its effectiveness) and resisting efforts of competing memes (such as “all religions are equally good”) to displace it.
Gimme Some Truth (or Not)
Of the other methods of meme propagation, surprisingly, one of the least effective is for a meme simply to seem true. The sheer force of logic can and does cause memes to spread (as in “Earth revolves around the Sun”). But more often than not, competing memes with other methods of propagation win out over those that depend solely on truth or plausibility. In particular, political and moral beliefs (which typically spread by offspring production, proselytism, and dropout prevention) usually displace beliefs whose only mechanism of reinforcement is objective fact. This could help to explain, for example, how a nation might muster public support for a war in the absence of objective evidence of danger from an enemy.
The basic principles of memetic theory that describe the ways in which beliefs spread, persist, and recede, can account for the rise and fall of numerous widespread beliefs, including economic trends, pro- and anti-abortion movements, terrorism, racism, diet fads, and hundreds of other memes. It can explain how TV programs or radio talk shows gain and lose popularity, why less effective technologies win in the marketplace over more effective ones, and how public opinion can shift rapidly on many major issues.
My predominant thought while reading Lynch’s descriptions was, “Well, of course that’s why so many people believe such-and-such. It’s obvious. How could it be any other way?” And yet, that is precisely what’s interesting about memetics: it points out and explains things that should have been obvious all along, but weren’t. Although Thought Contagion is written for a general audience and therefore avoids complex mathematics, memetic theory is in fact a very serious science, backed up by increasing amounts of highly technical analysis. Very few professionals currently consider themselves full-time memeticists, but that is certain to change, thanks to the rapidly spreading meme, “memetic explanations rock.” —Joe Kissell
As I look around at the many printed items within arm’s reach—books, magazines, a calendar, posters, checks, labels, boxes, and so on—I am vaguely aware that nearly all of them made their way through a printing press at some point. And, since I’ve used rubber stamps and stencils, I have an equally vague awareness that any printing process is based on putting ink or other coloring onto some parts of paper while keeping it off other parts. But despite having worked in the prepress field for a while, I never thought very deeply about the methods for transferring ink to paper; terms like “offset” and “lithography” had no specific meaning to me. Even after I finally grasped how laser printers work, ink-based printing methods remained a mystery.
Every time I realize that I’ve been living in blissful ignorance about something so common, I feel sort of guilty—it’s the same feeling I had when I was in high school and knew that I’d studied just enough to get through my exams, but not enough to actually understand or remember anything. So I began some remedial self-instruction in printing techniques, determined to fill in those embarrassing gaps in my knowledge. Along the way, I learned all sorts of interesting things, but one printing method particularly struck my fancy: intaglio (in-TAL-yo) printing.
Making an Impression
There are several major large-scale printing methods. The original printing press and its descendants (including rubber stamps) use raised letters to ensure that ink is applied only to the desired portions of the page; although an entire block of type may be covered with ink, only the raised parts make contact with the paper. In lithography, a printing plate (or stone) is moistened with water and then coated with ink; the greasy ink adheres only to the portions of the plate with the right texture (achieved in a variety of ways), while the water on the blank portions of the plate repels the ink. Although paper is brought into contact with the entire plate (directly, or, in offset lithography, via an intermediate rubber roller), only the inked portions transfer marks to the paper.
Intaglio printing (from an Italian word meaning “carve”) predates lithography by more than three centuries. Like lithography, it employs full-plate contact—but instead of relying on water to keep ink where it belongs, it uses recesses cut, engraved, or etched into a metal plate (or cylinder) to hold the ink. After the ink is spread, the plate is wiped down to remove excess ink from the top surface. The paper is then applied under tremendous pressure to push it into the grooves, transferring the ink where it has made contact. One of the side effects of intaglio printing is that the inked surfaces are very slightly raised on the front and indented on the back; depending on the type of paper and ink used, this can give intaglio prints a unique texture. A variant of intaglio printing called gravure varies the depth of the recesses in order to produce a range of tones; deeper grooves hold more ink and therefore create darker colors.
Show Me the Money
Intaglio presses can cost ten times as much as offset presses, and an intaglio printing plate can cost hundreds of times more than a comparable plate intended for offset printing; hence the relative popularity of the latter. But intaglio printing has some important advantages. For one thing, the plates have an incredibly long life; many millions of impressions can be made before the image quality degrades. For another, intaglio printing can achieve remarkably fine levels of detail. These facts, combined with the raised surfaces of the design, make intaglio printing the natural choice for currency, passports, and other high-security documents. Virtually every banknote in the world is printed at least partially using intaglio, because its distinctive appearance and texture make it easier to spot counterfeits. Although intaglio will never replace laser and inkjet printers on the desktop, there’s no better printing technique when only perfection is good enough. —Joe Kissell
I recently went to a toy store with my son, and found myself marveling at how little had changed since I was a kid. Alongside all the miracles of modern toy science were dozens of items that I remembered seeing on toy store shelves 25 years or more ago, and they looked exactly the same—except for the price. Slinkies. Magic Rocks. Ant Farms. Silly Putty. Nerf balls. And, of course, Sea Monkeys. I vividly remember the ads in comic books and magazines promising “Instant Life—Just Add Water!” The ads pictured anthropomorphic sea creatures with tails, smiling faces, and crown-like protuberances on their heads. These intelligent and fun-loving creatures could be your new pets for just a few dollars.
I never managed to prevail upon my parents to spring for the Sea Monkeys, but I always wondered just how close the real thing would be to the hype. A couple of years ago, when Morgen bought a Sea Monkeys set as a present for a friend, I got to see them in action. The little critters were, unsurprisingly, not terribly impressive as pets. However, in terms of both biology and marketing they are a marvel every bit as interesting as those ads implied.
Brine Shrimp Deluxe
Sea Monkeys are a variety of brine shrimp. Unlike the common species Artemia salina, Sea Monkeys were engineered as a larger and longer-lived hybrid variety the manufacturer calls Artemia nyos (NYOS stands for New York Ocean Science Laboratories, where the breed was developed). But like all brine shrimp, Sea Monkeys lay eggs encapsulated in a cyst shell. These cysts have the unusual capability of remaining viable over long periods of time when completely dehydrated—effectively maintaining a state of suspended animation. This state, known as cryptobiosis, is also seen in some plant seeds, insect larvae, and crustacean eggs. When the eggs are re-hydrated in a saline solution, they continue with their development and hatch soon thereafter.
Sea Monkeys have other interesting characteristics, such as the fact that they have one eye when they hatch but later grow two more. According to the official Sea Monkeys literature, the animals also breathe through their feet—I’ll have to take their word for it—and the females can reproduce either sexually or asexually.
Just Add Hype
But when you get right down to it, these creatures, which rarely grow longer than half an inch (about 15mm), are not that interesting as pets go. Brine shrimp are often sold as food for other fish, and their low status on the food chain says something about not only their size but their neural capacity. Compared to even the most ordinary tropical fish, the translucent Sea Monkeys are rather tedious to watch—if you can spot them at all—as they swim around in their little tanks.
That brine shrimp could ever be conceived of as pets is nothing less than a stroke of marketing genius. The man behind it was inventor Harold von Braunhut, who was also responsible for such kitschy fads as the X-Ray Spex, which got me in trouble when I tried to wear them during class in sixth grade. Von Braunhut began working with brine shrimp in 1957, and in 1960, his first simple kits went on sale. The fact that the eggs could be shipped easily, stored indefinitely, and brought back to life within a couple of days suggested the name “Instant Life,” which was how the product was first sold. When von Braunhut realized the creatures themselves needed a more marketing-friendly name, he began calling them Sea Monkeys, reportedly because of their tails. (Any actual resemblance to monkeys is purely in the mind of the beholder.)
Von Braunhut died on November 28, 2003. But in recent years, his invention—along with its innumerable variations and spin-offs—has sprung back to life as a retro fad. For about US$10 (rather than the original $0.49), you can get a plastic tank, water purifier, egg “crystals,” food, and accessories—including a handbook whose main purpose is to convince you to buy still more supplies to keep your new pets alive as long as possible. Sea Monkeys come with a two-year “growth guarantee,” but owners seldom maintain their interest in keeping the creatures alive for more than a few months. As pets, they make great fish food. —Joe Kissell
Once you’ve signed up for Dropsource, you would create a project. You can choose either iOS or Android. After that, you’ll see the editor’s main screen. Create the initial structure in a few clicks. Each screen in your app is represented as a page, and your app needs to have at least one page in it. So, the first thing we need to do is select the “Pages” option on the left of the editor.
The first page you create will be automatically set as the home (or landing) page for your app. This is the page your users will see first. You can also respond to page lifecycle events (such as “Page Loading,” “Page Appearing,” etc.) in the “Events” tab. For example, by changing “Page Loading” events, you can add a loading animation during the data-loading process.
Next, we need to tie two pages together. To allow the user to navigate between pages in your app, you can use actions. For example, we can add a button on the home page with a label “Get to know us,” and then the user can navigate to the “About Us” page by tapping the button.
Open the “Events” button in the “Properties” tab. Click “Manage,” choose “Go to Page,” and select the target page from the list of available pages. In our case, we’ll transition to “About Us” and choose the transition type “Push.”
Dropsource uses objects called Elements as the building blocks of an app’s user experience. In the “Elements” section, to the left of the editor, you’ll see a variety of common components that you can use in your pages. To add them, simply click and drag and drop them to the canvas.
For the “About Us” page, we’ll add two elements: “Image View” and “Text View.”
Now we need to fill them with real data; select an image for the “Image View,” and add the text to be displayed. We can do this in the right panel. With just a few clicks, we’ll have the following page:
A lot of tools intended for fast product development provide a limited number of style options, and in most cases, a tool will force users to select from the list of available templates. As a result, many apps created with the tool will look similar. Not so with Dropsource. Dropsource is fully customizable, and you have complete control over the look and feel of your app. You can change style options for each element presented on the canvas — simply click the element, and you’ll find all available style options in the right panel.
With Dropsource, your app will be as unique as your vision. (Large preview)
You can also set styles dynamically while the app runs, so you’ll be able to change the appearance of elements when events occur in the app. Last but not least, if you create an app for both iOS and Android platforms, you can see the differences between styles. An app created using Dropsource is designed to provide the standard look and feel for each platform.
API Integration
Dropsource allows creators to connect their app to any REST API. It uses Swagger (or OpenAPI) specifications to build requests to the APIs. You can use prebuilt APIs or create your own API for the app. Public API providers, as well as back-end-as-a-service (BaaS) and internal enterprise systems, can be plugged right into your app quickly and easily, putting the full potential of that data at your fingertips. You can connect your Dropsource app to a back end built with Bubble or Backendless or even create a mock API with Stoplight. Essentially, you can use any provider you like, as long as it provides a REST API.
Working with data is one of the more complex elements of building your app, and Dropsource provides a good deal of resources to help you along.
If you want to use your own API, create a Swagger description file to integrate with Dropsource, so that it can access the API endpoints, signatures and data types.
If you want to use your own API, create a Swagger description file to integrate with Dropsource, so that it can access the API endpoints, signatures and data types. (Large preview)
Let’s create a “Search” page, which will be used to search for restaurants in the user’s area. We’ll need a few elements for this page: a search box, a submit button and a dynamic list. To provide search features, we’ll also need Google API integration. This means we’ll need to add an API to our project and configure it to show the search results. Dropsource already preloads several APIs into the platform for testing purposes, such as the Google Places API, the Slack API and others. Compared to visual design, API integration will require some initial effort (it’s not as easy as visually dragging and dropping). But as soon as you are familiar with it, you’ll be able to create truly powerful mobile apps. You can connect external data using an API. In our case, we’ll use the Google Places API (provided by Dropsource) to search for the nearest places.
You can connect external data using an API. In our case, we’ll use the Google Places API (provided by Dropsource) to search for the nearest places. (Watch video)
Test the App
Testing is an essential part of the UX design process. It ensures that your applications will perform as expected in production and will deliver a consistent experience to users and earn you five-star ratings in the app stores. Unfortunately, this iteration often takes a significant amount of time. With Dropsource, the process of testing native apps is streamlined, because you can do so directly in the browser or on a real device.
Dropsource allows you to test right from the design screen.
Browser testing is done through the Appetize.io tool, which makes it possible to share the app via a link. Share your work with colleagues and friends to get immediate feedback. Alternatively, you can test your app on a mobile device; with just a few clicks, Dropsource will email you a link to install the app directly on your mobile phone. From there, you can test all of the native functionality of your app and see the mobile UI right on your device’s screen, all without ever opening an IDE such as Xcode or Android Studio!
It’s possible to test the app using a simulator or on a real device. You can test your ideas and quickly iterate upon them.
It’s possible to test the app using a simulator or on a real device. You can test ideas and quickly iterate on them. (Large preview)
Publish the App
Once everything is tested and polished, you can ship the app to the App Store or Google Play in a few clicks. Simply click “My Build,” select the build that is ready to be shipped, and choose the option “Request a Service.” The Dropsource team will help you with publishing to the App Store or Play store for no additional fee. (Note: This is a premium feature, costing around $49 per month, but there is a 30-day free trial!)
You can publish your app to the App Store or Google Play directly from Dropsource. (Large preview)
Advantages And Disadvantages Of Building An App Yourself Versus With Dropsource
It’s worth comparing the differences between the standard approach for creating a mobile app (i.e. coding the app in IDE) and using Dropsource. Let’s suppose we have all of the technical skills for building a mobile app.
Coding from scratch
Building with Dropsource
Software required to build for Android and iOS
You’ll need to download and install the IDE for each platform.
You’ll need only Dropsource. There’s no need to download anything; everything is available in the cloud.
Dealing with Android and iOS updates
You’ll have to update your project according to the platform’s requirements, as well as update broken code (the “Auto update” functionality integrated in Android Studio and Xcode rarely works well).
Dropsource is always up to date with the latest specifications for Swift and Java. Just run a new build in Dropsource after an OS update, and your native source code will be rewritten following any new standards or updates.
Visual inspection of UI elements; setting properties using visual editor
A limited set of features is available in the IDE’s Layout Editor (Android) or Interface Builder (Xcode). A lot more can be defined in code.
All properties of standard UI elements can be customized using Dropsource’s UI. It’s possible to set complex interactions by using a robust system of events and actions for each component.
Data-integration capabilities
Integration with each third-party service requires coding.
No coding needed to integrate app with external data sources.
Code ownership: Is it possible to download and distribute the source code of your app?
Yes
Yes
Is it possible to extend the app with custom logic?
Yes
Yes: You can either ask the Dropsource team to build a plugin or download your source code to customize yourself.
Performance optimization
In most cases, you’ll need to optimize the code to achieve good performance.
An app created with Dropsource doesn’t have any performance trade-offs; 100% truly native source code (Swift and Java) will always perform best on iOS and Android devices.
Testing on devices
Use the IDE emulator and on real devices.
Use the emulator in a browser and on real devices (either via a link or download the code to install on a device via the IDE).
Why Using Dropsource Is Good For Your Project
Hopefully, you now see that building a truly native app can be easy. Let’s see what the other benefits of using Dropsource are.
Both iOS and Android Are Supported
Dropsource allows you to create iOS and Android apps side by side. The app can be made for both platforms while maintaining similar interfaces and features. You won’t be stressed about OS updates because Dropsource is always up to date with the latest specifications for Swift and Java, eliminating any worry when Apple and Google update their operating systems.
No Lock-In
With Dropsource, you can download your app’s source code whenever you like. Dropsource generates source code that is written in Swift for iOS apps and Java for Android apps, and that code can be downloaded onto your desktop when you need it.
Dropsource allows you to download the source code in one click. This is a great opportunity to inspect the code and debug and to use that as the base for a fully customized app down the road.
Dropsource allows you to download the source code in one click. This is a great opportunity to inspect the code and debug and to use that as the base for a fully customized app down the road.
Prototyping and Development Finally Come Together
Usually, a prototyping phase that includes user interface design is separate from actual development. Developers get information from the designers (in the form of a specification) and start to implement the actual interactive app. With Dropsource, you have one phase, and this is a great advantage.
Easier Buy-in From Stakeholders
When talking about a design, a lot of stakeholders want to be able to see (and possibly play with) a prototype to better understand what’s being proposed. With Dropsource, you’re freed from asking stakeholders to imagine what they’ll see once the development team turns out the latest version — simply create a functional app prototype, and put it in their hands. Dropsource is perfect for building a minimum viable product to test out an idea.
Quick Iteration
The reality today is that we have to move fast in order to succeed. This is especially true in mobile development, where thousands of apps are released daily. We need to test a lot of hypotheses to figure out what works for us. One of the top mobile development trends is to reduce the duration of the development lifecycle and to shorten the gap between developing a concept and building the mobile application itself. With Dropsource, you can test ideas and quickly iterate on them. This eliminates the need for distinct, time-consuming phases of design (including static mockups and overwhelming specifications.) Dropsource substantially reduces the time to market for users and enterprises that need to innovate quickly.
Conclusion
App development should be available to all. Whether you’re an entrepreneur with a great idea but little in the way of development resources or a developer looking to save time, Dropsource offers powerful potential to save time and effort:
You can build a truly native app. A wide variety of common UI elements, such as buttons and input fields, are available on the platform.
Instead of having different developers (or even development teams) build the same product for different platforms, you can use the same team, regardless of platform.
The tool eliminates the requirement to manually code, while still providing access to native source code.
Easily integrate your app with any REST API’s back end.
Finally, the prototyping and testing phases are seamlessly integrated in the development process.
I would rate Dropsource five out of five for ease of use, features and functionality. If you’re looking for a robust tool to prototype or build a fully functional mobile app, try Dropsource for free. Every idea is worth building. Who knows? Maybe your app will change the world.
The first section you will see in the layout panel is Overlay Grid, which will show you all the elements on the page with display: grid applied. You will be able to turn on the grid overlay on each grid by checking their respective checkbox. For now, only one grid overlay can be displayed at any one time, but having multiple grid overlays is a feature on the roadmap.
Every additional grid will have a different color from the default purple, but you are free to change the colors of your grid overlays by clicking on the colored circle on the right of each grid element. The grid overlay will show all the grid tracks and grid gaps of the selected grid.
Once you select a grid, a rendering of the selected grid will appear in the space below in the color of the grid overlay. This rendering will show you each section of the grid you defined and hovering over any section will highlight its corresponding area on the actual page. There will also be a tool-tip that shows you the line number of the row and column of the highlighted grid item.
Most of us would be in the Rules panel when examining the CSS on our site, and you can toggle the grid overlay from there as well. Select the element which has display: grid applied to it, and click on the waffle-like icon on the property. The options for display of line numbers or grid area names that have been set on the Layout Panel will be respected when the grid overlay is toggled in this manner.
The next section on the panel is the Grid Display Settings, which allows us to toggle three options for now. The display of line numbers, the display of area names and the option to extend grid lines indefinitely.
The basic premise of how Grid works is that you first define a grid, then proceed to place your grid items within that grid. You can either place those grid items manually or let the browser do it for you. The position of the grid items depends on their grid-row and grid-column values. Grid lines are referred to by their numerical index which starts from 1.
Once Display line numbers is active, the selected grid overlay will display the line numbers of the grid in the color of each respective grid overlay. Each grid has their own numerical grid index which starts from 1, different grids will not share the same numerical grid index.
Line numbers cut off at the top edge (Large preview)Line numbers cut off at the side edge (Large preview)
If your grid extends the width or height of the viewport, you will notice that the line numbers get cut off at the edges. The Mozilla team is aware of this issue and it is being tracked under Bug 1396666.
You can also define a grid using the grid-template-areas property, which gives us the ability to name the areas on our grids. The syntax for this property also provides a visualization of the grid structure in the CSS itself, making it easier to understand the layout of the grid from your code.
This creates a 3 by 3 grid and each section is named according to how they are laid out in the grid-template-areas property. If the sections are named, they will be displayed as a second tool-tip when you hover over the rendering of the grid in the layout panel.
We can also toggle the display of the grid area names on the grid overlay by checking that option in Grid Display Settings. According to Mozilla, this feature was inspired by CSS Grid Template Builder, which was created by Anthony Dugois.
The last option you can toggle is to extend grid lines indefinitely. By default, the grid lines on each grid are constrained to within the bounds of the grid container. But sometimes it can be useful to see how the grid aligns in the context of the entire page.
The Box Model section under the Layout Panel shows a rendering of the dimensions of the selected element, its padding, borders, and margins. In addition to that, it also shows the CSS properties that affect the position, size and geometry of the selected element, namely box-sizing, display, float, line-height, position, and z-index. A convenience when it comes to troubleshooting layout-related CSS issues.
The computed value of the height and width of the selected element and its current positioning value is displayed below the box model outline. You can also directly manipulate the margins, borders, and paddings of the element from the diagram itself.
If you use CSS lengths other than pixels, the DevTools will convert the values into pixels automatically based on the computed value, which is really nifty.
Grid Inspector Plays Well With Transforms
There are many instances where Grid will be used in combination with other CSS layout properties, like transforms, for example. The Grid Inspector tool plays well with CSS transforms and the grid overlay will adjust to it, however, the selected element has been transformed. You will be able to see how the Grid has been rotated, skewed, scaled or translated.
As with any other browser feature, the Grid Inspector tool will inevitably have bugs as the team is hard at work adding new features and polishing existing ones. If you do encounter any such issues, please raise an issue at Bugzilla, Mozilla’s bug tracking tool.
The metabug, which tracks all Grid Inspector related issues, is Bug 1181227. You can search for the term Grid Inspector to see the list of related bugs as well.
If you have any suggestions or feedback on the Grid Inspector tool or the Firefox DevTools in general, Mozilla is on Discourse. Or you can also tweet at @FirefoxDevTools.
(This is a sponsored article.) If you manage a WordPress website, you’ve probably faced a common problem. How do you get insight into all of your content at a glance? WordPress’ admin area does not show you much about your pages, posts, users and comments. That can make it hard to find the right page, to check if all associated fields are properly filled, or simply to get a general sense of your website’s content. Does this sound familiar to you? Read on because we will demonstrate some simple custom solutions and a ready-to-deploy plugin to overcome this problem.
A modern WordPress website usually consists of much richer content than simply titles and chunks of text. Plugins such as Advanced Custom Fields and WooCommerce introduce custom fields that store specific pieces of content, such as prices, additional images, subtitles and so forth. Those functions on their own are great, but how do you keep track of all of that content when you can still only see the title, date and author in your admin screens? The answer is, you can’t.
In this tutorial, we’ll tackle this problem by showing you some easy-to-implement custom code. For those of you who don’t want to code, we’ll show you how to configure the Admin Columns plugin to do the job for you.
Also, you will learn how to:
add new columns to the posts overview,
sort your posts by these columns,
create a filtering form to find your content,
use Admin Columns to edit your content inline (without having to navigate to the individual post).
A Motivating Use Case
Imagine that you’re tasked with building or managing a website containing a real-estate agency’s portfolio. On the website, you display pictures, house addresses, locations, number of rooms and other attributes. On the admin screen, you manage the portfolio, adding, removing and editing existing real estate. The columns WordPress shows by default (title, author, publication date, number of comments) are hardly relevant for your real-estate website, and you’d be more interested in seeing the existing pictures and information about the real-estate listings as a whole.
Let’s look at a standard admin overview screen for custom post types:
This would be pretty useful if this were our website’s blog posts or news items, right? But for our real-estate portfolio, this gives us no information at all. The same goes for web shops, car dealerships, creative portfolios and so forth. Luckily, there’s a solution. We’ll work towards a far more pleasing overview of our real-estate portfolio, which will look like this:
As you can see, this gives us a lot of insight into our real-estate portfolio. It’s now much easier to find, validate and, as you’ll see, edit the content.
We’ll provide a step-by-step guide to adding custom columns to your WordPress admin screens, sorting them and adding custom filters. We’ll also show you how to do this with the Admin Columns plugin. (If you don’t want to code, you can just skip to that part right away.)
Managing Columns With Code
First up is the management of columns for admin screens: adding columns that are specific to your content type, removing columns that are obsolete, and reordering columns. For this goal, WordPress offers the Columns API. It’s available for users and taxonomies as well, but we’ll focus on the posts screen. Changing the existing columns can be accomplished using two WordPress hooks: manage_[post_type]_posts_columns, which allows you to remove, reorder and add columns, and manage_[post_type]_posts_custom_column. In place of [post_type], enter the post type you wish to target. For pages, for example, you would use manage_page_posts_columns and manage_page_posts_custom_column, respectively.
If you haven’t heard about WordPress hooks, we encourage you to move on to the “Managing Columns With the Admin Columns Plugin” section. It explains how you can manage your columns without touching any code. But if you feel like learning, then read more about WordPress hooks (filters and actions).
“Where Do I Place My Code?”
To add all of this custom functionality, we need a place to run our code. This is best done in a plugin. In this tutorial, for example, we’re creating a custom plugin to run all of this code in. If you don’t know how to create a plugin, you can learn how.
All of the code snippets we’ll provide will go in our custom plugin. It is advisable to place such code in a plugin, not in your theme.
Adding, Removing and Reordering Columns
The first hook for managing columns (manage_posts_columns) is a filter that handles the array of columns. The standard array of filters for the posts overview is this:
We’re going to remove a few columns from this list and add a few. To do so, we’ll add a callback to the manage_posts_columns filter and append our custom columns to the columns array. Note that we’re using the manage_realestate_posts_columns hook. Here, realestate is the name of our post type, passed as the first argument to the register_post_type function for registering custom post types. We use it in place of [post_type] in the manage_[post_type]_posts_columns filter.
The first line adds our function smashing_filter_posts_columns as a callback to the filter that handles the columns that are displayed. The second line defines the callback function. Lines 2 to 4 add our custom columns to the list of columns. Finally, line 6 returns the resulting columns list.
Note: The smashing_ part before our functions is just a best practice to make sure that our function name is unique in WordPress. The __ function is used for translating the string to the user’s preferred language. Notice that for both “Price” and “Area,” we use smashing as the text domain, which WordPress uses to determine what source should be used to translate the string. We can omit this for translating “Image” because WordPress already includes translations of this word itself. You can read more about text domains in the WordPress Codex.
We’ve added columns to display an image, the price and the area, and the array with the new columns has been returned. The resulting real-estate list looks like this:
Remove the “Author,” “Date” and “Comments” columns, which are irrelevant to our real-estate content.
Reorder the columns so that “Image” is first.
We’ll modify our function to accomplish this. Note that we do not explicitly remove the three columns mentioned above, but simply construct an entire new array of columns precisely as we need them. The modified lines are highlighted.
Our new real-estate overview screen is starting to take shape: Irrelevant columns have been removed, and new ones have been added in the right positions.
Next up is populating our columns. Again, WordPress provides a pretty simple hook to do so: the manage_[post_type]_posts_column action. Unlike the previously discussed hook, this is not a filter, so it only allows us to add content, not to change it. Thus, in the callback for this action, we’re simply going to echo the column content that we want to display.
We added a callback function, smashing_realestate_column, to the action 'manage_realestate_posts_custom_column', taking two parameters: the column name and the post ID. This is indicated by the fourth parameter, add_action: It specifies the number of arguments expected by the callback function. The third parameter, called the priority of the hook, determines in what order the callback functions registered to the hook should be executed. We’ll leave it at the default, which is 10. This callback function populates a single post’s “Image” column.
The remaining two columns, “Price” and “Area,” are stored as custom fields with the keys price_per_month and area, respectively. We’ll display these in the same way as we did with the image, displaying “n/a” when a price or surface area value is not available. The implementation is very similar for both columns. Starting with the price column, the changed lines in our smashing_realestate_column function are highlighted in the code block below.
Let’s move on to some of the more funky stuff. Let’s add some sorting functionality to our columns!
Making Columns Sortable
Making columns sortable is relatively easy in WordPress, yet it’s rarely implemented for custom columns. Sorting helps you organize content and enables you to find content quickly. For example, we could sort our real-estate overview by price and then find our cheapest and most expensive pieces of property.
We’ll start by adding our “price” column to the list of sortable columns:
This code hooks into the manage_edit-realestate_sortable_columns filter and adds smashing_realestate_sortable_columns as a callback function (line 1). The “price” column is made sortable by adding it to the list of sortable columns in line 3. Note that the array key, price, is the name we’ve given our column before. The array value is used to tell WordPress what it should sort by. We could, for example, use WordPress’ native sorting strategies to sort by title, date or comment count.
In our case, however, we want to sort by a custom field. This requires us to create another function, which needs to alter the posts query if we’re trying to sort by price. We’re going to use the pre_get_posts action. It allows us to change the WP_Query object (the object that WordPress uses to query posts) and fires before posts are queried. We check whether to sort by price and, if so, change the query accordingly:
Lines 1 and 2 add the callback function to the action and start the definition of the callback function, respectively. Line 3 then checks whether we’re in the admin panel and whether the query is the main posts query (see the Codex for more information). If not, we don’t change the query. Then, we check whether the current sorting strategy is by price. If it is, we adjust the query accordingly: We set the meta_key value to price_per_month, telling WordPress to retrieve this custom field for all real estate, and we set the orderby key to meta_value, which tells WordPress to sort by the value belonging to the specified meta key. Finally, we tell WordPress to sort numerically instead of alphabetically, because “price” is a numerical column.
Note: You might have noticed that the filter we hook into is named manage_edit-realestate_sortable_columns, whereas you might have expected it to be manage_realestate_sortable_columns (without the edit-). This is simply an inconsistency in filter naming in WordPress.
The result is a sortable price column:
The same procedure can be repeated for the “area” column. For textual columns, which should be sorted alphabetically, be sure to leave out the $query->set( 'meta_type', 'numeric' ) part.
Managing Columns With The Admin Columns Plugin
Now that we’ve covered the programming part of this tutorial, it’s time to move on to the much simpler method: using the Admin Columns plugin. Without touching any code and using a simple drag-and-drop interface, you can manage columns with just a few clicks. More than 150 column types exist. It comes with optional fields that let you customize how a column is named and behaves. In this last part of the tutorial, we’re going to show you how to set up Admin Columns to create the exact same overview as before. On top of that, we will show you how you can then filter and edit content directly from the content-overview screens.
First off, install Admin Columns as you would install any plugin, and activate it. It’s ready for use right away, so let’s start to manage our columns by going to the “Column Settings” page.
Admin Columns lets you control the columns per content type (for example, posts, pages, users or comments) using the dropdown box highlighted in the image above. In our case, we will select the post type “Real Estate.” You will see the screen immediately showing the columns that are currently active for this post type.
Let’s clean up a bit by removing columns we don’t need for our real-estate overview:
Wasn’t that easy? We will continue by adding our first relevant column: the featured image that shows a picture of the property. To do so, simply click the “Add Column” button, choose the “Featured Image” column type from the dropdown, and fill in the appropriate settings:
As you can see, Admin Columns shows relevant display options for your columns to give you full control over their appearance. Here, you’re asked to specify the dimensions of the image to display. Later, we will see that Admin Columns shows the appropriate options when you select a different column type. For these options, Admin Columns tries to present sensible defaults, to minimize the time required to add new columns.
The last part showed us how to drag the column to the first position. Admin Columns lets you reorder columns simply by dragging them around. Our real-estate screen now looks like this:
We’re now going to add the two columns to display the property’s living area and monthly rent. Because we’ve added these custom fields using the Advanced Custom Fields plugin, we will use Admin Columns’ ACF integration plugin for this task. However, the “Custom Field” column would have also sufficed for this purpose.
The animation below shows the process of adding the “Area” and “Price” columns:
Note: Admin Columns offers integration add-ons for quite a few other plugins, including WooCommerce, Ninja Forms and Yoast SEO.
For those who followed the code examples and paid close attention, we did not add the “City” column. It’s a little trickier to do that with code, but with Admin Columns it’s a breeze. We simply select the “Taxonomy” column and pick the “City” taxonomy, and voilà! Our result is there. Didn’t we tell you? It’s a breeze!
Depending on your mouse-handling speed, we’ve achieved this result, from top to bottom, in somewhere between two and three minutes!
Sorting and Filtering With Admin Columns
Most of what you’ve seen so far is part of the free version of Admin Columns, which can be downloaded from WordPress.org. However, there is also Admin Columns Pro, which offers additional features. We’ll discuss the most prominent features for this use case: sorting, filtering and editing. These features will help you to quickly find and update your content right from the overview screen.
Although the features might be pretty self-explanatory, I’ll explain them really quickly in the context of Admin Columns.
Sorting will display your content in a particular order based on the value of a column. It’s great for getting insight into your content very quickly. For example, it enables you see which pages have a page template and to order them alphabetically. For a regular blog, you could quickly find out which users have authored the highest number of posts by sorting users according to their post count.
Filtering helps you to find content faster. You can filter columns that have a specific value, or a value within some range (for numeric columns) or without any value set at all. For instance, you could find e-commerce products within a price range, or posts missing a featured image or custom field. You could even use multiple filters together to target content more precisely.
Let’s get back to our use case and consider a simple example: We want to find houses with the largest surface areas. This will take us only a few seconds because we can simply make the “Area” column sortable and sort by that column in the real-estate overview screen:
Now, let’s take it a step further by adding a filter: We want to find the top 10 houses with the largest surface areas, but only those with a monthly rental price between $300 and $500. Again, a few clicks are enough:
There are, of course, many other ways to sort and filter. Combined, the features are a powerful tool to gain insight into your content.
Editing With Admin Columns
The real-estate overview screen now shows all relevant information and allows you to find the content you need. However, one thing is lacking: To edit our content, we have to go to the editing page, find the fields we want to change, update them, click “Update,” and go back to our overview screen.
What if we could do the same process in just three simple steps: click, edit, save? With Admin Columns Pro, we can.
The screenshot above shows “direct editing” mode for the property title, and it’s available for almost all custom columns. In Admin Columns Pro, inline editing can be toggled from the columns settings screen. It automatically detects your content type and adds editability accordingly. With images, for instance, the media gallery will pop up.
In this example, we’ve used the Advanced Custom Fields add-on for Admin Columns, which comes with all business and developer licenses. It detects your ACF fields and adds them as possible columns. They are automatically sortable, filterable and editable — just toggle the corresponding icon.
The result is pretty neat: Our real-estate overview screen adds editing icons to all cells, and just by clicking, editing and saving, we can update our content. Let’s see that in practice: We’ve enabled direct editing for all of our custom columns, and we’re going to use that functionality to quickly update our content:
The changes are instantly saved. Should anything go wrong, undo and redo buttons are available to quickly revert.
Direct editing is supported for almost all columns. With the Advanced Custom Fields and WooCommerce add-ons, Admin Columns gives you a native editing experience as if you were editing from the details page.
Wrapping Up
Admin Columns can do much more cool stuff, but there’s just not enough room in this article. Why not take a look and check out some of the awesome features for yourself? We hope to see you there!
To get you in the right mood for December and the upcoming holiday season, artists and designers from across the globe once again got their creative ideas bubbling and created festive and inspiring desktop wallpapers for you. Wallpapers that are a bit more distinctive as the usual crowd and that are bound to add some holiday cheer to your screen.
All wallpapers featured in this post can be downloaded for free and come in versions with and without a calendar for December 2017. Happy holidays!
Please note that:
All images can be clicked on and lead to the preview of the wallpaper,
You can feature your work in our magazine by taking part in our Desktop Wallpaper Calendars series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?
December is undoubtedly the family month. As a civil engineer I worked abroad and this was the only month we were guaranteed to return home to be with our families. I tried to represent this in my illustration, using, naturally, my namesake: Rudolph, the red-nosed reindeer. Even he has the right… — Designed by Rodolfo Henriques from Portugal.
Christmas bells are swinging above the snow fields, we hear sweet voices ringing from lands of long ago… It’s time to count your blessings, sing your Christmas carols, open your gifts, and make a wish under the Christmas tree! — Designed by Norjimm Pvt Ltd from India.
There’s no more special time for a fire than in the winter. Cozy blankets, warm beverages, and good company can make all the difference when the sun goes down. We’re all looking forward to generating some hygge this winter, so snuggle up and make some memories. — Designed by The Hannon Group from Washington D.C.
Joy to the world, all the boys and girls now, joy to the fishes in the deep blue sea, joy to you and me. — Designed by Morgan Newnham from Boulder, Colorado.
A seemingly forgotten world under the shade of winter glaze hides a moment where architecture meets fashion and change encounters steadiness. — Designed by Ana Masnikosa from Belgrade, Serbia.
The winter solstice has always been special to me as a barren darkness that gives birth to a verdant future beyond imagination, a time of pain and withdrawal that produces something joyfully inconceivable, like a monarch butterfly masterfully extracting itself from the confines of its cocoon, bursting forth into unexpected glory. (Gary Zukav) — Designed by Dipanjan Karmakar from India.
At night, when the sky is full of stars and the sea is still, you get the wonderful sensation that you are floating in space. — Designed by UrbanUI from India.
It’s December! Like elsewhere in the world, it is celebration time for us. How well do you know? Santa is coming with gifts for us Indians this way. — Designed by Anish Joseph from India.
Great inspiration is Rudolph the reindeer and a song about him. Rudolph the red-nosed reindeer, had a very shiny nose… — Designed by S7 Design from Serbia.
I am a huge fan of Star Wars and there’s a new Star Wars movie premiering December 14, so I designed a parody cartoon image of Master Yoda on Dagobah wishing everyone a Merry Christmas… Yoda-style. I designed a candy cane as his walking stick and added a Christmas hat to complete the picture. I hope you like it! — Designed by Evita Bourmpakis from Greece.
Christmas is coming… Music fills the air, stars brighten up the sky, Santa is on his way loading gifts for us on his sleigh… It’s time that we awake from our slumbers, open up our hearts, and be taken by all wonders of this beautiful month! — Designed by IPIX Technologies from India.
The beauty of Christmas is in the happiness and cheers of the family that gathers around the gifts wrapped in colors of joy and peace all the way from Santa’s world. While the angels in the heaven, sing praises of the Lord, let us welcome Christmas with heartfelt joy and happiness. Wishing all a Merry Christmas and Happy Holidays. — Designed by Acodez IT Solutions from Mumbai, India.
How the snow falls in the north! Flake on flake falling incessantly, until the small dingles are almost on a level with the uplands. Let it snow! — Designed by Mozilor Technologies from India.
The snow kisses the trees and fields gently; and then covers the earth entirely with a white quilt and slowly whispers into its ears ‘Go to sleep, till the summer comes knocking at the door.’ — Designed by Tours In India from India.
I designed a front view of the famous Sassi of Matera, the Italian city that will be ‘European Capital of Culture in 2019’, by using ‘modular hearts’ and simulating the texture of typical Christmas jumpers. — Designed by Antonio Cappiello from Italy.
December 30th is the birthday of Rudyard Kipling, the writer of the Jungle Book. To celebrate, I decided to create a very festive jungle scene with some of the characters from the story. — Designed by Safia Begum from the United Kingdom.
2017 will end, hope the last month, you can do what you want to do, seize the time, cherish yourself, expect next year we will be better! — Designed by Hong Zi-Qing from Taiwan.
It is that time of the year when the world is covered in layers of white snow. Let’s bring some warmth to this cold month by getting wrapped in blankets and sipping a hot cup of chocolate by the fireplace. — Designed by TBPL Builders from India.
Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.
A big thank you to all designers for their participation. Join in next month!
What’s Your Favorite?
What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.
Everyone has an idea for a mobile app, from your mom to the guy you met in line at the grocery store. You might even be one of those people, if you are reading this tutorial. Building your own app really gives you the ability to create anything you can imagine. For some people, the idea is the easy part; when it comes to making it a reality, they have no clue where to start.
In this tutorial, we are going to look at one page of an existing app and learn how to get the design into Xcode. The design for this app was done using an app called Sketch. Sketch allows you to design anything from websites to mobile apps. It is my preference for designing mobile apps.
When you are building an app, do not jump directly into Xcode. You’ll want to work on the app’s look and feel before doing any code. This will enable you to figure out exactly what your app will do before you start coding. Fixing a design is easier than fixing code. Once you are done with the design, you will then match it in Xcode. Here are a few other options that you might want to look at if you are interested in designing an app:
Unlike Photoshop, Sketch was made for UI design right from the start; UI wasn’t an afterthought. If you’re a UI designer and are still using mostly Photoshop or Illustrator, it may be time to consider using Sketch instead. Read a related article →
Exploring The Design
One of the first things I like to do when I see an app is to review the design and see if I can figure out how they built it. Let’s first look at the design of this page:
As you can see, this is a product detail page, which might be similar to others you have seen in e-commerce apps. What I most like about this product detail page, for learning purposes, is that it contains a lot of different user interface (UI) components. Designing a UI like this enables you to explore Xcode in a meaningful way and to tackle many of the most common components you would encounter when designing an app. The following diagram breaks down the different UI components of our design page:
A UILabel is typically used to display text on a single line, although you can set it up to display multiple lines of text. This component is not interactive.
A UIStackView allows you to stack components vertically and horizontally. For example, if you wanted to display three buttons spaced 10 pixels apart, you could use a UIStackView to make it easier.
A UITextView is typically used to display multiple lines of text. Users can interact with this component by editing the text. If we simply wanted to display text, with no ability to edit, we would normally use a UILabel. However, for this tutorial, I want to introduce you to both the UILabel and UITextView components.
A UIScrollView allows you to add multiple components that scroll either horizontally or vertically.
Designing In Xcode
Before we begin designing our app page in Xcode, I want to introduce you to two important aspects of Xcode, storyboards and table views. Let’s start with storyboards.
What Are Storyboards, And Why Do We Use Them?
A storyboard is a tool in Xcode that enables us to set up our visual elements. These elements, our UI components, can be dragged and dropped into place without the need for code. If you are a visual person, you will most likely feel very comfortable with storyboards.
In addition to not having to code, I love storyboarding instead of coding all of the elements because it makes it easy for another person to understand what is going on in the project and to step in if need be. Storyboarding also makes it easier for you to step away from a project for a period of time and then come back to it. If everything is in the storyboard, it will be relatively easy to figure out what you did and where you left off, as well as to make any visual changes you desire. Plenty of people prefer coding to storyboarding, but in this tutorial I am going to show you the benefits of storyboards.
To get familiar with storyboarding, let’s review the five basic areas of Xcode.
The navigation area shows all of your files (such as Main.storyboard, where you design your visual elements) and Assets.xcassets (the blue folder), which holds your app’s icon and images.
Editor Area
The editor area is where you will work. Both storyboard and Swift files open in this area.
Toolbar
On the left side of the toolbar, you will find controls to launch your app using a simulator. On the far right of the toolbar, you will find icons that allow you to toggle different panels to be either shown or hidden.
Utility Area
When inside of a storyboard file, you will use the utility area to make changes to UI components. This area will change depending on the screen with which you are currently interacting.
Debug Area
The debug area is very useful when you are coding. It shows issues with your code that you need to address. In this tutorial, we will not be using this area because we will not be coding, focusing instead on storyboarding.
Now that you are familiar with storyboards, let’s discuss table views.
What Is A Table View?
As you can see above, our page is one in which the user scrolls down to view more information. One of the great features of iOS is that you can use a table view to scroll long pages without having to code anything. A table view is a way to list data in one column that can be vertically scrolled. A table view can have sections, and each section can have a header. There are two types of table views: dynamic and static.
Dynamic table views use code, and they typically have variable numbers of rows and/or sections based on some data. Dynamic table views are great for mailing and contact lists, which can change over time.
Static table views do not use code and instead are set up using storyboards in Xcode. They are not dynamic, and they have a finite number of rows or sections based on certain data. Static table views are good to use for things such as forms and detail pages that will not change.
For the product detail page in this tutorial, we will use static table views, which give us the flexibility to have complex layouts without having to write a lot of code. This solution will not work for every situation, but it is a good place to start.
Setting Up the Basic Structure
Let’s set up the bare bones of our basic structure; then, we can start entering the details of our page. I have already created a starter project for you, where you will find all of the assets needed to complete this tutorial. Download the files, and then open the file named DesignToXcode.xcodeproj in the file inspector in the navigation area:
As the image above shows, our storyboard contains a single view controller on the scene. Nothing else has been created, because we will create the rest together. This view controller is where we will add the UI components that we discussed.
Looking at our page design, we need to add a navigation bar at the top, which will automatically add a label and two placeholders for buttons. We will eventually update the label title to CONVERSE CHUCK TAYLORS and leave the button placeholders alone.
To add the navigation bar, we first have to add a navigation controller. So, select the view controller by choosing “View Controller” under “View Controller Scene” in the outline view or by clicking on the leftmost icon of the view controller in the scene. The outline view is located as shown in the following image:
Next, let’s update the title in our view controller to read CONVERSE CHUCK TAYLORS. Click on “Navigation Item” under the view controller. In the utility area, select the “Attributes Inspector:”
Type CONVERSE CHUCK TAYLORS in the title area. You will see the new title in the view controller in the scene.
Adding “Add to Cart” Button
Next, we need to address one of the major features of this product page. Looking at the design, you will notice that the “Add to Cart” button is pinned to the bottom and that the content scrolls underneath the button. We can create this design feature in a few different ways, but I find using a container view to be easiest. A container view is just a container that sits in our controller and allows us to use another view controller of our choice. For our design, the container view will consist of our static table view. Because a static table view cannot be dragged into a view controller with other elements, the container view will provide a separate container within which to set up the table view. In addition, the container view allows us to pin the “Add to Cart” button to the bottom, as the content is being scrolled.
The two main elements of the “Add to Cart” button are an image (the background of the button) and a button. Whenever I can, when items are grouped together, I put them into a UIView, which I treat as a container.
Let’s start setting up our “Add to Cart” button by adding the container. In the utility area, open the “Object” library, and then type view in the filter bar:
Drag the view into our view controller, and then click on the size inspector in the utility area:
Set the following values in the size inspector:
X: 0
Y: 607
Width: 375
Height: 60
Now that our container is in place, we need to add our image.
In the object library, type image in the filter area. Drag an image view into the view we just added. In the size inspector, add the following values:
X: 0
Y: 0
Width: 375
Height: 60
In the attributes inspector, set “Image” to btn-bg.
Finally, let’s add our button. Type button in the filter area, and drag the button into the same view. In the size inspector, add the following values:
X: 8
Y: 8
Width: 359
Height: 44
In the attributes inspector, add the following values:
Type: System
Title: Change Button to “ADD TO CART” in the text field above “Font.”
Font: Click the font icon, then “Custom,” and choose Avenir Next Condensed, Bold 24.0
Text color: White
Background: addtocart-bg
Now that we have set up the button, our storyboard should look like the following:
We now need to add some auto layout for our elements. Auto layout is a tool used to constrain components to the view. For example, you would use auto layout if you wanted a label to be pinned 10 pixels from the top of the view. You also would use auto layout to make sure that the label is vertically centered inside of your view. For our purposes, we will use auto layout to pin our “Add to Cart” button to the bottom of our view so that our content scrolls under it.
Let’s get started on applying auto layout to our “Add to Cart” button. First, select the view we recently added (i.e. our container), and click on the pin icon:
With the pin icon selected, enter the following values:
Left: 0
Right: 0
Bottom: 0
Height: 60 (make sure box is checked)
You can enter the left, right and bottom values just by clicking on the red barbells if their values are already at 0. After entering those values, click “Add 4 Constraints”:
Now, our elements will always be pinned to the bottom of the device, with a height of 60, regardless of how tall our device is.
Next, we want to ensure that, no matter the size of the view, the background will fill the entire area. Therefore, select the image we are using for the background, click the pin icon, and then enter 0 for the top, left, right and bottom constraints. After entering those values, click “Add 4 Constraints”:
We also need to apply auto layout to our button. Select the button, click the pin icon, and then enter 8 for the left, right, top and bottom constraints. After entering those values, click “Add 4 Constraints”:
The constraints we just added will make sure that our button is always 8 pixels from the left, right, top and bottom of the view.
Let’s see how our application of auto layout works across different devices. Rather than building and running our project for each device, we can preview how our “Add to Cart” button looks across devices quite quickly. In the top right of your Xcode screen (above the utility area), select the “Assistant Editor” button, which will split the screen:
Then, in the menu at the top of the new screen, select “Preview(1)”:
Once you select “Preview,” if you scroll to the bottom of the assistant editor screen, you will see the “Add to Cart” button pinned to the bottom of the iPhone 7 screen. Next, select and delete the iPhone 7 screen image in order to have an empty screen. Then, in the bottom-left corner, click the “+” button:
In the menu that appears, select the “iPhone SE.” Then, open this menu again and add the “iPhone 7 Plus” as well as the “iPad Pro 9.7″ | Full Screen.” When you are done, you will see the following:
Notice that auto layout works exactly as we expected. Our “Add to Cart” button has expanded to the full width of the screen and is pinned to the bottom. Feel free to look at other devices and orientations. When you are done, exit the assistant editor and return to the standard editor.
Adding a Table View
Let’s now add a table view to our design. In the object library, type container in the filter area. Drag a container view into the view, and in the size inspector add the following values:
X: 0
Y: 0
Width: 375
Height: 607
When we added our container view, you would have noticed that it created a view controller. Because we need a static table view, we will delete the view controller that was just created for us and replace it with a table view controller. Therefore, select the view controller that was created for us and hit “Delete.” Then, in the object library, type table view in the filter area. Drag a table view controller onto the scene. Then, from the container view that we just created, hold the Control button and drag to the table view controller. Select “Embed” on the screen that pops up:
You have now connected the container view to the table view controller. Next, select the “Table View” in the table view controller, and in the attributes inspector change the “Content” from “Dynamic Prototypes” to “Static Cells.” Three new cells should now be at the top of your table view controller:
As you can see, each of the five cells has different elements that we will need to add in order to create this product page. In order to get the desired layout and functionality, we need to update a few things.
First, in the outline view, select “Table View Section.” Then, in the attributes inspector, update “Rows” to 5. Select each cell, and in the size inspector update each cell row’s height to the following values:
Cell 1: 540
Cell 2: 290
Cells 3 and 4: leave as the default
Cell 5: 235
When you are done, hover your mouse over the table view in the scene, and then swipe up and down to scroll through the table view:
Select each table view cell, and in the attributes inspector update “Selection” from “Default” to “None.” Table views, by default, allow the user to select an item such as a cell. Because we do not need the behavior of cell selection, we have now removed this default.
Finally, we need to add auto layout to the container view that we added. Select the container view, click the pin icon, and then enter 0 for the top, left, right and bottom constraints. After entering those values, click “Add 4 Constraints”:
Let’s build and run the project by hitting the play button (or press Command + R). You should see our static table view, as well as have the behavior we want, which is the table view scrolling under our “Add to Cart” button:
Now that our basic structure is established, it is time to start building our product page to make it look like the design we reviewed at the beginning of this tutorial.
Updating Our Cells
We will work with one cell at a time in order to add all of the elements we need and position them in the cell, and then we’ll add auto layout to ensure that the elements will work with any device’s screen.
Cell One
In our first cell, we need two labels to display the product’s name and price. In addition, we need five images, four as product thumbnails and one for the product’s large image.
To begin, type label in the filter area of the object library, and drag two UILabels into the table view cell. Then, type image in the filter area, and drag five UIImageViews into the table view cell. We need to update each of these element’s size and position to the following.
UILabel 1
Size inspector:
X: 15
Y: 308
Width: 345
Height: 28
Attributes inspector:
Text: plain
Under text: change “Label” to “CONVERSE CHUCK TAYLOR ALL STAR HIGH TOP”
Color: light gray
Font: Click font icon, then “Custom,” and choose Avenir Next Condensed, Medium 20.0
UILabel 2
Size inspector:
X: 15
Y: 337
Width: 54
Height: 28
Attributes inspector:
Text: plain
Under text: change “Label” to $55
Color: black
Font: Avenir Next Condensed, Bold 20.0
UIImage 1
Size inspector:
X: 0
Y: 0
Width: 375
Height: 300
Attributes inspector:
Image: red-chucks
UIImage 2
Size inspector:
X: 15
Y: 474
Width: 77
Height: 50
Attributes inspector:
Image: red-chuck-thumbs
UIImage 3
Size inspector:
X: 100
Y: 474
Width: 77
Height: 50
Attributes inspector:
Image: pink-chuck-thumbs
UIImage 4
Size inspector:
X: 185
Y: 474
Width: 77
Height: 50
Attributes inspector:
Image: yellow-chuck-thumbs
UIImage 5
Size inspector:
X: 270
Y: 474
Width: 77
Height: 50
Attributes inspector:
Image: blue-chuck-thumbs
After adding all of these elements and updating all of their attributes, you should see the following in your storyboard scene:
The only remaining components we need to add to cell one are the shoe sizes. If we break this down, for when the shoe is out of stock, we need three elements: (1) the background, (2) the label and (3) the slash image. If the shoe is in stock, we need just the background and the label. Earlier, I mentioned that whenever elements are grouped together, I prefer to put them in a container. The shoe size elements are an instance of this.
Let’s begin setting this up by dragging a UIView, which will act as our container, into our first table view cell. In the object library, type image in the filter area and update the following values in the size inspector:
X: 15
Y: 374
Width: 40
Height: 40
Next, in the object library, type image in the filter area and drag a UIImageView into the container we just created, and then update the image with the following values:
Size inspector:
X: 0
Y: 0
Width: 40
Height: 40
Attributes inspector:
Image: outstock-bg
Now, in the object library, type label in the filter area and drag a UILabel into the same container, and update the following values for that label.
Size inspector:
X: 0
Y: 0
Width: 40
Height: 40
Attributes inspector:
Text: plain
Under text: change “Label” to 8
Color: light gray
Font: System 17.0
Alignment: center (icon)
Finally, in the object library, type label in the filter area and drag another UIImageView into the same container, and then update the image’s following values:
Size inspector:
X: 0
Y: 0
Width: 40
Height: 40
Attributes inspector:
Image: slash
At this point, your storyboard should look like this:
Now, we need to duplicate this element to create all of the different shoe sizes.
For the first row of shoe sizes, in the outline view, select the container that we just created and hit Command + C to copy, and then hit Command + V to paste. Continue to hit Command + V until you have seven of these containers.
We need to ensure that all seven of these views stay the same size, in both height and width, when in a StackView, which, as the name suggests, allows us to stack both horizontally and vertically.
First, select all of these views in the outline view (hold Shift, and then click the first and last one to select all):
Our containers are now all in a StackView. However, they are stacked right next to each other. To fix this, in the outline view, select the StackView that we just created, and in the attributes inspector update the following values:
Axis: horizontal
Alignment: fill
Distribution: equal spacing
Spacing: 10
We need to add another row. With the StackView still selected, hit Command + C to copy, and then Command + V to paste. Once you paste the new StackView, move it to right under the first one. They do not need to line up perfectly.
Next, select both of the StackViews and then the StackView icon. Similar to when we selected the StackView icon, the StackViews are now stacked; however, they are on top of each other, rather than next to each other. Select the main StackView, and in the attributes inspector update the following values:
Axis: vertical
Alignment: leading
Distribution: equal spacing
Spacing: 7
Then, click the pin icon and enter the following values:
Top: 9
Right: 15
Left: 15
Height: 87
Constrain to Margins: unchecked
Click “Add 4 Constraints.”
Select one of the other two StackViews in the outline view, click the pin icon, and enter the following values:
Right: 0
Left: 0
Height: 40
Constrain to Margins: unchecked
Click “Add 3 Constraints.” Repeat this step for the remaining StackView. When you are done, you will see the following:
Finally, select the last four boxes of the bottom StackView, and hit “Delete.” When you complete this step, the boxes will fill the space evenly.
Our next step for setting up cell one is to change the “8” in each of the boxes to the shoe sizes that are in our example page. In addition, we need to adjust two of the boxes to reflect the sizes that are in stock, 9 and 9.5, without a slash through the boxes.
To change the 8 to another shoe size, select the label under the view for a particular box, and in the attributes inspector change the 8 to a new shoe size. Repeat this for each of the sizes in our design.
Lastly, to show that size 9 is available, select the view with “9” as the label, and in the attributes inspector change the outstock-bg image to instock-bg. Repeat for the view with “9.5” as the Label. Then, in the outline view, for each of these two sizes, select the slash image and click “Delete.” This will now show that you have two sizes in stock, 9 and 9.5:
Cell one is now complete.
Cell Two
Let’s add our elements to cell two. Here, we have two components, a UILabel to display our header and a UITextView for a large body of text. Drag one of each into our second table view cell. With the label selected, update the following values.
Size inspector:
X: 18
Y: 7
Width: 109
Height: 21
Attributes inspector:
Text: plain
Under text: change “Label” to “DESCRIPTION”
Font: Avenir Next Condensed, Demi Bold 14
Next, with the text view selected, update the following values:
Size inspector:
X: 13
Y: 22
Width: 362
Height: 261
Attributes inspector:
Text: plain
For the text, enter the following:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec id maximus erat, imperdiet iaculis ligula. Curabitur elit dui, ullamcorper ut rutrum in, facilisis non nibh. Maecenas eget ipsum dictum, commodo purus id, aliquam lorem. Duis vitae tincidunt velit. Praesent vestibulum et velit vel tempus. Vivamus fringilla sollicitudin cursus. Nunc sit amet elit mauris. Sed quis tincidunt sem. Proin a rutrum nibh. Nunc porta aliquam dolor at sollicitudin. Nam nisl diam, mattis vel sapien a, eleifend convallis lacus.
Proin tortor arcu, semper vitae blandit pharetra, efficitur eu purus. Sed pharetra odio vitae massa efficitur dapibus. Aenean vitae arcu sollicitudin, mollis erat et, convallis dolor. Mauris feugiat mi elit, ac suscipit mi tempus sodales. Aliquam vitae odio luctus sem bibendum eleifend. Praesent eu aliquet justo, quis tristique dui. Nunc sed purus purus.
Font: Avenir Next Condensed, Ultra Light 17
This text view is now set up to match our design. So, the height of 261 that I asked you to enter above is to completely show all of the text we entered. Feel free to experiment with this by changing the amount of text, which would then require a change in height as well.
In regards to UITextView versus UILabel, I honestly do not use UITextView much. My preference is to use UILabel, but in this tutorial I wanted to show you both. I do not have a reason for using the latter other than I just like it more. For this cell, we are adding dummy data to match our design. If you were trying to make the UITextView or UILabel dynamic in height, you would need to do some auto layout updates. For this tutorial, set the height manually and rest assured that the heights of both UILabel and UITextView will adjust to their content’s size using auto layout.
Lastly, let’s add some auto layout to our cell items. First, select the label, click the pin icon, and then enter the following values:
Top: 7
Left: 18
Width: 109
Height: 21
Then, click “Add 4 Constraints.”
Select the text view, click the pin icon, and enter the following values:
Top: 22
Right: 0
Bottom: 6.5
Left: 13
Constrain to Margins: unchecked
Click “Add 4 Constraints.” Cell two is now complete.
Cells Three and Four
Cells three and four are basically the same, except for their text. First, drag a UILabel into each of cell three and cell four. For each label, enter the following values.
Size inspector:
X: 18
Y: 10
Width: 109
Height: 21
Attributes inspector:
Text: plain
Font: Avenir Next Condensed, Demi Bold 14
Finally, for the text, for cells three and four, change “Label” to “SIZE GUIDE” and to “REVIEWS (0),” respectively.
Cell Five
Let’s update our last cell. As you can see from the design we reviewed at the beginning of this tutorial, cell five contains a UIScrollView in order for our “You may also like” section to scroll from left to right. ScrollViews can be created through code; however, consistent with the rest of this tutorial, we will build a working ScrollView with no code.
First, drag four UIImageViews into the cell, next to each other (even overlapping them in order to fit). In the size inspector for each image, change the width to 118 and the height to 172. Then, in the attributes inspector, change “Image” under the four image views to mn-hoodie1, mn-hoodie2, wm-hoodie1 and wm-hoodie2, in any order you like. When you are done, you should have something resembling the following:
Next, select all four images and select the pin icon. Set the width and height for all four images by clicking the boxes next to width and height and then on “Add 8 Constraints.” With the four images still selected, hit the StackView icon. In the attributes inspector, update the following values:
Axis: horizontal
Distribution: equal spacing
Spacing: 10
As you can see below, the images are now spaced equally, with 10 pixels in between:
Next, we need to put the StackView inside of a view. Select the StackView that you just created, and in the Apple toolbar click on “Editor” → “Embed In” → “View.” We need to adjust the size of the newly created view by updating the width to 502 and the height to 172. We also need to adjust the position of where the StackView is located in this new view. Select the StackView and enter the following values in the size inspector:
X: 18
Y: 0
Now, we need to get everything we just created into a ScrollView. Select the view in which the StackView resides, and then select “Editor” → “Embed In” → “Scroll View.” With the new ScrollView selected, enter the following values in the size inspector:
X: 0
Y: 0
Width: 375
Height: 172
Lastly, in order to make our images scroll, we need to put the ScrollView in another view. Select the ScrollView, and then click “Editor” → “Embed In” → “View.” With this new view selected, enter the following values in the size inspector:
X: 0
Y: 33
Width: 375
Height: 172
The last element we need to add is a UILabel. Drag a label into cell five, and enter the following values in the size inspector:
X: 18
Y: 3
Width: 116
Height: 21
In the attributes inspector, enter these:
Text: plain
Under text: change “Label” to “YOU MIGHT ALSO LIKE”
Font: Avenir Next Condensed, Demi Bold 14
Let’s add auto layout to our elements in cell five. With the Label selected, click the pin icon, and enter the following values:
Top: 3
Left: 18
Width: 116
Height: 21
After entering the values, click “Add 4 Constraints.”
Then, for all of the other elements in cell five, to add auto layout, ensure that all of the disclosure arrows are open in the main view container that is holding the ScrollView, and ensure that you can see all the way to your images, as follows:
Now, select the StackView, click the pin icon, and enter the following values:
Top: 0
Right: 0
Left: 0
Height: 172 (should be checked)
When you are done entering the values, click “Add 4 Constraints.”
Next, click on the align icon, which is just to the left of the pin icon, and enter the following values:
Horizontally in container: 0 (should be checked)
Then, click “Add 1 Constraint.”
Next, in the outline view, select the view that is holding the StackView. With that view selected, click the pin icon and enter the following values:
Top: 0
Right: 0
Left: 18
Bottom: 0
After entering the values, click “Add 4 Constraints.”
In the outline view, select the ScrollView, click the pin icon, and enter the following values:
Top: 0
Right: 0
Left: 0
Bottom: 0
Then, click “Add 4 Constraints.”
Finally, in the outline view, select the main container (the view holding the ScrollView), click the pin icon, and enter the following values:
Top: 0
Right: -8
Left: 0
Height: 172 (should be checked)
When you are done, click “Add 4 Constraints.” You have now completed all of the auto layout for cell five.
Let’s build and run the project by hitting the play button (or press Command + R). You will now be able to see your ScrollView working without having had to code anything. If you run your project on multiple devices, you will also see that everything fits the way it is supposed to.
Where To Go From Here?
Now that you have completed this tutorial, my first suggestion would be to try repeating what you’ve done without referring to the steps in the tutorial. Once you are comfortable with storyboarding in Xcode, take some time to learn Swift 3. By knowing Swift, you will be able to add a product list as well as to show products on the detail page that we just created with dynamic data. If you still want to learn more, check out my book iOS 11 Programming for Beginners, which will be released later this year.
Summary
In this tutorial, you’ve learned how to bring a design into Xcode without any code. You’ve also learned how to look at a design and figure out what components it has. Then, you added all of the components of the design into storyboards and updated them to match the design. You’ve also learned how to add auto layout so that the design looks good on any device. Hopefully, this tutorial has introduced you to the ease and possibilities of storyboards. The more you work with storyboards, the more comfortable you will get.
As a full-time iOS engineer, I love doing the design side of an app because it helps me to become a better engineer. To me, it is always fun going into the App Store or looking at my favorite app and trying to figure out how they built it, including how they designed it. I really enjoy trying to recreate an app that catches my eye.
If you are a designer, I am sure you have seen plenty of designs that are not perfect. I am OK with my design not being perfect, and you should feel that way with your app’s design. You have to start somewhere, and with the help of other designers and developers, you will improve. Hopefully, this tutorial has opened your eyes to some things that you did not know or at least enabled you to hone your existing skills.
The influence of design is expanding beyond the realms of typography and objects and into healthcare, public policy, education, financial services, and more. Designers working in these emerging design fields are responsible for projects that have significant and fundamental impact on the quality of people’s lives with clear ethical implications.
In healthcare, for example, designers are responsible for creating everything from the industrial designer’s medical device that keeps a heart beating to the service designer’s physical layout of an operating room. Clinicians, with similar levels of influence, initiate their professional practice by swearing to follow the Hippocratic Oath. This sets specific boundaries that guide the ethics of their behavior. Designers, on the other hand, are given no guidance for ethical decision-making even as they continue to expand their influence into newer and riskier fields with long-standing moral implications.
Are designers talking about ethics in their practices? Do designers need or want ethical guidelines? Who should be involved in creating ethical guidelines for a design practice or project? Is there one code of ethics for all types of design and designers?
This article explores multiple interactive methods to create ethical guidelines with interdisciplinary teams using design.
Designing Healthcare Apps
As designers, we have the power to help millions of people live longer, healthier and happier lives. But a truly delightful and meaningful app doesn’t happen by magic.Read a related article →
Ethics In Design History
Small design groups have been exploring ethics in design through manifestos like First Things First in 1964 where Ken Garland focused on the responsibilities of designers working in advertising. In 2007, Valerie Casey’s Designer’s Accord project brought designers, educators, and business leaders together to define guidelines around environmental sustainability in design.
Later, in 2009, David Berman wrote the Do Good Pledge to encourage graphic designers to pledge ten percent of their professional time to “doing good” while simultaneously adhering to moral codes in their work. Unlike these existing manifestos, pledges and projects, we were interested in how designers might collaboratively create ethical guidelines for specific project engagements and teams.
With this rich history in mind, we set out to understand how designers thought about and used ethics in contemporary design. We spent a year asking interaction designers, service designers, game designers, graphic designers, industrial designers, and designers in the healthcare space if they were talking about ethics in their practices, trying to understand if designers felt the need for ethical guidelines and if so, how we could help designers develop them. We connected and engaged with 50 designers through an effort with the Service Design Network publication, BarnRaise (a design hackathon event in Chicago), and an IxDA conference workshop.
We had a few hypotheses about how ethics would work and about the ethical guidelines that we hoped to create:
Ethics were the personal responsibility of individuals
If we talked to enough people, we would be able to create a single code of ethics that would be applicable across design and
We would be able to create a replicable process to guide people in the creation of these ethical codes.
We conducted our exploration in three stages:
First stage: “Shifting Ethical Responsibilities From Individuals To Communities”
Second stage: “Creating Project-Specific Ethics”
Third stage: “Breaking Down Barriers Through Conversation”
Shifting Ethical Responsibilities From Individuals To Communities
As the year progressed, we learned that not all of these hypotheses were correct. We began our work by collaborating with Mad*Pow and the Service Design Network by inviting 15 designers from across the nation to each remotely rewrite one piece of the Modern Hippocratic Oath, the ethical guideline for medical doctors, to make it applicable to design.
We selected designers from different backgrounds (game design, graphic design, healthcare, and industrial design) to see if the essence of ethical responsibility was different across design disciplines. Each designer received a fill-in-the-blank template to express their individual ethical guidelines.
We stitched these 15 templates together to create three Designer’s Oaths. Each designer had been assigned one of five sections of the MHO to rewrite, so we placed the pieces back in the order of the original MHO. We had invited 15 designers to take part, so we were able to form three distinct Oaths. This process allowed us to showcase individual design voices as well as highlight their collective representation of a broader community. We formalized these templates and published them online to make the Designer’s Oath an open-sourced tool that anyone can use to document their individual or communal ethical guidelines.
It is important to stress the remote work that was done at this stage. None of these designers ever met face-to-face or had the opportunity to influence each other’s Oaths. We would learn the importance of in-person collaboration when we began to work with specific project groups. By nature, design is collaborative, so we needed to begin to think about how ethics could be created through collaboration rather than individual reflection.
Creating Project-Specific Ethics
The SDN experience helped us realize that we were asking the wrong questions about ethics in design. Ethics are not something one person decides for everyone in a community. In fact, different groups might require different types of ethics specific to their situation. How could we create a tool that teams could use to define the ethical guidelines of their collaboration?
Moving forward with this idea, we experimented with more open-ended tools and conversation prompts. We wanted to give teams of people coming from different backgrounds the flexibility to create their ethical guidelines without a template. We were able to explore this concept at BarnRaise, an interactive conference/hackathon for social impact design. We led a multidisciplinary team through the entire design process from research to prototyping in one weekend. We kicked off the experience by facilitating and documenting a conversation with our team to define their ethical guidelines as a collective. The conversation focused on how the team would work together and which responsibilities they collectively had for the people they were designing for.
We began by sharing the Hippocratic Oath to spark our team thinking about what a code of ethics might look like. The conversation followed about the community that we would be working with and how we, a design team, should understand our relationship with them. We then focused on answering questions like, “What approach do we want to adapt to address this problem? What is the spirit with which we want to address this problem? What role does the community play in understanding and addressing the problem?”
Through these conversations we crafted an oath that outlined their ethical guidelines as a team specific to their project work over the next few days (see below). This document framed the space they were working in, the methodologies they would use, and the mindset they needed to accomplish this task.
The team, called “Team Neuron Sparks”, referenced their oath throughout the design process. They had been tasked with answering the question, “How might we support stroke prevention by empowering community leaders to educate community members on the South side of Chicago?” The team’s oath heavily influenced their design process, guiding the manner in which they conducted interviews with community leaders and leading them to perform a participatory design exercise.
The oath also kept the team focused on understanding the community members holistically in the context of their lives. It helped them maintain their commitment to conducting interviews with humility and with respect for the dignity of the community. In the end, they created a prototype of an orientation kit for community leaders considering spearheading stroke prevention and a digital app that allowed them to coordinate their efforts. These prototypes have been adopted by the team’s clinician lead who is continuing to iterate on them with support from IIT + ID, the graduate school of design at Illinois Institute of Technology.
Ethics are not something that you decide on once and never revisit. Working with “Team Neuron Sparks” helped us realize how important it was to continue to talk about ethics throughout a project, not just at the beginning. Ethics are alive and must be iterative as our knowledge and position about a project grows and changes. With this in mind, we decided to focus the next effort of our journey on facilitating conversations around ethics.
Breaking Down Barriers Through Conversation
Conversation facilitation led us in an unexpected direction: game design. Our final ethical inquisition led us to create a role-playing game, Ethics Quest, which we play-tested at IxD16, in Helsinki. Ethics Quest encourages members of a multidisciplinary project team to role play through several ethical situations, each taking on a new role in the process. This empathy-building exercise removes the self from ethical conversations, lowering the barrier to entry and making participants more comfortable talking about difficult subjects.
A role-playing game named “Ethics Quest” (Large preview)
The game gives players the opportunity to take on a role in a project team that they do not play in real life. We provide backstory, skills, and experience to help players get into character and understand how their role might perceive a situation. Players go through 3 different situations: solo, head to head, and cooperative so the player can ease into their character before taking on ethical situations (or “combat”) against another team member.
With Ethics Quest, we discovered that conversations between team members were the most powerful tool for changing the way people thought about ethics. Conversations about ethics are often difficult and awkward, but by framing these conversations within the “safe space” of a game, we were able to make things easy and even enjoyable. Ethics Quest also helped people empathize with the goals and perspectives of others which is an essential ingredient for a productive conversation. These realizations helped us shift our focus from creating tools that document ethical guidelines to focusing on the importance of ethical conversations. With this in mind, we are continuing to iterate on Ethics Quest, exploring new ways to incorporate it with project teams and design education.
Ethics Quest helps team members change the way they think about ethics. (Large preview)
What We Learned
At the end of our year of asking questions, we realized that our initial assumptions about ethics in contemporary design had not been correct.
General ethics for design cannot be created by a single entity.
Ethics are dynamic, a living breathing thing, unique to each team.
Ethics require care and attention from every member of a team to stay alive and relevant.
The only way that each team member can feel the personal ownership necessary to maintain a collective code is by taking part in thoughtful, reflective, and co-creative conversations designed to create and regularly breathe life into the team’s ethical guidelines.
This evolution in our understanding of ethics changed how we understood our role as designers. We shifted from seeing ourselves as creators of static ethical documentation to being the facilitators of conversations that would change the practice of design ethics. If we hope to change the function of ethics in our profession, then we must first change how we view our role in that process. We must become designers of conversations and find new ways for people to relate to and communicate with each other.
This shift is necessary not only to change the view of ethics within our profession but also to position designers to be catalysts for ethical change within our larger organizations. As designers, we have the opportunity to design conversations about ethics with every team we are a part of, influencing the perception of ethics in any organization wielding the power of design. Through these conversations, design can become a powerful tool for doing good.
Taking The Next Step
Take action by facilitating these conversations and empowering your teams to design ethically.
Start small and think about your own ethical guidelines first.
Consider any duties you believe you have as a designer. What or who do you stand for in your design work?
Write, draw, or find some other way you feel comfortable expressing and documenting your ethical guidelines.
Engage with your project team and invite them to think about their individual ethical guidelines.
Ask each individual team member to express and document their ethical guidelines. Consider how you might make this easier for people by co-opting an existing guideline by turning it into a fill-in-the-blank outline, prompting alternative ways of thinking by asking people to express themselves visually instead of verbally, or creating a safe space to talk about ethics by using gameful design.
Share and discuss with each other to understand and empathize with each team member’s ethical beliefs.
Facilitate a team discussion about how you might combine your individual ethical documents into one collective statement that is specific to your team’s problem space or current engagement.
Consider answering the following questions: what roles are represented by the group assembled? What roles are missing? Who are you designing for? What are the specific concerns and ethical ramifications of the problem space? How do you ensure ethical alignment and integrity of the project throughout the engagement? How might you invite “end users” to collaborate on these guidelines? How does your statement interact with other relevant professional codes?
Document your discussion by collectively crafting an ethical statement to guide your team’s decisions throughout your engagement.
What happens when we take the web browser out of web browsing? Google’s new “Add to Homescreen” feature delivers fast, focused web experiences that are indistinguishable from those of a native app. What can designers learn from the successes of early adopters such as Twitter, and how can we leverage app-like design patterns to tackle this brand new set of user experience challenges?
The “Add to Homescreen” installation process, as shown on Google Chrome Developer’s mobile website (Image source) (Large preview)
We’ve seen debates on the topic of native versus web experiences. Both have their pros and cons, but very often the biggest downside of the in-browser experience is that it doesn’t feel as reliable, fast and immersive as the native app experience.
In this article, we will cover tips and tricks for designing and developing progressive web applications (PWAs), specifically the ones that are added to the home screen on Android devices. But first, let’s see a couple of examples and make a case for PWAs.
From Web Apps To Desktop Apps
Did you know that you can add “desktop app developer” to your resumé with just a little more effort? All you need to do is look over some API documentation and create your first modern desktop app. Read a related article →
The Rise Of The App-Like Experience
PWAs are, simply put, websites that look and feel like native applications. In his talk at the Google I/O developer conference, Google’s VP of Product, Rahul Roy-Chowdhury, describes them as “a radically better web experience… which users love and are more engaged with.”
The numbers back up Rahul’s claims. Forbes has seen its user engagement double since the launch of its PWA. The numbers also continue to show growth in the e-commerce sector, with Lancôme seeing a large increase in conversion rates following the launch of its new PWA.
These kinds of fast, fluid, app-like mobile experiences are what users want and will come to expect as more PWAs emerge in the mainstream market. One feature that will seem to accelerate this wave is “Add to Homescreen,” which is basically a PWA installation process. For the end user, adding a PWA to the home screen kicks off that app-like experience.
What Is “Add To Homescreen,” And Is It Worth It?
“Add to Homescreen” is a feature that installs a PWA to Android’s home screen, making the PWA instantly accessible without the user needing to open a browser and type the URL or use a search engine. (Side note: Even though a similar feature has been available on iOS Safari since the earliest iPhones, users were not offered much to simulate the behavior of an app. For this reason, Safari’s version is not a part of this article.)
As reflected in Google’s Lighthouse checklist, PWAs with this capability score higher and, as a result, are likely to rank better in search results.
Take Twitter Lite, a PWA. Traditionally, Twitter has found it difficult to re-engage its millions of users on the mobile web. Since introducing the “Add to Homescreen” prompt to its Twitter Lite PWA, it is seeing 250,000 unique daily users launch the web app from the home screen at an average of four times a day.
Twitter Lite’s “Add to Homescreen” prompt and subsequent PWA launched in full-screen mode (Large preview)
The retail sector is also seeing success. Alibaba has reported a four-times higher interaction rate after users added the PWA to their device’s home screen, and Flipkart has seen a 70% increase in conversion rate among shoppers who arrived via the home-screen icon.
Although “Add to Homescreen”’s user base is limited to Android Chrome, the feature rewards this highly engaged minority with an immersive, more exclusive experience — a role traditionally played by native apps.
Aren’t Progressive Web Applications Just Websites Wrapped Up As Apps?
These are the kind of statistics that would lead any retailer down the path of native app development. However, with the average cost of a native app sitting at around $270,000, “Add to Homescreen” offers an attractive financial alternative.
Users couldn’t care less about whether a technology is native, an installed web app or a website. What makes users engage and makes shoppers convert is the experience itself:
Does it load quickly?
Does it work offline?
Is navigation instant?
Does it integrate seamlessly with the device?
These are the characteristics of app-like design that must be incorporated if “Add to Homescreen” is to deliver the kind of high engagement statistics commonly associated with native apps.
What Makes An Experience App-Like?
“Add to Homescreen” creates an experience focused solely on the app in question. The website is launched via an app icon, without the browser’s URL bar or any navigation toolbar that would otherwise offer links to external websites.
It’s a good starting point, but we must also recognize and meet certain expectations of native app users if the experience is to feel truly app-like, including:
instant page transitions;
high perceived performance;
offline accessibility;
full device integration;
app-style navigation;
back button;
sharing action;
copy URL, print, and go forward.
Ready to dive in? Let’s look at each one.
Instant Page Transitions
Users expect to be able to get in and around an app quickly, without waiting for new content to load after each interaction.
Solved With PWA
For a PWA to pass the Lighthouse checklist, it must follow certain performance-enhancing guidelines. Content must be cached behind the scenes, and new pages must load so quickly that it feels like there was no loading event.
Fast page transitions in Pure Formulas’ PWA (Large preview)
Perceived Performance
Amazingly, the level of stress caused by mobile delays is comparable to that of watching a horror movie! Users who download an app do not expect to have to wait for their content. Nor are they willing to suffer a disjointed experience caused by elements appearing asynchronously as they load.
Solved With PWA
The “Add to Homescreen” PWA launch transition (see Flipkart example below) provides a visual bridge between loading and loaded content. This is an example of how “preloaded states” can enhance the perception of speed and seamlessness. A well-designed PWA will build on this idea by using placeholders (skeletons) that mimic the end state of the page and by using lazy-loading to deprioritize elements that are out of view, making the initial loading seem faster.
Built-in app loader provides a smooth transition to the content, as seen in Flipkart’s PWA. (Large preview)
Works Offline
Users who download native apps do not expect to have to rely on an Internet connection in order for the apps to function properly.
Solved With PWA
Service workers (a technology that improves the offline experience) can be used to instantly display online content in areas of low or no connectivity. Page content is cached behind the scenes, allowing it to be accessed where there would otherwise be a lag in the browsing experience, such as when entering a tunnel on a train.
Offline browsing, as shown on Merlin’s Potions (Mobify’s PWA demo) (Large preview)
Full Device Integration
There are certain locations on a device where users expect to find and manage their apps.
PWA Solution
PWAs added to the home screen now show up anywhere you’d expect an Android app to show up. This includes the app launcher, task switcher and system settings. This also ensures that any other app that links to a page on the PWA, such as a Google search or social media link, will open the app and not the browser. Push notifications even appear as if they come from a native app.
Trivago’s PWA, as shown in the app launcher, device search and system settings (Image source) (Large preview)
App-Style Navigation
Apps share a common approach to navigation. The header bar typically shows the title of the current section in the center; the back button is in the top left; and any contextual actions (favoriting, sharing, etc.) are in the top right.
No PWA Solution, Yet
This pattern is not common on the mobile web. Instead, these actions are found in the browser’s built-in functionality (for example, the browser’s back button). The web works this way for a reason. An app will typically start from the same screen each time, whereas mobile web users are often referred from search or social media — any page can be their landing page. For this reason, the logo and other global actions take center stage in the header bar and remain there throughout the experience.
Etsy’s mobile website (left) and its Android app (right) illustrate how app headers typically differ in design — the latter favoring contextual actions such as sharing over global elements such as the logo and sign-in link. (Large preview)
This expectation must be addressed if PWAs with “Add to Homescreen” are to really feel like apps. In order to do this, designers must figure out how to recover key navigation patterns now lost with the browser.
Back Button
Some might argue that because Android provides a back button through the device itself, then there is no need to replace the browser’s back functionality. In fact, the two interactions do different things. Most apps continue to offer a back button in the header as an “up” action, to navigate within the hierarchical relationship between pages. The system’s back functionality might close a modal window or navigate to a different app entirely.
The back button is a useful interaction in both Chrome iOS and Opera for Android’s web browsers. (Large preview)
Solution
One possible solution is to replace the menu button in the top left with a back button once the user progresses past the initial page. This was validated when we put this pattern in front of users. Once participants had progressed through the initial home page (and a menu icon was no longer visible), we asked them to navigate to a new section. Six out of six intuitively used the back button to navigate to the home page, where they could open the menu.
Proposed menu and back-button placement in PWAs added to the home screen (Large preview)
Sharing Action
Built into the user interface of any web browser is the ability to share a page on social media and through other apps installed on the device.
Both Chrome and Samsung Internet browsers have a sharing action available behind a menu overlay. (Large preview)
Solution
Designers should provide more prompts to share commonly shared content within the page. We found during testing that users will typically look for sharing buttons around the page’s head or product image before opening any menus. If the functionality was not found, participants expected to find a sharing icon in the header bar.
The “More” icon is an Android-esque pattern used to indicate an overflow of options. Try adding the sharing action behind a menu like this. It is even possible to trigger Android’s native sharing dialog using the Web Share API (which, at the time of writing, is a Chrome-only feature and still not standards-tracked).
Proposed menu overlay with global sharing prompt (Large preview)
Copy URL, Print, Go Forward
Less common actions, such as copying the URL and printing, are basic functions of a browser and should not be overlooked.
Copying a URL is a useful interaction in many different situations. (Large preview)
Solution
An easy way to offer copy-URL and print functionality is by using the Web Share API (again, at the time of writing, supported only in Google Chrome). Alternatively, they can be presented as separate options in the overflow menu. This menu can then be extended to include the forward action or anything else that would benefit from a persistent location in the header bar (logging in and out, for example).
Actions such as copying a URL and sending to a printer can be accessed via the sharing option, demonstrated here using the Web Share API. (Large preview)
How To Make It Work In The Real World
It will take time for “Add to Homescreen” to develop into an accepted group of patterns. Below are some best practices that could help in this development.
Sticky Headers, Persistent Actions
“Add to Homescreen” early adopters Flipkart and AliExpress both recognize the importance of learnability when introducing new patterns. They ensure that users always know where to find crucial global actions (back, cart, search): in a header bar that sticks to the top of the screen.
Modern PWAs AliExpress, Flipkart and Snapdeal share commonalities in the design of their header bars. (Large preview)
Prompt Intelligently
Since the Google Chrome team announced that it would be giving PWAs full control of when to prompt users, “Add to Homescreen” installations have increased. Flipkart saw a threefold increase in engagement when prompting users after they had made a purchase.
Example of Flipkart’s “Add to Homescreen” prompt on the order-confirmation page (Large preview)
Stress and Test
Part of the validation process for any new pattern is to stress test it in multiple applications. We found that the pattern stood up well to the edgiest of edge cases. The header bar in Lancome’s PWA contains many calls to action. Lancome identified the overflow menu as a great opportunity to simplify its user interface, while offering exclusives to power users whom it expected to use “Add to Homescreen,” exclusives such as a link to its loyalty program.
This interactive prototype was used to test the proposed pattern. (Large preview)
Where Is “Add To Homescreen” Supported?
Apple has announced it will support service workers, but it has also made a commitment to making the App Store an attractive place for native app developers to spend their time and money. This could be the reason why iOS’ Safari browser has been slow to adopt PWAs and browserless web browsing, despite advances from competitors.
Samsung Internet browser has developed a persistent “Add to Homescreen” prompt within the browser bar, so that users always know where to find it.
“Add to Homescreen”’s persistent location in the new Samsung Internet browser (Image source) (Large preview)
Windows takes “Add to Homescreen” one step further. Any PWA with this ability will now be listed in the Windows Store as a downloadable app. These apps are light and can be installed on desktop and tablet devices quickly, running the websites as convenient, browserless experiences.
Jig.space’s PWA is shown as a downloadable desktop app in the Windows store. (Image source) (Large preview)
Conclusion
“Add to Homescreen” offers an immersive, exclusive experience to the highly engaged, converting user. While adoption grows, both in user base and the devices that support the feature, validation can be found in early success stories, such as Twitter Lite. These stories show how a more modern, app-like web can have a positive effect on engagement when it meets user expectations of performance and design.
These expectations are met by combining PWA performance enhancements with intuitive design patterns in navigation and app-like user experiences. With this, we can pave the way for a new era of browserless web browsing.
Editor’s Note: This article originally appeared on Inclusive Components. If you’d like to know more about similar inclusive component articles, follow @inclusicomps on Twitter or subscribe to the RSS feed. By supporting inclusive-components.design on Patreon, you can help to make it the most comprehensive database of robust interface components available.
Classification is hard. Take crabs, for example. Hermit crabs, porcelain crabs, and horseshoe crabs are not — taxonomically speaking — true crabs. But that doesn’t stop us using the “crab” suffix. It gets more confusing when, over time and thanks to a process called carcinisation, untrue crabs evolve to resemble true crabs more closely. This is the case with king crabs, which are believed to have been hermit crabs in the past. Imagine the size of their shells!
In design, we often make the same mistake of giving different things the same name. They appear similar, but appearances can be deceptive. This can have an unfortunate effect on the clarity of your component library. In terms of inclusion, it may also lead you to repurpose a semantically and behaviorally inappropriate component. Users will expect one thing and get another.
The term “dropdown” names a classic example. Lots of things “drop down” in interfaces, including the set of <option>s from a <select> element, and the JavaScript-revealed list of links that constitute a navigation submenu. Same name; quite different things. (Some people call these “pulldowns”, of course, but let’s not get into that.)
Dropdowns which constitute a set of options are often called “menus”, and I want to talk about these here. We shall be devising a true menu, but there’s plenty to be said about not-really-true menus along the way.
Let’s start with a quiz. Is the box of links hanging down from the navigation bar in the illustration a menu?
A navigation bar with includes a shop link, underneath which hangs a set of three further links to dog costumes, waffle irons, and magical orbs respectively. (Large preview)
The answer is no, not a true menu.
It’s a longstanding convention that navigation schemas are composed of lists of links. A convention nearly as longstanding dictates that sub-navigation should be provided as nested lists of links. If I were to remove the CSS for the component illustrated above, I should see something like the following, except colored blue and in Times New Roman.
Semantically speaking, nested lists of links are correct in this context. Navigation systems are really tables of content and this is how tables of content are structured. The only thing that really makes us think “menu” is the styling of the nested lists and the way they are revealed on hover or focus.
That’s where some go wrong and start adding WAI-ARIA semantics: aria-haspopup="true", role="menu", role="menuitem" etc. There is a place for these, as we’ll cover, but not here. Here are two reasons why:
ARIA menus are not designated for navigation but for application behavior. Imagine the menu system for a desktop application.
The top-level link should be usable as a link, meaning it does not behave like a menu button.
Regarding (2): When traversing a navigation region with submenus, one would expect each submenu to appear upon hovering or focusing the “top level” link (“Shop” in the illustration). This both reveals the submenu and places its own links in focus order. With a little help from JavaScript capturing focus and blur events to persist the appearance of the submenus while needed, someone using the keyboard should be able to tab through each link of each tier, in turn.
Menu buttons which take the aria-haspopup="true" property do not behave like this. They are activated on click and have no other purpose than to reveal a secreted menu.
Left: a menu button labeled ‘menu’ with a down-pointing arrow icon and the aria-expanded = false state. Right: The same menu button but with the menu open. This button is in the aria-expanded = true state. (Large preview)
As pictured, whether that menu is open or closed should be communicated with aria-expanded. You should only change this state on click, not on focus. Users do not usually expect an explicit change of state on a mere focus event. In our navigation system, state doesn’t really change; it’s just a styling trick. Behaviorally, we can Tab through the navigation as if no such show/hide trickery were occurring.
The Problem With Navigation Submenus
Navigation submenus (or “dropdowns” to some) work well with a mouse or by keyboard, but they’re not so hot when it comes to touch. When you press the top-level “Shop” link in our example for the first time, you are telling it to both open the submenu and follow the link.
There are two possible resolutions here:
Prevent the default behavior of top-level links (e.preventDefault()) and script in full WAI-ARIA menu semantics and behavior.
Make sure each top-level destination page has a table of contents as an alternative to the submenu.
(1) is unsatisfactory because, as I noted previously, these kinds of semantics and behaviors are not expected in this context, where links are the subject controls. Plus users could no longer navigate to a top-level page, if it exists.
Sidenote: Which devices are touch devices?
It’s tempting to think, “this isn’t a great solution, but I’ll only add it for touch interfaces”. The problem is: how does one detect if a device has a touch screen?
You certainly shouldn’t equate “small screen” with “touch activated”. Having worked in the same office as folks making touch displays for museums, I can assure you that some of the largest screens around are touch screens. Dual keyboard and touch input laptops are becoming increasingly prolific too.
By the same token, many but not all smaller devices are touch devices. In inclusive design, you cannot afford to make assumptions.
Resolution (2) is more inclusive and robust in that it provides a “fallback” for users of all inputs. But the scare quotes around the fallback term here are quite deliberate because I actually think in-page tables of content are a superior way of providing navigation.
Gov.uk tables of content are minimal with hyphens as list styles. Wikipedia provides a bordered grey box with numbered items. Both are labeled contents.
Tables Of Content
Tables of content are navigation for related pages or page sections and should be semantically similar to main site navigation regions, using a <nav> element, a list, and a group labeling mechanism.
<nav aria-labelledby="sections-heading"> <h2>Products</h2> <ul> <li><a href="http://www.smashingmagazine.com/products/dog-costumes">Dog costumes</a></li> <li><a href="http://www.smashingmagazine.com/products/waffle-irons">Waffle irons</a></li> <li><a href="http://www.smashingmagazine.com/products/magical-orbs">Magical orbs</a></li> </ul></nav><!-- each section, in order, here -->
Notes
In this example, we’re imagining that each section is its own page, as it would have been in the dropdown submenu.
It’s important that each of these “Shop” pages has the same structure, with this “Products” table of content present in the same place. Consistency supports understanding.
The list groups the items and enumerates them in assistive technology output, such as a screen reader’s synthetic voice.
The <nav> is recursively labeled by the heading using aria-labelledby. This means “products navigation” will be announced in most screen readers upon entering the region by Tab. It also means that “products navigation” will be itemized in screen reader element interfaces, from which users can navigate to regions directly.
All on one page
If you can fit all the sections onto one page without it becoming too long and arduous to scroll, even better. Just link to each section’s hash identifier. For example, href="#waffle-irons" should point to id="waffle-irons".
<nav aria-labelledby="sections-heading"> <h2>Products</h2> <ul> <li><a href="#dog-costumes">Dog costumes</a></li> <li><a href="#waffle-irons">Waffle irons</a></li> <li><a href="#magical-orbs">Magical orbs</a></li> </ul></nav><!-- dog costumes section here --><section tabindex="-1"><h2>Waffle Irons</h2></section><!-- magical orbs section here -->
(Note: Some browsers are poor at actually sending focus to linked page fragments. Placing tabindex="-1" on the target fragment fixes this.)
Where a site has a lot of content, a carefully constructed information architecture, expressed through the liberal use of tables of content “menus” is infinitely preferable to a precarious and unwieldy dropdown system. Not only is it easier to make responsive, and requires less code to do so, but it makes things clearer: where dropdown systems hide structure away, tables of content lay it bare.
Some sites, including the Government Digital Service’s gov.uk, include index (or “topic”) pages that are just tables of content. It’s such a powerful concept that the popular static site generator Hugo generates such pages by default.
Family tree style diagram with topic landing page at top with two individual page offshoots. Each of the individual page offshoots have multiple page section offshoots (Large preview)
Information architecture is a big part of inclusion. A badly organized site can be as technically compliant as you like, but will still alienate lots of users — especially those with cognitive impairments or those who are pressed for time.
Navigation Menu Buttons
While we’re on the subject of faux navigation-related menus, it’d be remiss of me not to talk about navigation menu buttons. You’ve almost certainly seen these denoted by a three-line “hamburger” or “navicon” icon.
Even with a pared down information architecture and only one tier of navigation links, space on small screens is at a premium. Hiding navigation behind a button means there’s more room for the main content in the viewport.
A navigation button is the closest thing we’ve studied so far to a true menu button. Since it has the purpose of toggling the availability of a menu on click, it should:
Identify itself as a button, not a link;
Identify the expanded or collapsed state of its corresponding menu (which, in strict terms, is just a list of links).
Progressive enhancement
But let’s not get ahead of ourselves. We ought to be mindful of progressive enhancement and consider how this would work without JavaScript.
In an unenhanced HTML document there’s not a lot you can do with buttons (except submit buttons but that’s not even closely related to what we want to achieve here). Instead, perhaps we should start with just a link which takes us to the navigation?
<a href="#navigation">navigation</a><!-- some content here perhaps --><nav> <ul> <li><a href="http://www.smashingmagazine.com/">Home</a></li> <li><a href="http://www.smashingmagazine.com/about">About</a></li> <li><a href="http://www.smashingmagazine.com/shop">Shop</a></li> <li><a href="http://www.smashingmagazine.com/content">Content</a></li> </ul></nav>
There’s not a lot of point in having the link unless there’s a lot of content between the link and the navigation. Since site navigation should almost always appear near the top of the source order, there’s no need. So, really, a navigation menu in the absence of JavaScript should just be… some navigation.
Some older browsers — you know which ones — don’t support hidden, so remember to put the following in your CSS. It fixes the problem because display: none has the same affect of hiding the menu from assistive technologies and removing the links from focus order.
[hidden] { display: none; }
Doing one’s best to support older software is, of course, an act of inclusive design. Some are unable or unwilling to upgrade.
Placement
Where a lot of people go wrong is by placing the button outside the region. This would mean screen reader users who move to the <nav> using a shortcut would find it to be empty, which isn’t very helpful. With the list hidden from screen readers, they’d just encounter this:
<nav></nav>
Here’s how we might toggle state:
var navButton = document.querySelector('nav button');navButton.addEventListener('click', function() { let expanded = this.getAttribute('aria-expanded') === 'true' || false; this.setAttribute('aria-expanded', !expanded); let menu = this.nextElementSibling; menu.hidden = !menu.hidden; });
aria-controls
As I wrote in Aria-controls Is Poop, the aria-controls attribute, intended to help screen reader users navigate from a controlling element to a controlled element, is only supported in the JAWS screen reader. So you simply can’t rely on it.
Without a good method for directing users between elements, you should instead make sure one of the following is true:
The expanded list’s first link is next in focus order after the button (as in the previous code example).
The first link is focused programmatically upon revealing the list.
In this case, I would recommend (1). It’s a lot simpler since you don’t have to worry about moving focus back to the button and on which event(s) to do so. Also, there’s currently nothing in place to warn users that their focus will be moved to somewhere different. In the true menus we’ll be discussing shortly, this is the job of aria-haspopup="true".
Employing aria-controls doesn’t really do much harm, except that it makes readout in screen readers more verbose. However, some JAWS users may expect it. Here is how it would be applied, using the list’s id as the cipher:
A true menu (in the WAI-ARIA sense) should identify itself as such using the menu role (for the container) and, typically, menuitem children (other child roles may apply). These parent and child roles work together to provide information to assistive technologies. Here’s how a list might be augmented to have menu semantics:
We could, of course, suppress the list semantics of the <li>s using role="presentation" or role="none" (which are equivalent) and place the menuitem role on each link. However, this would suppress the implicit link role. In other words, the example to follow would be announced as “Home, menu item”, not “Home, link” or “Home, menu item, link”. ARIA roles simply override HTML roles.
<!-- will be read as "Home, menu item" --><li role="presentation"><a href="http://www.smashingmagazine.com/" role="menuitem">Home</a></li>
We want the user to know that they are using a link and can expect link behavior, so this is no good. Like I said, true menus are for (JavaScript driven) application behavior.
What we’re left with is a kind of hybrid component, which isn’t quite a true menu but at least tells users whether the list of links is open, thanks to the aria-expanded state. This is a perfectly satisfactory pattern for navigation menus.
Sidenote: The <select> element
If you’ve been involved in responsive design from the beginning, you may remember a pattern whereby navigation was condensed into a <select> element for narrow viewports.
Handset with select element showing “home” selected at top of viewport.
As with the checkbox-based toggle buttons we discussed, using a native element that behaves somewhat as intended without additional scripting is a good choice for efficiency and — especially on mobile — performance. And <select> elements are menus of sorts, with similar semantics to the button-triggered menu we shall soon be constructing.
However, just as with the checkbox toggle button, we’re using an element associated with entering input, not simply making a choice. This is likely to cause confusion for many users — especially since this pattern uses JavaScript to make the selected <option> behave like a link. The unexpected change of context this elicits is considered a failure according to WCAG’s 3.2.2 On Input (Level A) criterion.
True Menus
Now that we’ve had the discussion about false menus and quasi-menus, the time has arrived to create a true menu, as opened and closed by a true menu button. From here on in I will refer to the button and menu together as simply a “menu button”.
But in what respects will our menu button be true? Well, it’ll be a menu component intended for choosing options in the subject application, which implements all the expected semantics and corresponding behaviors to be considered conventional for such a tool.
As mentioned already, these conventions come from desktop application design. ARIA attribution and JavaScript governed focus management are needed to imitate them fully. Part of the purpose of ARIA is to help web developers create rich web experiences without breaking with usability conventions forged in the native world.
In this example, we’ll imagine our application is some sort of game or quiz. Our menu button will let the user choose a difficulty level. With all the semantics in place, the menu looks like this:
The aria-haspopup property simply indicates that the button secretes a menu. It acts as warning that, when pressed, the user will be moved to the “popup” menu (we’ll cover focus behavior shortly). Its value does not change — it remains as true at all times.
The <span> inside the button contains the unicode point for a black down-pointing small triangle. This convention indicates visually what aria-haspopup does non-visually — that pressing the button will reveal something below it. The aria-hidden="true" attribution prevents screen readers from announcing “down pointing triangle” or similar. Thanks to aria-haspopup, it’s not needed in the non-visual context.
The aria-haspopup property is complemented by aria-expanded. This tells the user whether the menu is currently in an open (expanded) or closed (collapsed) state by toggling between true and false values.
The menu itself takes the (aptly named) menu role. It takes descendants with the menuitem role. They do not need to be direct children of the menu element, but they are in this case — for simplicity.
Keyboard And Focus Behavior
When it comes to making interactive controls keyboard accessible, the best thing you can do is use the right elements. Because we’re using <button> elements here, we can be assured that click events will fire on Enter and Space keystrokes, as specified in the HTMLButtonElement interface. It also means that we can disable the menu items using the button-associated disabled property.
There’s a lot more to menu button keyboard interaction, though. Here’s a summary of all the focus and keyboard behavior we’re going to implement, based on WAI-ARIA Authoring Practices 1.1:
Enter, Space or ↓ on the menu button
Opens the menu
↓ on a menu item
Moves focus to the next menu item, or the first menu item if you’re on the last one
↑ on a menu item
Moves focus to the previous menu item, or the last menu item if you’re on the first one
↑ on the menu button
Closes the menu if open
Esc on a menu item
Closes the menu and focuses the menu button
The advantage of moving focus between menu items using the arrow keys is that Tab is preserved for moving out of the menu. In practice, this means users don’t have to move through every menu item to exit the menu — a huge improvement for usability, especially where there are many menu items.
The application of tabindex="-1" makes the menu items unfocusable by Tab but preserves the ability to focus the elements programmatically, upon capturing key strokes on the arrow keys.
As part of a sound API design, we can construct methods for handling the various events.
For example, the open method needs to switch the aria-expanded value to “true”, change the menu’s hidden property to false, and focus the first menuitem in the menu that isn’t disabled:
We can execute this method where the user presses the down key on a focused menu button instance:
this.button.addEventListener('keydown', function (e) { if (e.keyCode === 40) { this.open(); }}.bind(this));
In addition, a developer using this script will now be able to open the menu programmatically:
exampleMenuButton = new MenuButton(document.querySelector('[aria-haspopup]'));exampleMenuButton.open();
Sidenote: The checkbox hack
As much as possible, it’s better not to use JavaScript unless you need to. Involving a third technology on top of HTML and CSS is necessarily an increase in systemic complexity and fragility. However, not all components can be satisfactorily built without JavaScript in the mix.
In the case of menu buttons, an enthusiasm for making them “work without JavaScript” has led to something called the checkbox hack. This is where the checked (or unchecked) state of a hidden checkbox is used to toggle the visibility of a menu element using CSS.
/* menu closed */[type="checkbox"] + [role="menu"] { display: none;}/* menu open */[type="checkbox"]:checked + [role="menu"] { display: block;}
To screen reader users, the checkbox role and checked state are nonsensical in this context. This can be partly overcome by adding role="button" to the checkbox.
Unfortunately, this suppresses the implicit checked state communication, depriving us of JavaScript-free state feedback (poor though it would have been as “checked” in this context).
But it is possible to spoof aria-expanded. We just need to supply our label with two spans as below.
These are both visually hidden using the visually-hidden class, but — depending on which state we’re in — only one is hidden to screen readers as well. That is, only one has display: none, and this is determined by the extant (but not communicated) checked state:
/* class to hide spans visually */.vh { position: absolute !important; clip: rect(1px, 1px, 1px, 1px); padding: 0 !important; border: 0 !important; height: 1px !important; width: 1px !important; overflow: hidden;}/* reveal the correct state wording to screen readers based on state */[type="checkbox"]:checked + label .expanded-text { display: inline;}[type="checkbox"]:checked + label .collapsed-text { display: none;}[type="checkbox"]:not(:checked) + label .expanded-text { display: none;}[type="checkbox"]:not(:checked) + label .collapsed-text { display: inline;}
This is clever and all, but our menu button is still incomplete since the expected focus behaviors we’ve been discussing simply cannot be implemented without JavaScript.
These behaviors are conventional and expected, making the button more usable. However, if you really need to implement a menu button without JavaScript, this is about as close as you can get. Considering the cut-down navigation menu button I covered previously offers menu content that is not JavaScript dependent itself (i.e. links), this approach may be a suitable option.
Executing some methods should emit events so that we can set up listeners. For example, we can emit a choose event when a user clicks a menu item. We can set this up using CustomEvent, which lets us pass an argument to the event’s detail property. In this case, the argument (“choice”) would be the chosen menu item’s DOM node.
MenuButton.prototype.choose = function (choice) { // Define the 'choose' event var chooseEvent = new CustomEvent('choose', { detail: { choice: choice } }); // Dispatch the event this.button.dispatchEvent(chooseEvent); return this; }
There are all sorts of things we can do with this mechanism. Perhaps we have a live region set up with an id of menuFeedback:
<div role="alert"></div>
Now we can set up a listener and populate the live region with the information secreted inside the event:
exampleMenuButton.addEventListener('choose', function (e) { // Get the node's text content (label) var choiceLabel = e.details.choice.textContent; // Get the live region node var liveRegion = document.getElementById('menuFeedback'); // Populate the live region liveRegion.textContent = 'Your difficulty level is ${choiceLabel}';});
When a user chooses an option, the menu closes and focus is returned to the menu button. It’s important users are returned to the triggering element after the menu is closed. (Large preview)
When a menu item is selected, the screen reader user will hear, “You chose [menu item’s label]”. A live region (defined here with the role="alert" attribution) announces its content in screen readers whenever that content changes. The live region isn’t mandatory, but it is an example of what might happen in the interface as a response to the user making a menu choice.
Persisting Choices
Not all menu items are for choosing persistent settings. Many just act like standard buttons which make something in the interface happen when pressed. However, in the case of our difficulty menu button, we’d like to indicate which is the current difficulty setting — the one chosen last.
The aria-checked="true" attribute works for items that, instead of menuitem, take the menuitemradio role. The enhanced markup, with the second item checked (set) looks like this:
While traversing the menu with a screen reader running, focusing this checked item will prompt an announcement like “check mark, Medium menu item, checked”.
The behavior on opening a menu with a checked menuitemradio differs slightly. Instead of focusing the first (enabled) item in the menu, the checked item is focused instead.
The menu button starts with the menu unopened. On opening the second (Medium) difficulty setting is focused. It is prefixed with a check mark based on the aria-checked attribute’s presence. (Large preview)
What’s the benefit of this behavior? The user (any user) is reminded of their previously selected option. In menus with numerous incremental options (for example, a set of zoom levels), people operating by keyboard are placed in the optimal position to make their adjustment.
Using The Menu Button With A Screen Reader
In this video, I’ll show you what it’s like to use the menu button with the Voiceover screen reader and Chrome. The example uses items with menuitemradio, aria-checked and the focus behavior discussed. Similar experiences can be expected across the gamut of popular screen reader software.
Inclusive Menu Button On Github
Hugo Giraudel and I have worked together on creating a menu button component with the API features I have described, and more. You have Hugo to thank for many of these features, since they were based on the work they did on a11y-dialog — an accessible modal dialog. It is available on Github and NPM.
npm i inclusive-menu-button --save
In addition, Hugo has created a React version for your delectation.
Checklist
Don’t use ARIA menu semantics in navigation menu systems.
On content heavy sites, don’t hide structure away in nested dropdown-powered navigation menus.
Use aria-expanded to indicate the open/closed state of a button-activated navigation menu.
Make sure said navigation menu is next in focus order after the button that opens/closes it.
Never sacrifice usability in the pursuit of JavaScript-free solutions. It’s vanity.
We can’t believe it’s actually happening. After 18 months of hard work on the big bang relaunch of this little website, today is the day when everything changes. New design and new technical stack. New personality and new ambitious goals. But most importantly, a new focus on our wonderful web community, with the brand new Smashing Membership.
Rewarding Great People Doing Great Work
In times when we fight all the craziness and narrow-mindedness around us, we need to remind ourselves how wonderful a vast majority of the web community actually is. There are thousands of active, hard-working folks who contribute to open-source projects, who share, blog, speak, teach and learn from each other — and for each other.
There are people who deeply care about diversity and respect. People who care about accessibility and performance. People who care about quality. People who change things for the better. People who help and share. Truly smashing people like you.
Unfortunately, these people usually remain unnoticed, sometimes making huge contributions in their little spare time, and as time passes by, too often so does their motivation. We want to reward and highlight these people, and support their contributions.
Over the last 18 months, we’ve been cooking something new. It’s about time to give you a taste of what we have in mind!
That is why today we are proud to launch Smashing Membership. A community effort dedicated to support and highlight new and old voices of the community side by side.
A safe, friendly place where together we can share, learn and decide on the future of the web. But also an effort to move away from an ad-ridden, noisy, clicks-driven web to a friendlier, cleaner and calmer place.
Web community lies in the very heart of the Membership; but it’s much more than that. We’re building a place with features worth using daily — webinars, books, eBooks, printed magazine, hefty discounts for books, video courses, tools and Smashing TV.
Bonus: 68 enchantingly beautiful cats and UX gems scattered across the site. Smash it up alright: that’s Smashing Membership for y’all!
What’s In It For You?
We don’t believe in donations, but we do believe in value of good products. We want your Smashing Membership to be worth every penny. It should provide you with tangible benefits, day after day. Here’s what you should be expecting.
Smashing TV and Webinars
Every community grows slowly, but its value shines through slow, mindful discussions. We want to encourage this kind of discussions with Smashing TV, our regular live sessions with you and other smart people from the industry.
Unlike in regular webinars, you’ll be the central part of the events, having discussions with us and other people from the industry. Format: 60 mins talk + 45 mins Q&A, taking place every second Thursday. Can’t watch it live? You can download recordings of webinars, too. That’s how you stay on the cutting edge of digital.
Smashing TV, a new Hollywood blockbuster for designers and developers. Okay, it won’t knock your socks off, but it might be pretty close.
Suggest Topics For Articles and Webinars
We’re listening to you. You’d like us to cover a particular topic in the magazine or run a webinar, or even in-house training on it? Suggest your ideas in the open channel with our editors, and we will do our best to make it happen.
Hefty Discounts to Books and Videos
We also want to build up a place worth coming back to. Be it due to hefty discounts for tools or video courses, or books and eBooks for your personal growth. We’ve teamed up with Rachel Andrew, Chris Coyier, Remy Sharp, Wes Bos and others to provide you with discounts for their video courses and tools.
Ideally, you should learn something new every day. Also, you get access to Smashing eBooks, the old ones and the new ones, so you can start reading a book before it officially gets released.
We know you might be a dog person. That’s fine: we don’t judge around here. Our community is friendly, respectful and open-minded.
Home, Where You Meet Friends
But we also want it to be a fireplace where you meet new and old friends. Everybody around here is called by their real name. We’ve set up a discussion place over at Spectrum, kind-of-a-community-forum thing for threaded, lengthy discussions. That’s where you hopefully meet friends and make genuine, authentic connections. Perhaps it could become a place you might call home one day.
Super-Early-Bird Tickets
You should feel like home around people you know and trust. This goes not just for digital gatherings — we’d love to see you at Smashing conferences and meet-ups, too. To make it a bit easier for you to come, we’ve set up discounts for Smashing workshops and conferences. With a Membership, you save the money spent with one conference ticket already.
We would love to welcome you at a Smashing Conference one day. It’s a great place for networking and learning, with eventual snowball fights.
A New Printed Magazine
Print is dead? Think again! With Smashing Magazine Print, we’re rediscovering what a printed magazine looks like. Not just a recycling of online content; no ads or fill content — long-form articles written for the magazine and designed to stay relevant long-term. Now in print, every 4 months, and delivered to your doorsteps worldwide. Designed by one-and-only Veerle Pieters.
The brand new Smashing Print, featuring long-form content written for the magazine and designed to stay relevant long-term. Designed by one-and-only Veerle Pieters. Table of Contents. Large view. A spread of the very first issue of Smashing Magazine Print, the Pilot issue. Large view.
Transparency and Public Reporting
By the end of every month, we’ll be reporting the earnings and how we spent the money. You’ll see where the money goes, the projects we supported and initiated, and what you made possible.
No hidden agenda — full transparency. By the end of every month we’ll report how many members we have and how we’ve spent the money in the Membership Dashboard.
Support New Voices in The Industry
We search and support new voices in the industry: people who write, or code, or design, people who want to learn but can’t afford it, and people who are disadvantaged in any way.
One thing is certain: with our community, you’re in for a wonderful, diverse, respectful group of people who share values and have versatile experiences. Most importantly, they are willing to share them with you. We do not tolerate any disrespect around here.
Bonus: Ditching Display Ads
The web is polluted with cranky, malicious and painfully slow ad scripts, creating a culture of exaggerated, click-baiting titles that generate ad impressions. It’s about time to take a stand against it.
Let’s be honest: display ads are just out-of-date. They don’t serve anybody, and nobody really likes them. They slow us down and they distract from what we are here to do; and advertisers don’t fancy them either because they communicate next to nothing about their offering.
However, we all need to pay the bills at the end of the day. In the new design, you won’t find that many ad spots any longer, and we’ll remove them entirely once we reach 5.000 members.
We want to help our industry transition away from display ads to more effective ways of spreading the word that benefits everybody. After all, we still believe that the companies who have supported us over the years bring so much to the web community. Without them many events wouldn’t happen, many open source projects would close their doors, and much of the content you read wouldn’t exist.
It’s about time. We’ll remove display ads entirely once we reach 5.000 members. We strongly believe that they have no place in the future of Smashing Magazine. Let’s make it happen.
The Day When Everything Changes
We couldn’t be more excited about getting Membership finally out there. We’ve put a lot of effort and consideration into shaping it and designing it and building it, and to us, it feels like the beginning of something very special. We’d love you to be a part of it, too. Welcome to the brand new Smashing Magazine.
Ah, by the way, as it always is with a relaunch, please be patient: not everything on the new site might work as expected, and we still have a few issues to fix. If you find a errors, please report a bug, or help us squash it, the smashing way. So long, and good luck finding all those 68 hidden cats!
We’re changing the direction of the magazine. We’d love to embark on this journey with you. Join the Smashing family.
Articles In The Series
This article is a part of the series about how we work and design and build and play. We’ll be publishing a case study on the work we did, both from the design perspective and the technical perspective, soon. Stay tuned!
(This is a sponsored post). Web design is tricky. Designers and developers have to take a lot of things into account when designing a website, from visual appearance (how the website looks) to functional design (how the website works). To simplify the task, we’ve prepared this little guide.
In this article, I’ll focus on the main principles, heuristics, and approaches that will help you to create a great user experience for your website. I’ll start with global things like the user journey (how to define the “skeleton” of the website) and work down to the individual page (what should be considered during web page design). We’ll also cover other essential aspects of design, such as mobile considerations and testing.
Designing The User Journey
Information Architecture
People often use the term “information architecture” (IA) to mean the menus on a website. But that’s not correct. While menus are a part of IA, they are only one aspect of it.
IA is all about the organization of information in a clear and logical way. Such organization follows a clear purpose: helping users to navigate a complex set of information. Good IA creates a hierarchy that aligns with user’s expectations. But good hierarchy and intuitive navigation don’t happen by chance. They are a result of proper user research and testing.
There are a number of ways to research user needs. Often, an information architect will take an active part in user interviews or card sorting, where they would hear of user expectations directly or see how prospective users would categorize a variety of information groups. Information architects also need access to the results of usability tests to see whether users are able to navigate efficiently.
Card sorting is a simple way to figure out how best to group and organize content based on user input. One of the reasons why information architects like card sorting is because of the clarity of patterns that typically emerges. (Image credit: FosterMilo)
A menu structure would be created based on the results of user interviews, and card sorting would be tested for whether it satisfies the user’s mental model. UX researchers use a technique called “tree testing” to prove that it will work. This happens before designing the actual interface.
Tree testing is a reliable method of finding whether users can work with the proposed menu structure. (Image credit: Nielsen Norman Group) (View large version)
Global Navigation
Navigation is a cornerstone of usability. It doesn’t matter how good your website is if users can’t find their way around it. That’s why navigation on your website should adhere to a few principles:
SimplicityNavigation should be designed in a way that gets visitors where they want to go with the fewest clicks possible.
ClarityThere shouldn’t be any guessing about what each navigation option means. Every navigation option should be self-evident to visitors.
ConsistencyThe navigation system should be the same for all pages on the website.
Consider a few things when designing navigation:
Select a navigation pattern based on the user’s needs.Navigation should accommodate the needs of the majority of your app’s users. A given target group expects a particular type of interaction with your website, so make these expectations work in your favor. For example, avoid hamburger-menu navigation if the majority of your users aren’t familiar with the meaning of the icon itself.
Prioritize navigation options.One simple way to prioritize navigation options is to assign different priority levels (high, medium, low) to common user tasks, and then give prominence in the layout to paths and destinations with high priority levels and frequent use.
Make it visible.As Jakob Nielsen says, recognizing something is easier than remembering it. Minimize the user’s memory load by making all important navigation options permanently visible. The most important navigation options should be available at all times, not just when we anticipate that the user will need them.
Communicate the current location.“Where am I?” is a fundamental question to which users need an answer in order to effectively navigate. Failing to indicate the current location is a common problem on many websites. Think about location indicators.
Links and Navigation Options
Links and navigation options are key factors in the navigation process and have a direct effect on the user journey. Follow a few rules with these interactive elements:
Recognize the difference between internal and external links.Users expect different behavior for internal and external links. All internal links should open in the same tab (this way, you’ll allow users to use the “back” button). If you decide to open external links in a new window, you should provide an advanced warning before automatically opening a new window or tab. This might take the form of text added to the link text stating “(opens in a new window)”.
Change the color of visited links.When visited links don’t change color, users could unintentionally revisit the same pages.
Knowing which pages they’ve visited keeps the user from unintentionally revisiting the same pages.
Double-check all links.A user can easily get frustrated by clicking a link and getting a 404 error page in response. When a visitor is searching for content, they expect every link to take them where it says it will, not to a 404 error page or another place they weren’t expecting.
The “back” button is perhaps the second-most popular UI control in the browser (after the URL input field). Make sure the “back” button works according to user expectations. When a user follows a link on a page and then clicks the “back” button, they expect to return to the same spot on the original page. Avoid situations in which clicking “back” brings the user to the top of the initial page, instead of where they left off, especially on pages. Losing their spot forces the user to scroll through content they have already seen. It’s no surprise that users get frustrated quickly with no proper “back to position” functionality.
Breadcrumbs
Breadcrumbs are a set of contextual links that function as a navigation aid on websites. It’s a secondary navigation scheme that usually shows the user’s location on a website.
While this element doesn’t require a lot of explanation, a few things are worth mentioning:
Don’t use breadcrumbs as a substitute for primary navigation.The main navigation should be the element that leads the user, whereas breadcrumbs should only support the user. Relying on breadcrumbs as a primary method of navigation, rather than an extra feature, is usually an indication of poor navigation design.
Use arrowheads, not slashes, as separators. Separate each level clearly.A more-than sign (>) or right-pointing arrow (→) is recommended, because these symbols signal direction. A forward slash (/) isn’t recommended as a separator for e-commerce websites. If you’re going to use it, be certain that no product category will ever use a slash:
Distinguishing between different levels of this breadcrumb trail is hard. (View large version)
Search
Some users come to a website looking for one particular item. They don’t want to use the navigation options. They want to type text in a search box, submit their search query and find the page they’re looking for.
Take these few basic rules into account when designing the search box:
Put the search box where users expect to find it.The chart below was created based on a study by A. Dawn Shaikh and Keisi Lenz. It shows the expected location of the search field, according to a survey of 142 participants. The study found that the most convenient spot is the top left or top right of every page on a website. Users can easily find it using the common F-shaped scanning pattern.
Display search prominently on content-rich websites.
If search is an important function on your website, display it prominently, because it can be the fastest route to discovery for users.
Size the input box appropriately.
Making the input field too short is a common mistake among designers. Of course, users can type a long query into a short field, but only a portion of the text will be visible at a time, which is bad for usability because seeing the entire query at once won’t be possible. In fact, when a search box is too short, users are forced to use short, imprecise queries, because longer queries would be hard and inconvenient to read. Nielsen Norman Group recommends a 27-character input field, which would accommodate 90% of queries.
Put the search box on every page.
Show the search box on every page, because if users cannot navigate to the content they are looking for, they will try to use search regardless of where they are on the website.
Designing Individual Pages
Content Strategy
Perhaps the most important thing about content strategy is to focus the design on page objectives. Understand the goal of the page, and write content according to the goal.
Here are a few practical tips to improve content comprehension:
Prevent information overload.Information overload is a serious problem. It prevents users from making decisions or taking action because they feel they have too much information to consume. There are some simple ways to minimize information overload. One common technique is chunking — breaking content into smaller chunks to help users understand and process it better. A checkout form is a perfect example. Display at most five to seven input fields at a time, and break down the checkout into pages, progressively disclosing fields as necessary.
Avoid jargon and industry-specific terms.Each unknown term or phrase that appears on the page will increase the cognitive load on users. A safe bet is to write for all levels of readers, and pick words that are clearly and easily understandable to all groups of users.
Minimize long content sections with a lot of detail.In line with the point about information overload, try to avoid long blocks of text if the website isn’t geared to major information consumption. For example, if you need to provide details about a service or product, try to reveal details step by step. Write in small, scannable segments to facilitate discovery. According to Robert Gunning’s book “How to Take the Fog Out of Business Writing”, for comfortable reading, most sentences should be 20 words or less.
Avoid capitalizing all letters.All-caps text — that is, text with all letters capitalized — is fine in tiny doses, such as for acronyms and logos. However, avoid all caps for anything longer (such as paragraphs, form labels, errors, notifications). As mentioned by Miles Tinker in his book Legibility of Print, all caps dramatically reduces the speed of reading. Also, most readers find all capitals to be less legible.
Text in all caps is hard for users to read.
Page Structure
A properly structured page makes it clear where each user interface element is located in the layout. While there are no one-size-fits-all rules, there are a few guidelines that will help you create a solid structure:
Make the structure predictable.Align your design to user expectations. Consider websites from a similar category to find out which elements to use on the page and where. Use patterns that your target audience is familiar with.
Use a layout grid.A layout grid divides a page into major regions, and defines the relationships between elements in terms of size and position. With the help of a grid, combining different parts of a page together in a cohesive layout becomes much easier.
Grids and layout systems are part of the heritage of design and are still relevant in a multi-screen world. Adobe XD’s layout grids enable designers to achieve consistent, organized designs for different screen sizes and to manage the proportions between elements with customized grids.
Use a low-fidelity wireframe to cut out clutter.Clutter overloads an interface and reduces comprehension. Every added button, image and line of text makes the screen more complicated. Before building the page with real elements, create a wireframe, analyze it, and get rid of anything that isn’t absolutely necessary.
People are more likely to quickly scan a web page than to read everything there. Therefore, if a visitor wants to find content or complete a task, they are going to scan until they find where they need to go. You, as a designer, can help them with that by designing good visual hierarchy. Visual hierarchy refers to the arrangement or presentation of elements in a way that indicates importance (that is, where their eyes should focus first, second, etc.). A proper visual hierarchy makes it easy to scan the page.
Use natural scanning patterns.As designers, we have a lot of control over where people look when they’re viewing a page. To set the right path for the visitor’s eyes to follow, we can use two natural scanning patterns: the F-shaped pattern and the Z-shaped pattern. For text-heavy pages, such as articles and search results, the F pattern is better, whereas the Z pattern is good for pages that aren’t text-oriented.
Visually prioritize important elements.Make screen titles, log-in forms, navigation options and other important content focal points, so that visitors see them right away.
The “Learn More About Brains” call to action stands out. (View large version)
Create mockups to clarify the visual hierarchy.Mockups enable designers to see what a layout will look like when it’ll have a real data. Rearranging elements in a mockup is much easier than doing it when the developer is building the web page.
A persistent myth among web designers is that people don’t scroll. To be clear: Today, everybody scrolls!
Improving scrolling behavior is possible with a few tips:
Encourage users to scroll.Despite the fact that people usually start scrolling as soon as the page loads, content at the top of the page is still very important. What appears at the top sets the impression and expectation of quality for visitors. People do scroll, but only if what’s above the fold is promising enough. Thus, put your most compelling content at the top of the page:
Offer a good introduction.An excellent introduction sets the context for the content and answers the user’s question, “What’s this page about?”
Use engaging imagery.Users pay close attention to images that contain relevant information.
Persist navigation options.When you create lengthy pages, keep in mind that users still require a sense of orientation (of their current location) and a sense of navigation (other possible paths). Long pages can make navigation problematic for users; if the top navigation bar loses visibility when the user scrolls down, they will have to scroll all the way back up when they’re deep within the page. The obvious solution to this is a sticky menu that shows the current location and that remains on screen in a consistent area at all times.
Provide visual feedback when loading new content.This is especially important for web pages where content loads dynamically (such as news feeds). Because content-loading during scrolling is supposed to be fast (it shouldn’t take longer than 2 to 10 seconds), you can use looped animation to indicate that the system is working.
Subtle animation (such as Tumblr’s loading indicator) tells the user that more content is being loaded.
Don’t hijack scrolling.Hijacked scrolling is one of the most annoying things because it takes control away from the user and makes the scrolling behavior completely unpredictable. When you design a website, let the user control their browsing and movement through the website.
Content loading is worth additional clarification. While an instant response is best, there are occasions when your website will need more time to deliver content to visitors. A bad Internet connection could cause a slow reaction, or an operation could take a bit more time to complete. But no matter the cause of such behavior, your website should appear fast and responsive.
Make sure regular loading doesn’t take long.The attention span and patience of web users is very low. According to Nielsen Norman Group research, 10 seconds is about the limit for keeping the user’s attention on a task. When visitors have to wait for a website to load, they will become frustrated and likely leave if the website doesn’t load quickly enough for them. Even with the most beautifully designed loading indicator, users will still leave if loading takes too long.
Use skeleton screens during loading.Many websites use progress indicators to show that data is loading. While the intention behind a progress indicator is good (providing visual feedback), the result can be negative. As Luke Wroblewski mentions, “Progress indicators by definition call attention to the fact that someone needs to wait. It’s like watching the clock tick down — when you do, time seems to go slower.” There is an excellent alternative to progress indicators: skeleton screens. These containers are essentially a temporarily blank version of the page, into which information is gradually loaded. Rather than showing a loading indicator, designers can use a skeleton screen to focus users’ attention on actual progress and create anticipation for what’s to come. This creates a sense that things are happening immediately, as information is incrementally displayed on the screen and people see that the website is acting while they wait.
Facebook uses skeleton screens to fill out the UI as content is loaded incrementally. (View large version)
Buttons
Buttons are vital to creating a smooth conversational flow. It’s worth paying attention to these basic best practices for buttons:
Ensure that clickable elements look like ones.With buttons and other interactive elements, think about how the design communicates affordance. How do users understand the element as a button? Form should follow the function: the way an object looks tells users how to use it. Visual elements that look like links or buttons but aren’t clickable (such as underlined words that aren’t links or elements that have a rectangular background but aren’t buttons) can easily confuse users.
Is the orange box in the top-left corner of the screen a button? No, but the shape and label make the element look like one. (View large version)
Label buttons according to what they do.The label on any actionable interface element should always tie back to what it will do for the user. Users will feel more comfortable if they understand what action a button does. Vague labels such as “Submit” and abstract labels like in the example below don’t provide enough information about the action.
Don’t make people wonder what an interface element does. (Image credit: UX Matters)
Design buttons consistently.Users remember details, whether consciously or not. When browsing a website, they’ll associate a particular element’s shape with button functionality. Therefore, consistency will not only contribute to a great-looking design, but will also make the experience more familiar to users. The image below illustrates this point perfectly. Using three different shapes in one part of an app (such as the system toolbar) is not only confusing, but sloppy.
Strive for consistency.
Imagery
As the saying goes, a picture is worth a thousand words. Human beings are highly visual creatures, able to process visual information almost instantly; 90% of all information that we perceive and that gets transmitted to our brains is visual. Images are a powerful way to capture the user’s attention and to differentiate a product. A single image can convey more to the viewer than an elaborately designed block of text. Furthermore, images cross language barriers in a way that text simply can’t.
The following principles will help you integrate imagery in your web design:
Make sure images are relevant.One of the biggest dangers in design is imagery that conveys the wrong message. Select images that strongly support your product goals, and ensure that they are relevant to the context.
Images that aren’t related to the topic will cause confusion. (View large version)
Avoid generic photos of people.Using human faces in design is an effective way to engage users. Seeing faces of other humans makes viewers feel like they are connecting with them, and not just being sold a product. However, many corporate websites are notorious for using generic stock photos to build a sense of trust. Usability tests show that such photos rarely add value to the design and more often impair rather than improve the user experience.
Inauthentic images leave the user with a sense of shallow, false pretence. (View large version)
Use high-quality assets with no distortion.The quality of assets of your website will have a tremendous impact on the user’s impression and expectations of your service. Make sure images are appropriately sized for displays across all platforms. Images shouldn’t appear pixelated, so test resolution sizes for various ratios and devices. Display photos and graphics in their original aspect ratio.
With increasing Internet speeds, videos are becoming more popular, especially considering that they extend time spent on site. Today, video is everywhere. We’re watching it on our desktops, tablets and phones. When used effectively, video is one of the most powerful tools available for engaging an audience — it conveys more emotion and really gives people a feel for a product or service.
Set audio to off by default, with the option to turn it on.When users arrive on a page, they don’t expect that it will play any sound. Most users don’t use headphones and will be stressed because they’ll need to figure out how to turn the sound off. In most cases, users will leave the website as soon as it plays.
Facebook videos play automatically as soon as the user reaches them, but no sound plays unless the user enables it. (View large version)
Keep promo video as short as possible.According to the research by D-Mak Productions, short videos are more appealing to the majority of users. Thus, keep business videos in the range of two to three minutes.
Provide an alternative way to access content.If a video is the only way to consume content, this can limit access to the information for anyone who cannot see or hear the content. For accessibility, include captions and a full transcript of the video.
Subtitles and transcript will make video content more accessible. (Image credit: TED) (View large version)
Call-to-Action Buttons
Calls to action (CTA) are buttons that guide users towards your conversion goal. The whole point of a CTA is to direct visitors to a desired course of action. Some common examples of CTAs are:
“Start a trial”
“Download the book”
“Sign up for updates”
“Get a consultation”
Take a few things into account when designing CTA buttons:
SizeThe CTA should be large enough to see from a distance, but not so large as to detract attention from other content on the page. To confirm that your CTA is the most prominent element on the page, try the five-second test: View a web page for five seconds and then write down what you remember. If the CTA is on your list, then congrats! It’s sized appropriately.
Visual prominenceThe color you choose for CTAs has a tremendous impact on whether it will be noticeable. With color, you can make certain buttons stand out more than others by giving them more visual prominence. Contrasting colors work best for CTAs and make for striking buttons.
The green of the CTA on Firefox’s page jumps off the page and immediately gets the user’s attention. (View large version)
Negative spaceThe amount of space around a CTA is important, too. White (or negative) space creates essential breathing room and separates a button from other elements in the interface.
The previous version of Dropbox’s home page has a good example of using negative space to make the primary CTA pop. The blue “Sign up for free” CTA stands out against the light blue of the background. (View large version)
Action-oriented textWrite text for the button that will compel visitors to take action. Begin with a verb like “Start,” “Get” or “Join.”
Evernote has one of the most common yet still effective action-oriented texts for its CTA. (View large version)
Tip: You can quickly test a CTA using a blur effect. A blur test is a quick technique to determine whether the user’s eye will go where you want it to go. Take a screenshot of your page and apply a blur effect in Adobe XD (see the example on Charity Water below). Looking at the blurred version of your page, which elements stand out? If you don’t like what’s being projected, revise.
A blur test is a technique to reveal a design’s focal point and visual hierarchy. (View large version)
Web Forms
Filling a form remains one of the most important types of interaction for users on the web. In fact, a form is often considered the final step in the completion of a goal. Users should be able to complete forms quickly and without confusion. A form is like a conversation, and like any conversation, there should be logical communication between two parties: the user and the website.
Ask only what’s required.Ask for only what you really need. Every extra field you add to a form will affect its conversion rate. Always think about why you’re requesting certain information from users and how you will be using it.
Order the form logically.Questions should be asked logically from the user’s perspective, not from the application or database’s perspective. For example, asking for someone’s address before their name would be incorrect.
Group related fields together.Group related information into logical blocks or sets. The flow from one set of questions to the next will better resemble a conversation. Grouping related fields together also helps the user make sense of the information.
Group related fields together. (Image: Nielsen Norman Group)
Animation
More and more designers are incorporating animation as a functional element to enhance the user experience. Animation is no longer just for delight; it is one of the most important tools for effective interaction. However, animation in design can enhance the user experience only if it’s incorporated at the right time and place. Good UI animation has a purpose; it is meaningful and functional.
Here are a few cases in which animation can enhance the experience:
Visual feedback on user actionGood interaction design provides feedback. Visual feedback is helpful when you need to inform users about the result of an operation. In case an operation isn’t performed successfully, functional animation can provide information about the problem in a fast and easy way. For example, a shake animation can be used when a wrong password is entered. It’s easy to understand why the shake is a fairly universal gesture to communicate “no,” because a simple head shake is so prevalent in interpersonal communication.
Users will see this animation and immediately understand the problem. (Image credit: The Kinetic UI)
Visibility of system statusOne of Jakob Nielsen’s 10 heuristics for usability, visibility of system status remains among the most important principles in user interface design. Users want to know their current context in a system at any given time, and an app shouldn’t keep them guessing — it should tell the user what’s happening via appropriate visual feedback. Data uploading and downloading operations are great opportunities for functional animation. For example, an animated loading bar shows how fast a process is going and sets an expectation for how fast the action will be processed.
Navigational transitionsNavigational transitions are movements between states on a website — for example, from a high-level view to a detailed view. State changes often involve hard cuts by default, which can make them difficult to follow. Functional animation eases users through these moments of change, smoothly transporting users between navigational contexts and explaining changes on the screen by creating visual connections between states.
BrandingSuppose you have dozens of websites that have the same exact features and help users to accomplish the same tasks. They might all offer a good user experience, but the one that people really love offers something more than just a good user experience. It establishes an emotional connection with users. Branding animation plays a key role in engaging users. It can support a company’s brand values, highlight a product’s strengths and make the user experience truly delightful and memorable.
Today, almost 50% of users access the web from mobile devices. What does this mean for us web designers? It means that we must have a mobile strategy for every website we design.
Practice Responsive Web Design
It’s essential to optimize your website for the vast landscape of desktop and mobile browsers, each of which has a different screen resolution, supported technologies and user base.
Aim for a single-column layout.Single-column layouts usually work best on mobile screens. Not only does a single column help with managing the limited space on a small screen, but it also easily scales between different device resolutions and between portrait and landscape mode.
Use the Priority+ pattern to prioritize navigation across breakpoints.Priority+ is a term coined by Michael Scharnagl to describe navigation that exposes what’s deemed to be the most important elements and hides away less important items behind a “more” button. It makes use of available screen space. As space increases, the number of exposed navigation options increases as well, which can result in better visibility and more engagement. This pattern is especially good for content-heavy websites with a lot of different sections and pages (such as a news website or a large retailer’s store). The Guardian makes use of the Priority+ pattern for its section navigation. Less important items are revealed when the user hits the “All” button.
The Guardian employs the Priority+ pattern for its section navigation. (Image credit: Brad Frost)
Make sure images are sized appropriately for displays and platforms.A website must adapt to look perfect on all of the different devices and in all of the various resolutions, pixel densities and orientations. Managing, manipulating and delivering images is one of the main challenges web designers face when building responsive websites. To simplify this task, you can use tools such as Responsive Image Breakpoints Generator to generate breakpoints for images interactively.
Responsive Image Breakpoints Generator helps you to manage multiple sizes of images, enabling you to generate responsive image breakpoints interactively. (View large version)
Going From Clickable to Tappable
On the mobile web, interaction is done via finger taps, not mouse clicks. This means that different rules apply when you’re designing touch targets and interactions.
Properly sized touch targets.All interactive element (such as links, buttons and menus) should be tappable. While the desktop web lends itself well to links whose active (i.e. clickable) area is small and precise, the mobile web requires larger, chunkier buttons that can be easily pressed with a thumb. When a tap is used as a primary input method for your website, refer to the MIT Touch Lab’s study to choose a proper size for your buttons. The study found that the average size of finger pads are between 10 and 14 millimeters and that fingertips range from 8 to 10, making 10 × 10 millimeters a good minimum touch target size.
Smaller touch targets are harder for users to tap than larger ones. (Image credit: Apple)
Stronger visual signifiers of interactivity.On the mobile web, there is no hover state. While on a desktop, it’s possible to provide additional visual feedback when a user hovers the mouse over an element (for example, revealing a dropdown menu), a mobile user would have to tap to see that response. Thus, users should be able to correctly predict how an interface element will behave just by looking at it.
Accessibility
Today’s products must be accessible to everyone, regardless of a person’s abilities. Designing for users with impairments is one way that designers can practice empathy and learn to experience the world from someone else’s perspective.
Users With Poor Eyesight
A lot of websites use low contrast for text copy. While low-contrast text may be trendy, it’s also illegible and inaccessible. Low contrast is especially problematic for users with low vision and who struggle with contrast sensitivity.
Gray text on a light-gray background is hard to read. The experience will be far from good, and the design simply won’t work. (View large version)
Low-contrast text is hard to read on a desktop, but it becomes even more difficult on mobile. Imagine trying to read low-contrast text on a mobile device while walking in bright sunlight. This is a good reminder that accessible visual design is better visual design for all users.
Never sacrifice usability for beauty. The most important characteristic of text and other vital elements on a website is readability. Readability requires sufficient contrast between text and background. To ensure that text is readable by people with visual impairments, the W3C’s Web Content Accessibility Guidelines (WCAG) has a contrast-ratio recommendation. The following contrast ratios are recommended for body text and image text:
Small text should have a contrast ratio of at least 4.5:1 against its background. A ratio of 7:1 is preferable.
Large text (at 14-point bold and 18-point regular and up) should have a contrast ratio of at least 3:1 against its background.
Bad: These lines of text do not meet the color-contrast ratio recommendations and are difficult to read against their background.Good: These lines of text follow the color-contrast ratio recommendations and are legible against their background.
You can use WebAIM’s Color Contrast Checker to quickly find out whether you’re within the optimal range.
It’s estimated that 4.5% of the global population experience color blindness (that’s 1 in 12 men and 1 in 200 women), 4% suffer from low vision (1 in 30 people), and 0.6% are blind (1 in 188 people). It’s easy to forget that we design for this group of users because most designers don’t experience such problems.
To make design accessible for these users, avoid using color alone to convey meaning. As the W3C states, color shouldn’t be used “as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”
One common example where color is used as the sole means of conveying information is alerts in forms. Success and error messages are often colored green and red, respectively. But red and green are the colors most affected by color-vision deficiency — these colors can be difficult to distinguish for people with deuteranopia or protanopia. Most probably, you’ve seen error messages like, “The fields marked in red are required.” While it might not seem like a big deal, this error message appearing in a form like the one below can be extremely frustrating for people with a color-vision deficiency. Designers should use color to highlight or complement what is already visible.
Bad: This form relies only on red and green to indicate fields with and without errors. Color-blind users wouldn’t be able to identify the fields in red.
In the form above, the designer should give more specific instruction, like, “The email address you entered is not valid.” Or at least display an icon near the field that requires attention.
Good: Icons and labels show which fields are invalid, better communicating the information to a color-blind user.
Blind Users
Images and illustrations are a significant part of the web experience. Blind people use assistive technologies such as screen readers to interpret websites. Screen readers “read” images by relying on alternative text attributed to the image. If that text is not present or is not descriptive enough, they won’t be able to get the information as intended.
Consider two examples — first, Threadless, a popular t-shirt store. This page doesn’t say much about the item being sold. The only text information available is a combination of price and size.
The second example is from ASOS. This page, selling a similar shirt, provides accurate alternative text for the item. This helps people who use screen readers to envision what the item looks like.
When creating text alternatives for images, follow this guideline:
All “meaningful” images require descriptive alternative text. (A “meaningful” photo adds context to the information being conveyed.)
A text alternative isn’t needed if an image is purely decorative and provides no useful information to the user to aid them in understanding the content of the page.
Keyboard-Friendly Experience
Certain users navigate the Internet using their keyboard, rather than a mouse. For example, people with motor impairments have difficulty with the fine motor movements required for using a mouse. Make interactive and navigation elements easily accessible to this group of users by enabling interactive elements to be focused with the Tab key and by displaying a keyboard-focus indicator.
Here are the most basic rules for keyboard navigation:
Check that keyboard focus is visible and obvious.Some web designers remove the keyboard focus indicator because they think it’s an eyesore. This hinders keyboard users from properly interacting with the website. If you don’t like the default indicator provided by the browser, don’t remove it altogether; instead, design it to satisfy your taste.
All interactive elements should be accessible.Keyboard users must be able to access all interactive elements, not just the main navigation options or primary calls to action.
You can find detailed requirements for keyboard interaction in the “Design Patterns and Widgets” section of the W3C’s “WAI-ARIA Authoring Practices” document.
Testing
Iterative Testing
Testing is an essential part of the UX design process. And like any other part of the design cycle, it is an iterative process. Gather feedback early on in the design process, and iterate throughout.
Users hate slow-loading web pages. That’s why response time is a critical factor on modern websites. According to Nielsen Norman Group, there are three response-time limits:
0.1 secondThis feels instant for users.
1 secondThis keeps the user’s flow of thought seamless, but the user will sense a slight delay.
10 secondsThis is about the limit for keeping the user’s attention focused on the operation. A 10-second delay will often make users leave the website immediately.
Obviously, we shouldn’t make users wait 10 seconds for anything on our websites. But even a few seconds of delay, which happens regularly, makes an experience unpleasant. Users will be annoyed with having to wait for the operation.
What usually causes slow loading time?
Heavy content objects (such as embedded video and slideshow widgets),
Unoptimized back-end code,
Hardware-related issues (infrastructure that doesn’t allow for fast operations).
Tools like PageSpeed Insights will help you to find the causes of slow times.
A/B Testing
An A/B test is ideal when you’re struggling to choose between two versions of a design (such as an existing version and a redesigned version of a page). This testing method consists of showing one of two versions randomly to an equal number of users and then reviewing analytics to see which version accomplished your goal more effectively.
A UX design process has two important steps: prototyping the design and developing a working solution. The step that connects the two is called a handoff. As soon as the design is finalized and ready to be moved to development, designers prepare a specification, which is a document that describes how the design should be coded. A specification ensures that the design will be implemented according to the original intention.
Precision in the specification is critical because, with an inaccurate specification, the developers will have to either rely on guesswork when building the website or go back to the designer to get answers to their questions. But assembling a specification manually can be a headache and usually takes significant time, depending on the complexity of the design.
With Adobe XD’s design specs feature (in beta), designers can publish a public URL for developers to inspect flows, grab measurements and copy styles. Designers no longer have to spend time authoring specifications to communicate positioning, text styles or fonts to the developer.
Adobe XD’s design specs feature (in beta)
Conclusion
As with any aspect of design, the tips shared here are just a start. Mix and match these ideas with your own for best results. Treat your website as a continually evolving project, and use analytics and user feedback to constantly improve the experience. And remember that design isn’t just for designers — it’s for users.
This article is part of the UX design series sponsored by Adobe. Adobe XD tool is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype and share — all in one app.You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.
Editor’s Note: Our dear friend Anselm Hannemann summarizes what happened in the web community in the past few weeks in one handy list, so that you can catch up on everything new and important. Enjoy!
Welcome back to our monthly reading list. Before we dive right into all the amazing content I stumbled upon — admittedly, this one is going to be quite a long update — I want to make a personal announcement. This week I launched a personal project called Colloq, a new conference and event service for users and organizers. If you’re going to events or are organizing one or if you’re interested in the recorded content of conferences, this could be for you. So if you like, go ahead and check it out.
In this issue, we’ll focus on some usually rather underaddressed things, such as numerals in web typography, variable fonts, or the image async attribute that’s coming to Chrome soon. So without further ado, let’s get started.
News
WebKit just got support for the Touch Bar Web API that will make use of the menuitem. It’s still in WebKit trunk currently and likely to land in Safari next year at the earliest.
Chrome 62 was released this week with some important updates to the Network Information API that now reflects the actual connection type even when tethering. Support for OpenType Variable Fonts and Media Capture from DOM elements also landed in the new version. Notably, Chrome 62 on iOS got support for the Payment Request API which is interesting because the iOS WebKit doesn’t support it yet in stable channel. It seems that they used a custom extension to support this feature. Might get interesting to see what else could be supported this way.
With the new Windows 10 fall update, Edge 16 is pushed to customers — with full CSS Grid support, object-fit and object-position, the Payment Request API, Service Worker preview behind flags, and Motion Controllers in WebVR.
WebVR for Edge has added support for motion controllers that allow for fine grained interaction with digital objects in virtual reality. (Image credit)
David Yates’ plea for “RSS: there’s nothing better” is a thoughtful column that praises the idea of the good old RSS over the siloed, algorithm-driven feeds of social media services.
Inter UI is a nice, completely free to use open-source font family optimized for screen readability.
Adobe announced the first stable version of their screen design tool XD at this year’s MAX conference. Besides a lot of smaller improvements, XD now supports sharing, as well as first-class integrations of third-party tools like Zeplin and Sympli. Apart from that, Adobe provided major updates for nearly all their software products during the event.
InVision had a big announcement to make this week: They are going to bring a new screen design tool called “Studio” to the market in January and now invite beta testers to preview it.
InVision announced Studio, a new screen design tool that will be released publicly in January. (Image credit)
Web Performance
Vlad Krasnov got the chance to compare the newest server processors at Cloudflare. The results are pretty interesting: Qualcomm achieves a similar performance as the fastest Intel processors, but it needs about 30% less power, sometimes even less. So while newer Qualcomm chips might have some issues with software incompatibilities, it’s going to be interesting what will happen on the server market. Especially with large data centers in mind where saving energy is quite important — not only because our planet benefits from less power consumption but also because it’s cheaper.
Chrome is implementing an async attribute for HTMLImageElement and SVGImageElement. It’ll have two states: “On” will indicate that the developer prefers responsiveness and performance over the atomic presentation of image and non-image content, while “off” will indicate that the developer prefers atomic presentation of content over responsiveness.
Alexey Ivanov shares how to optimize web servers for high throughput and low latency. But please note: These are small, fine-tuning methods that can be very useful but we should apply them one after another, measure them and then decide if they are useful for the project or not. A thoughtful post that gives us insights into how the Dropbox team improves their edge network servers.
Tooling
Webpack Monitor is a nice dashboard for your JavaScript toolchain. It gives insights into bundle size, the individual parts of the bundle and how the bundle and its size change over time. With tips for optimizing the output, the dashboard is quite useful if you care about reducing the payload for users on your website.
Webpack Monitor displays your bundle so you can make informed decisions about your optimizations. (Image credit)
Security
This week, the “KRACK”-attack was widely discussed. It’s effectively breaking WPA2 encryption on most WiFi hardware. But vendors aren’t sleeping, some already updated their systems and offer software updates for the devices which you should patch as soon as possible. One thing to note here is that websites that use HSTS preloading aren’t affected by the issue, which reminds us that we should consider adding this header to our websites.
Vincent De Oliveira wrote about the amazing CSS element() function which is only available in Firefox currently (but that might change). Actually, it’s not even a new function, but it allows us to use images from the HTML DOM in our CSS, e.g. for a background-image.
Richard Rutter wrote a guide about how to use old-style numerals on the web with the font-variant-numeric CSS property, if available. Proper sub- and superscripts are explained, too, and we can learn when to use which feature for a specific purpose.
Jake Archibald wrote about Netflix removing client-side React and why this step makes the site more robust while still benefiting from the advantages of React.
GitHub open-sourced their own client-side accessibility error scanner. It’s basically a JavaScript module that you import into your codebase, and that then reports back basic issues such as images without alt attribute, links without labels and similar accessibility errors.
Work & Life
200 universities just launched 560 free online courses. Here’s the full list.
Going Beyond…
The Guardian recently published an interesting article called “Ashamed to work in Silicon Valley: how techies became the new bankers”. Seeing that working at tech giants like Facebook is considered negatively by a growing number of people is something I didn’t expect. The article also shares that employees at such companies are even ashamed of their jobs — an interesting change when you remember how most people craved to land a job at one of these companies only until this year.
A chatbot called DoNotPay has saved motorists millions in parking fines — without charging a cent. Its next target: divorce law. And airlines, landlords, and telemarketers will follow, too, in the future.
We hope you enjoyed this Web Development Update. The next one is scheduled for December 15th. Stay tuned!
When using any new CSS, the question of browser support has to be addressed. This is even more of a consideration when new CSS is used for layout as with Flexbox and CSS Grid, rather than things we might consider an enhancement.
In this article, I explore approaches to dealing with browser support today. What are the practical things we can do to allow us to use new CSS now and still give a great experience to the browsers that don’t support it?
What Do We Mean By Support?
Before deciding how you are going to support browsers without grid support, it is worth working out what you mean by support. Support might mean that the site has to look absolutely identical in all the browsers on your list. It might mean that you are happy for some finishing touches not to be available in all browsers. It might mean that you are testing these browsers but are completely happy for them to receive a much simplified experience.
A linked question is how do you come up with your list of supported browsers? Even for a brand new website, this shouldn’t need to be a guess. For most businesses today, a new website won’t be the first site they have ever built. You probably have some analytics you can look at to see the browsers in use, although you need to take care that they are not skewed by a site that is entirely mobile unfriendly for example. People won’t be visiting the site on mobile if it is impossible to use on a small screen!
If you don’t have any relevant analytics you can look at data on Can I Use, where you can import the data for your location.
It is also worth keeping the site goals in mind here too. For example, a site hoping to attract visitors who live in emerging markets such as India will want to ensure the site works well in browsers used in those countries.
Is It Just Old Browsers I Should Worry About?
A the time of writing Edge, Chrome, Firefox, Opera, Safari, iOS Safari all support Grid Layout.
IE10 and IE11 have support for the original spec with an -ms prefix. In terms of old browsers you are looking at:
Internet Explorer 9 (or IE 11 and below if only considering the new spec)
Edge 15 and below
Firefox older than version 52
Safari and iOS Safari older than version 10.1
Chrome older than version 57
Samsung Internet older than version 6.2
However, as mentioned in the last section, these popular desktops and mobile browsers are joined by browsers more commonly used in emerging markets. These browsers haven’t yet adopted grid. For example, if we take a worldwide view UC Browser comes in at 8.1% of traffic — the third most popular browser in the world. If you happen to live in the USA or Europe, it’s possible that you may have never heard of it.
UC Browser does not support Grid Layout. It is also a browser optimized for lower powered devices, but also for users in areas with expensive, often metered data. This is an important thing to consider as we begin to plan a strategy for support.
Is There A CSS Grid Polyfill?
When first encountering CSS Grid, an obvious question is, “Can I use a polyfill?” Unfortunately, a magic polyfill for your entire layout is unlikely to be forthcoming or a great idea to use even if there were such a thing.
Grid does things that are pretty much impossible with older layout methods. So, in order to replicate Grid in browsers that don’t have support, you would need to do a lot of work in JavaScript. Even on a well-resourced computer, with a fast rendering engine that is likely to give you something of a janky experience as heights are calculated and items positioned. As we already know, the browsers that don’t support grid are older, slower browsers or browsers most often found on lower powered devices in emerging markets. Why would you force a bunch of JavaScript onto those devices?
Instead of searching for a polyfill, consider how using Grid Layout can actually provide a better experience to those browsers that don’t support it. Grid will allow you to create complex layout experiences for supporting browsers with minimal CSS, while still offering a good experience to those browsers without support. Yes, it will be a little more work than just throwing a polyfill at the problem, but by doing so, you are ensuring that support means providing a good experience, rather than making the site looking the same the most important goal.
Providing Support For Browsers That Don’t Understand Grid Layout
So, how do we provide support that is tailored to the device and browser in use? It turns out that CSS has the answers for you.
Browsers Ignore CSS They Don’t understand
The first part of the picture is the fact that browsers ignore CSS they don’t understand. If a browser that doesn’t support CSS Grid, comes across the grid-template-columns property, it doesn’t know what it is and so throws that line away and continues.
This means that you can use some old CSS, for example, floats or display: table-cell to provide a grid type layout for older browsers, just as you would in the past. The browsers that do not support Grid Layout will use this layout and ignore all the grid instructions. Browsers that do support Grid Layout will continue and discover the grid instructions and apply those. At which point we need to consider what happens if an item using another layout method becomes a grid item.
New Layout Knows About Old Layout
Defined in the specification is exactly how Grid behaves if you have elements in your page positioned by other layout methods.
Items that are floated or that use the clear property, which then become a grid item, no longer exhibit any floating or clearing behavior. As if this was never applied. Remove all of the properties applied to the class .grid in this next CodePen, and you can see how we have floated all of the items and cleared the third one. However, once we are in Grid Layout this is ignored.
The same is true for inline-block. The value inline-block can be applied to the child item, but as soon as the parent has display: grid the inline-block behaviour will no longer be applied.
I often use CSS display: table-cell when I need to create a column layout and also align items in non-supporting browsers, as the vertical-align property works when you use display: table-cell.
If this is new to you, read The Anti-hero of CSS Layout — “display:table”. I wouldn’t suggest you use this today as your main layout method, but it can be very helpful as a fallback.
When you use display: table-cell to create columns, CSS will create what is known as anonymous boxes. These are the missing parts of the table — a table cell in a real HTML table will be inside a tr element, and that will be inside a table element. The anonymous boxes essentially fix up these missing parents. If your table-cell item becomes a Grid Item however, this happens before the boxes are generated and so once again the item will act as if the CSS tables display had never happened.
The vertical-align property does not apply once in Grid Layout either and so if you use it in a CSS tables layout or with inline-block you can safely ignore that and use Box Alignment for Grid Layout. You can see a layout that uses display: table-cell and vertical-align overwritten by Grid Layout in this next CodePen.
You can also use Flexbox as a fallback, if you have used the flex property or individual flex-grow, flex-shrink or flex-basis properties on the item these will be ignored once it becomes a Grid Item.
Finally, don’t forget that Multi-column layout can be used in some cases as a fallback. For example, when laying out a list of card components or images. It will display items in columns rather than across the row but in some circumstances can be useful. You apply column-count or column-width on the container to make it a multicolumn container, if you then apply display:grid the column-* behaviour will be ignored.
Feature Queries
In the majority of other layout methods, we target the individual items rather than their container. For example in a floated layout, we have a set of items that we have given a percentage width and then set to float: left. This causes them to line up next to each other. As long as we don’t end up with more than a total of 100%, we can make something that looks like a grid.
.grid > * { float: left; width: 33%;}
Floating items and giving them a width gives us the appearance of a grid. (Large preview)
If we then turn that layout into a CSS Grid Layout, we create a grid on the parent. The only thing we apply to the items is an instruction as to how many columns to span.
In our old layout we have floated items with a size applied, in our new layout those items become Grid Items, and typically we don’t want to give those items a size, as they will get that information from the grid tracks that they span.
It is here that we come to an issue with simply being able to override one layout method with another. In the example of a floated layout where the items have been given a percentage size, once that item becomes a Grid Item the size becomes a percentage of the Grid Area it is in and not a percentage of the overall container width. You can see this by using the Firefox Grid Inspector to highlight the lines — the items are now squashed to one side of the Grid Cell.
In a Grid Layout, the width becomes a percentage of the track. (Large preview)
This is where Feature Queries can help. Feature Queries act much like a Media Query, instead of checking for the width or orientation of a device, we check to see if the browser supports a CSS feature.
In our example of a floated layout that we want to turn into a grid layout, we only need to override one thing inside the Feature Query — we want to set the width back to auto.
How much overwriting of CSS used for nonsupporting browsers you need to do depends on how much you have decided to create a different layout for those older browsers.
The IE10 And 11 Version Of Grid Layout
While Edge has now updated to the modern grid layout, IE10 and 11 only have support for the early version first shipped with a -ms prefix in those browsers. The Grid specification that we know of today came originally from Microsoft. So far from being unhappy about this old implementation, we should be glad they kickstarted the process and gave us Grid in the first place. You can read more about the story in the article The Story of CSS Grid, from Its Creators.
You might decide to offer IE10 and 11 a fallback experience based on a floated or other layout type as described above. This will work well, as will using Feature Queries, which are not supported in IE10 and 11. As long as you use these to overwrite your older methods checking for support, then creating the version for supporting browsers, IE10 and 11 will continue to use the older method.
You could however make use of the -ms-grid version to create a fallback method. However this prefixed version is not the same as modern Grid Layout, it was the first version and experimental version. Things have changed in the five years or so since it shipped. This means you can’t just use autoprefixer to add the prefixes, that approach will probably leave IE10 and 11 users with a worse experience than if you do nothing at all. Instead, you need to create a layout using this different and more limited spec.
The key points to note are as follows:
There is no auto-placement. You need to place each item on the grid using line-based positioning.
The grid-template-areas ascii-art method of positioning is not part of the implementation.
There are no grid gap properties.
Instead of specifying start and end lines, you specify a start line and the number of tracks to span.
If you have a large number of users with these browsers then you may find that this old spec is helpful. It is definitely worth knowing it exists even if you only use it to solve a couple of small issues that are real showstoppers for you.
Why Bother Using Grid If I Have To Support These Browsers?
If you have non-supporting browsers in your list, and you have to offer them an identical experience to supporting browsers then I would indeed question whether to use Grid Layout, or any new CSS. Use the methods that work. That approach is still perfectly valid.
You might still consider using Grid Layout with a high level of fallback if you know that within the short-term it is likely that you will be dropping a bunch of those browsers from the “must be identical” list. Especially if you know the development you are doing now will have a long shelf-life. You could then lose the fallbacks at a later date and only use the Grid version.
However, support for you may mean that it is possible for non-supporting browsers to get some level of simplified experience, and there are things you want to do with Grid Layout that are essentially impossible without it. That’s the time to use Grid Layout and design a good non-grid experience for those browsers.
Testing Fallbacks
A final note on testing these fallbacks. The only real way to test your fallbacks is to have access to browsers that do not support CSS Grid. One way to do this, without buying a stack of extra computers, is to download the Virtual Machines offered by Microsoft. You could then test using a version of Internet Explorer without support.
You could download UC Browser onto a phone, or use the desktop version on Windows or in a Virtual Machine.
There are also tools such as BrowserStack which give you access to remote Virtual Machines running a whole range of browsers. These services aren’t free, but they can save you a lot of time setting up VMs for testing.
BrowserStack gives access to many different browsers and operating systems. (Large preview)
I have seen people recommend switching your Feature Query to test for something that doesn’t exist — such as testing for support of display: gridx. This will work reasonably well. However, you do then need to put all of your Grid code inside the Feature Query Block, rather than relying on the fact it is ignored by browsers that don’t support it. You could easily end up with a false positive result by not realizing that some Grid code had wound up outside of a Feature Query. Even if you are using this method for quick checks, I would highly recommend doing some testing on actual browsers too.
Further Reading
I’ve rounded up the URLs referenced in this article and also some additional resources to help you navigate your own path to supporting browsers while still taking advantage of new layout. If you have come across any good resources, or particularly tricky issues, add them to the questions. Grid Layout is still new to all of us as something we can use in production, so there are bound to be some unanswered questions we can take a look at.
If anything’s clear in 2017, it’s that lying is back in fashion (if it ever left us at all). From the heated fake news debate to the false data provided by Facebook, lying is all the rage these days. A white lie here and there is no big deal. We’re all guilty of it. The problem arises when lies turn into full-grown myths, then become accepted as truths.
In an era of digital chaos, we understandably gravitate to our trusted sources of information. For us designers, this usually means guidelines as defined by juggernauts such as Google and Apple.
With the impending switch to a mobile-first search engine world, myths about mobile interfaces are on the rapid rise. As we transition to a mobile-first world, I’d like to remind designers to see guidelines for what they are: guidelines. Somehow, many mobile concepts have evolved into biblical truths, when their intent might rather be case by case.
Having white-labeled design and marketing work for ad agencies for a few years, I’ve heard the following statements boldly proclaimed as unquestionable truths more times than I can count. From my experience with ad teams and client meetings, these are the most frequent myths I think we need to put to bed, or at least remember to evaluate case by case.
Let’s take some time to cover five mobile interface myths you’ve probably been sold on (and why that might be a bad thing).
To Use Or Not To Use
Many criticize gestural controls as being unintuitive and unnecessary. Despite this, widespread adoption is underway already. Read a related article →
Myth 1: Mobile Users Are Always In A Hurry
The prevailing wisdom about mobile users is that they’re always in a rush.
They’re easily distracted, they hate tapping, they have bad taste, and they’re overwhelmingly suspicious of anything laid out in front of them.
While these ideas are rooted deep and might have pieces of truth, they’re not the full picture. Furthermore, one-size-fits-all statements don’t make much sense in an increasingly niche-audience Internet. What works for some webmasters doesn’t necessarily hold true for others.
The Truth: Get to Know Your Real Users
There’s no question that mobile speed is key, and Google’s AMP project serves as a strong reminder of the importance of website-loading time.
What’s less discussed is that you’ll never know which (if any) of these stereotypes apply to your website unless you get to know your target audience.
Take the following company. We could argue over this screenshot all day, but let’s not dive too deep into the analytics. Just compare the website’s “Device Category” column with the “Average Session Duration” column on the far right:
You’ll notice almost no difference in time spent on site when comparing desktop and mobile session durations. In this company’s case, most website visitors come from organic search, so this screenshot is fairly representative of the website’s overall traffic.
In this case, mobile users don’t seem to be in a hurry. Should we assume that all websites have analytics like these? Of course not. Should we assume that session duration is the perfect and only indicator of conversions? No.
Take a longer look at this screenshot and you could accurately find that the bounce rate is higher on mobile and that the percentage of sessions skews heavily towards desktop, as well as a number of other interesting discrepancies. My point is not that session duration means everything, but that each website’s audience behaves differently and that you need to understand your unique audience. Then, optimize accordingly.
Here’s what you should do to better understand your audience:
Know the goals of your website. Do you plan on using the website or app as a new revenue stream? Do you want to outdo your competitors by showing how innovative you are?
Find out who your target audience is. A buyer persona might come in handy for this. Get inside their heads. What do they need? What are they looking for? What problems are they trying to solve? Are they ready to sit and read long posts? Do they prefer a quick video?
Test your ideas. Before rolling out any changes, make it a point to gain customer feedback. Do not hesitate to test. Knowing what works and what doesn’t ahead of time will facilitate your design and development process.
Spend time reviewing your own website’s analytics, and work to understand your audience’s intent, which is hiding behind the raw numbers.
Myth 2: Mobile Websites Require Fewer Features
I’m sure we all remember how we typically used the Internet nearly 10 years ago — we were primarily looking for time-sensitive content. Back then, our needs were rather immediate and specific.
People on mobile websites had little to no intent to explore or purchase anything. Data connections were slow and expensive. It made sense to design mobile websites for pared-down tasks, offering the bare minimum. Publishers adopted an “if in doubt, leave it out” mentality, and if users wanted to view the full website, they’d need to hop onto their PC or Macintosh.
This just isn’t the case anymore.
The Truth: Prioritize and Maximize Mobile Capabilities
Nowadays, when someone visits a website on their mobile device, they expect to see everything that the desktop version offers. The practical way to accomplish this is to prioritize and maximize the capabilities of mobile features, including:
taking advantage of mobile sensors’ superpowers, something that desktops don’t have;
adding more content and features to a mobile website — depending on your user’s goals, this could mean adding share buttons pinned to the bottom of the screen or quick-tap functionality to return to the top of the page;
building your website or blog to adapt to the particular needs of each device type.
The idea is to get rid of the thought that a smaller screen indicates less intent among users to explore. Instead of eliminating features on mobile, prioritize them.
Common wisdom (and probably your experience) tells you that popups are annoying and that you should delete them immediately. Here’s the problem with this advice: You still need to encourage signups, downloads and so on for mobile visitors.
The key is to prioritize this content, not eliminate its purpose.
Myth 3: Simplicity Is Good, Complexity Is Bad
Closely related to myth 2, the next myth is one of the most widely held beliefs in the industry. When it comes to websites and apps, “less is more,” right?
This myth states that mobile applications should be the “light version” of a desktop website. This comes from the principle that the organic interface has to be as close to zero as possible.
Marissa Mayer famously discussed the two-tap rule: The fewer the clicks needed to achieve a goal, the better.
Three-click rule of UX in action (Image: Prototypr.io)
A ton of designers tend to treat mobile and desktop as two different creatures, with opposing needs. Yes, there are significant limitations to a mobile device’s capabilities (namely, screen size). However, the intent of a user doesn’t drastically change, whether they’re using their mobile device or a desktop computer.
So, why should the mobile interface be simpler?
The Truth: Embrace Complexity
Depending on your website or app’s users, this myth could ring true.
Could you imagine needing eight taps to send snaps on Snapchat? Me neither.
The point is more that mobile users don’t want a dumbed-down version of a website. People simply need complexity presented in a way that’s uncomplicated. It all boils down to giving a good user experience. Consider the following:
Have one big idea per screen.
Instead of sending elements to secondary pages, you could put more content under properly labeled display elements.
Requiring more taps on a screen isn’t necessarily a bad thing. The idea is to make the website’s screen clear and easily digestible, rather than cluttered and dense. If a click has a goal to it, it can stay.
A lot is involved in creating a profile. Is this a personal user? Is it a business profile? Will you choose social login? Email login? This signup process incorporates a lot of information but doesn’t feel overwhelming because it’s easily digestible.
Complexity is not the bane of mobile design. When you build your website, you just need to make it enticing and user-friendly.
Most designers treat guidelines as gospel, and for a decent reason.
Many times, guidelines are incredible resources, to be followed as instructed. Google’s material design is a great resource for understanding how to craft digital experiences using a consistent set of principles.
Designers often hold that applications created for iOS should follow Apple’s guidelines and that apps made for Android should follow Google’s guidelines, and that if an app needs to be accessible on both operating systems, then the designs should be entirely different from each other.
The problem arises when designers find themselves stuck between a rock and a hard place, where they envision a design that conflicts with the guidelines.
Should they follow guidelines? Or can they trust their design instincts for each unique case?
The Truth: Treat Guidelines as Recommendations
The dictionary defines a guideline as a “general rule, principle, or piece of advice.” A guideline is intended to serve as a loose guide or as helpful suggestions, not a strict mandate to obey.
Design is an exploration to discover what works best.
– Google Design
If your intended design severely clashes with conventional guidelines, you’ll need to weigh whether this is an indicator to rethink your layout approach or whether you’re simply designing with your unique users’ needs and intentions in mind.
To put this myth to bed, Google even ignores its own material design guidelines (on occasion). Take its icons:
To paraphrase Android Authority, Google’s icons fly in the face of product-icon anatomy. The guideline states that you shouldn’t crop elevated material elements within another shape, meaning that the uppermost layer shouldn’t have its boundaries defined by the lower layer.
The icons for Movies, Music, Games, Books and Newsstand all are beautifully designed, while defying this straightforward guideline. These icons have also done away with the 45-degree light source that is commonly encouraged for all icons.
On the whole, Apple and Android guidelines are a tremendous gift. However, don’t treat them as hard and fast rules. Always design with your users in mind, even if that means bending some of the guidelines.
Myth 5: The Designer And The User Think The Same
This myth is more of a commonly held belief carried out in practice, rather than an actual myth. Of course, the first rule of user-centered design is that you are not the user. But, so often, clients and designers fall for the “we know what’s best” approach.
It’s tempting to think that everybody thinks just like you.
Often, designers fall into the trap of thinking like their client or thinking of themselves when approaching design. “Would I like this feature if I implemented it?” or “Would my client tap on this button if I placed it here?” are questions that fall under this umbrella.
The problem with this is that you lose sight of who you’re designing for: the user.
The Truth: Users Have Experiences Unique From Yours
It’s possible that the demographics of your users include yours or your client’s. However, you’ll need to look at design from the perspective of your visitors, not of your client.
This is true for a couple of reasons:
Users only want what’s beneficial for them. You, as a designer, are able to come up with ideas to present a product in a way that you think would engage the user. However, these ideas will only matter as long as they are beneficial to the user. If the user doesn’t find value in it, they won’t enjoy engaging with the content you produce.
Users only want their problems to be solved. The client knows more about the business than the user. They immerse themselves in the industry, studying it, learning its ins and outs. This data isn’t of interest to the user, who only wants their problems to be solved. The client is all about gaining profit; the user is all about finding solutions. Sometimes these interests overlap, but keep your eye on user needs first and foremost.
I’m hardly a usability testing expert, but I’ve been thinking about how my team could use a significantly simplified version of user testing for an upcoming website redesign. Here’s the basic outline of user testing I have in mind:
Gather an unbiased group of individuals.
Do not disclose which website is being tested, to avoid bias. Instead, show several websites sequentially, including our website and competitor websites.
For each website, walk individuals through each page, discussing the intended user flow, mission, etc.
Let each individual test how they would achieve the tasks, while providing no indication of how you think the goals should be completed.
Test on various devices and connections, to compare between devices.
Ask each individual to write down any issues they run up against, while trying to achieve the stated purpose for each page.
Ask each participant to grade each website, asking for their feedback on accessibility, speed, UX, navigation, readability, the overall score, etc.
Repeat these observations over time to identify new recommendations.
This is not a perfect scenario, but it enables us to define a preliminary report of usability issues and observations, and to pinpoint key recommendations for our work moving forward.
Summary
If I had to encapsulate the sections above, along with what I’ve learned at my web design and marketing agency, it would be this: Test, test, test. And then test again.
Takeaways
Understand your audience and purpose. Determine the goals of your website, find out who your target audience is, and test your ideas to gain useful data about your visitors.
Maximize mobile capabilities. Take advantage of the superpowers of mobile sensors, add mobile-specific features, and adapt to the specific needs of each device and mobile operating system.
Embrace complexity. Have one big idea per screen. Put content under properly labeled display elements, instead of on secondary pages. And make sure the screen is clear and easily digestible, rather than cluttered and dense.
Treat guidelines as useful recommendations, not mandates. Guidelines can serve as helpful suggestions. But, ultimately, design is an exploration to discover what works best.
Work to understand your audience’s unique points of view. Try employing mobile usability testing to better understand your visitors’ needs.
Make time to track and analyze the analytics for how your audience responds to your company’s split-testing efforts. Don’t take anybody’s word for it (including mine).
Observe what your visitors are doing, anticipate their needs, and design for their approval and convenience. Over time, you’ll gain a deeper understanding of your unique audience and will naturally attract a growing number of visitors eager to engage with you and your business.
