Eleventy Love

Been seeing a lot of Eleventy action lately. It’s a smaller player in the world of static site generators, but I think it’s got huge potential because of how simple it is, yet does about anything you’d need it to do. It’s Just JavaScript™.

The post Eleventy Love appeared first on CSS-Tricks.

All Things Smashing: Monthly Update

All Things Smashing: Monthly Update

All Things Smashing: Monthly Update

Iris Lješnjanin

2020-01-17T11:30:00+00:00 2020-01-17T22:07:03+00:00

We can’t repeat enough how wonderful the web performance community is! There are good folks who help make the web faster, and their efforts matter indeed. With the new year sinking in and everyone’s resolutions still being put to the test, personal goals such as reproducing bugs and fixing issues suddenly become something we all have in common: improving the web for everyone involved.

As various areas of performance become more and more sophisticated and complicated throughout the years, Vitaly refines and updates his front-end performance checklist every year. This guide covers pretty much everything from performance budgets to single-page apps to networking optimizations. It has proved to be quite useful to folks in the past years — anyone can edit it (PDF, MS Word Doc and Apple Pages) and adjust it to their own personal needs or even use it for their organization.

Now, without further ado, let’s see what’s been cooking at Smashing!

Exciting Times: New Smashing Book

The cover of the upcoming Smashing Book named “Ethical Design Handbook”Are you ready for the next Smashing book? Well, just like all the printed books we’ve published, each and every is crafted to deliver in-depth knowledge and expertise shared by experts and practitioners from the industry. The Ethical Design Handbook will not be any different. Written by Trine Falbe, Martin Michael Frederiksen and Kim Andersen, the book will be pre-released late January.

As always, there will be a pre-order discount available. We expect to ship printed hardcover copies late February, but in the meantime, feel free to subscribe to the book mailing list so that you can be one of the first folks to get your hands on the book!

Less Speaking, More Time For Questions

Our SmashingConfs are known to be friendly, inclusive events where front-end developers and designers come together to attend live sessions and hands-on workshops. From live designing to live debugging, we want you to ask speakers anything — from naming conventions to debugging strategies. For each talk, we’ll have enough time to go into detail, and show real examples from real work on the big screen.

A photo of Dan Mall standing on stage explaining code shown on the screen behind him
Dan Mall, Brad Frost and Ian Frost coding live on stage at SmashingConf in NYC. (Image credit: Drew McLellan) (Watch video)

If you’re eager not to miss out on one of our SmashingConfs, then early-bird tickets are still available. And if you need a lil’ help convincing your boss to send you to an event, let us know! We’ve got your back. 😉

A Taste Of Smashing… Offscreen

Smashing Podcast moderated by Drew McLellanWe’ve reached our 7th episode of the Smashing Podcast! We’re so proud and thrilled to have our dear friends and colleagues, Drew McLellan and Bethany Andrew, managing the bi-weekly interview show so brilliantly! The feedback has been overwhelmingly positive, and now we’re excited for many more!

Shining The Spotlight On TypeScript

Smashing TVIn less than two weeks (Jan. 29), we’ll be hosting a Smashing TV webinar with Stefan Baumgartner who’ll shed light on what type-checking has in store for folks creating and using the web. TypeScript has been one of the most hyped technologies in 2019 — it’s now time to look beyond the hype!

Mark your calendars and join us at 17:00 London time — we’d love to hear your thoughts and experiences you’ve had in your career.

We publish a new article every day on various topics that are current in the web industry. Here are some that our readers seemed to enjoy the most and have recommended further:

Best Picks From Our Newsletter

With the start of a brand-new decade, we decided to start off with topics dedicated to web performance. There are so many talented folks out there working on brilliant projects, and we’d love to spread the word and give them the credit they deserve!

Note: A huge thank you to Cosima Mielke for writing and preparing these posts!

Which Metrics Matter Most?

First Meaningful Paint, Time to Interactive, First Input Delay, SpeedIndex. With so many performance metrics floating around, it’s not easy to strike just the right balance for a project. And most of the time, these metrics alone will be too generic and not precise enough, so we’ll need to complement them with custom ones as well. In small and large companies it’s common to define important pixels in the UI, measure how fast we can start render them, and how quickly we can provide input responsiveness for them.

Every project could benefit from a mix of at least 4 metrics. Time To Interactive (TTI) is the key metrics for understanding how much wait a user has to experience to use the site without a lag. First Input Delay (FID) complements TTI very well as it describes the missing part of the picture: what happens when a user actually interacts with the site.

A graph showing JavaScript fetch, parse, and compile loading phases
JavaScript fetch, parse, and compile loading phases (Image credit)

