Archive

Archive for October 1st, 2021

Links on React and JavaScript II

October 1st, 2021 No comments

The post Links on React and JavaScript II appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

Using the platform

October 1st, 2021 No comments

While I’m a front-end developer at heart, I’ve rarely had the luxury of focusing on it full time. I’ve been dipping in and out of JavaScript, never fully caught up, always trying to navigate the ecosystem all over again each time a project came up. And framework fatigue is real!

So, instead of finally getting into Rollup to replace an ancient Browserify build on one of our codebases (which could also really use that upgrade from Polymer to LitElement…), I decided to go “stackless”.

Elise Hein

I’m certainly not dogmatic about it, but I think if you can pull of a project with literally zero build process. It feels good while working on it and feels very good when you come back to it months/years later. Plus you just pick up and go.

Imports, yo — they go a long way.

Native support for modularity is the most important step towards a build-free codebase. If I had access to only one ES6 feature for the rest of my life, I’m confident that modules would take me most of the way there when it comes to well-structured native JavaScript.

That last sentence in the post is a stinger. I’d say we’re not far off.

Direct Link to ArticlePermalink


The post Using the platform appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

Working With Built-in GraphQL Directives

October 1st, 2021 No comments

Directives are one of GraphQL’s best — and most unspoken — features.

Let’s explore working with GraphQL’s built-in schema and operation directives that all GraphQL spec compliant APIs must implement. They are extremely useful if you are working with a dynamic front-end because you have the control to reduce the response payload depending on what the user is interacting with.

An overview of directives

Let’s imagine an application where you have the option to customize the columns shown in a table. If you hide two or three columns then there’s really no need to fetch the data for those cells. With GraphQL directives, though, we can choose to include or skip those fields.

The GraphQL specification defines what directives are, and the location of where they can be used. Specifically, directives can be used by consumer operations (such as a query), and by the underlying schema itself. Or, in simple terms, directives are either based on schema or operation. Schema directives are used when the schema is generated, and operation directives run when a query is executed.

In short, directives can be used for the purposes of metadata, runtime hints, runtime parsing (like returning dates in a specific format), and extended descriptions (like deprecated).

Four kinds of directives

GraphQL boasts four main directives as defined in the specification working draft, with one of them unreleased as a working draft.

  • @include
  • @skip
  • @deprecated
  • @specifiedBy (working draft)

If you’re following GraphQL closely, you will also notice two additional directives were merged to the JavaScript implementation that you can try today — @stream and @defer. These aren’t part of the official spec just yet while the community tests them in real world applications.

@include

The @include directive, true to its name, allows us to conditional include fields by passing an if argument. Since it’s conditional, it makes sense to use a variable in the query to check for truthiness.

For example, if the variable in the following examples is truthy, then the name field will be included in the query response.

query getUsers($showName: Boolean) {
  users {
    id
    name @include(if: $showName)
  }
}

Conversely, we can choose not to include the field by passing the variable $showName as false along with the query. We can also specify a default value for the $showName variable so there’s no need to pass it with every request:

query getUsers($showName: Boolean = true) {
  users {
    id
    name @include(if: $showName)
  }
}

@skip

We can express the same sort of thing with just did, but using @skip directive instead. If the value is truthy, then it will, as you might expect, skip that field.

query getUsers($hideName: Boolean) {
  users {
    id
    name @skip(if: $hideName)
  }
}

While this works great for individual fields, there are times we may want to include or skip more than one field. We could duplicate the usage of @include and @skip across multiple lines like this:

query getUsers($includeFields: Boolean) {
  users {
    id
    name @include(if: $includeFields)
    email @include(if: $includeFields)
    role @include(if: $includeFields)
  }
}

Both the @skip and @include directives can be used on fields, fragment spreads, and inline fragments which means we can do something else, like this instead with inline fragments:

query getUsers($excludeFields: Boolean) {
  users {
    id
    ... on User @skip(if: $excludeFields) {
      name
      email
      role
    }
  }
}

If a fragment is already defined, we can also use @skip and @include when we spread a fragment into the query:

fragment User on User {
  name
  email
  role
}

query getUsers($excludeFields: Boolean) {
  users {
    id
    ...User @skip(if: $excludeFields)
  }
}

@deprecated

The @deprecated directive appears only in the schema and isn’t something a user would provide as part of a query like we’ve seen above. Instead, the @deprecated directive is specified by the developer maintaining the GraphQL API schema.

As a user, if we try to fetch a field that has been deprecated in the schema, we’ll receive a warning like this that provides contextual help.

In this example, the title field has been marked deprecated and the directive provides a helpful hint to replace it.

