Boris

Simon

Tom Stothard Whitaker

Simon V has a new article that shows you how to produce landscape and portrait formatted videos from the same footage.

Dinesh gives a run through of how you can use Keystone as a data layer in a Next.js project.

A collection of readings crafted by the talented folks at Thinkmill.

This post is to show all. the different components that we have the ability to use directly in the document editor of Keystatic.

If you want to play around with these in the editor head over to this post in the Keystatic admin pannel.

If you want to see how they're setup take a look at the 

Want to see more of what we're doing at Thinkmill? Check out our news page 

Have a project the Thinkmill team could help with? We would love to hear from you! 

Want to work with us?

This is a more styled version of just using a markdown image syntax including 

 file in the style of a looping gif. Running the component this way we get to keep up the performance benefits of using a video file over a gif.

The Kitchen Sink

The likely result: social sharing takes a hit (or, it takes forever). So, what if there was a solution to take the great content you’re engaging with, and share it to a social platform really quickly — and really easily?

We recently created a version of this solution on a Thinkmill project, finding a way to improve the experience for users who prefer keyboard-based navigation when sharing to Twitter. This article will show you how to build your own using PopperJS and the native Selection API with improved accessibility for keyboard-based users thanks to your web browser’s Caret Browsing capability.

You can try this out now, by selecting this paragraph and, with any luck, being presented with a popover interface that builds the tweet, and takes you to Twitter:

To build this feature we’ll need to accomplish the following:

 to display the sharing interface at the location where the user selected the text. We’ll also tie this up into a reusable hook in order to access it across many parts of a project. To do this we’ll break the feature into 2 parts:

Capturing selected text with the Selection API

First things first, let's get text highlight selection in place. To do this we need to reach for the HTML spec's 

. As well as getting the selected text we want to also get the coordinates to pass through to PopperJS.

In the above we are also resetting our text selection when we have de-selected text on the screen.

Extracting the page URL with window.location.href

While we're at it, let's grab the URL of the page we're on to include it in the tweet. To do that we can call 

 method, which converts it to UTF-8 encoding to put in our URL bar.

const pageUrl = encodeURIComponent(window.location.href)

Supporting keyboard-based selection with Caret Browsing

We can improve the accessibility of this feature by taking advantage of a browser setting called 

. Available in Chrome, Firefox and Edge through the F7 keyboard shortcut - Caret Browsing lets users navigate the page and select text with directional keys like they are in a MS Word or Google document. We will also trigger the function to fire on text selection change.

 of the selected text which we can use to position the popover. We’re going to use the coordinates Popper provides to set our reference element by passing it up to the parent to be set as the 

return () => ({
  width: 0,
  height: 0,
  top: y,
  right: x,
  bottom: y,
  left: x,
})

Now that we have the main pieces, we can put them together to build that tweet!

We need to ensure that the selected text fits within Twitter’s tweet limit of 280 characters. By including the truncated text in the popover’s preview, we’ll avoid any last-minute surprises that the user might encounter when they go to share their tweet.

const buildTweet = ({
  pageUrl,
  tweetContent,
}: {
  tweetContent: string | undefined
  pageUrl: string
}) => {
  if (tweetContent !== undefined) {
    const characterTotal = tweetContent.length + pageUrl.length
    if (characterTotal + 19 < 280) {
      return encodeURIComponent(`"${tweetContent}" – `)
    }
    const amountToTrim = 280 - (pageUrl.length + 19)
    return encodeURIComponent(`"${tweetContent.slice(0, amountToTrim)}…" – `)
  }
  return ''
}

export const buildTargetLink = ({ quote }: ShareQuoteProps) => {
  const pageUrl = encodeURIComponent(window.location.href)
  const twitterLink = (tweetContent: string) =>
    `https://twitter.com/intent/tweet?text=${tweetContent}&url=${pageUrl}&via=thethinkmill`
  const tweet = buildTweet({
    pageUrl,
    tweetContent: quote,
  })
  return twitterLink(tweet)
}

Let's go through some of the numbers in the snippet above:

Sharing the tweet with Twitter's URL API

