After that first second, a mental context switch occurs. In the user’s mind, it has been so long that they start to think about other things.

And after about 10 seconds, the user is already bored and will probably close their browser tab and get on with their day.

What I will cover in this guide is a process for optimizing your website’s performance. I’m going to use my own site as an example.

If you haven’t done the things discussed in this guide, you will get guaranteed website speed improvements after performing the steps that I will be discussing.

Initial Benchmarking

The first thing to do is to test the current performance of the site. This will help us see issues related to web performance, as well as help us prioritize our efforts.

One excellent tool for benchmarking front-end performance is Google’s performance analysis tool, PageSpeed Insights. It will check your site and give you a score based against a set of performance guidelines and best practices.

Here’s the first result I got for mobile:

And for desktop:

Google Developers has another useful test available, called Mobile-Friendly Test. This tool will show you potential areas for improvements. For this test, everything’s OK on my site:

Improving Performance

There are two general approaches to improving website performance with the use of developer tools.

You can use online tools

You can use open source web development tools on your machine

The first approach is straightforward: Grab all your files and use the online tools to do whatever it needs to do (lint, minify, concatenate, etc.).

Done. Well… not quite.

What if you have 50 files to minify? Or 200? And what if you change your code? Are you going to repeat that task over and over?

That’s why I’ll cover the second approach, because it’s more flexible and scalable. However, it’s a more complicated approach, especially at the start.

We’ll use Gulp, a JavaScript task runner (similar to Grunt), that will do all the work for us. (If you don’t know what developer tools like Gulp, Grunt, Bower, and Yeoman are, check my blog post where I give a brief intro about them.)

To improve website speed and performance, this is what we will do:

Set up Gulp

Minify the CSS and JavaScript files

Concatenate the CSS files and JavaScript files

Lint our JavaScript code to check for errors and issues

Optimize the images

Minify the HTML documents

Setting Up Gulp

The first thing to do is to set up a project working environment. All I did was grab all the files from my site and move them to a folder called src in my computer.

By the way, you will need Node (and npm) installed to be able to use Gulp in the manner I’ll be describing. See How to Install Node.js.

First, we need to install Gulp globally so that it’s accessible anywhere in our computer. Just open your terminal/command prompt and type:

npm install --global gulp

Then go to your project folder and install it in your development dependencies.

npm install --save-dev gulp

After that, you’ll see a new folder that will automatically be created for you called node_modules. That’s where Gulp and all your other Node modules for the project will be stored.

There’s just one more step to perform before running Gulp: We need to set up a configuration file so that Gulp knows what tasks to perform on our files. And that’s as easy as creating a file called gulpfile.js in your root folder with any text editor or source code editor.

Here’s the initial contents of gulpfile.js:

var gulp = require('gulp');
gulp.task('default', function () {});

Right now it isn’t doing anything, but you can still run it. Just type:

Now that we have Gulp ready to go, the next step is to create the Gulp tasks to do all the work for us.

Minifying CSS and JS Files

OK, let’s get some stuff done with Gulp! First task: Minifying our CSS and JS files.

The minification process, what it does basically does, is it strips off all white spaces, tabs, carriage returns, newlines, comments, and other unnecessary characters from our files. For JavaScript, it will also change object names to shorter ones.

Minification is performed in order to get a very small file size, while still preserving all our style rules and JS functionality.

In order to minify our files, we’ll need to install node modules that will help us with the task.

Let’s install the gulp-minify-css package, which will minify our CSS files. Then we will use the gulp-uglify package for our JavaScript files.

Now that we have our required modules, we have to create the task for each one. We can actually do everything inside our default task, but I prefer to do a separate task for each type of file. This way, we’ll keep our code cleaner, easier to read and maintain, and, if we want, we can run the task for the CSS or the JS files separately.

Let’s add our minify-css and gulp-uglify modules to the top of our gulpfile.js.

We’re using different modules because gulp-concat-css is more appropriate for CSS files since it does the rebase of the URLs automatically.

Gulp is a stream-based build system, so if you want to apply another process after that, you just keep piping. Both modules require a string argument with the name of the concatenated file. In this case, I’m using semeano.min.css and semeano.min.js. (Actually, I’m not using any JS on my site, but I’ll do it just for the sake of the tutorial.)

Linting JS Files

Linting won’t actually help reduce the size of the files, but it will help you detect errors and potential problems in our JavaScript code. And if we were to stretch it, JavaScript errors can lead to broken or low-performing functionality and, subsequently, a bad user experience. So linting your code is a must, in my opinion.

JSHint is a fork from another similar tool called JSLint. So why use JSHint? Basically, it all comes down to what you prefer. (If you want to know the reason behind the JSHint fork, read this article.)

Let’s install JSHint:

npm install --save-dev gulp-jshint

Add the dependency:

var jshint = require('gulp-jshint');

We need to pipe the code linting process before uglifying our source code, or else it will be tough to debug if JSHint spots an error:

The reporter method is what will output the warnings on the terminal/command prompt. We’re using the default reporter, but you can change it to a different one.

Optimizing Images

