Some people hate writing documentation, and others just hate writing. I happen to love writing; otherwise, you wouldn’t be reading this. It helps that I love writing because, as a design consultant offering professional guidance, writing is a big part of what I do. But I hate, hate, hate word processors.
Have you ever wanted to make a website that non-technical folks can edit right in the browser? Or have you ever wanted to make a website that presents an editable collection of items (e.g. your portfolio)? Or simply upload images to a website you made, right from the browser?
Well, what if I told you, that you can do these things (and more!), just with HTML and CSS? No programming code to write, no servers to manage. You can make any element editable and saveable just by adding one HTML attribute to it. In fact, you can store your data locally in the browser, on Github, on Dropbox, or any other service just by changing an HTML attribute.
A sitemap is (usually) an XML document, containing a list of pages on your website that you have chosen to tell Google and other search engines to index. Google often uses the sitemap file as a guide to the pages available on your website — even though it may decide not to index every page you list on your sitemap. The sitemap also carries information about each page, including when it was created and last modified, and its importance relative to other pages on your site. This speeds up the process of indexing pages. A sitemap is one of those…
HTML email: Two words that, when combined, brings tears to a developer’s eyes. If you’re a web developer, it’s inevitable that coding an email will be a task that gets dropped in your lap at some time in your career, whether you like it or not. Coding HTML email is old school. Think back to 1999, when we called ourselves “webmasters” and used Frontpage, WYSIWYG editors and tables to mark up our websites.
Not much has changed in email design. In fact, it has gotten worse. With the introduction of mobile devices and more and more email clients, we have even more caveats to deal with when building HTML email.
I’m big on modular design. I’ve long been sold on dividing websites into components, not pages, and amalgamating those components dynamically into interfaces. Flexibility, efficiency and maintainability abound.
But I don’t want my design to look like it’s made out of unrelated things. I’m making an interface, not a surrealist photomontage. As luck would have it, there is already a technology, called CSS, which is designed specifically to solve this problem. Using CSS, I can propagate styles that cross the borders of my HTML components, ensuring a consistent design with minimal effort.
Living style guides are an important tool for web development today, especially in large, complex web applications. They help document styles and patterns, keep designers and developers in sync, and greatly help to organize and distill complex interfaces. Indeed, living style guides remain one of the best ways to communicate design standards to an organization.
Recently, our company went through the process of creating a living style guide. This is the story of how we developed our living style guide, the mistakes we made along the way, and why the current landscape of style guide generators did not suit our needs.
In May of 2015, Facebook unveiled its new in-app publishing platform, Instant Articles. A month later, Apple declared that the old Newsstand experience (essentially a fancy folder full of news apps) would be replaced in iOS 9 with a brand-new news aggregation and discovery platform called Apple News.
Four months later, it was Google’s turn to announce its own, somewhat belated but no less ambitious, plan to revolutionize mobile news consumption with an open-source web-based solution called Accelerated Mobile Pages, or AMP. In just a few months, we’ve seen the relative tranquility of mobile digital publishing erupt into yet another full-scale platform war as Facebook, Apple and now Google compete for both the loyalty of publishers and the attention of readers.
What is the difference between a web page and a web application? Though we tend to identify documents with reading and applications with interaction, most web-based applications are of the blended variety: Users can consume information and perform tasks in the same place. Regardless, the way we approach building web applications usually dispenses with some of the simple virtues of the readable web.
One upcoming technology that represents a big leap forward in making the web a mature application platform is web components. From a high-level perspective, web components will enable better composability, reusability and interoperability of front-end web application elements by providing a common way to write components in HTML.
The goal of this article is to show you why this will be such an important step, by showing off what can be accomplished right now using Polymer. Polymer is currently the most advanced and (self-proclaimed) production-ready library based on web components.