Total Blocking Time (TBT) helps quantify the severity of how non-interactive a page is prior to it becoming reliably interactive. And Cumulative Layout Shift (CLS) highlights how often users experience unexpected layout shifts (reflows) when accessing the site. All these metrics will appear in Lighthouse v6 as it starts rolling out in 2020.

Additionally, you can look into FrustrationIndex that looks at the gaps between metrics instead of looking at them individually, ad weight impact and Component-Level CPU costs. Note that First Meaningful/Contentful Paint are being replaced with Largest Contentful Paint, and the role of SpeedIndex has decreased with new metrics showing up.

The Impact Of Performance Optimization

It’s no secret that performance has a direct impact on user experience and business metrics and that sometimes, even a seemingly small web performance optimization like shaving off a few milliseconds load time can lead to a better conversion rate. To demonstrate this impact, WPO Stats collects case studies and experiments from products and e-commerce sites — stories of successes and of things that went wrong. Inspiring!

UX Speed Calculator
An open-source visualization tool that helps explain the relationship between page speed, conversion and bounce rates. (Image credit)

To support your performance optimizations with some hard figures and help you better grasp their impact, Sergey Chernyshev built the UX Speed Calculator. It lets you see how speed distribution, error rate, bounce rate, and conversion rate intertwine for the values you enter. A handy little helper.

Automatically Compress The Images In Your PRs

Image optimization is probably one of the easiest tasks on your performance optimization checklist. However, if you have a lot of images to optimize, it can also take up quite some time, and in the hurry, some images might even make it into production skipping this step.

Image Actions
“State of the Web: Video Playback Metrics” by Doug Sillars (Image credit)

To change that, the team at Calibre built a GitHub action that automatically compresses all the JPEGs, PNGs, and WebP images in your pull requests. It’s fast, efficient, and, for near-lossless compression, it uses the best image compression algorithms available: mozjpeg and libvips. A real timesaver.

Resources To Stay On Top Of Performance

A lot of people in the web community are committed to performance and to helping spread the word about it. One of them is Tim Kadlec. In his podcast Chasing Waterfalls, he invites people who work to make the web faster for everyone. Three episodes have already been released, with Reefath Rajali sharing insights into PayPal’s performance journey, Malek Kalim exploring how to scale a culture of performance across an organization, and Katie Hempenius talking about performance budgets, third-party challenges, JavaScript, and a lot of other things that impact performance.

Chasing Waterfalls podcast hosted by Tim Kadlec
Conversations with the people working to make the web faster for everyone, hosted by Tim Kadlec. (Image credit)

Another handy resource to keep you on top of web performance comes from Ben Schwarz and Karolina Szczur. Together they curate the Performance Newsletter, delivering web performance tools, talks, and other resources to your inbox twice a month. There’s also an archive of previous newsletter issues for you to catch up on until the next issue will be sent out.

Each and every issue of the Smashing Newsletter is written and edited with love and care. No third-party mailings or hidden advertising — you’ve got our word.

Smashing Editorial (cm, vf, ra, il)
Thinking Through Styling Options for Web Components

Where do you put styles in web components?

I’m assuming that we’re using the Shadow DOM here as, to me, that’s one of the big draws of a web component: a platform thing that is a uniquely powerful thing the platform can do. So this is about defining styles for a web component in a don’t-leak-out way, and less so a way to get global styles to leak in (although that’s very interesting as well, which can be done via custom properties which we’ll look at later in the article).

If you’re building the template inside the JavaScript — which is nice because of template literals and how we can sprinkle our data into the template nicely — you need access to those styles in JavaScript.

const template = ` <style>${styles}</style> <div class="${class}"> <h2>${title}</h2> ${content} </div>
`;

Where does that style variable come from? Maybe also a template literal?

const style = ` :host { background: white; } h2 { font: 900 1.5rem/1.1 -system-ui, sans-serif; }
`;

I guess that’s fine, but it makes for a big messy block of code just dunked somewhere in the class where you’re trying to build this web component.

Another way is to <template> the template and make a <style> block part of it.

<template id="card-template"> <style> :host { background: white; } h2 { font: 900 1.5rem/1.1 -system-ui, sans-serif; } </style> <div id="card-hook"> <h2 id="title-hook"></h2> <p id="desc-hook"></p> </div>
</template>

I can see the appeal with this because it keeps HTML in HTML. What I don’t love about it is that you have to do a bunch of manual shadowRoot.querySelector("#title-hook").innerHTML = myData.title; work in order to flesh out that template. That doesn’t feel like a convenient template. I also don’t love that you need to just chuck this template somewhere in your HTML. Where? I dunno. Just chuck it in there. Chuck it.