When we run PageSpeed Insights, it will check if the images that we’re using are larger than they need to be. We can strip all the metadata from the images, which will reduce the file size a small bit. To optimize images, we’ll be using gulp-imagemin for raster images (e.g. JPG, PNG, and GIF) and gulp-svgmin for SVG files respectively.

In my case, this didn’t actually make a big difference on the image, it just saved 543 bytes:

gulp-imagemin: Minified 1 image (saved 543 B - 0.2%)

But I remembered that the image was the main issue on the tests:

That is happening because I’m using the same image for desktop and mobile. Everything was fine on the desktop tests, but on mobile, since I’m using the original image and resizing it, I’m wasting a lot of pixels. The solution for this is to have different image sizes for each media-query breakpoint. That way, if you need a 200x200px image, the browser will download only that size, saving bandwidth along the wire.

Minifying HTML

Minifying our HTML files is also important, and here is where you’ll probably see the most savings in file size. To minify our HTML documents, we’ll use the gulp-minify-html. Also, in order to make the changes on the resources automatically, from the files in the src folder to the dist folder, we need to install gulp-useref.

This task requires a small change in the HTML files (in this case there’s only one, the index.html). We need to add a special comment for the gulp-useref module referencing a block on resource files (html5reset-1.6.1.css and semeano.css) that will result in a single file (semeano.min.css) after the concatenation and minification.

What that basically means is that before running the default task, Gulp needs to run all those tasks first.

Conclusion

After these changes, we can see some improvement on the score. It seems like a small change (only 12%) but after the minification of our files we are sending 33% fewer KBs compared to before. That’s something! And it didn’t take a whole lot of time to achieve.

Here are some other things that could help improve the loading speed of your web pages:

Use of spritesheets. Instead of downloading a set of images, just put them all together inside one single image file and use CSS to specify the area of each image. This solution also applies to SVGs.

Convert images to WebP. WebP is a new image format that provides lossless and lossy compression for images on the web. WebP lossless images are 26% smaller in size compared to PNGs. But WebP browser support is low compared to PNG, GIF and JPEG.

Inline CSS. If your CSS files are small, just inline them in your HTML using the <style> tag. That will save you some server requests and will help avoid page-render-blocking CSS. This is a practice Google PageSpeed Insights recommends.

In future guides, I’ll share more intermediate-to-advanced website performance optimization tips and strategies, such as making changes to the structure of our HTML markup, other solutions for optimizing content delivery, and even some server configurations that will give us that final speed boost!

Feel free to share this guide on Twitter and Facebook if this was helpful to you. Also, if you have ideas and tips for improving website speed, please share them in the comments.

]]>http://sixrevisions.com/web-performance/improve-website-speed/feed/0http://sixrevisions.com/web-performance/improve-website-speed/Disable Text Selection with CSShttp://feedproxy.google.com/~r/SixRevisions/~3/uUH_81ihXtc/
http://sixrevisions.com/css/disable-text-selection/#commentsFri, 27 Mar 2015 14:00:28 +0000http://sixrevisions.com/?p=8107A short guide on how to use the non-standard user-select CSS property to prevent users from selecting text and other HTML elements.

Demo

Important Things to Keep in Mind

There’s a catch: user-select is not a standard CSS property included in any W3C specification. Although user-select has a good level of browser support, utilizing the property requires vendor prefixes.

In the prior example, I didn’t use an unprefixed user-select property declaration. That’s because there’s no such property in the eyes of web standards. I would go so far as to analogize the use of user-select as being equivalent to using a proprietary CSS property such as Internet Explorer’s -ms-filter or -ms-text-kashida-space.

Other things to note:

user-select is buggy and inconsistent. Sometimes you can still select the text, especially when you start by selecting portions of the UI which aren’t disabled.

Using the “Select All” command will occasionally include disabled texts. (Win: Ctrl + A/Mac: Cmd + A) This situation can clearly be seen in Internet Explorer 11.

This technique is not a bullet-proof way of preventing user-selection. CSS can easily be disabled. This technique relies on non-standard CSS properties, which means there’s a whole deal of uncertainty with regards to its continued support in future web browsers.

Disabled user-selection is annoying. I would use this technique within the framework of progressive enhancement: Use it only in situations where it will enhance the UX of people who use browsers and devices that support the user-select property. I would not, however, assign this to a broad CSS selector like the universal (*) selector or body.

The user-select property might invalidate your stylesheet. If standards compliance is important to you, using this property might give you issues when using validator tests such as the CSS Validation Service when set to its strictest options.

:root Pseudo-class

We need a place to put our custom properties in. We can specify custom properties within any style rule, but many times, that’s not a good idea because specifying custom properties all over the place presents maintainability and CSS-readability challenges.

The :root pseudo-class represents the top level of our HTML documents. This selector is a good place to put our custom properties in because we can predictably overwrite the custom property values through other CSS selectors that have greater specificity.

Benefits of CSS Variables

Maintainability

Within a given web development project, we’ll often be reusing certain CSS property values. We’ll often reuse colors, line heights, margins, font sizes and so forth.

Here’s an example of four style rules that could benefit from CSS variables:

The problem surfaces when we need to change certain property values later on.

If we manually change our values by hand, it might take us a lot of time, and there’s a huge chance we’ll make an error somewhere, especially if our stylesheet is huge. Similarly, if we perform a batch find-and-replace, we might unintentionally affect other style rules.