To mark a field deprecated, we need to use the @deprecated directive within the schema definition language (SDL), passing a reason inside the arguments, like this:

type User {
  id: ID!
  title: String @deprecated(reason: "Use name instead")
  name: String!
  email: String!
  role: Role
}

If we paired this with the @include directive, we could conditionally fetch the deprecated field based on a query variable:

fragment User on User {
  title @include(if: $includeDeprecatedFields)
  name
  email
  role
}

query getUsers($includeDeprecatedFields: Boolean! = false) {
  users {
    id
    ...User
  }
}

@specifiedBy

@specifiedBy is the fourth of the directives and is currently part of the working draft. It’s set to be used by custom scalar implementations and take a url argument that should point to a specification for the scalar.

For example, if we add a custom scalar for email address, we will want to pass the URL to the specification for the regex we use as part of that. Using the last example and the proposal defined in RFC #822, a scalar for EmailAddress would be defined in the schema like so:

scalar EmailAddress @specifiedBy(url: "https://www.w3.org/Protocols/rfc822/")

It’s recommended that custom directives have a prefixed name to prevent collisions with other added directives. If you’re looking for an example custom directive, and how it’s created, take a look at GraphQL Public Schema. It is a custom GraphQL directive that has both code and schema-first support for annotating which of an API can be consumed in public.

Wrapping up

So that’s a high-level look at GraphQL directives. Again, I believe directives are a sort of unsung hero that gets overshadowed by other GraphQL features. We already have a lot of control with GraphQL schema, and directives give us even more fine-grained control to get exactly what we want out of queries. That’s the sort of efficiency and that makes the GraphQL API so quick and ultimately more friendly to work with.

And if you’re building a GraphQL API, then be sure to include these directives to the introspection query.. Having them there not only gives developers the benefit of extra control, but an overall better developer experience. Just think how helpful it would be to properly @deprecate fields so developers know what to do without ever needing to leave the code? That’s powerful in and of itself.


Header graphic courtesy of Isabel Gonçalves on Unsplash


The post Working With Built-in GraphQL Directives appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Categories: Designing, Others Tags:

Email Newsletter Guide: How To Write Newsletters That Actually Get Read

October 1st, 2021 No comments

Why do you pick a book at a store or go for a movie?

It’s probably because you heard great reviews about it or you “opted in” because something about it caught your attention.

You’d go back looking for new releases of the book and the movie only if the author and the director are consistent in their efforts to give you the best work.

Won’t you?

So, how different is a newsletter from this?

Honestly, not much!

A newsletter like a book or a movie is when an audience genuinely opt-in to hear from you because they find you promising, useful, and unique.

If your newsletter, like an interesting book or a movie, does not make the reader want to grab popcorn and fully indulge in the content, don’t bother writing at all!

Newsletters are not another task to be checked off on your to-do list.

You’ve got to have a lot of passion to be able to spin a story, sketch a screenplay, and make your newsletters a blockbuster hit!

Why Should Your Newsletters Be Read?

Before we delve into how to write a newsletter that gets read, let’s first find answers to why it should get read in the first place.

  • Increase brand awareness
  • Nudge users to move further down the funnel
  • Engage your audience with useful content
  • Share product and feature updates
  • Become a thought leader

5 Steal-Worthy Strategies To Make Your Newsletters Irresistible To Read

1. Stick to the magical three-step formula 

A magical three-step formula to an engaging newsletter is an attractive subject line, compelling email copy, and also measuring the success of your content to understand what works and what doesn’t.

  • Attractive subject line copy + Key elements = Higher open rates

The starting point to an email content that wants to be read is an attractive subject line. Here are some pointers on making your subject lines attractive:

  • Personalize your subject lines with the recipient name, company name, or any other relevant attribute
  • Add emojis to make it instantly relatable
  • Breakthrough the inbox clutter by creating urgency (use words like “hurry”, “expires”, “limited”, “soon”, and more)
  • Intrigue the recipient with a question
  • Phase-out bland subject lines and incorporate the art of storytelling. Try analogies, metaphors, and more

Bonus Tip: Be Data-driven

Tap into customer interests. Base your subject lines on your subscribers’ last activity on your store, last purchase, tastes and preferences, and more. 

Ex: If you have a food delivery app and see that a customer orders pizzas way too often in the nighttime, your subject lines should be something like this:

, It’s almost dinner time, let’s order your favorite pizza

Based on what we just discussed, you’d know the key elements now! To summarize,

  • Emojis
  • Personalization tag
  • Data-driven
  • Punctuations
  • Good design + Mobile responsiveness = Better engagement