The CSS is moved out of the JavaScript too, but it just moved from one awkward location to another.

If we wanted to keep the CSS in a CSS file, we can sorta do that like this:

<template id="card-template"> <style> @import "/css/components/card.css"; </style> <div id="card-hook"> <h2 id="title-hook"></h2> <p id="desc-hook"></p> </div>
</template>

(The use of <link rel="import" type="css" href=""> is deprecated, apparently.)

Now we have @import which is an extra HTTP Request, and notorious for being a performance hit. An article by Steven Lambert says it clocked in at half a second slower. Not ideal. I don’t suppose it would be much better to do this instead:

class MyComponent extends HTMLElement { constructor() { super(); this.attachShadow({ mode: "open" }); fetch('/css/components/card.css') .then(response => response.text()) .then(data => { let node = document.createElement('style'); node.innerHTML = data; document.body.appendChild(node); }); } // ...
}

Seems like that would potentially be a Flash-of-Unstyled-Web-Component? I guess I should get off my butt and test it.

Now that I’m digging into this again, it seems like ::part has gotten some steam (explainer). So I can do…

const template = ` <div part="card"> <h2>${title}</h2> ${content} </div>
`;

…then write styles in a global stylesheet that only apply inside that Shadow DOM, like:

my-card::part(card) { background: black; color: white;
}

…which has a smidge of browser support, but maybe not enough?

These “part” selectors can only touch the exact element it’s connected to. You’d have to do all your styling by applying a part name to every single DOM node and then styling each entirely on its own. That’s no fun, particularly because the appeal of the Shadow DOM is this isolated styling environment in which we’re supposed to be able to write looser CSS selectors and not be worried our h2 { } style is going to leak all over the place.

Looks like if native CSS modules becomes a thing, that will be the most helpful thing that could happen.

import styles from './styles.css'; class MyElement extends HTMLElement { constructor() { this.attachShadow({mode: open}); this.shadowRoot.adoptedStyleSheets = [styles]; }
}

I’m not sure, however, if this is any sort of performance boost. Seems like it would be a wash between this and @import. I have to say I prefer the clarity and syntax with native CSS modules. It’s nice to be writing JavaScript when working with JavaScript.

Constructable Stylesheets also look helpful for sharing a stylesheet across multiple components. But the CSS modules approach looks like it could also do that since the stylesheet has already become a variable at that point.

The post Thinking Through Styling Options for Web Components appeared first on CSS-Tricks.

Can Best Practice Replace Design Research?

Heart-warming or not, co-creation with a client—the utopian ideal of shared vision—has its drawbacks. There are only so many times you can hear the words “brand strategy” before actually chewing your own face off. In the age of WordPress, Drupal and, dare I say it, Wix, it’s never been more tempting to pay lip-service to research and consultation. Instead of building a principles framework from scratch, why not roll out something from a template in a fraction of the time?

Well, in fact, there probably are situations where a simple WordPress-type approach will work really well. The trick is knowing when.

What Is “Best Practice” Anyway?

Well, exactly.

Even if you slept through design school, or didn’t go at all, you probably know the fundamentals already. And it’s true. If you stick to first principles, you won’t go far wrong. Here are some examples:

  • Color and Contrast: 2-3 colors maximum, use contrast to highlight important elements;
  • White Space: Use plenty of it, be consistent with proportions above and below;
  • Layout: Symmetric Grid. Err…Always. Work ‘above the fold’;
  • Typography: No more than 2-3 typefaces;
  • Logo: Long, top left, always;
  • Compexity vs Simplicity: Look for balance and visual interest;
  • Visual Hierarchy: Use color, contrast, size and complexity to highlight important elements;
  • Consistency: With all of the above, whatever you decide, be consistent;
  • And so on…

One size, though, doesn’t fit all. By bending and even breaking the rules sometimes, you’ll create designs that stand out and, more importantly, meet the real requirements of the brief.

The One Unbreakable Rule

It’s pretty hard to find a “Best Practice” that really works in every situation, but here’s one:

No matter what you’re doing, make sure you know why you’re doing it.

And, just in case you were wondering, “err…because it looks pretty?” and “because it’s easier than what I probably ought to do instead…” aren’t really reasons.

There are clearly situations where a client—whatever they may think—is best served by a simple off-the-shelf approach. Particularly if their budget is more Scrooge than Soros. The thing is, you probably still need to go through a research process to find out whether that’s the case or not.

When And How To Go Off Piste

Before or just after accepting the job, you’ll likely need to do some research with the client. This process should focus on (you guessed it) brand strategy.

Ideally, in the first instance, you’ll build a design principles framework. Whatever decisions you make after that (whether you’re going to stick to the rules or break them) should be justified with reference to the framework.

Here are some examples of situations where you might consider deviating from “best practice”:

You Want to Send a Particular Message

Take this site for a children’s fitness company, for example.

It clearly breaks all the rules about color and typeface, and a few more besides, but overall gives a sense of vibrance and playfulness, which of course is ideal for this market.

You Want to Draw Attention to Something

By ignoring the imperative to “work above the fold” and putting product and logo front and centre, candle manufacturer Waxxy draws the eye directly to their “product centred” philosophy and creates a sense of light and space:

Natale’s Clothing uses additional fonts and a broken grid layout to emphasise content and create a sense of being “out of the ordinary”.

You Want to Keep Things Clean

Legend has it, if you “put everything on the homepage” it’s good for SEO and easier for users. These days, though, there’s often a lot of information, and we prefer to have more space, even if it means a bit more browsing.

If you visit Toke’s site here, you’ll see that they break the animation taboo in a subtle and effective way as well.

These are just a few examples, there are many more. In each case the key questions to ask are:

  1. How does it meet the brief?
  2. How does it help brand strategy?

When To Stick To The Script

A big consideration here will likely be the client’s budget. With the best will in the world, you’re going to struggle to create a logo, design a custom typeface, and build a multi-page site from scratch on $800. If that’s what the client’s asking for, and can’t understand the limitations, maybe consider saying no!

If, on the other hand, there’s scope to negotiate, where budgets are small and, in situations where, for example, the client has a small number of products and/or services, a single page WordPress site will often be exactly what they need. Here it’s not a question of “doing the bare minimum” but rather “not doing too much”. Even so, there will probably be bespoke elements that you can change to better fit the strategy.

Another important moment to check yourself, is whenever you’re not sure if an idea works. If you can’t justify a decision with reference to your design principles framework—or at least with reference to the client’s brand strategy—then it’s probably best to err on the side of caution.

Research or Best Practice?

In a word, both.

There are definitely situations where a “first principles” approach will be exactly what the client needs. Particularly if their budget is small and their needs are simple. Even in this case, though, a great designer will take the time to understand (or help to develop) the brand strategy, and add whatever tweaks are necessary. Each client and each brand is unique, and a designer’s job, if you think about it, is to reflect just that.

When using a bespoke approach, breaking with convention can, as we’ve seen, produce interesting and stylish results. It’s important, though, that each decision makes sense, and can be linked back to the brand strategy. If it can’t, it probably shouldn’t be in the design.

And whatever you do, don’t chew your face off.

 

Featured image via Unsplash.

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

The Deal with the Section Element

Two articles published the exact same day:

  1. Bruce Lawson on Smashing Magazine: Why You Should Choose HTML5 <article> Over <section>
  2. Adam Laki on Pine: The Difference Between <section> and <div> Element

They are comparing slightly different things, but they both involve the <section> element.

I find it pretty clear when you reach for a <div>: When you want that element to be essentially meaningless. You’re only using it for styling purposes.

I always think of RSS when I think of <article>: Would this little bit of stuff make sense as an entry (which doesn’t necessarily need to be the entire content of the article)? If yes, use <article>; if not, don’t.

Bruce has a go-to answer:

[…] think of <article> not just as a newspaper article, or a blog post, but as an article of clothing — a discrete entity that can be reused in another context. So your trousers are an article, and you can wear them with a different outfit; your shirt is an article, and can be worn with different trousers; your knee-length patent leather stiletto boots are an article.

More importantly, it has some actual functionality. Bruce mentions that Apple WatchOS specifically uses it to find content on pages.

But <section> is more nebulous. At one point, you were supposed to think of sections as places where your <h1><h6> headings would reset, but that never came to fruition because it required a thing called “HTML5 Outlining” which zero browsers support.

So should we use <section> it at all? According to Bruce, sometimes! Smashing Magazine’s design for articles has a summary at the beginning of the article. Visually, that’s fairly clear, but less-so for screen reader users. The solution was wrapping the summary in an element with an aria-label to make that clear. But you aren’t supposed to use aria-label unless that element also has a role. You could apply a role to a <div>, but <section> already has a good default role, so:

<section aria-label="quick summary"> Summary text
</section>

Adam’s article (sorry, Adam) is very vague on the points.

The main difference comes from the semantic. If you have a part in your site or application which has its logic you need to use the <section> tag to declare it…

… use <section> when it is logically correct to make a part of your site or app readable to the assistive technology. It is an excellent approach if you keep in mind the screen readers.

So you get a role="region" automatically for sections, but I’m not sure that does anything for screen readers, sans the label. In a quick test (Chrome for desktop with VoiceOver enabled), a <section> without an aria-label just wasn’t there in the Landmarks section of the Web Rotor, but it showed up once it had an aria-label.

Point is: don’t just use <section> and assume you’re doing something good for accessibility. Its purpose is pretty limited and only useful for establishing landmarks. Even then, you aren’t helping that much. Leonie Watson in the comments:

When the choice is between a visually hidden heading and a section element with an accessible name there are a couple of things to consider before deciding which approach is the right one.

When a section element has an accessible name it becomes a navigable landmark element, so a screen reader user can use their screen reader’s shortcut key for navigating from one to the next – just like they can do with headings.

According to the most recent WebAIM screen reader user survey though, 68% of screen reader users prefer to navigate by headings compared to 2.9% who prefer landmarks.

So from a strict accessibility point of view, you could probably drop the heading, but from a usability point of view you really want to keep the heading – at least until more screen reader users express a preference for using landmarks to navigate content.

The post The Deal with the Section Element appeared first on CSS-Tricks.

The Mythical Mythical Man-Month

The Mythical Mythical Man-Month

The Mythical Mythical Man-Month

John Foreman

2020-01-15T13:00:00+00:00 2020-01-16T22:09:13+00:00

As a product leader at a tech company, I am a bottomless pit of need. My job as the Chief Product Officer at Mailchimp is to bring the product to market that’s going to win in a very competitive space. Mailchimp’s aspirations are high, and to realize them we need to deliver a substantial amount of product to the market. Oftentimes to many at the company, it feels like we are doing too much. We’re always at the edge of the wheels coming off.

And when you’re doing too much and you decide to do more than even that, you will inevitably begin to hear The Mythical Man-Month referenced. It’s like one of those stress-relief balls where if you squeeze one end, then out pops the Mythical Man-Month at the other end.

Published by Frederick Brooks back in 1975 (you remember 1975, right? When software development 100% resembled software development in 2020?), this book is rather famous amongst software engineers. Specifically, there’s one point in the entire book that’s famous (I’m not convinced people read anything but this point if they’ve read the book at all):

“…adding more men lengthens, not shortens, the schedule.”

Easy fix. I’ll just staff women to projects from now on (see the Return of the King and the fight against the Witch King of Angmar).

But let’s assume that Brooks’ point holds regardless of the gender identification of the software engineers in question. Here’s the point: software is difficult to build with lots of complex interdependencies. And everyone needs to work together to get it done.

As I add people to a team, they need to be onboarded and grafted into the project. Someone’s gotta carve off the right work for them. The team has to communicate to make sure their stuff all works together, and each additional person increases that communication complexity geometrically. And at some point, adding people becomes a burden to the project — not a benefit.

Here’s the graph from the book illustrating that point:

As you add people to tasks with complex interdependencies, progress grinds to a halt
Add people to go slow (Large preview)

This is absolutely a fair point. That’s why I hear it so much at work. Exhausted individual contributors and exhausted leaders alike will toss it out — we can’t go faster, we can’t do more, stop the hiring, read The Mythical Man-Month and despair! The only solution is apparently to stop growing and kill some projects.

When I as CPO say, “we’re going to do this thing!” the reply then is often, “OK, so then what are we going to kill?” The Mythical Man-Month turns product development into a zero-sum game. If we want one thing, we must stop another. Now, that’s an actual myth, and I call hogwash.

And taken to its pathologically misinterpreted (we’ll get to this) conclusion, the book apparently says that the fastest tech company is one that employs all of four people — four men, apparently. Anything more just slows it all down. Someone should send Amazon, Apple, and Google copies of the book, so they can fix their obviously bloated orgs.

The only problem with this approach is that in a space where the competition is growing and iterating and executing — merely tamping organizational growth — editing and focusing the workload to match can be a recipe for extinction. You’ll be more sane and less stressed — right until you’re out of a job.

And as the owner of product management for my company, I’m not unsympathetic with this need to slow down and focus. We must ruthlessly prioritize! No doubt. But running a product is an exercise in contradiction. I must prioritize what I’ve got while simultaneously scheming to get more done. But what am I to do in the face of the Mythical Man-Month?

Surprisingly, the answer to this question comes from Brooks’ same book. Here’s another graph in the same chapter:

Partitionable tasks requiring communication can still add workers and go faster
(Large preview)

There is a battle in scaling product development. If the work you’re trying to accomplish is purely partitionable, then go ahead and add people! If your work is all connected, then at some point adding people is just wrong.

If someone says that I absolutely have to kill a project in order to start another one, that’s just not the case. If the two projects require very little communication and coordination, then we can scale away.

This is why adding cores to a CPU can increase the experienced speed of your computer or phone up to a point — something engineers should know all about. Sure, adding cores won’t help me complete a complex single-threaded computation. But it may help me run a bunch of independent tasks.

The conflict for a product executive then between scaling and ruthless prioritization can be managed.

  1. You ruthlessly prioritize in places that are single-threaded (the backlog for a product team let’s say).
  2. You scale by adding more cores to handle independent work.

Very rarely, however, is anything fully-independent of all else at a company. At the bare minimum, your company is going to centralize supporting functions (global IT, legal, HR, etc.) leading to bottlenecks.

It’s All About Dependency Management

The job of a product executive then becomes not only creating a strategy, but executing in a way that maximizes value for the customer and the business by ensuring throughput and reducing interdependency risk as much as possible. “As much as possible” being key here. That way you can make the company look as much like the latter graph rather than the former. Interdependency is a disease with no cure, but its symptoms can be managed with many treatments.

One solution is to assemble a strategic direction for the company that minimizes or limits dependency through a carefully-selected portfolio of initiatives. The funny thing here is that many folks will push back on this. Let’s say I have two options, one where I can execute projects A, B, and C that have very little coordination (let’s say they impact different products), and another option with projects D1, D2, and D3 that have tons of interdependencies (let’s say they all impact the same product). It’s often the case that the Mythical Man-Month will be invoked against the former plan rather than the latter. Because on paper it looks like more.

Indeed, it’s less “focused.” But, it’s actually less difficult from a dependency perspective and hence fairs better with added personnel.

Keep in mind, I’m not saying to choose a bunch of work for the company that’s not related. Mailchimp will not be building a microwave oven anytime soon. All work should drive in the same long-term direction. This approach can increase customer experience risk (which we’ll discuss later) as well as the burden on global functions such as customer research. Keep an eye out for that.

Another treatment is to create a product and program management process that facilitates dependency coordination and communication where necessary without over-burdening teams with coordination if not required. Sometimes in attempting to manage coordination so we can do more we end up creating such onerous processes that we end up doing less. It’s a balance between doing too little coordination causing the pieces to not inter-operate and doing too much coordination causing the pieces to never get built because we’re all in stand-ups for eternity.

The contention in the Mythical Man-Month is that as you add folks to a software project, the communication needs to increase geometrically. For example, if you have 3 people on the project, that’s 3 lines of communication. But if you have 4, that’s 6 lines of communication. One extra person, in this case, leads to double the communication! Fun. (This is, of course, an over-simplification of communication on software development projects.)

Different people have different roles and hence receive different amounts of autonomy. Perhaps the project manager needs to communicate with everyone on the team. But does an engineer working on the API need to communicate with the product marketer? Or can the marketer just go through the product manager? A good process and meeting cadence can then eliminate unnecessary communication and meetings. The point is that Brooks’ intercommunication formula is an upper bound on coordination, not a death sentence.

Finally, use tools, principles, and frameworks combined with independent work over actual collaboration to combat interdependency symptoms. For example, if I can coordinate two teams’ key performance indicators (KPIs, i.e. measurements of success) to incentivize movement in more-or-less the same direction, then their independent work is more likely to end up “closer together” than if their KPIs incentivize orthogonal movement. This won’t ensure things fit together perfectly, only that the work I need to do to make them fit together in the future is less than it might otherwise be. Other examples might include using “even-over” statements, design systems, and automated testing.

So there’s a start. But interdependencies take on lots of forms beyond code. Let me give an example from Mailchimp.

Customer Experience Risk: The Hidden (But Acceptable?) Cost Of Firewalling Work

Since Mailchimp’s customer is often a small business owner who’s a marketing novice (and there are millions of small business owners turned marketers worldwide), we must deliver an experience that is seamless and immediately understandable end-to-end. We’re not afforded the luxury of assembling a Frankenstein’s monster of clouds via acquisition the way that enterprise players can. We can’t paper over poorly-integrated software with consultants and account managers.

As a consumer product (think Instagram or a Nintendo Switch or a Roomba), we have to be usable out of the box. For an all-in-one marketing platform meant to power your business, that’s hard! And that means each thing Mailchimp builds must be seamlessly connected from an experience perspective.