Now imagine your client says to you that the text on the screen is hard to read because the text color is too light. In this situation, we just need to update one line in our CSS:

--text-color: black;

That’s -66% fewer lines of code we have to edit, in the context of the previous set of style rules (one line versus three lines) .

In the same token, using CSS variables gives us an easier time when we want to experiment with our designs. While we’re developing the project, we can rapidly test color values, line-heights, and bottom-margin values all in one place, and we’ll be able to see the effects in a holistic way.

Improved CSS Readability

Custom properties can help make our stylesheets easier to read. It could make our CSS property declarations more meaningful as well.

Property values like yellow and 18px don’t give us any useful contextual information. But when we read custom property names like --base-font-size and --highlight-color, even when we’re reading someone else’s code, we instantly know what the property value is doing.

However, if we remove the .container style rule from our code, the link will be assigned the color of green because body now becomes the next selector that matches our links.

Fallback Values

You can assign a fallback property value when using the var() function notation. Simply provide the fallback property value as an additional argument delineated with a comma (,).

In the following example, the .box element is supposed to be rendered with a black background. However, because there’s a typo when referencing the custom property name, the background will be rendered using the fallback value (i.e. red).

]]>CSS preprocessors like Sass and Less are now a common part of our workflows. They have their pros and cons, and I’d like to start a discussion about their value to our work.

Some possible talking points (up to you, though):

Do you use a CSS preprocessor? Why or why not?

What are the benefits and disadvantages of using a preprocessor?

Which preprocessor do you use? And, more importantly, why?

Got tips and things-you-wish-you-knew’s to share to those of us thinking about using a preprocessor for the first time?

The floor is yours. See you in the comments!

What’s the deal with these open threads?

In my post about the Six Revisions redesign, I shared to you that one of the things I wanted to work on was creating more chances for us to talk and engage with each another. Open Threads is hopefully a small step towards this.

I want to try this concept out and get your feedback before formally codifying any sort of community guidelines, but a couple of basic ground rules:

We’ll only keep the threads open for a short time: I’m thinking this period should be between three to five days, but I’d like to get your feedback on this. The current thread will be open from Saturday until Wednesday, then the comments section will be closed. This way, you won’t come in here six months from now after we’ve have already moved on from the topic.

Let’s be civil: There might be instances where a topic we’re talking about leads to disagreements, which is OK. When this happens, let’s promise each other not to let our passion about our viewpoints take us down towards name-calling, flame wars, and so forth. Instead, let’s offer each other constructive counter-arguments when replying to comments that are contradictory to what we believe in.

Anyways, I’m excited to hear your thoughts about the subject of this open thread. CSS preprocessors are really interesting to me, and I wanted to see what you felt about them.

]]>http://sixrevisions.com/open-thread/why-use-css-preprocessors/feed/20http://sixrevisions.com/open-thread/why-use-css-preprocessors/Bower Beginner’s Guidehttp://feedproxy.google.com/~r/SixRevisions/~3/9xZrNBJ9iGQ/
http://sixrevisions.com/tutorials/bower/#commentsFri, 20 Mar 2015 15:00:47 +0000http://sixrevisions.com/?p=7890A quick tutorial that will help you get started with Bower, an excellent front-end development package manager.

]]>Modern web development generally involves using third-party dependencies: CSS libraries and preprocessors like Bootstrap and Sass, JavaScript libraries like jQuery and Angular, and everything else in between.

I bet if you listed down all of the tools you currently use/have used to develop sites with, you’d be shocked at just how many of them you’ve been relying on.

How do you effectively keep track of them all, across all of your various development projects? How do you keep your project dependencies updated? How do you update them in such a way that your older projects, which might not be compatible with the latest releases, aren’t affected?

Managing all of your project dependencies manually is a full time job all on its own. Without the proper tool.

If you work on a lot of dev projects and you use third-party dependencies, using a package manager such as Bower is a must.

This tutorial covers the basics of Bower. This tutorial is geared towards front-end developers who are new to Bower, but are not new to command-line interfaces (CLIs).

If you’re not comfortable with CLIs, Bower is an excellent and gentle introduction to them (compared to, say, jumping directly into managing your own web server/VPS through a command-line interface).

What is Bower?

Bower is a tool that helps you install, update, and manage all of your front-end development dependencies. A dependency in this context is an open source project that you rely on to build your site, such as Bootstrap, jQuery, and Normalize.css.

Install Bower

To install Bower, you’ll need:

Node

npm (which comes with Node by default)

Git

If you don’t have Node (and npm) installed yet, you might want to read this tutorial first: How to Install Node.js. If you don’t have Git either, check out our tutorial called How to Quickly Get Started with Git — it’s written by Tobias Günther (who knows a thing or two about Git, given that his company built one of the most popular Git graphical user interfaces in the market).

Once you have Node, npm, and Git ready to go, install Bower by running the following command in your command prompt/terminal:

npm install -g bower

The command above installs Bower globally, which means it will be accessible anywhere in your computer.

Just a funny aside, the command above is similar to using Mozilla Firefox to download Google Chrome. Anyways, moving on.

