You know, we use ad-blockers as well. We gotta keep those servers running though.
Did you know that we publish useful books and run
friendly conferences — crafted for pros like
yourself? E.g. our upcoming SmashingConf Barcelona,
dedicated to smart front-end techniques and design patterns.
Ben Gremillion is a Writer at ZURB. He started his career in newspaper and magazine design, saw a digital future, and learned HTML in short order. He writes tutorials and facilitates the ZURB University training courses.
CSS floats and clears define web layout today. Based on principles derived from centuries of print design, they’ve worked well enough — even if, strictly speaking, floats weren’t meant for that purpose. Neither were tables, but that didn’t stop us in the 1990s.
Nevertheless, the future of web layout is bright, thanks to flexbox. The CSS layout mechanism lets us arrange elements in a truly web-like way. Some elements can be fixed, while others scroll. The order in which they appear can be independent of the source order. And everything can fit a range of screen sizes, from widescreen TVs to smartphones — and even devices as yet unimagined. Browser support is fantastic (except you-know-who). Yep, it’s a great time to jump into flexbox if you haven't done so yet.
It's just like that for your product, too: people rely on our products to work. Bugs erode trust, which in turn loses customers. So when we began updating Foundation, a responsive CSS framework, we wanted to ensure everything worked. Thoroughly. We know that many people rely on our software for their work, and maintaining that trust is paramount.
In this article you'll learn our methodology for testing responsively, not just on a case by case, page-from-PSD comp. See, we've developed a certain system to make sure that nothing's broken at launch on different devices.
Designing websites for smartphones is easy compared to retrofitting those already in place. More than that, it’s embarrassing how, almost eight years after CSS gained practical acceptance, a lack of foresight haunts those of us who write HTML.
Converting older websites to responsive design causes headaches not because small screens are difficult, but because most HTML documents were written under an assumption about screen size.
The most valuable part of a computer is also its most fragile: Data are the wealth of a digital lifestyle, a currency of which many notes are irreplaceable. At least, that’s how I felt staring at a “Confirm you want to wipe your hard disk” message, my finger poised over the mouse.
During an emergency is a bad time to plan for one. It’s the feeling one might get jumping from a plane before checking one’s parachute. That’s one experience I’d rather avoid, but it happened. Not the skydiving part. My OS was dying, and I wasn’t prepared.
People who make websites face a triple threat: Live websites need backups; test environments need backups, especially when they double as backups for live websites. Subversion and Git provide safety nets in case of data loss. But there are also support files: Photoshop files, fonts, reusable jQuery snippets — not to mention music collections, an essential part of many creative processes.
The trouble with a color’s name is that it never really is perceived as the exact same color to two different individuals — especially if they have a stake in a website’s emotional impact. Name a color, and you’re most likely to give a misleading impression. Even something like “blue” is uncertain. To be more precise, it could be "sky blue", "ocean blue", "jeans blue" or even "arc welder blue". [Links checked February/17/2017]
Descriptions vary with personal taste and in context with other colors. We label them "indigo", "jade", "olive", "tangerine", "scarlet" or "cabaret". What exactly is "electric lime"? Names and precise shades vary — unless you’re a computer.
As iOS, Android, and Windows 8 take the Web to smaller screens, designers are adopting techniques to make their websites usable on handheld devices.
Responsive Web designs present different formatting and layout to suit the device on which their pages are displayed. Browsers choose the appropriate styles on page load, freeing website owners from having to maintain different sets of pages for different display scenarios.
As Web technology improves, users expect Web-based widgets to be useful, content to be relevant and interfaces to be snappy. They want to feel confident navigating a website and using its functionality. They crave being able to get things done with little friction and on demand. And demand they do.
People are picky. When a website gives them problems, they are less inclined to use it. From a design perspective, testing for a good user experience entails making improvements based as much on critical feedback as on design expertise. As long as your website is around, offering a good user experience is critical. And like the website itself, improving the user experience doesn’t end when the website launches.
For too many projects, there comes a time when every action taken, every decision and sacrifice made, is spurred on by pressure to finish. Tempers seem to shrink along with the available days, talk about “high standards” gives way to “good enough,” and people realize that deadlines are aptly named. During the last-minute crunch, someone may well wonder, how did it come to this? Could it have been prevented?
Every Web project has deadlines. But not every designer or developer deals with them the same way. Because a deadline marks the end of a project, everyone involved in the project must understand the deadline’s role. Most projects follow a schedule or have an estimated date by which they must be completed. The concept is simple then: when the work takes longer than expected, deadlines get missed.