This extended category features articles on client-side and server-side programming languages, tools, frameworks and libraries, as well as back-end issues. Experts and professionals reveal their coding tips, tricks and ideas. Curated by Dudley Storey and Rey Bango. Subscribe to the RSS-Feed.
Whether you’re in a Fortune 500 company or part a two-person team launching your first web app, email is one of the most important tools for reaching your customer base. But with the ever-growing number of emails to send, getting them all out the door can seem a little overwhelming.
By putting in place a solid email design workflow, you’ll be able to regularly ship engaging and mobile-friendly emails with ease.
I recently migrated my blog from WordPress to Jekyll, a fantastic website generator that’s designed for building minimal, static blogs to be hosted on GitHub Pages. The simplicity of Jekyll’s theming layer and writing workflow is fantastic; however, setting up my website took a lot longer than expected.
In this article we’ll walk through the quickest way to set up a Jekyll powered blog, how to avoid common problems with using Jekyll, how to import your content from WordPress, use your own domain name, and blog in your favorite editor, how to theme in Jekyll, with Liquid templating examples, a couple of Jekyll 2.0’s new features, including Sass and CoffeeScript support and collections.
Like most web developers, I spend my days giving instructions to computers. These instructions generally involve some input (a request for a web page), some logic (get the right content from a database) and some output (send the content to the requesting browser). This process of telling a computer how to perform a task, such as generating a web page, is what we commonly call “programming,” but it’s only a subset of programming: imperative programming.
There’s another type of programming, declarative programming, that most web developers also use every day but don’t often recognize as programming. With declarative programming, we tell a computer what, not how. We describe the result we want, and the details of how to accomplish it are left to the language interpreter. This subtle shift in approach to programming has broad effects on how we build software, especially how we build the future web.
Front-end development is no longer about individual frameworks. Tools are available — we merely have to choose. To make the right choices for your project, you need to start with a general approach, or methodology. But most methodologies have been created by big companies? Are they still useful for small companies, or do we need to reinvent them at a small scale?
You probably already know of BEM, one of those methodologies developed by a big company — namely, Yandex. BEM posits that three basic entities (blocks, elements and modifiers) are enough to define how to author HTML and CSS, structure code and components, describe interfaces and scale a project up to an industry-leading service.
It's one thing to create a web application and quite another to keep it accessible — independent of the device that the user is using and its capabilities. That's why Heydon Pickering, now the accessibility editor on Smashing Magazine, wrote an eBook Apps For All: Coding Accessible Web Applications, outlining the roadmap for well-designed, accessible applications.
This article is an excerpt of a chapter in the eBook that introduces many of the ideas and techniques presented. Reviewed by Steve Faulkner, it's an eBook you definitely shouldn't miss if you're a developer who cares about well-structured content and inclusive interface design. – Ed.
Because the W3C’s mission from the outset has been to make the web accessible, accessibility features are built into its specifications. As responsible designers, we have the job of creating compelling web experiences without disrupting the inclusive features of a simpler design.
Functional programming is the mustachioed hipster of programming paradigms. Originally relegated to the annals of computer science academia, functional programming has had a recent renaissance that is due largely to its utility in distributed systems (and probably also because “pure” functional languages like Haskell are difficult to grasp, which gives them a certain cache).
Stricter functional programming languages are typically used when a system’s performance and integrity are both critical — i.e. your program needs to do exactly what you expect every time and needs to operate in an environment where its tasks can be shared across hundreds or thousands of networked computers.
From a motion design perspective, Facebook.com is phenomenally static. It's purposefully dumbed down for the broadest levels of compatibility and user comfort. Facebook’s iOS apps, on the other hand, are fluid. They prioritize the design of motion; they feel like living, breathing apps.
This article serves to demonstrate that this dichotomy does not need to exist; websites can benefit from the same level of interactive and performant motion design found on mobile apps. Before diving into examples, let's first address why motion design is so beneficial.
Z-index is an inherently tricky thing, and maintaining z-index order in a complex layout is notoriously difficult. With different stacking orders and contexts, keeping track of them as their numbers increase can be hard — and once they start to spread across CSS files, forget about it! Because z-index can make or break a UI element’s visibility and usability, keeping your website’s UI in working order can be a delicate balance.
Optimizing your website assets and testing your design across different browsers is certainly not the most fun part of the design process. Luckily, it consists of repetitive tasks that can be automated with the right tools to improve your efficiency.