Next, navigate to your project’s directory/folder. This is important — and I want to say this early on in this tutorial — because the rest of the tutorial assumes you’re already in your project’s directory. If you don’t have one, just create a folder somewhere in your computer, name it something like “bower-tutorial” or “messing-around-with-bower” or whatever, and then navigate to it. You don’t want to be doing all of this in your Desktop folder or something.

Getting Help

Since this is probably your first time using Bower, the command I’d like to talk about first is the help command, which displays inline docs and tips.

Issuing the help command without any arguments will show you a list of Bower commands.

bower help

If you want to learn about a particular Bower command, there are two ways to go about it.

The first is to issue the help command followed by the name of the command you want to learn more about. For example, let’s say you want to learn about the prune Bower command. We can do:

bower help prune

The other method is to type the command followed with the -help (or its shortcut, -h) option. This way of displaying help documentation is useful when you’re typing a Bower command and then, midstream, you suddenly realize you’ve completely forgotten what the command does, or that you’d like to explore what its options are before issuing the command.

bower prune -help

The following is exactly the same as bower prune -help, except we’re using the short version of the -help option, which is -h:

bower prune -h

By the way, Bower command options will often have shortened versions to make them easier to type. For example, the --verbose option can also be written as -v and --force can be written as -F.

Find Bower Packages to Install

To locate Bower packages you might want to install, you can use the search command followed by a keyword or the package’s name.

For example, if we’d like to look for packages tagged with the keyword “responsive”, we can issue this command:

bower search responsive

If you already know the name of the project you want to install and want to see if it’s available as a Bower package, you can type its name instead. The package name is equal to the project’s GitHub repository name. For instance, if we’re interested in seeing if HTML5 Boilerplate has a Bower package, and we know that the project’s name is “html5-boilerplate”, we can type:

bower search html5-boilerplate

The command will return all the Bower packages that match the package name you’ve entered.

Get Information on a Package

In the above example, you can see that Bower returned several results when we did our search command. If you’re not sure which package you want, or if you’d like to learn more about a particular package, issue the info command followed by the package name.

Let’s output some information on Bootstrap.

bower info bootstrap

The command will display the contents of the bower.json manifest file of the package — we will talk about bower.json later on — which typically contains details like the package’s official site, a description of the project, the project’s license, keywords, other available version releases, etc.

Installing Bower Packages

The main way to get Bower packages into your project is through the install command followed by the package name you want to install. All the packages you install will go into a folder called bower_components that will be automatically created in your project’s folder.

Let’s grab the jQuery package. We can do so using this command:

bower install jquery

The command will get the latest version of jQuery.

Installing a Specific Version

By default the install command will get the latest version of the package. But if you want to use another version, you can specify the version name.

Perhaps you’re feeling a bit adventurous, and would like to use a not-yet-stable release candidate version, or maybe you want to use an older version that’s compatible with an old project you’re working on, or you’re doing some sort of backwards-compatibility testing. To do this, we just need to specify the version number, preceded by a hash (#).

I recommend issuing the info command first so you can see all the available versions of the package.

Doing bower info jquery, for example, revealed several available versions of jQuery.

If we wanted to install an old version, like version 1.11 for example, then this is the command we’d use:

bower install jquery#1.11

Setting Up Your Own Bower Package

A lot of us use the same set of dependencies in our development projects. And some of us even have multiple sets of dependencies, like one set for our personal projects and another set for work-related projects.

You may have found yourself always using the same third-party dependencies — Sass to write CSS, Angular for front-end functionality, HTML5shiv to support old browsers, etc. — throughout your different development projects. It would therefore be more efficient and manageable to set up a sort of template for your dependencies.

We can do this by creating our own custom Bower package. This is done by creating a manifest file called bower.json in the root folder of your project.

You can create bower.json manually using a text editor or source code editor, but it’s just more convenient to do this through the command line using the init command.

bower init

Issuing the init command will give you prompts for filling out details about your Bower package, such as its name, version, description, etc.

If you already have other Bower packages installed prior to running the init command, Bower will ask you if you want to include them as dependencies in your bower.json file.

Next, we will include other packages to our own Bower package by specifying them as dependencies. We do this by issuing the install command with the --save option (or its shortcut -S) to let Bower know we want to include the package we’re installing in our bower.json manifest file.

Let’s set up the package to include jQuery, Normalize.css, and HTML5shiv.

bower install jQuery --save

bower install normalize.css -S

bower install html5shiv --save

Note: For developer tools such as code linters, CSS compressors, and unit tests — i.e. packages that are only used during development — use the --save-dev option instead. This will include the package in your bower.json as a developer-dependency (which are listed under the devDependencies JSON object in your manifest file).

Now whenever you want to install your packages in another web development project, just use the Bower install command followed by the location of your custom Bower package. Then, if you want to customize your packages for that new project, you can modify its bower.json file.

If you would like to configure your bower.json file manually, or add other settings beyond the ones created by bower init, read Bower’s JSON specifications.

Useful Bower Commands

Here are a few other basic commands that will surely help. (To see all the Bower commands, go to Bower’s list of commands.)

See All of Your Bower Packages

If you’ve stepped away too long from a dev project — let’s say you’re doing maintenance or redesign work for a client a couple of years down the line — a useful command that will remind you which packages you used in the project is the list command.

bower list

What’s great about this command is Bower will also check to see if there are new versions of your packages available. Below, you can see that there are new versions of the packages I’m using:

]]>Testing your responsive web designs is crucial because the user experience on mobile devices is quite different from desktops.

