Web News

erdfisch: Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Web - Sáb, 05/12/2018 - 5:00am
Drupalcon mentored core sprint - part 2 - your experience as a sprinter 12.05.2018 Michael Lenahan Body:  Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Hello! You've arrived at part 2 of a series of 3 blog posts about the Mentored Core Sprint, which traditionally takes place every Friday at Drupalcon.

If you haven't already, please go back and read part 1.

You may think sprinting is not for you ...

So, you may be the kind of person who usually stays away from the Sprint Room at Drupal events. We understand. You would like to find something to work on, but when you step in the room, you get the feeling you're interrupting something really important that you don't understand.

It's okay. We've all been there.

That's why the Drupal Community invented the Mentored Core Sprint. If you stay for this sprint day, you will be among friends. You can ask any question you like. The venue is packed with people who want to make it a useful experience for you.

Come as you are

All you need in order to take part in the first-time mentored sprint are two things:

  • Your self, a human who is interested in Drupal
  • Your laptop

To get productive, your laptop needs a local installation of Drupal. Don't have one yet? Well, it's your lucky day because you can your Windows or Mac laptop set up at the first-time setup workshop!

Need a local Drupal installation? Come to the first-time setup workshop

After about half an hour, your laptop is now ready, and you can go to the sprint room to work on Drupal Core issues ...

You do not need to be a coder ...

You do not need to be a coder to work on Drupal Core. Let's say, you're a project manager. You have skills in clarifying issues, deciding what needs to be done next, managing developers, and herding cats. You're great at taking large problems and breaking them down into smaller problems that designers or developers can solve. This is what you do all day when you're at work.

Well, that's also what happens here at the Major Issue Triage table!

But - you could just as easily join any other table, because your skills will be needed there, as well!

Never Drupal alone

At this sprint, no-one works on their own. You work collaboratively in a small group (maybe 3-4 people). So, if you don't have coding or design skills, you will have someone alongside you who does, just like at work.

Collaborating together, you will learn how the Drupal issue queue works. You will, most likely, not fix any large issues during the sprint.

Learn the process of contributing

Instead, you will learn the process of contributing to Drupal. You will learn how to use the issue queue so you can stay in touch with the friends you made today, so that you fix the issue over the coming weeks after Drupalcon.

It's never too late

Even if you've been in the Drupal community for over a decade, just come along. Jump in. You'll enjoy it.

A very welcoming place to start contributing is to work on Drupal documentation. This is how I made my first contribution, at Drupalcon London in 2011. In Vienna, this table was mentored by Amber Matz from Drupalize.Me.

This is one of the most experienced mentors, Valery Lourie (valthebald). We'll meet him again in part 3, when we come to the Drupalcon Vienna live commit.

Here's Dries. He comes along and walks around, no one takes any notice because they are too engaged and too busy. And so he gets to talk to people without being interrupted.

This is what Drupal is about. It's not about the code. It's about the people.

Next time. Just come. As a sprinter or a mentor. EVERYONE is welcome, we mean that.

This is a three-part blog post series:
Part one is here
You've just finished reading part two
Part three is coming soon

Credit to Amazee Labs and Roy Segall for use of photos from the Drupalcon Vienna flickr stream, made available under the CC BY-NC-SA 2.0 licence.

Schlagworte/Tags:  planet drupal-planet drupalcon mentoring code sprint Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank
Categorías: Web

KnackForge: How to update Drupal 8 core?

Web - Sáb, 03/24/2018 - 1:01am
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Categorías: Web

Web Wash: Getting Started with Bootstrap in Drupal 8

Web - Hace 9 horas 21 mins
Bootstrap is a front-end framework for building websites. It ships prebuilt CSS and JavaScript components that make building sites fast. It comes with all sorts of common components that every website needs such as a grid system, buttons, drop-down, responsive form elements, carousel (of course) and so much more. As a developer I don't want to spend time styling yet another button. I just want to know which CSS class to add to an tag so it looks like a button and I'm good to go. One complaint about Bootstrap is you can spot it a mile away because a lot of developers use the default look-and-feel. When you see the famous Jumbotron you know it's a Bootstrap site. But with a little bit of effort you can make your site look unique.