Now that we have our page URL and our built tweet at the right length we can use Twitter's 

 URL to fire off the tweet. The function we have above builds this URL in this way:

Now that we have done all the heavy lifting of selecting the text and building our tweet. All that's left is to wrap it all up and be ready to ship this feature. To do this we will make a component to wrap our content and trigger the share function. Below is the whole component and then we will go into it more in-depth.

export const ShareableText = ({
  wrapperId,
  children,
}: {
  wrapperId: string
  children: React.ReactElement
}) => {
  const { textElementRef, textElementSelectionChangeHandler, popupElement } =
    useShareableText({ wrapperId })
  const childrenWithProps = React.Children.map(children, (child) =>
    React.cloneElement(child, {
      id: wrapperId,
      ref: textElementRef,
      onMouseUp: textElementSelectionChangeHandler,
    })
  )
  return (
    <React.Fragment>
      {childrenWithProps}
      {popupElement}
    </React.Fragment>
  )
}

We are pulling in the pieces we need out of the useShareableText hook. We grab the selection handler function and the relevant parts used by PopperJS.

const { textElementRef, textElementSelectionChangeHandler, popupElement } =
  useShareableText({ wrapperId })

 method from React and attach the required props needed.

const childrenWithProps = React.Children.map(children, (child) =>
  React.cloneElement(child, {
    id: wrapperId,
    ref: textElementRef,
    onMouseUp: textElementSelectionChangeHandler,
  })
)

Now we can return a fragment with the props for the wrapper and the PopperJS element.

return(
  {childrenWithProps}
  {popupElement}
);

The result is a convenient wrapper around our content, which is the final piece of the share-to-Twitter puzzle. That gets placed around our content and we’re done.

return <ShareableText wrapperId="shareable-wrapper">{content}</ShareableText>

We used the selection API to get selected text from the page. We took advantage of PopperJS’ 

 function to know where on the page our selected text was located. And finally, we built a neat function that creates the tweet with some wrapping text and fits it within Twitter‘s 280 character limit. The end result is a seamless sharing experience you can use across mouse, touch, and keyboard inputs to let readers share their favourite excerpt of an article without having to copy, paste and edit.

. If you have more questions about the implementation you can find 

To learn more about the tools and APIs used in this tutorial check out the links below.

Medium has a feature that lets readers share selected article text straight to Twitter — without having to copy, paste and edit. It’s a cool way to support sharing without drawing the user too far away from their reading experience. But, that same nifty sharing feature isn’t available for all the great content on the internet.

Building a share text selection to Twitter feature in React

This article is originally from the talented folks at Thinkmill. Check out the original post 

Many people who don’t know much about Thinkmill perceive us as a classic agency with all the classic agency problems like short term projects, churn, and superficial work.

While our commercial model is one of a classic agency (we sell time for money), how we create value, is not. We take a longer term view of developing knowledge, which is enabled through our work with 

 the product of Thinkmill, one that we work hard to improve over time.

We get to practice and innovate over and over again, reinforcing a 

 that means over time, we collectively get better at a certain set of things: 

We get to practice doing the thing in a wide variety of environments, under many different constraints – technology, people, culture, budgets, ambition, industry, etc.

With each iteration of the loop (client engagement) we accumulate new experience, and refine what we know. We get opportunities to innovate and try out new approaches and methods. Sometimes we get long stretches, sometimes we get short bursts. This is the innovation wheel that causes our product knowledge to get better over time.

This is also why all of Thinkmill is a team, and why we invest a lot in breaking down silos and spreading knowledge. We all contribute to the turning of the innovation wheel.

If we get too caught up in any individual project, we may lose sight of the value we gain from the engagement. But if we keep the bigger picture in view, and remember that each experience is additive, it’s easier to remember that the challenges of any engagement are transient, and always present an opportunity to improve our craft.

Getting better at our craft over time is the goal. It’s the whole game. This perspective is crucial for growing at Thinkmill and having a good time with amazing people (both clients, and colleagues) throughout.

How the work we do in open source and client services drives our craft to new levels.

The Thinkmill Learning Loop

Over the last decade, Thinkmill has organically evolved a set of mindsets that inform how we build products. Together, these mindsets form a Philosophy of Working that permeates our daily practice and shapes the tools we make in 