But, perfectly partitioning projects then introduces experience risk. It’s not that the code can’t be written independently. That can be achieved, but there’s still a risk that the products will look like they’ve been built by different teams, and that experience can be really damn confusing for the user. We bump up against Conway’s law — our customers can tell where one team’s work ends and the other team’s work begins.

So you try to connect everyone’s work together — not just on the back-end but on the front-end, too. In the ecosystem era, dominated by CX excellence from players like Apple, this has become almost table stakes in the consumer space. But this is a Mythical Man-Month nightmare, though not from an engineering perspective this time. It’s from a service design perspective. As we add more people to all of this “end-to-end” connected work, everything slows to a collaborative crawl.

Other than the third fix I noted above, using tools and frameworks rather than over-watchers and stage-gates, there is another release valve: make some deliberate customer experience trade-offs. Specifically, where are we comfortable releasing an experience that’s disconnected from the rest (i.e. that’s sub-par)? Accepting risk and moving forward is the product leader’s job. And so you use some criteria to sort it out (perhaps it’s not holding new, low-traffic areas of the app to the same experience standards as your “cash cows”), and make a decision (e.g. iteration and learning over polish on adjacent innovations). This, of course, extends beyond design.

You can always short-circuit Brooks’ law by choosing to firewall efforts, including efforts that, in a perfect world, shouldn’t be firewalled!

I’ll caveat this by saying the software I build doesn’t kill anyone. I wouldn’t advocate this approach if I were building a medical device. But at a marketing software company, I can deliberately isolate teams knowing that I’ve increased the odds of incompatibility as a trade-off for scaling up personnel and moving faster.

I’m sad to admit that the Mythical Man-Month is a reality at my company, and I suspect at yours as well. But it’s manageable — that’s the bottom line. Parallelization and dependency mitigation offer us a way out that limits the near-mythical status of the Mythical Man-Month. So the next time the stark dichotomy is raised at your company (scale to go slower or give up your aspirations) remember that if you’re smart about how you line up the work, you can still grow big.

Don’t Forget About The Softer Side Of Scaling

Keep in mind that managing the Mythical Man-Month will not stop engineers from invoking it like dark magic. They’re invoking the principle not only because there’s some truth in it, but because scaling just sucks (always) from an emotional and cognitive perspective. If I think I’m paid to write code and solve customer problems, the last thing I wanna do is change up my routine and figure out how to work with new people and a larger team.

As you scale your company, remember to empathize with the pain of scaling and change. A team that adds even a single member becomes a whole new team from a trust and cultural perspective. People are tired of this change. That means that while you go about managing and mitigating the Mythical Man-Month, you’ll need to manage the emotions surrounding growth. That’s perhaps the most critical task of all.

Strong belief in the Mythical Man-Month by a team in and of itself can bring its conclusions into reality. It’s basically the equivalent of the belief in flying in Peter Pan. If the team believes that scaling will slow them and they don’t buy into the change, they will indeed slow down.

So as you work to manage dependencies and introduce tools to help scale, make sure you clearly communicate the why behind the practices. Get folks involved in selecting the work and processes that mitigate man-month issues, because when they’re part of the change and their outlook changes, suddenly scaling becomes at least culturally possible.

Smashing Editorial (ra, il)
A Trick That Makes Drawing SVG Lines Way Easier

When drawing lines with SVG, you often have a <path> element with a stroke. You set a stroke-dasharray that is as long as the path itself, as well as a stroke-offset that extends so far that you that it’s initially hidden. Then you animate the stroke-offset back to 0 so you can watch it “draw” the shape.

Figuring out the length of the path is the trick, which fortunately you can do in JavaScript by selecting the path and doing pathEl.getTotalLength(). It’ll probably be some weird decimal. A smidge unfortunate we can’t get that in CSS, but c’est la vie.

Here’s the trick!

You don’t have to measure the length of the path, because you can set it.

So you do like:

<path d="M66.039,133.545 ... " pathLength="1" />

That doesn’t do anything by itself (as far as I know). It’s not like that only draws part of the path — it still draws the whole thing like as if you did nothing, only now the “math” of the path length is based on a value of 1.

Now we can set the stroke-dasharray to 1, and animate the offset in CSS!

.path { stroke-dasharray: 1; stroke-dashoffset: 1; animation: dash 5s linear alternate infinite;
} @keyframes dash { from { stroke-dashoffset: 1; } to { stroke-dashoffset: 0; }
}

Which works:

See the Pen
Basic Example of SVG Line Drawing, Backward and Forward
by Chris Coyier (@chriscoyier)
on CodePen.

High five to Adam Haskell who emailed me about this a few months back.