But actual testing on all the mobile devices in the market isn’t practical for most of us.

So a simple responsive design testing technique some of us do is resizing our browser’s window size to kind of match the viewport sizes of smartphones and tablets. This is a quick-and-dirty trick for basic visual testing and it help us spot major problems, but it’s a terribly inaccurate portrayal of the mobile device experience.

Mobile devices have unique touch interactions like swipes and pinch-to-zooms, and likewise desktops have interactions like hovering and right-clicking. Responsive designs must account for these variances.

This tutorial will discuss an effective and practical method for debugging and testing your responsive designs. It involves a tool you probably already have: Google Chrome.

Google Chrome’s DevTools has a feature called device mode that’s loaded with helpful tools for testing and debugging responsive designs.

Mobile device emulation: Device mode has accurate models for popular smartphones and tablets (e.g. iPhone, Galaxy, BlackBerry, Kindle, Nexus, and a ton more) that simulates how your responsive designs look and function on touchscreens. It even spoofs the UA string to match the particular device you’re testing so that you’re getting a very precise design preview of your work.

Touch events emulation: This feature allows you to experience your designs as if you were interacting with them on your smartphone or tablet.

Media queries inspector: This is a ridiculously useful feature that shows you all your media query breakpoints. Clicking on a breakpoint resizes your design’s preview, so you no longer have to manually resize your browser window.

Mobile network simulation: mobile internet connectivity is different from our machine’s high-speed broadband connection. Also, many parts of the world still don’t have access to faster mobile internet technologies like LTE. Device mode can show you how your designs perform on EDGE, 3G, LTE, DSL, and WiFi to help you identify potential web performance problems.

To start using device mode, open up your web design in Google Chrome.

Then, open Developer Tools by clicking on Chrome’s menu and then choosing More tools > Developer Tools. The keyboard shortcut for opening Developer Tools is Ctrl+Shift+I (Win) or Option+Command+I (Mac).

You should now see the Chrome Developer Tools (abbreviated as DevTools from now on) panel at the bottom or on the right of your browser’s viewport.

Click on the device mode icon (it’s a super tiny button that looks like a smartphone) to toggle device mode on and off.

When device mode is turned on, you’ll see something along the lines of the image below, and the smartphone icon will turn blue:

Responsive Design Testing on a Specific Mobile Device

Use the Device panel to emulate the experience of a particular mobile device. This will allow you to visually test your design on said mobile device, as well as test touch-like interactions.

Let’s say we’d like to see how our responsive design looks and functions on an iPhone 5. All we’ll need to do is select that device in the <Select model> dropdown list:

Device mode will change the design preview so that you’re seeing what an iPhone 5 user might see. What’s more, if you notice, your mouse cursor is now a circle. When you move your mouse up and down, the design preview will scroll up and down, simulating the swipe interaction behavior. Moving your cursor over a link won’t act like you’re hovering over it (because there’s no hover on touchscreens).

Media Queries Testing/Debugging

Debugging and testing your media query breakpoints is super easy when you’re using device mode. Just click on the the “waterfall” icon at the top-left of device mode and it will show you a bar graph of your breakpoints.

Also, hovering over the “waterfall” icon will display the number of media queries there are on the page you’re testing.

Clicking on the bars will immediately switch the design preview to that media query breakpoint. Switching back and forth between your media queries is quick, making this feature quite a huge time-saver.

The colors of the media query bars are indicative of the type of media query being represented: Orange is a min-width media query, blue is a max-width media query, and green is a min and max range media query (e.g. @media (min-width: 320px) and (max-width: 640px)).

Mobile Internet Testing

You can test the perceived performance of your responsive design by using the Network feature of device mode. Click the Network dropdown menu and choose the mobile network technology you want to test with, such as EDGE or 3G. This feature will throttle your Internet connection to match your chosen network technology.

Conclusion

DevTools is an incredibly powerful tool, and device mode makes it an even more indispensable part of the modern web designer’s toolkit.

There are a few more features in the device mode for you to explore, such as:

Changing the devicePixelRatio in the Device panel for testing the UX on Retina displays

Vertical/horizontal rulers on the top and left of the viewport to help you eyeball certain pixel lengths

Manual override of the UA string (the text field at the bottom of the Network panel)

Share your strategies for responsive design testing in the comments below. Do you have tips to share about device mode?

]]>http://sixrevisions.com/tutorials/test-responsive-designs/feed/6http://sixrevisions.com/tutorials/test-responsive-designs/Six Revisions Gets a Redesignhttp://feedproxy.google.com/~r/SixRevisions/~3/eUVQiFMQzvw/
http://sixrevisions.com/site-news/six-revisions-version-2/#commentsTue, 17 Mar 2015 08:07:39 +0000http://sixrevisions.com/?p=7875The new site design of Six Revisions just launched. This is the most significant redesign of the site in years.

]]>The new site design of Six Revisions was launched a few hours ago (officially named Six Revisions version 2). This is the most significant redesign of the site in years.