Aten Design Group: Using Address Fields in Configuration Forms

Web - Hace 9 horas 41 mins

In Drupal 7, the Address Field module provided developers an easy way to collect complex address information with relative ease. You could simply add the field to your content type and configure which countries you support along with what parts of an address are needed. However, this ease was limited to fieldable entities. If you needed to collect address information somewhere that wasn’t a fieldable entity, you had a lot more work in store for you. Chances are good that the end result would be as few text fields as possible, no validation, and only supporting with a single country. If you were feeling ambitious, maybe you would have provided a select list with the states or provinces provided via a hardcoded array.

During my most recent Drupal 8 project I wanted to collect structured address information outside the context of an entity. Specifically, I wanted to add a section for address and phone number to the Basic Site Settings configuration page. As it turns out, the same functionality you get on entities is now also available to the Form API.

Address Field’s port to Drupal 8 came in the form of a whole new module, the Address module. With it comes a new address form element. Let’s use that to add a “Site Address” field to the Basic Settings. First we’ll implement hook_form_FORM_ID_alter() in a custom module’s .module file:

use Drupal\Core\Form\FormStateInterface;   function MYMODULE_form_system_site_information_settings_alter(&$form, FormStateInterface $form_state) { // Overrides go here... }

Don’t forget to add use Drupal\Core\Form\FormStateInterface; at the top of your file. Next, we’ll add a details group and a fieldset for the address components to go into:

function MYMODULE_form_system_site_information_settings_alter(&$form, FormStateInterface $form_state) { // Create our contact information section. $form['site_location'] = [ '#type' => 'details', '#title' => t('Site Location'), '#open' => TRUE, ];   $form['site_location']['address'] = [ '#type' => 'fieldset', '#title' => t('Address'), ]; }

Once the fieldset is in place, we can go ahead and add the address components. To do that you’ll first need to install the Address module and its dependencies. You’ll also need to add use CommerceGuys\Addressing\AddressFormat\AddressField; at the top of the file as we’ll need some of the constants defined there later.

use Drupal\Core\Form\FormStateInterface; use CommerceGuys\Addressing\AddressFormat\AddressField;   function MYMODULE_form_system_site_information_settings_alter(&$form, FormStateInterface $form_state) { // … detail and fieldset code …   // Create the address field. $form['site_location']['address']['site_address'] = [ '#type' => 'address', '#default_value' => ['country_code' => 'US'], '#used_fields' => [ AddressField::ADDRESS_LINE1, AddressField::ADDRESS_LINE2, AddressField::ADMINISTRATIVE_AREA, AddressField::LOCALITY, AddressField::POSTAL_CODE, ], '#available_countries' => ['US'], ]; }

There’s a few things we’re doing here worth going over. First we set '#type' => 'address', which the Address module creates for us. Next we set a #default_value for country_code to US. That way the United States specific field config is displayed when the page loads.

The #used_fields key allows us to configure which address information we want to collect. This is done by passing an array of constants as defined in the AddressField class. The full list of options is:

AddressField::ADMINISTRATIVE_AREA AddressField::LOCALITY AddressField::DEPENDENT_LOCALITY AddressField::POSTAL_CODE AddressField::SORTING_CODE AddressField::ADDRESS_LINE1 AddressField::ADDRESS_LINE2 AddressField::ORGANIZATION AddressField::GIVEN_NAME AddressField::ADDITIONAL_NAME AddressField::FAMILY_NAME

Without any configuration, a full address field looks like this when displaying addresses for the United States.

For our example above, we only needed the street address (ADDRESS_LINE1 and ADDRESS_LINE2), city (LOCALITY), state (ADMINISTRATIVE_AREA), and zip code (POSTAL_CODE).

Lastly, we define which countries we will be supporting. This is done by passing an array of country codes into the #available_countries key. For our example we only need addresses from the United States, so that’s the only value we pass in.

The last step in our process is saving the information to the Basic Site Settings config file. First we need to add a new submit handler to the form. At the end of our hook, let’s add this:

function MYMODULE_form_system_site_information_settings_alter(&$form, FormStateInterface $form_state) { // … detail and fieldset code …   // … address field code …   // Add a custom submit handler for our new values. $form['#submit'][] = 'MYMODULE_site_address_submit'; }

Now we’ll create the handler:

/** * Custom submit handler for our address settings. */ function MYMODULE_site_address_submit($form, FormStateInterface $form_state) { \Drupal::configFactory()->getEditable('system.site') ->set(‘address’, $form_state->getValue('site_address')) ->save(); }

This loads our site_address field from the submitted values in $form_state, and saves it to the system.site config. The exported system.site.yml file should now look something like:

name: 'My Awesome Site' mail: test@domain.com slogan: '' page: 403: '' 404: '' front: /user/login admin_compact_mode: false weight_select_max: 100 langcode: en default_langcode: en address: country_code: US langcode: '' address_line1: '123 W Elm St.' address_line2: '' locality: Denver administrative_area: CO postal_code: '80266' given_name: null additional_name: null family_name: null organization: null sorting_code: null dependent_locality: null

After that, we need to make sure our field will use the saved address as the #default_value. Back in our hook, let’s update that key with the following:

function MYMODULE_form_system_site_information_settings_alter(&$form, FormStateInterface $form_state) { // … detail and fieldset code …   // Create the address field. $form['site_location']['address']['site_address'] = [ '#type' => 'address', '#default_value' => \Drupal::config('system.site')->get('address') ?? [ 'country_code' => 'US', ], '#used_fields' => [ AddressField::ADDRESS_LINE1, AddressField::ADDRESS_LINE2, AddressField::ADMINISTRATIVE_AREA, AddressField::LOCALITY, AddressField::POSTAL_CODE, ], '#available_countries' => ['US'], ];   // … custom submit handler ... }

Using PHP 7’s null coalesce operator, we either set the default to the saved values or to a sensible fallback if nothing has been saved yet. Putting this all together, our module file should now look like this:

<?php   /** * @file * Main module file. */   use Drupal\Core\Form\FormStateInterface; use CommerceGuys\Addressing\AddressFormat\AddressField;   /** * Implements hook_form_ID_alter(). */ function MYMODULE_form_system_site_information_settings_alter(&$form, FormStateInterface $form_state) { // Create our contact information section. $form['site_location'] = [ '#type' => 'details', '#title' => t('Site Location'), '#open' => TRUE, ];   $form['site_location']['address'] = [ '#type' => 'fieldset', '#title' => t('Address'), ];   // Create the address field. $form['site_location']['address']['site_address'] = [ '#type' => 'address', '#default_value' => \Drupal::config('system.site')->get('address') ?? [ 'country_code' => 'US', ], '#used_fields' => [ AddressField::ADDRESS_LINE1, AddressField::ADDRESS_LINE2, AddressField::ADMINISTRATIVE_AREA, AddressField::LOCALITY, AddressField::POSTAL_CODE, ], '#available_countries' => ['US'], ];   // Add a custom submit handler for our new values. $form['#submit'][] = 'MYMODULE_site_address_submit'; }   /** * Custom submit handler for our address settings. */ function MYMODULE_site_address_submit($form, FormStateInterface $form_state) { \Drupal::configFactory()->getEditable('system.site') ->set(‘address’, $form_state->getValue('site_address')) ->save(); }

Lastly we should do some house cleaning in case our module gets uninstalled for any reason. In the same directory as the MYMODULE.module file, let’s add a MYMODULE.install file with the following code:

/** * Implements hook_uninstall(). */ function MYMODULE_uninstall() { // Delete the custom address config values. \Drupal::configFactory()->getEditable('system.site') ->clear(‘address’) ->save(); }

That’s it! Now we have a way to provide location information to the global site configuration. Using that data, I’ll be able to display this information elsewhere as text or as a Google Map. Being able to use the same features that Address field types have, I can leverage other modules that display address information or build my own displays, because I now have reliably structured data to work with.

Categorías: Web

Twitter's Anthony Noto leaves company for CEO role at SoFi - CNET

Webware - Hace 10 horas 20 mins
Twitter's Chief Operating Officer is logging out.
Categorías: Web

Snapchat makes Stories easier to share. Just not yours - CNET

Webware - Hace 10 horas 26 mins
Stories, which let people string together photos and videos, will be sharable outside Snapchat as part of a redesign, but only officially produced ones.
Categorías: Web

Elon Musk won't earn salary unless Tesla hits mega milestones - Roadshow

Webware - Hace 10 horas 26 mins
Electric carmaker's CEO will not earn any compensation unless a series of hugely ambitious valuation targets are met.
Categorías: Web

As 5G hype amps up, Verizon's growth hums along - CNET

Webware - Hace 10 horas 29 mins
The nation's largest wireless carrier posts decent fourth-quarter results as it shifts its focus to faster next-gen wireless tech.
Categorías: Web

Apple HomePod coming on Feb. 9, preorders open on Friday - CNET

Webware - Hace 10 horas 40 mins
Apple's smart speaker will be available for preorder from Friday Jan. 26.
Categorías: Web

Firefox update kicks graphics speed up a notch - CNET

Webware - Hace 10 horas 43 mins
Graphics get faster in Firefox 58. Also new: better support for when you're on the mobile web.
Categorías: Web

Hopping into bed with sleep tech? Not so fast - CNET

Webware - Hace 10 horas 52 mins
All kinds of companies are pitching products that promise a better night's rest. Whether you should snuggle up to sleep tech is a more complicated question.
Categorías: Web

Photoshop's Select Subject gives you a head start on masks - CNET

Webware - Hace 11 horas 21 mins
The one-click masking tool, previewed in fall, is available in a new update, and it's... OK. Plus, Windows 10 users get better interface scaling.
Categorías: Web

Great Barrier Reef gets government life support - CNET

Webware - Hace 11 horas 30 mins
Australian funds will go toward stopping polluted water from entering the reef, culling predatory starfish, researching coral and monitoring bleaching.
Categorías: Web

Mazda to build electric SUV with Chinese partner - Roadshow

Webware - Hace 11 horas 43 mins
Mazda and Changan Automobile are said to be developing a battery-powered EV for sale by 2019.
Categorías: Web

The King vs. Pawn Game of UI Design

A List Apart - Hace 11 horas 48 mins

If you want to improve your UI design skills, have you tried looking at chess? I know it sounds contrived, but hear me out. I’m going to take a concept from chess and use it to build a toolkit of UI design strategies. By the end, we’ll have covered color, typography, lighting and shadows, and more.

But it all starts with rooks and pawns.

I want you to think back to the first time you ever played chess (if you’ve never played chess, humor me for a second—and no biggie; you will still understand this article). If your experience was anything like mine, your friend set up the board like this:

And you got your explanation of all the pieces. This one’s a pawn and it moves like this, and this one is a rook and it moves like this, but the knight goes like this or this—still with me?—and the bishop moves diagonally, and the king can only do this, but the queen is your best piece, like a combo of the rook and the bishop. OK, want to play?

This is probably the most common way of explaining chess, and it’s enough to make me hate board games forever. I don’t want to sit through an arbitrary lecture. I want to play.

One particular chess player happens to agree with me. His name is Josh Waitzkin, and he’s actually pretty good. Not only at chess (where he’s a grandmaster), but also at Tai Chi Push Hands (he’s a world champion) and Brazilian Jiu Jitsu (he’s the first black belt under 5x world champion Marcelo Garcia). Now he trains financiers to go from the top 1% to the top .01% in their profession.

Point is: this dude knows a lot about getting good at stuff.

Now here’s the crazy part. When Josh teaches you chess, the board looks like this:

King vs. King and Pawn


Compared to what we saw above, this is stupidly simple.

And, if you know how to play chess, it’s even more mind-blowing that someone would start teaching with this board. In the actual game of chess, you never see a board like this. Someone would have won long ago. This is the chess equivalent of a street fight where both guys break every bone in their body, dislocate both their arms, can hardly see out of their swollen eyes, yet continue to fight for another half-hour.

What gives?

Here’s Josh’s thinking: when you strip the game down to its core, everything you learn is a universal principle.

That sounds pretty lofty, but I think it makes sense when you consider it. There are lots of things to distract a beginning chess player by a fully-loaded board, but everything you start learning in a king-pawn situation is fundamentally important to chess:

  • using two pieces to apply pressure together;
  • which spaces are “hot”;
  • and the difference between driving for a checkmate and a draw.

Are you wondering if I’m ever going to start talking about design? Glad you asked.

The simplest possible scenario

What if, instead of trying to design an entire page with dozens of elements (nav, text, input controls, a logo, etc.), we consciously started by designing the simplest thing possible? We deliberately limit the playing field to one, tiny thing and see what we learn? Let’s try.

What is the simplest possible element? I vote that it’s a button.

This is the most basic, default button I could muster. It’s Helvetica (default font) with a 16px font size (pretty default) on a plain, Sketch-default-blue rectangle. It’s 40px tall (nice, round number) and has 20px of horizontal padding on each side.

So yeah, I’ve already made a bunch of design decisions, but can we agree I basically just used default values instead of making decisions for principled, design-related reasons?

Now let’s start playing with this button. What properties are modifiable here?

  • the font (and text styling)
  • the color
  • the border radius
  • the border
  • the shadows

These are just the first things that come to my mind. There are even more, of course.


Playing with the font is a pretty easy place to start.

Blown up to show font detail.

Now I’ve changed the font to Moon (available for free on Behance for personal use). It’s rounded and soft, unlike Helvetica, which felt a little more squared-off—or at least not as overtly friendly.

The funny thing is: do you see how the perfectly square edges now look a tad awkward with the rounded font?

Let’s round the corners a bit.

Bam. Nice. That’s a 3px border radius.

But that’s kind of weird, isn’t it? We adjusted the border radius of a button because of the shape of the letterforms in our font. I wouldn’t want you thinking fonts are just loosey-goosey works of art that only work when you say the right incantations.

No, fonts are shapes. Shapes have connotations. It’s not rocket science.

Here’s another popular font, DIN.

With its squared edges, DIN is a clean and solid workhorse font.

Specifically, this is a version called DIN 2014 (available for cheap on Typekit). It’s the epitome of a squared-off-but-still-readable font. A bit harsh and no-nonsense, but in a bureaucratic way.

It’s the official font of the German government, and it looks the part.

So let’s test our working hypothesis with DIN.

How does DIN look with those rounded corners?

Well, we need to compare it to square corners now, don’t we?

Ahhh, the squared-off corners are better here. It’s a much more consistent feel.

Now look at our two buttons with their separate fonts. Which is more readable? I think Moon has a slight advantage here. DIN’s letters just look too cramped by comparison. Let’s add a bit of letter-spacing.

When we add some letter-spacing, it’s far more relaxed.

This is a key law of typography: always letter-space your uppercase text. Why? Because unless a font doesn’t have lowercase characters, it was designed for sentence-case reading, and characters in uppercase words will ALWAYS appear too cramped. (Moon is the special exception here—it only has uppercase characters, and notice how the letter-spacing is built into the font.)

We’ll review later, but so far we’ve noticed two things that apply not just to buttons, but to all elements:

  • Rounded fonts go better with rounded shapes; squared-off fonts with squared-off shapes.
  • Fonts designed for sentence case should be letter-spaced when used in words that are all uppercase.

Let’s keep moving for now.


Seeing the plain default Sketch blue is annoying me. It’s begging to be changed into something that matches the typefaces we’re using.

How can a color match a font? Well, I’ll hand it to you. This one is a bit more loosey-goosey.

For our Moon button, we want something a bit more friendly. To me, a staid blue says default, unstyled, trustworthy, takes-no-risks, design-by-committee. How do you inject some fun into it?

Well, like all problems of modifying color, it helps to think in the HSB color system (hue, saturation, and brightness). When we boil color down to three intuitive numbers, we give ourselves levers to pull.

For instance, let’s look at hue. We have two directions we can push hue: down to aqua or up to indigo. Which sounds more in line with Moon? To me, aqua does. A bit less staid, a bit more Caribbean sea. Let’s try it. We’ll move the hue to 180° or so.

Ah, Moon Button, now you’ve got a beach vibe going on. You’re a vibrant sea foam!

This is a critical lesson about color. “Blue” is not a monolith; it’s a starting point. I’ve taught hundreds of students UI design, and this comes up again and again: just because blue was one color in kindergarten doesn’t mean that we can’t find interesting variations around it as designers.

“Blue” is not a monolith. Variations are listed in HSB, with CSS color names given below each swatch.

Aqua is a great variation with a much cooler feel, but it’s also much harder to read that white text. So now we have another problem to fix.

“Hard to read” is actually a numerically-specific property. The World Wide Web Consortium has published guidelines for contrast between text and background, and if we use a tool to test those, we find we’re lacking in a couple departments.

White text on an aqua button doesn’t provide enough contrast, failing to pass either AA or AAA WCAG recommendations.

According to Stark (which is my preferred Sketch plugin for checking contrast—check out Lea Verou’s Contrast Ratio for a similar web-based tool), we’ve failed our contrast guidelines across the board!

How do you make the white text more legible against the aqua button? Let’s think of our HSB properties again.

  • Brightness. Let’s decrease it. That much should be obvious.
  • Saturation. We’re going to increase it. Why? Because we’re contrasting with white text, and white has a saturation of zero. So a higher saturation will naturally stand out more.
  • Hue. We’ll leave this alone since we like its vibe. But if the contrast continued to be too low, you could lower the aqua’s luminosity by shifting its hue up toward blue.

So now, we’ve got a teal button:

Much better?

Much better.

For what it’s worth, I’m not particularly concerned about missing the AAA standard here. WCAG developed the levels as relative descriptors of how much contrast there is, not as an absolute benchmark of, say, some particular percentage of people to being able to read the text. The gold standard is—as always—to test with real people. AAA is best to hit, but at times, AA may be as good as you’re going to get with the colors you have to work with.

Some of the ideas we’ve used to make a button’s blue a bit more fun and legible against white are actually deeper lessons about color that apply to almost everything else you design:

  • Think in HSB, as it gives you intuitive levers to pull when modifying color.
  • If you like the general feel of a color, shifting the hue in either direction can be a baseline for getting interesting variations on it (e.g., we wanted to spice up the default blue, but not by, say, changing it to red).
  • Modify saturation and brightness at the same time (but always in opposite directions) to increase or decrease contrast.

OK, now let’s switch over to our DIN button. What color goes with its harsh edges and squared-off feel?

The first thing that comes to mind is black.

But let’s keep brainstorming. Maybe a stark red would also work.

Or even a construction-grade orange.

(But not the red and orange together. Yikes! In general, two adjacent hues with high saturations will not look great next to each other.)

Now, ignoring that the text of this is “Learn More” and a button like this probably doesn’t need to be blaze orange, I want you to pay attention to the colors I’m picking. We’re trying to maintain consistency with the official-y, squared-off DIN. So the colors we go to naturally have some of the same connotations: engineered, decisive, no funny business.

Sure, this match-a-color-and-a-font business is more subjective, but there’s something solid to it: note that the words I used to describe the colors (“stark” and “construction-grade”) apply equally well to DIN—a fact I am only noticing now, not something done intentionally.

Want to match a color with a font? This is another lesson applicable to all of branding. It’s best to start with adjectives/emotions, then match everything to those. Practically by accident, we’ve uncovered something fundamental in the branding design process.


Let’s shift gears to work with shadows for a bit.

There are a couple directions we could go with shadows, but the two main categories are (for lack of better terms):

  • realistic shadows;
  • and cartoon-y shadows.

Here’s an example of each:

The top button’s shadow is more photorealistic. It behaves like a shadow in the real world.

The bottom button’s shadow is a bit lower-fidelity. It shows that the button is raised up, but it’s a cartoon version, with a slightly unrealistic, idealized bottom edge—and without a normal shadow, which would be present in the real world.

The bottom works better for the button we’re crafting. The smoothness, the friendliness, the cartoon fidelity—it all goes together.

As for our DIN button?

I’m more ambivalent here. Maybe the shadow is for a hover state, à la Material Design?

In any case, with a black background, a darkened bottom edge is impossible—you can’t get any darker than black.

By the way, you may not have noticed it above, but the black button has a much stronger shadow. Compare:

The teal button’s shadow is 30%-opacity black, shifted 1 pixel down on the y-axis, with a 2-pixel blur (0 1px 2px). The black button’s is 50%-opacity black, shifted 2 pixels down on the y-axis, with a 4-pixel blur (0 2px 4px). What’s more, the stronger shadow looks awful on the teal button.

Why is that? The answer, like so many questions that involve color, is in luminosity. When we put the button’s background in luminosity blend mode, converting it to a gray of equal natural lightness, we see something interesting.

The shadow, at its darkest, is basically as dark as the button itself. Or, at least, the rate of change of luminosity is steady between each row of pixels.

The top row is the button itself, not shadow.

Shadows that are too close to the luminosity of their element’s backgrounds will appear too strong. And while this may sound like an overly specific lesson, it’s actually broadly applicable across elements. You know where else you see it?


Let’s put a border on our teal button.

Now the way I’ve added this border is something that a bunch of people have thought of: make the border translucent black so that it works on any background color. In this case, I’ve used a single-pixel-wide border of 20%-opacity black.

However, if I switch the background color to a more standard blue, which is naturally a lot less luminous, that border all but disappears.

In fact, to see it on blue just as much as you can see it on teal, you’ve got to crank up black’s opacity to something like 50%.

This is a generalizable rule: when you want to layer black on another color, it needs to be a more opaque black to show up the same amount on less luminous background colors. Where else would you apply this idea?

Spoiler alert: shadows!

Each of these buttons has the same shadow (0 2px 3px) except for different opacities. The top two buttons’ shadows have opacity 20%, and the bottom two have opacity 40%. Note how what’s fine on a white background (top left) is hardly noticeable on a dark background (top right). And what’s too dark on a white background (lower left) works fine on a dark background (lower right).


I want to change gears one more time and talk about icons.

Here’s the download icon from Font Awesome, my least favorite icon set of all time.

I dislike it, not only because it’s completely overused, but also because the icons are really bubbly and soft. Yet most of the time, they’re used in clean, crisp websites. They just don’t fit.

You can see it works better with a soft, rounded font. I’m less opposed to this sort of thing.

But there’s still a problem: the icon has these insanely small details! The dots are never going to show up at size, and even the space between the arrow and the disk is a fraction of a pixel in practice. Compared to the letterforms, it doesn’t look like quite the same style.

But what good is my complaining if I don’t offer a solution?

Let’s create a new take on the “download” icon, but with some different guiding principles:

  • We’ll use a stroke weight that’s equivalent (or basically equivalent) to the text weight.
  • We’ll use corner radii that are similar to the corner radii of our font: squared off for DIN, rounded for Moon.
  • We’ll use a simpler icon shape so the differences are easy to see.

Let’s see how it looks:

I call this “drawing with the same pen.” Each of these icons looks like it could basically be a character in the font used in the button. And that’s the point here. I’m not saying all icons will appear this way, but for an icon that appears inline with text like this, it’s a fantastic rule of thumb.

Wrapping it up

Now this is just the beginning. Buttons can take all kinds of styles.

But we’ve got a good start here considering we designed just two buttons. In doing so, we covered a bunch of the things that are focal points of my day-to-day work as a UI designer:

  • lighting and shadows;
  • color;
  • typography;
  • consistency;
  • and brand.

And the lessons we’ve learned in those areas are fundamental to the entirety of UI design, not just one element. Recall:

  • Letterforms are shapes. You can analyze fonts as sets of shapes, not simply as works of art.
  • You should letter-space uppercase text, since most fonts were designed for sentence case.
  • Think in HSB to modify colors.
  • You can find more interesting variations on a “basic” color (like a CSS default shade of blue or red) by tweaking the hue in either direction.
  • Saturation and brightness are levers that you can move in opposite directions to control luminosity.
  • Find colors that match the same descriptors that you would give your typeface and your overall brand.
  • Use darker shadows or black borders on darker backgrounds—and vice versa.
  • For inline icons, choose or design them to appear as though they were drawn with the same pen as the font you’re using.

You can thank Josh Waitzkin for making me a pedant. I know, you just read an entire essay on buttons. But next time you’re struggling with a redesign or even something you’re designing from scratch, try stripping out all the elements that you think you should be including already, and just mess around with the simplest players on the board. Get a feel for the fundamentals, and go from there.

Weird? Sure. But if it’s good enough for a grandmaster, I’ll take it.

Categorías: Web

Major cyber-attack on the UK is a matter of 'when, not if' - CNET

Webware - Hace 11 horas 52 mins
National Cyber Security Centre chief says an attack with the potential to hit infrastructure could come within the next two years.
Categorías: Web

Caveman caper 'Early Man' is a prehistoric pleasure - CNET

Webware - Hace 12 horas 4 mins
"Wallace and Gromit" creator Aardman takes us to the plasticine Pleistocene age with this joyous stop-motion animation.
Categorías: Web

With two questions, Facebook is deciding the future of news - CNET

Webware - Hace 12 horas 12 mins
Commentary: First it was the Disney Princess quizzes. Then it was Russian propaganda. Now Facebook is going to ask who you trust when it comes to news. That’s dangerous.
Categorías: Web

Amazee Labs: Practices - Amazee Agile Agency Survey Results - Part 9

Web - Hace 16 horas 11 mins
Practices - Amazee Agile Agency Survey Results - Part 9

This is part 9 of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about client interactions; this time let’s focus on practices. How often do teams deploy code? Are they practising peer reviews, automated testing, pair programming or story mapping?

Josef Dabernig Tue, 01/23/2018 - 10:10

When asked about “How often does your team deploy code?”, 53% of the teams answered they would do deployments “Rolling / Whenever necessary”. 13.3% deploy “About once a week”, another 13.3% “About every two weeks” and 6.7% answered they would deploy “Daily”. The remaining chose to go with freeform answers such as different frequencies based on the dev/stage/live environments or that it would depend on the client.

For us at Amazee, the deployment schedule depends on the needs of the clients. Thanks to the automatization that our Amazee.io hosting environment provides, any team member can execute a deployment on their own if it makes sense. Some High-availability clients require a fixed deployment schedule that our team has programmed to happen every week, besides that only critical hotfixes would be deployed instantly out of the schedule. Most of our clients allow us to deploy whenever, yet if a downtime for more complex deployments is needed we usually try to schedule them outside of business hours. For global customers that run their website across the globe, we try to find the deployment slot that fits best and rely on a proxy server like Varnish that keeps serving anonymous users during a deployment downtime.

Our second question was geared towards finding out which agile practices would be used by teams and how important they are considered. Contestants were able to rate from “Unknown”, “Not needed”, “Tried but failed” to “Somewhat in use”, “Actively in use” up to “Very important”. The practice that was mostly unknown is Mob programming.  Story mapping is also widely unknown but also has a good number of constants rating it with “Somewhat in use”. Pair programming is somewhat in use for many but also has a good number of contestants who responded “Unknown” or “Not needed”. The practices mostly rated as “Very important” where Peer reviews/code reviews as well as User testing. Automated testing got a lot of votes for “Somewhat in use”, and a few ones rated it as “Very important”. Per-ticket branch test environments have been rated as “Somewhat in use” by many as well.

For us at Amazee, we do Peer & code reviews for every work increment within our Scrum teams. This ensures code quality, knowledge transfer and feedback between team members. Automated testing happens for mission-critical features. Vasi has an article with good arguments why you should invest in it. User testing is performed on about a third of our projects. Automated deployments, continuous integration and per-ticket branch test environment are extensively used thanks again to the Amazee.io hosting environment goodies. Pair programming is quite common for our teams. While we have experimented with mob programming for teaching purposes, our team didn’t entirely pick it up. Finally, story mapping is something that we started using recently with good results, but we don’t have too much experience with it, yet.

Which practices do you use and how often do you do deployments? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.

Stay tuned for the last post where we’ll do a round up of the Agile Agency Survey.

Categorías: Web

Colorfield: Install Solr 7 for Drupal 8 Search API on Ubuntu 16.04

Web - Hace 17 horas 30 mins
Install Solr 7 for Drupal 8 Search API on Ubuntu 16.04 christophe Tue, 23/01/2018 - 08:51 A brief introduction to Search API Solr, an update on the ecosystem and how to get Search API 2.x working on a dev environment with multiple collections.
Categorías: Web