. This article unpacks our mindsets to give you a better sense of how we bring value to the work of product, and offer a case for adopting them in your own team.

Originally coined by our Design Director Lauren Argenta, engineering-led emerged as a product-building mindset stemming from the fact that most Thinkmill practitioners are engineers.

In practical terms, engineering-led means that we tend to think about how the schema, database, and system architecture are going to be developed as a way of informing and shaping (sometimes constraining) the products that we then end up designing. Engineering-led has been a useful way for us to differentiate our way of working from a design-led one, which you may find in other organisations.

For a deeper dive into the engineering-led mindset, watch Lauren talk about how we design in an engineering-led way at 

This mindset is especially important to the work we do in design. It conveys the idea that in a world of abstractions, converging on code as the primary source of truth — wherever possible — is the least problematic way to build products.

Practitioners who don’t subscribe to this approach might be of the opinion that the artefacts of a design tool like Figma represent the source of truth. In our view they make for a brittle source of truth because they’re a static picture of the dynamic thing that will exist as code running on the internet.

We’ve developed the mindset that as technical designers, all the stuff we’re creating and expressing will ultimately live as code in a repo. So we should work with this reality and limit the abstractions by understanding, referencing, subscribing to, and contributing to – the code. As much and as soon as possible.

As an example, our goal is not to maintain perfect synchrony between Figma components, and the components in the code repository or Storybook; but rather to be comfortable using and improving those components in their native context.

We often talk about schema-first as an extension of the engineering-led mindset. In some ways it’s an expression of how we learned to build software. We found that by describing the data model or a schema for an application first, it serves as middleware to align a product’s back-end infrastructure, API, and front-end needs.

If the practitioners involved in delivering those aspects can converge and collaborate on the schema – it ends up being a useful way of aligning those different practices. Such that you can then go away and work relatively independently and come back to the schema when the need to update shared understandings arises.

 is an open source framework we maintain that’s predicated on this schema-first way of working. With Keystone you literally write schema and it gives you back a database, GraphQL API, and Admin UI.

As opposed to starting with the interface or elsewhere, we strive to start with schema-related questions as much as possible. These questions look something like:

Answering these questions in the form of a schema gives us a really good idea of how to design interfaces and flows that are inherently aware of the data that underpins the user experience. The result is fewer gaps when we’re delivering the thing we designed.

We’ve found that it’s really hard (if not impossible) to build good software and products if we’re not intentionally working in a deeply collaborative and cross-functional way. Getting people from different practices collaborating effectively is something we think a lot about. Two extensions of this cross-functional mindset are 

Invision coined this term in their excellent 

. We subscribe to this mindset, and have embedded it as a central concept in the Thinkmill Method. Design Engineering to us is not about filling the gaps between the disciplines of design and engineering, but rather acknowledging and optimising their overlap.

As designers, the more we care about accessibility and API design, the better. As engineers, the more we care about interface quality, usability principles and heuristics, the better. The more we overlap, the more we reduce the likelihood of gaps both 

 gaps are what we might miss on the path to delivery, and 

 gaps arise from a designer creating without due consideration of something like performance, or conversely, an engineer building something that’s really performant without considering how useable that performant thing is.

Code ♥ Design is another shorthand for our cross-functional way of working across design and engineering that we’re known for. In 2018 we partnered on a 

 to bring greater awareness to cross functional collaboration, so there's a literal physical expression of our mindset out there.

This cloud of mindsets comes together to form our Philosophy of Working. Most of these mindsets have been around for a while. They’re robust, proven, and hang together in such a way that we, as a group of people, can channel and embody them to build great things. Feel free to adopt or remix them to meet your own team needs.

If you’re interested in learning more about how we embody our philosophy in the work of building products, watch my talk from Dovetail’s Delighter’s conference:

To explore how we can help you build great products and delivery culture within your organisation – 

The mindsets, principles, and enablers that shape how we build great products.

A collection of readings crafted by the talented folks at Thinkmill.

The Kitchen Sink

The Thinkmill Learning Loop

Our Philosophy of Working

Building a share text selection to Twitter feature in React