Hey, speaking of SVG line drawing: Lemonade made a landing page for their 2019 charity that uses scroll-triggered SVG line drawing up and down the entire page. They did a behind-the-scenes look at it, which I always appreciate.

animated GIF of line drawing on Lemonade page - as page scrolls down a teddy bear shape is drawn

The post A Trick That Makes Drawing SVG Lines Way Easier appeared first on CSS-Tricks.

Understand Your Users with Positionstack

One of the best things about the Internet is that it (mostly) doesn’t care where you are. The person you’re interacting with might be in Rio or Rhode Island, Bahrain or Birmingham. The Internet opens up the world.

But opening up the world doesn’t mean removing it. The geographic independence loved by users can be a real headache for businesses, because nearly all businesses are constrained by geography. For business, having an accurate picture of where your users are means understanding them, understanding your relationship to them, and can mean the difference between an enviable user experience, and a PR disaster.

Geocoding grants you Sherlock Holmes-like powers of deduction

One option for understanding a user’s location is Geolocation, which allows you to locate a user via their IP address; it’s not perfect because IP addresses are tricky things. Arguably a better option, thanks largely to the accuracy of the starting data, is Geocoding. Greater reliability than Geolocation makes Geocoding a more useful option for UX designers.

Geocoding grants you Sherlock Holmes-like powers of deduction, to seek out rich data about your users. But where do you start? One of the best ways is to integrate your site or app with positionstack.

What Are The Benefits of Geocoding?

It’s awesome that you can sell your band’s T-shirt to a fan in Vietnam, or ship a used car part to a mechanic in Siberia, but until 3D printing gets a lot more sophisticated there needs to be a way to move objects from Point A, to Point B; step 1 in that process is figuring out exactly where Points A and B are.

Shipping goods, with all the automatically calculated costs, isn’t the only reason you may want to know someone’s location. For example, it’s good manners to present prices in the local currency, or direct customers to a support line that speaks their language. And unfortunately, there are legal issues to consider: national and international bans exist on trading with some nations, accepting certain orders from some users could land you in hot water.

The key to a great user experience is gathering data about your users and then acting on it

One of the best features of a Geocode API like positionstack is that once your user has disclosed their location you can make an educated-guess at a whole lot more, from their probable first language, to their marketing preferences, and even the time they’re likely to come home from the office.

Imagine you’re offering a callback service on your website. Geocoding not only ensures you can pre-fill the international dialling code in the callback form, but it tells you the user’s timezone—essential if you don’t want to wake them up with a 4am sales pitch.

A user’s location also affects their outlook on the world. Go visit a major international company like Apple, Nike, or Pepsi, change your location on their site, and compare how brands with millions of research dollars pitch their wares differently in North America, France, Indonesia, or New Zealand. The key to a great user experience is gathering data about your users and then acting on it.

Why Choose positionstack?

With just a user’s physical address you can determine dozens of different characteristics that allow you to naturalize your site or app for users. Based on an address—even a partial address—positionstack can determine the user’s currency, dialling code, even their hours of daylight.

One of the best features of positionstack is its ability to translate an address into a latitude and longitude, then plot that position on a map that you can easily embed on your site. Nothing builds a connection like showing a user a place they recognize; it builds confidence, increases conversions, and ultimately means higher profits for you.

And that’s not all. positionstack enables both forward, and reverse geocoding. That means as well as finding a global position from an address, it can also find an address from a latitude and longitude. You can even perform batch queries (multiple searches) allowing you to narrow down addresses from an approximate location.

a super-reliable infrastructure, handling over a billion requests per day, with a typical response time of less than 100 milliseconds

As you can probably guess, any Geocoding API is only as useful as the data that underpins it. positionstack is run by apilayer, one of the most trusted names in APIs. It boasts a super-reliable infrastructure, handling over a billion requests per day, with a typical response time of less than 100 milliseconds. positionstack’s API is built on a database of more than two billion global locations, sourced from high-quality data sources, and it’s updated on a daily basis.

positionstack is also exceptionally easy to integrate into a site or app. There are code examples provided in PHP, Python, Nodejs, Go, Ruby, and jQuery—you can even use the service with vanilla JavaScript. Data is returned in XML, JSON, or GeoJSON formats.

Perhaps the most appealing feature of positionstack is that it’s completely free for use up to 10,000 API requests per month. So if you’re running a small site, or just getting started, you can make use of professional-grade data at zero cost. Once you’ve grown large enough to need it, premium subscriptions start at just $9.99 per month.

Head over to positionstack.com today, to get started with Geocoding for free.

 

[– This is a sponsored post on behalf of positionstack –]

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google