The main objective of this new design is to improve your reading and overall experience on the site.

Highlights

There’s still quite a lot of design, web performance, and functionality issues to resolve, but overall this redesign should greatly enhance your experience on Six Revisions.

I’ll briefly walk you through some of the design improvements in the new version.

Responsive Design

Six Revisions readers accessing the site with their mobile device will be pleased to know that the site now provides them a much better reading experience. A quick check on Google PageSpeed Insights shows no issues with mobile UX. (However, I still need to work on mobile and desktop page speed improvements across the site, as well as enhancements beyond PageSpeed Insights suggestions.)

Dealing with the embedded code samples (content wrapped in <pre> elements) with wide line lengths was one of the trickier design challenges. I explored a couple of solutions: horizontal scrollbars on code samples that were wider than the native device width, or making long lines wrap to the next line. I chose, last-minute, to go with the latter solution because horizontal scrolling (swiping left-and-right) on smartphones was too disruptive to the reading flow.

Improved Readability

The old web design was aesthetically outdated. It was clunky. It was broken in so many areas and in so many ways. Most importantly, it got in the way of your reading experience on the site.

The new design is optimized to present Six Revisions content in the best way possible, so that the hard work of our authors is no longer being overshadowed by UX, usability, and readability problems created by the previous design. The new UI is clean and simple, and is designed with the intent of complementing your reading experience, rather than being a focal point.

Improving readability, among other things, involved significant time and effort given to designing, evaluating, and testing the design’s typography.

The primary web font used in Six Revisions version 2 is Lato, an extremely legible and pleasant-to-read font designed by Lukasz Dziedzic. It comes in 18 variants and has 3,000 glyphs, making it a flexible and robust font that can handle old, current, and future Six Revisions content.

Code samples are an essential component of a publication that caters to professional developers and web designers. The font used to present embedded code samples is one of my most favorite programming fonts, Source Code Pro. It works well with the main body font, and it’s simply gorgeous. It’s exceptionally legible, and makes reading code a more delightful experience.

The site’s typography still needs to be perfected and fine-tuned, so this area is a work in progress.

Improved Site Navigability

One major issue with the old UI was it was tough to navigate to content that you might be interested in.

One feature aimed at improving site navigability is the fixed navigation bar on top of our web pages. This allows you to move throughout the site easily without having to scroll back up to the top of the page. Scrolling back to the top of the page to navigate the site was particularly troublesome in the old design, since Six Revisions publishes long-form articles.

In the future, this navigation bar will display contextual navigation items and information based on where you are on the site to help you discover other articles and tutorials you might be interested in.

I’m in the process of building more interfaces that will make our body of content easier to navigate. For instance, I’m currently developing an interface that makes it manageable to view 50 to 100 Six Revisions articles on a single web page to reduce the amount of time and effort required to transition to another page.

A critical issue right now is that the site search feature is not displaying search results. This is a high-priority bug that I will work on in the next few hours (after I get some sleep).

Better UX for Discussions

One of my main goals is to improve your ability to interact with other members of the Six Revisions community. One of the first steps I took towards this goal was to enable multi-level commenting so that we can all have better conversations in the comments.

My desire is for Six Revisions to become a venue where people from all over the world interested in development and design come together to talk about the subject we’re passionate about.

I’ll be introducing a feature that allows you (and other people on Six Revisions) to view your comment history on the site. Another feature I’m thinking about implementing is social voting in the comments section so that the community gets to decide which comments other readers should pay attention to.

Also, I’ll be developing ways to encourage readers to contribute to the discussions by giving people who regularly share important information and engage in meaningful conversations special avatars, one-on-ones, and so forth.

For now, Gravatar support has been disabled due to web performance concerns. I’m reviewing our options for better avatar support in the comments.

Roadmap

I want to talk about some things you can expect on this site from here on out.

I have a million things I want to share with you regarding the future of Six Revisions, and I can’t fit them all into this post, so I’ll be discussing them in more detail in subsequent posts.

Vision

My mission is for Six Revisions to be a leading source of information on development and design, a place where you go to learn and stay updated on essential topics related to building sites and apps.

Main Topics

These are the core topics that we’ll be covering in the form of tutorials, articles, guides, and other forms of content:

Other subjects that matter to developers and designers will also occasionally be covered. These include project and business management, content strategy, SEO, and general design and code theory.

Content Improvements

The most critical area of concern is the site’s content. Six Revisions hasn’t been publishing articles regularly, and I need to address that right away.

These are some things I’d like to improve on:

Improve publication schedule

Right now, Six Revisions publishes between one to three articles per week.

The first step is to work towards consistently publishing three articles per week (Monday, Wednesday, and Friday). The next objective will be to publish 5 articles a week (M-F). After that, Six Revisions will start to post at least one article a day.

Improvements in the authoring experience

The writing process and incentives for our authors need to be improved. The task of contributing articles to the publication must be streamlined and made easier in order for Six Revisions to be able to publish high-quality articles regularly.

If you’re interested in writing tutorials and articles to be published on Six Revisions, please email me at jacob@sixrevisions.com.

Content archive maintenance

We’ve published over a thousand articles. A lot of them are timeless. However, many are also outdated because that’s just the nature of development and design, things change so much and so frequently. I’ll develop methods that will keep our content up-to-date as much as possible: Facts that are no longer true must be corrected, broken links and other issues will be addressed.

Community Engagement and Transparency

Without you, there would be no Six Revisions.

I will create more engagement opportunities, whether that’s in the form of introducing new discussion features on the site, or simply just having more regular conversations with you in the comments section, social media, and/or email.

Also, I’ll keep you updated with the things that happen behind the scenes. For example, I’ll start posting quarterly reports to give you a status update on Six Revisions.

Design

Right now, there’s still a lot of UI-related issues with the Six Revisions version 2 design. For example, you’ll see some "jankness" when you view the site on iOS devices, and possibly in other devices that I haven’t gotten the opportunity to test with yet (outside of emulators). I will fix these throughout the week.

If I may ask you a favor: Please leave a comment below (or email me) if you spot any issues with the design. Thank you so much.

Enhance the site navigation experience: A few key site navigational aids were introduced in version 2, such as the menu bar and better pagination. I will create more interfaces to make Six Revisions content easier to navigate to.

Code

In terms of front-end development, these things still need to be done:

Web performance optimization: CSS selectors and media queries need to be optimized, JS and CSS files need to be combined and be served compressed, the average web page file size of Six Revisions must be reduced, the web font has to be moved to our CDN to cut down on DNS lookups, etc. When I’ve tackled the "easy" web performance issues, I will go for more advanced WPO improvements, such as using inline CSS so that only style rules needed to render the page will be included in the request.

High Scalability publishes articles about the techniques and technologies involved in producing high-performance sites. Check out the case studies of YouTube, Google, PlentyOfFish and other high-traffic websites to discover insights and strategies for building resilient sites.

Steve Souders, considered by many as a leader and pioneer in the front-end web performance field, runs a personal blog called High Performance Web Sites where he regularly writes about HTML, CSS, JavaScript and web-page-resource performance. For those seeking a gentle introduction to the field of front-end performance optimization, a must-read on Steve Souders’s blog is the 14 Rules for Faster-Loading Web Sites.

The company blog of Dynatrace has a large variety of web-performance-related content. Their blog shares tips and best practices for creating and maintaining high-performing sites and apps. Their piece on performance metrics other than response times is very enlightening.

The personal blog of web performance engineer Ilya Grigorik has a ton of posts on network performance. Other topics such as front-end performance are also covered on this blog. Ilya Grigorik’s post on choosing web fonts for optimal performance is a great read, and provides excellent insights on how browsers render web fonts.

Zoompf’s web performance blog covers industry news and best practices for making websites fast. This is a blog where you can learn things such how to implement HTTP/2 or how to perform a mobile performance audit.

]]>With more and more companies adopting remote working policies and with the rise of entrepreneurial startups, coworking spaces have multiplied like rabbits. From 2012-2013, for example, the number of coworking spaces in the U.S. grew 83% and coworking memberships have more than doubled.

At Formstack, we transitioned into a remote company in 2013. We have team members from all departments working remotely across the country, and often from various coworking spaces. I’m one of those employees. I work from a coworking space that I cofounded in Bloomington, Indiana called Cowork Btown.

With experience working remotely from a coworking environment, here are five reasons why coworking works.

1. Social Interaction

Let’s face it: Working from home can get mighty lonely. Sometimes it just helps to be around people to break up your work day. And studies have shown that social interaction is important to your health. Some of my really good friends are people who work, or have worked, at my coworking space. Establish relationships with the people in your coworking space, and you’ll be able to learn from and bounce ideas off one another.

2. Networking

A natural side effect of working around new people is getting to know them better. Growing your network by working at a coworking space is a huge benefit. You’ll likely meet some talented people who can help you get where you’re going. You’ll probably even come across someone who’s been where you’re wanting to go, and you can ask them for advice.

3. In-Person Meetings

The nice part about working from your computer is the ability to work from anywhere in the world with a solid internet connection.

But not always having the opportunity to meet face-to-face with clients or coworkers can have its downsides, so it’s a good idea to be able to meet in person from time to time. Some discussions should just never happen over email, chat or voice calls. (Video conferencing can be a close alternative if geographic distance is an issue.)

The good thing is that most coworking spaces have a dedicated room for in-person meetings. This can be a great space to sit down with a new client, discuss projects and have brainstorming sessions with your team, or pitch a group of investors. These rooms can also be a great place for phone calls. Nobody wants to be that guy walking around the coworking space on the phone all day.

Just keep in mind these rooms must typically be reserved for a specific time. Don’t just schedule a meeting without scheduling the room, or you could be in a pickle.

4. A Guaranteed Place to Work

One thing coworking spaces have to offer, that coffee shops don’t, is a consistent place to work. You won’t have to stress about finding a power outlet or that loud group sitting next to your table.

Coworking spaces are often located in business districts, and are often within walking distance of a store, post office and local restaurants. Many offer perks such as a shared coffeemaker, and maybe even morning snacks, and some spaces might even have their own cafe. This is a nice convenience that can save you some cash and prevent that morning run to Starbucks.

5. It Could Be Your Third Place

I talked about how a coworking space helps give you a way to get out of the house or office and an opportunity to socialize and network with others.

Now let’s talk about the concept of the third place (or third space). The third place helps an individual establish a sense of place or belonging in an informal setting outside of home and work. Some common characteristics of this third place include a welcoming environment, close proximity, often food and drink, and both new and regular faces who congregate there. But probably the most important characteristic of the third place is that an individual’s status in society does not matter.

If you work mostly from home or mostly at the office with an option to work remotely occasionally, a coworking space could act as your third place. Coworking spaces will often have social activities or meetups that resemble a third place atmosphere.

About the Author

Aaron White is a UX Developer at Formstack where he works on streamlining the form building process for users. Aaron is a proud father and veteran of the U.S. Army. He’s also one of Formstack’s many remote employees. Aaron works out of Bloomington, Indiana at a coworking space he cofounded called Cowork Btown. Connect with Aaron on Twitter.

]]>http://sixrevisions.com/business/why-coworking/feed/2http://sixrevisions.com/business/why-coworking/Intro to Topcoat – A Performance-First UI Frameworkhttp://feedproxy.google.com/~r/SixRevisions/~3/Mi7Ele9sTHU/
http://sixrevisions.com/tutorials/intro-to-topcoat/#commentsWed, 04 Mar 2015 14:00:03 +0000http://sixrevisions.com/?p=7858A short tutorial on Topcoat, an open source CSS framework that has web performance as its number one goal.

]]>Topcoat is a CSS framework that will help you build fast, high-performance UIs.

Topcoat is one of the Adobe Open Source initiatives. In terms of philosophy, Topcoat believes that UI performance results in better UX. Also, the project aims to bring web apps closer to native apps in terms of speed and responsiveness of user-interactions.

One of the ways Topcoat achieves performance improvements is by benchmarking how browsers perform when rendering Topcoat components. This is done by measuring load time and frames per second (fps) to find underperforming CSS properties.

Topcoat is still very new. The latest release is version 0.8.0 at the time of writing.

Set Up Topcoat

In this tutorial, we will build a simple user interface with Topcoat.

You can download the source code for this tutorial by clicking the link below:

The first thing you will need to do is download Topcoat’s source code from GitHub. Afterwards, extract the contents of the Zip archive somewhere on your computer.

Alternatively you can use your Git command prompt to clone Topcoat’s source code to your computer:

git clone https://github.com/Topcoat/Topcoat.git

Here are Topcoat’s top-level directories and files:

To see the UI components that come with Topcoat, go in the demo directory and open index.html in your browser. You should see a web page that looks like this:

Overview of Topcoat’s Stylesheets

If you look inside Topcoat’s css directory, you will see eight CSS files:

topcoat-desktop-dark.css

topcoat-desktop-dark.min.css

topcoat-desktop-light.css

topcoat-desktop-light.min.css

topcoat-mobile-dark.css

topcoat-mobile-dark.min.css

topcoat-mobile-light.css

topcoat-mobile-light.min.css

The CSS files that have .min in their file names are minified versions, so there are really just four unique stylesheets that come with Topcoat. For example, topcoat-desktop-dark.min.css is identical to topcoat-desktop-dark.css, except the former is smaller in file size. You should only use one or the other.

Wireframing the UI

Let’s start with a quick wireframe of the user interface we will build with Topcoat. Doing this will help us figure out which Topcoat components we will need. Here’s the wireframe:

Looking at the wireframe, we can see that we will need these three Topcoat components:

Navigation Bar

List

Button

Tip: You can use the demo file that we looked at earlier to learn how to implement other Topcoat components.

Create an HTML Document

The next step is to create an HTML document for our UI. Start with some basic HTML markup, making sure to reference one of Topcoat’s stylesheets.

For this example, we will use the topcoat-mobile-light.css stylesheet.

Next open up the Node command prompt. If you don’t have this set up yet, you can read Installing Node.js to learn how to install and configure Node on your computer. By default, Node will automatically install npm.

Using the Node command prompt, navigate to your topcoat directory using the following syntax:

If you don’t have Grunt CLI installed, install it globally using the following command:

npm install -g grunt-cli

Next, install all the required dependencies by issuing the install command with no arguments:

npm install

Issuing the command above will automatically install all the npm packages that are required to build our custom Topcoat stylesheets.

To build our custom stylesheets, we just need to issue this command:

grunt

Now when you go inside Topcoat’s css directory, you will notice that the file sizes of your stylesheets are smaller. This is because we have removed style rules that we don’t need. In the case of the stylesheet we’re using, topcoat-mobile-light, the file size dropped by -74.4%.

Things to Look Forward to

As stated earlier, Topcoat is still pretty new. However, the team behind Topcoat has a clear vision of what they must do in order to achieve further performance improvements.

To learn more about what’s up ahead in Topcoat’s future and how it plans to address common performance issues in web apps, check out this wiki page over at Topcoat’s GitHub repository.

Related Content

About the Author

Miguel Gomez is a Web Architect. He’s passionate about web technologies (HTML, CSS, JavaScript, PHP and Node), web services, and cloud infrastructure. He has worked with Fortune 100 companies as well as in non-profit endeavors. Connect with him through his website, LinkedIn and Twitter.