Attractive subject lines are just the tip of an iceberg, more like luring in your audiences for the real feast – your email copy (will be discussed later) and design.

So, what is a good design?

  • A clean layout without any intrusive elements
  • Rich in graphics – charts, images, gifs, videos, or any other entertaining media asset
  • A layout that is mobile responsive 
  • Monitor your metrics

I cannot stress this enough! Whether your newsletter gets read or not largely depends on understanding your audience.

  • Dig into the data and understand your metrics. What type of content has the most and least engagement
  • What does the majority of your audience like
  • What content resonates with your audience segments
  • How can you tweak your content to get the maximum engagement

Needless to say,

Higher open rates
+ Better engagement 
+ Monitoring the metric
= Email Newsletter Success

2. Write like you talk: Treat your subscribers like your pals

Your newsletters may reach hundreds of thousands of subscribers. But, if you want the email to be read, you should make the email sound like a personal one-to-one conversation rather than a lousy blast.

Phase-out generic content and add some pop, fizz, and pizzaz!

Here’s a good example from Lessonly. After I subscribed to Lessonly, I started receiving a series of emails from them based on my interaction. This is a great example of how to keep the tone friendly, conversational, light, and lifelike 🙂

Pro tips to make your emails look personal [Like a 2 am phone call to your BFFs] ?

  • Make sure that it’s from an individual and not under a brand’s name
  • Use a simple conversational tone
  • Avoid using jargon unless your audience can digest it
  • Switch between plain text emails and design-heavy emails
  • Break down your content into bullets and make it instantly skimmable
  • Be conversational with your sign-off (Try “Talk soon”, “Cheers”, “Good day” etc. instead of the usual “Regards”)

Note? Don’t go overboard with this strategy as there’s a fine line between being friendly and creepy! 

3. Be useful and have solid takeaways

Newsletters are not a channel to load promotional emails.

If that’s the objective, I’m sorry to break the bubble – it ain’t gonna happen!

Emails are a great channel for you to connect with your customers, educate them, entertain them, solve their problems, hear about their appreciation and woes, and also promote.

It’s just a small piece of the pie.

Email Newsletters must be leveraged to optimize customer experience, heavily.

Think about it.

Your typical subscriber has an inbox flooded with emails. Ask yourself why should they take the time to open your email, read it, and take action?

They should do so because your newsletters cover the following:

  • Tips and tricks pertaining to the industry are shared in the body of the email itself and not a random link to a blog 
  • Diverse content resources for free – ebooks, whitepapers, blogs, webinars, infographics, videos, and more that cover different stages of a buyer’s journey
  • An opportunity to hit reply and have all their doubts and queries answered

4. Tap on emotions and trigger response

There’s no marketing without emotions. Think about how Apple manages to get hundreds and thousands of customers excited about their launches.

Through teasers and keynotes, they trigger the emotion of excitement and curiosity and reap the benefits of massive sales on their launch day.

Similarly, your newsletters must also appeal to reader’s emotions for them to connect with you.

Let’s look at some trigger words to instill emotions in your newsletters.

How to map the emotions with your objectives?

  • Instill the emotion of curiosity for your launches
  • Instill the emotion of happiness for the brand’s as well as user’s milestones
  • Instill the emotion of urgency for your offers, sale, and discounts
  • Instill the emotion of information to get your content across to your audience
  • Instill the emotion of action for your marketing goals

5. Segment your audience

The foundation to getting your newsletters to read is segmenting your audience. This is a crucial step because people read only when they are relevant.

Imagine opening your newsletter by checking upon your subscriber who lives in Newyork regarding a recent storm that happened in California.

You’ll look like a bot that the user wants to unsubscribe from with no second thoughts.

Don’t be vague and generic with your segmentation as rightly pointed out by Marketoonist.

On what basis should you segment your subscribers?

  • Geography
  • Demography
  • Interaction with your website
  • Stage in the marketing funnel
  • Tastes and preferences
  • Past purchases

Depending on the nature of your business, the segmentation goals may widely vary!

Wrapping Up

When you put in a lot of effort and have the drive to make your newsletters the talk of the town, I’m sure you can see a lot of ROI from it,

But, more often than not, the interest tends to slowly fade away and the quality of the newsletter starts to dwindle.

You have to constantly make efforts to ensure that your newsletter gets read and engaged with. 

Spend time on writing a kickass copy and as far as the design, mobile responsiveness, and layout are concerned you may want to consider some good tools.

There are tools for email newsletters like BayEngage, Hubspot, and Mailchimp. You may want to consider some alternatives too!

I hope these tips come in handy!

If you have any other tips, do share them in the comments and I’d be happy to chat!

Categories: Others Tags: