There are many ways to misuse Bootstrap, but it’s entirely possible to use it on a better way with a few tweaks on your process.

Use it as an external package

The greatest thing about Bower it’s not the ability to download whatever library or script but to use it as the package manager it’s intended to be, which primarily means to never modify packages installed with Bower.

There’s a simple reason for this: one of the key advantages of using a package manager is being able to keep your packages up-to-date, and since a package manager it’s not a version control system, whatever changes you make to an installed package will be lost with an update.

In the case of Bootstrap, here’s what I do:

I just launched a new design for this site, and in this process I was particularly meticulous about my typographic choices.

These are a few of the things I learned.

Only use what’s necessary

This is somewhat obvious, but it’s still a fairly common mistake: you should only use and include the necessary fonts that make your design work.

There are several font families that use multiple styles and sometimes it’s tempting to use nearly all of them: normal, light, medium, bold, ultrabold, italic, bold italics… But you should remember that for every style, the user must download another file, and all of those bytes can add up to a painfully slow page load — which will make both your users and Google sad.

Try to avoid using an specific style for a single UI element, and remember that different families have very different file sizes.

Lastly, and even though it might be considered an abomination for typography nerds, remember that browsers can an usually will fake some basic font styles such as bold (simply thickening the “normal” style) or italics (with a slight slant).

Create a check-list with your requisites

The Google Fonts catalogue has over 700 font families; the full Typekit library over 1200. If you have enough time or are somewhat indecisive you can really go crazy before settling for the perfect fonts combo.

A good idea to help in your decision process it’s to create a check-list with all the requisites you need to fulfil, for instance:

  • The file weight for a single style must be less than 40 Kb (compressed)
  • The font family must have these styles: normal, bold, italic, bold italic
  • It must support non-english characters such as accented vowels
  • The normal style must be highly readable on small sizes

Changing your main font family on the middle of the design process can be a real pain: re-setting the body size and line height affects your entire design, so it’s a choice that must be carefully weighted.

Watch out for bugs

Fonts are not immune to bugs; watch out for thinks like:

  • Missing or erroneous characters: make sure you thoroughly test all the characters you need to support and check that all of them are shown correctly. For instance, when testing a font I found that the character for a typographic ellipsis looked like a single dot.
  • Variable heights on different styles: previous versions of the Roboto family had different heights on some of the styles, even when setting an explicit line-height. For instance, a single line of text using just the normal style showed the expected line-height, but when using a single (or more) bold characters, it increased the line-height. This was fixed on a newer version.
  • Hinting issues: when I decided to self-host the fonts for this site, I used FontSquirrel’s webfont generator to convert to the different formats required for each browser and further optimize the fonts by subsetting only the required characters. Even though I used previosuly hinted fonts, when I chose to Keep the existing hints the result looked awful on Windows, so instead I used the unhinted versions with TTFAutohint.

Many of the fonts available through Google Fonts are published on GitHub, so if you find a bug you could contact the developers and submit an issue, but it’s uncertain how long will it take for Google to update their version (which it’s in part why I’m self-hosting the fonts for this site).

Enable ligatures or other font features

After you finally made up your mind and chose the perfect fonts, make sure to show them in all of their glory.

Even though Firefox enables ligatures by default, Google Chrome and Safari don’t, so you need to explicitly activate them, like:

h1, h2, h3, h4, h5, h6{
    font-variant-ligatures: common-ligatures discretionary-ligatures;

There are plenty of other font features that you can control; check the font-variant docs on MDN to get a good overview.

Una de las desventajas de trabajar con pre-procesadores (ya sea LESS, SASS u otros) es que los archivos producidos pueden generar mucho ruido en el historial de versiones de tu proyecto, lo que es especialmente crítico si estás compilando a archivos minificados o a varias cascadas a partir de un set de variables.

Por ejemplo, si cambias una variable que define un color utilizado en muchos lugares, tu historial mostrará no solamente ese cambio sino también todas las líneas del CSS donde cambió ese valor. Luego, al revisar cambios anteriores se hace mucho más difícil poder determinar fácilmente cuáles son cambios son relevantes (el cambio en el archivo fuente LESS/SASS) de los que no (todas las líneas modificadas en el CSS resultante).

Por ello, una práctica recomendada es versionar los archivos LESS/SASS pero no el CSS resultante, ya que estos últimos son solamente el producto del proceso de compilación de las fuentes.

Para que tu CSS refleje fielmente los cambios en LESS/SASS, puedes automatizar la compilación con una mezcla de tareas en Grunt y hooks de git.

Uno de los grandes aprendizajes que he podido aplicar al desarrollo de sitios con WordPress, y del cual soy particularmente entusiasta de sermonear es la necesidad de mantener una versión local de desarrollo lo más parecida posible a lo que vas a utilizar en producción, lo que además se apoya y soporta un montón de otras buenas prácticas como evitar el cowboy coding, utilizar control de versiones, etc.

Puesto que para el cliente no se trata de uno de los objetivos del proyecto, la capacidad de importar una base de datos para tener una réplica de desarrollo debe ser algo sencillo y rápido de ejecutar. Aunque existen múltiples plugins y herramientas para hacerlo, para mí la forma más sencilla es recurrir a herramientas muy básicas a través de la línea de comandos.

UX Myths

UX Myths collects the most frequent user experience misconceptions (such as “people don’t scroll”, “mobile users are distracted” or “accesible sites are ugly”) and explains why they don’t hold true, with research findings and articles.

Patronizing Passwords

Password Security Guide it’s an alternative interaction pattern for password meters that not only helps your users choose a better password but also explains and educates.

What Open-Access Publishing Actually Costs

The Chronicle of Higher Education hace una revisión sobre los costos reales de las publicaciones de acceso abierto y algunas de las alternativas para lograr una publicación gratis para los usuarios pero que sin embargo se debe hacer cargo de costos en recursos humanos y técnicos.