
Inspired by [Chris Biscardi](https://twitter.com/chrisbiscardi), [Joel Hooks](https://twitter.com/jhooks), [Shawn Wang](https://twitter.com/swyx), and others, I, too, wanted to dynamically generate social images for my blog posts.

But the thought of creating an image generation API was daunting to me. Cloudinary, Lambdas, Chromium are cool, but I wanted something more straightforward.

It was around this time that [Marina](https://twitter.com/MarinaAisa/status/1250425913705025536) introduced me to Microlink and its creator [Kiko](https://twitter.com/kikobeats). Microlink was just about to release their new product, [Microlink Cards](https://cards.microlink.io/).

Being one of the alpha testers of Microlink Cards, I decided to take it for a spin and rely on it to generate the social images for me.

Microlink Cards works like this:

1. Pick a template or build your own
2. Define your dynamic queries
3. Add the generated URL to your `meta` tag, providing the right queries

<Image src="/posts/generating-open-graph-images/microlink.png" width="3104" height="2024">
  A screen shot of Microlink Cards showing my template
</Image>

## Building my template

Instead of using an existing template, I decided to build my own. Have a [look here](https://cards.microlink.io/editor?preset=pedro).

Templates are built (designed) in JSX, powered by [Theme UI](https://theme-ui.com). What a good idea! 👏

## Defining my queries

This how you choose what can be customised via query strings passed in to the generated URL.

I created the following queries:

- `heading`: the heading of the card
- `subheading`: the sub-heading of the card
- `title`: the main title of the page you're sharing
- `domain`: the URL of the page you're sharing
- `theme`: a theme object following (I'm using a subset from [Wallop System](/blog/wallop-system-built-with-modulz) theme)

## Showing dynamic images

The last step is to take the generated URL and pass in your queries via query strings.

For example, let's say you want to generate a card with a title of "The future is now.":

## Wrapping up

I think this is a sweet balance between flexibility and simplicity. I love that I can build templates in JSX and decide how customisable I want them to be.

The ability to take a URL, provide some query strings, and get back a social image (at the right size!) is brilliant to me.

In order to create templates right now, you need to contribute to [the repo](https://github.com/microlinkhq/cards). It would be cool if there was a way to do it all in the app.

Finally, I think there's some potential for a [Modulz](https://modulz.app) integration. Imagine connecting your Modulz generated design system and having access to all your components? 🤯

---

## Have a play

See for yourself how it works. Enjoy! ✌️

<CardPlayground />


Dynamically generating social images


Last year I talked at [JAMstack meetup](https://www.meetup.com/JAMstack-London/events/257961818/) in London. As part of this talk, I created an online guide to help people get started with JAMstack, it's called [jamstack.wtf](https://jamstack.wtf).

I built it with [Rebass](https://rebassjs.org). If you're not familiar with Rebass, it's a React UI Library. It's one of many projects by [Brent Jackson](https://jxnblk.com/), and it's powered by [Styled System](https://styled-system.com/).

At the time it was the right tool for the job. But the times are a changing! I now have [Wallop System](/blog/wallop-system-built-with-modulz), which is my own design system.

It's time to migrate from Rebass to Wallop System.

---

Wallop System was created, developed and deployed with [Modulz](https://modulz.app). Design systems generated by Modulz have a similar API to Styled System and [Theme UI](https://theme-ui.com), but with a few differences.

> The migration from Rebass to Wallop would be the same for any Modulz generated design system

## Props

The first class support of system props in Rebass and Wallop System are different. With Rebass, you can use the following props on all components:

- `margin`, `marginTop`, `mt`, `marginRight`, `mr`, `marginBottom`, `mb`, `marginLeft`, `ml`, `marginX`, `mx`, `marginY`, `my`
- `padding`, `paddingTop`, `pt`, `paddingRight`, `pr`, `paddingBottom`, `pb`, `paddingLeft`, `pl`, `paddingX`, `px`, `paddingY`, `py`
- `color`
- `backgroundColor`, `bg`
- `opacity`
- `width`, `minWidth`, `maxWidth`
- `height`, `minHeight`, `maxWHeight`
- `size`,
- `overflow`, `overflowX`, `overflowY`
- `display`
- `verticalAlign`
- `fontFamily`
- `fontSize`
- `fontWeight`
- `lineHeight`
- `letterSpacing`
- `textAlign`
- `fontStyle`
- `alignItems`
- `alignContent`
- `justifyContent`
- `flexWrap`
- `flexBasis`
- `flexDirection`
- `flex`
- `justifySelf`
- `alignItems`
- `order`
- `sx`

In addition to the above, the Rebass' `Tile` component also supports:

- `columns`
- `gap`

With Wallop System, you can use the following props on all components:

- `margin`, `marginTop`, `mt`, `marginRight`, `mr`, `marginBottom`, `mb`, `marginLeft`, `ml`, `marginX`, `mx`, `marginY`, `my`
- `padding`, `paddingTop`, `pt`, `paddingRight`, `pr`, `paddingBottom`, `pb`, `paddingLeft`, `pl`, `paddingX`, `px`, `paddingY`, `py`
- `sx`

### Why only three?

- **Typescript**: some system props can clash with a valid HTML attributes. For example, `size` is a valid HTML attribute of an `input` element, but it's also a system prop. System props support the responsive syntax, and HTML attributes don't. So, `<Input size={["small", "large"]}` would result in a Typescript error.
- **Best practices**: when props are first class citizens it implies that they _should_ be used, but design systems generated by Modulz have already been fully styled, so overrides should be kept to a minimum
- **Predictable**: not all system props make sense on all components. For example, passing a `fontSize` to a `Radio` wouldn't do anything, since the Radio component doesn't render a text node, but an `input`
- **Simple API**: we want to keep the API surface area simple to learn and consistent across all components

Any CSS can still be passed in via the `sx` prop, and by default the values are theme-bound, just like system props.

## In practice

Now that we've established the key API differences, let's look at how to migrate from one to another:

### Rebass

```jsx
<Box px={[4, 5, 6]} py={[4, 5]} bg="black" color="white">
  <Text as="h1" fontSize={[2, 3]}>
    JAMstack
  </Text>
</Box>
```

### Wallop System

```jsx id=one line=1,2
<Box px={[4, 5, 6]} py={[4, 5]} sx={{ bg: 'black', color: 'white' }}>
  <Text as="h1" sx={{ fontSize: [2, 3] }}>
    JAMstack
  </Text>
</Box>
```

Have a look at the [full migration PR](https://github.com/peduarte/jamstack-wtf/pull/14/) is on Github, where you can see many more examples.

I love how compatible the APIs are. I hope that one day we can have full [interoperability](https://jxnblk.com/blog/interoperability/) in UI systems.


Migrating from Rebass to Wallop System


I've often thought about creating a design system for myself. Something I could rely on for my personal website and projects. The thought of being able to build consistent user interfaces using my own system was exciting.

I had never gotten round to it, though. It always seemed too big a job and I had too many questions:

- How do I build accessible components?
- How do I keep it up to date?
- How do I structure my tokens?
- How about the Component API?
- ...and many, many more

Fast forward a few years... and I've finally done it! I've got my own design system, aptly named _Wallop System_.

In this article I'll share how I designed, developed and deployed a production-ready design system with [Modulz](https://modulz.app) — without writing code.

---

## Creating, styling and publishing

In this section, I'll go through how I created, styled and published Wallop System to npm.

### Creating a design system

First step was to create a new Design System in Modulz.

<video src="/posts/wallop-system-built-with-modulz/create-a-new-design-system.mp4" />

### Updating settings

On the design system settings page, I can update the name, style guide subdomain and manage team members - good for collabs.

<video src="/posts/wallop-system-built-with-modulz/design-system-settings-screen.mp4" />

### Configuring tokens

On the editor screen, I have access to tokens. Here I can add, remove or update tokens, from colors to font families.

<video src="/posts/wallop-system-built-with-modulz/editor-tokens.mp4" />

### Styling components

On the editor screen, I can start consuming my tokens and applying them to components. I can also create and manage variants - super powerful!

<video src="/posts/wallop-system-built-with-modulz/editor-styling.mp4" />

### Publishing

On the publish screen, I can publish my design system to npm. I can also select between a major or minor version and add release notes. Have a look at Wallop System [on npm](https://www.npmjs.com/package/@peduarte/wallop-system/).

<video src="/posts/wallop-system-built-with-modulz/design-system-publish.mp4" />

### Style guide

A documented style guide is auto generated. This will serve as documentation for anyone wishing to use my design system. Have a look at Wallop System's [style guide](https://style-guide-develop.now.sh/live?sg=VJWEuVXytSNI91xSdD4).

<video src="/posts/wallop-system-built-with-modulz/style-guide.mp4" />

---

## Consuming the generated library

In this section, I'll go through how I'm consuming Wallop System as a React library.

### Installing it

Since this is already published to npm, I can install it as a normal dependency:

```bash
yarn add @peduarte/wallop-system
```

### Wrapping it in a Provider

Then, I can wrap my app in `WallopProvider`, this makes it so all of the components are correctly bound to my tokens:

```jsx
import { WallopProvider } from '@peduarte/wallop-system';

<WallopProvider>
  <h1>Wallop!</h1>
</WallopProvider>;
```

### Importing components

I'm able to import all of my components directly from `@peduarte/wallop-system`, like this:

```jsx
import { Box, Text } from '@peduarte/wallop-system';

() => (
  <Box>
    <Text as="1">Wallop!</Text>
  </Box>
);
```

### Using system props

All components support `margin`, `padding` and `sx` props. I can use these to start laying out components on the page:

```jsx line=4,5
import { Box, Text } from '@peduarte/wallop-system';

() => (
  <Box m="5" sx={{ backgroundColor: 'black' }}>
    <Text as="h1" sx={{ color: 'gray' }}>
      Wallop!
    </Text>
  </Box>
);
```

If I want to change a value based on breakpoint, I can use the responsive syntax, like this:

```jsx line=4
import { Box, Text } from '@peduarte/wallop-system';

() => (
  <Box m={['3', '5']} sx={{ backgroundColor: 'black' }}>
    <Text as="h1" sx={{ color: 'gray' }}>
      Wallop!
    </Text>
  </Box>
);
```

This API is inspired by [Styled System](https://styled-system.com/) and [Theme UI](https://theme-ui.com/).

### Using variants

All the variants created in Modulz are available here too. Obviously. And I can use them like this:

```jsx line=5
import { Box, Text } from '@peduarte/wallop-system';

() => (
  <Box m={['3', '5']} sx={{ backgroundColor: 'black' }}>
    <Text as="h1" size="5" sx={{ color: 'gray' }}>
      Wallop!
    </Text>
  </Box>
);
```

### Demo

If youre curious to play around with the exported code, I've created a [Wallop System playground](https://codesandbox.io/s/wallop-system-playground-s1hho?file=/src/App.tsx) on CodeSandbox.

Feel free to fork it and build something with it. Make sure to refer to the [style guide](https://style-guide-develop.now.sh/live?sg=VJWEuVXytSNI91xSdD4) for documentation

---

## Conclusion

Being able to focus on the design system in one place, and then compose my screens in another felt really refreshing.

When I'm in Modulz, I'm worried about my tokens, the syling of my components, their variants, and how everything works in harmony – how a design system should be.

When I'm coding, my focus is on layout, logic and product-features. I can trust that when I import a component from my design system it works and it looks how it should.

It felt like the gap between design and development has just gotten shorter.

But most importantly, I can now answer those questions that have been hunting me for years:

### How do I build accessible components?

Modulz took care of that. I didn't have to worry about the accessibility concerns of `Tooltip`, `Tabs`, `Select` and many other complex components.

### How do I keep it up to date?

Modulz took care of that. Whenever a token is changed, all of the instaces where that token's being used get automatically updated. Publishing a new version to npm is only a few clicks away.

### How do I structure my tokens?

Modulz took care of that. I just had to choose their values.

### How about the Component API?

Modulz took care of that. All components are shipped with a consistent and documented API, I just had to worry about passing the right props.

## Thanks for reading

If you have any questions about Modulz or would like to learn more, feel free to reach out to me on the [bird site](https://twitter.com/peduarte).


Wallop System, built with Modulz


Another year, another website redesign. But this one's special.

## Tech and UI

I'm using [Next.js](https://nextjs.org/) as a foundation. If you haven't heard of it, go check it out, it's pretty cool. I've set it up using [Typescript](https://www.typescriptlang.org/) and [React](https://reactjs.org/).

I'm deploying it to [Vercel](https://vercel.com). It's great because it's fast and easy to set up.

The UI is powered by [Wallop System](https://www.npmjs.com/package/@peduarte/wallop-system). Wallop System is a design system I built with [Modulz](https://modulz.app). You can read more about this process [over here](/blog/wallop-system-built-with-modulz).

<Image src="/posts/website-refresh-2020/modulz.png" width="3016" height="1936">
  A screen shot of Wallop System in Modulz
</Image>

The code is hosted on [Github](https://github.com/peduarte/ped.ro) and you're free to take a look, get inspired or fix a bug.

## Blog

I've finally decided to start a blog. Deep down, it's something I've always wanted to do, but never got round to doing it. It was probably a mix of not knowing what to write and being lazy.

But here we are, so let's see how it goes.


Website refresh 2020


JAMstack is revolutionising the way we think about workflow by providing a simpler developer experience, better performance, lower cost and greater scalability.

Yet, you may be wondering: how? why? wtf is it?

This is why I created [https://jamstack.wtf](https://jamstack.wtf)

The goal of this guide is to gather the concept of JAMstack in a straight-forward guide to encourage other developers to adopt the workflow.
[**JAMstack WTF** - _A simple guide to help you get on the JAMstack_](https://jamstack.wtf)


WTF is JAMstack?


I’ve recently migrated Dona Rita’s website from Jekyll to Gatsby. I’d like to share my process with you, as well as a few tips about building a JAMstack site with Gatsby, Netlify and Netlify CMS.

## A bit of background

### What is JAMstack?

_JAM_ stands for **J**avascript **A**PI & **M**arkup. The term JAMstack was popularised by [Mathias Biilmann](https://twitter.com/biilmann?lang=en) (CEO & Co-founder of Netlify) to describe “a modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup”. You can read more about [JAMstack here](https://jamstack.org).

### What is Gatsby?

Gatsby is a _blazing-fast_ **Static Site Generator for React** — this is important because I wanted to keep the JAMStack I had with Jekyll. Apart from being a SSG, Gatsby is build with modern technologies, it’s future-proof, it’s a static PWA out-of-the-box and you can query your data from anywhere via GraphQL 😍

### What/Who is Dona Rita?

Dona Rita is my side business. When I’m not busy coding, I’m selling gluten-free Brazilian cheese balls to the British population 😅

## My process

The original Dona Rita website was built with Jekyll and hosted on Github Pages. It was built in an MVP approach, you can [read more about that here](https://medium.com/@OiDonaRita/starting-a-food-business-from-scratch-9baed673657c). Overall, it was working well, but let’s be honest… Liquid partials are not React components.

When I decided to change my setup from Jekyll to Gatsby, I wasn’t quite sure how much work/effort that’d be. I wanted to keep things as simple as possible. In the end I think I was able to find a nice process.

Here’s how I did it:

### Documentation

I started by reading [Gatsby’s documentation](https://www.gatsbyjs.org/docs/). They also wrote a neat [tutorial](https://www.gatsbyjs.org/tutorial/). Gatsby works differently than Jekyll, so it’s worth giving these a read first.

### Choosing a Gatsby starter

I used the [\*gatsby-starter-hello-world](https://github.com/gatsbyjs/gatsby-starter-hello-world)\*. This is probably the simplest starter you can use. I chose this because I wanted to start with bare minimum configuration. I find it easier to learn a framework this way.

### Creating a Gatsby Layout

Anything you add to a [Layout Component](https://www.gatsbyjs.org/docs/building-with-components/#layout-components) will be shared amongst all other pages. This is particularly useful for global components, such as Navigation or Footer.

You can see the source code for my [layout here](https://github.com/peduarte/dona-rita-website/blob/master/src/layouts/index.js).

### Stateless pages

I started by creating stateless [Page Components](https://www.gatsbyjs.org/docs/building-with-components/#page-components). The point here was to start getting a feel for how Gatsby creates pages, without having to worry about GraphQL.

I left stateful pages (pages that depend on data) and dynamic pages (pages that will be generated from Markdown files) for later.

The first page I added was the [Ingredients](https://www.donarita.co.uk/ingredients/) page, you can see the [source code here](https://github.com/peduarte/dona-rita-website/blob/master/src/pages/ingredients.js).

### **Adding styles**

The original Dona Rita website was styled with global CSS, written in Sass. To keep things moving, I decided to keep this approach instead of converting my styles to [Styled Components](https://www.gatsbyjs.org/docs/styled-components/).

In order for Gatsby to process Sass files, you need install [\*gatsby-plugin-sass](https://www.gatsbyjs.org/packages/gatsby-plugin-sass/) \*(drop-in support, works like a charm).

Because I needed to inject the styles globally, I imported them in my Layout file.

### Stateful pages

By now I had a few static pages rendered and styled correctly. I was becoming more comfortable with Gatsby and I was ready to create my first stateful page.

I decided to start with the [Buy Page](https://donarita.co.uk/buy). For this page I needed to get access to a list of allowed postcodes which I will be passed down to my [Product Component](https://github.com/peduarte/dona-rita-website/blob/master/src/components/Product/Product.js#L26) to determine whether we can deliver there or not.

I created a file called [postcodes.json](https://github.com/peduarte/dona-rita-website/blob/master/src/data/postcodes.json) in a src/data/ directory and installed the following dependencies: [\*gatsby-source-filesystem](https://www.gatsbyjs.org/packages/gatsby-source-filesystem/)* and [*gatsby-transformer-json](https://www.gatsbyjs.org/packages/gatsby-transformer-json/).\*

[Here’s source code](https://github.com/peduarte/dona-rita-website/blob/master/src/data/postcodes.json) for the JSON file and [here’s the source code](https://github.com/peduarte/dona-rita-website/blob/master/src/pages/buy.js#L35-L41) for the Buy page.

```json
// postcodes.json
[
  {
    "allowed": ["E1", "E11", "E12", "E14"]
  }
]
```

```js
// buy.js
export const pageQuery = query`
	query BuyPageQuery {
		allPostcodesJson {
			edges {
				node {
					allowed
				}
			}
		}
	}
`;
```

**#protip:** Gatsby has a [really nice tutorial](https://www.gatsbyjs.org/tutorial/part-four/) to help understand its data layer. Definitely worth a read.

### Components abstraction

Once most of my stateless and stateful pages were created, I took a bit of time to refactor some parts of the code. I created a src/components/ folder and added a few components to help improve maintainability of the project.

[Here’s a list](https://github.com/peduarte/dona-rita-website/tree/master/src/components) of the components I abstracted.

## Moving from GH Pages to Netlify

I was happy with Github Pages, but [Netlify](https://netlify.com) is so good, so fast, so easy to use that it’s hard to say no… it offers instant rollbacks, one-click SSL, prerendering, deploy previews, and many more awesome features.

When a new Pull Request is created, Netlify automatically generates a [Deploy Preview](https://www.netlify.com/blog/2016/07/20/introducing-deploy-previews-in-netlify/). This feature is pure gold. It allows you and other members of the team to see how the changes affect the project.

When the PR gets merged to the master branch, then Netlify triggers the production deployment. I’ve turned on [Slack Notification](https://www.netlify.com/blog/2016/07/18/shiny-slack-notifications-from-netlify/), so everyone in the team knows when a new production deployment has happened 🎉

<Image src="/posts/jamstack-gatsby-netlify-netlify-cms/slack.png" width="2432" height="1548" />

## Adding Netlify CMS

[Netlify CMS](https://www.netlifycms.org/) is an open source content management system for Git workflows. I decided to give it a try as it seemed surprisingly simple.

The way I set it up was by authenticating Netlify CMS with Github via [Netlify Identity](https://www.netlifycms.org/docs/authentication-backends/). As with anything Netlify related, it was only a couple of clicks.

I used Netlify CMS to manage my “Shops” data. The way I am managing this data is by having one Markdown file per Shop. You can see the source for the Shops page [here](https://github.com/peduarte/dona-rita-website/blob/master/src/pages/shops/index.js).

I also created a [configuration](https://www.netlifycms.org/docs/configuration-options/) file. Through this file I was able to create collections and to define which fields can be modified via the CMS.

You can see the source for Netlify config [here](https://github.com/peduarte/dona-rita-website/blob/master/static/admin/config.yml).

```yaml
# config.yml
backend:
  name: git-gateway
  branch: master

publish_mode: editorial_workflow

media_folder: static/img
public_folder: /img

collections:
  - name: 'shops'
    label: 'Shop'
    folder: 'src/pages/shops'
    create: true
    slug: '{{name}}' # this will be filename
    fields:
      - { label: 'Name', name: 'name', widget: 'string' }
      - { label: 'Area', name: 'area', widget: 'string' }
      - { label: 'Address', name: 'address', widget: 'string' }
      - { label: 'Postcode', name: 'postcode', widget: 'string' }
      - { label: 'Outcode', name: 'outcode', widget: 'string' }
```

If you’re interested in adding a CMS to your static site, I’d definitely recommend using Netlify CMS. You can read [the docs here](https://www.netlifycms.org/docs).

## Wrapping up

I’m really happy with these changes. Gatsby, Netlify and Netlify CMS are all game changers. And when used together, they work in complete harmony.

If you’re as interested in JAMstack as I do, I’d highly recommend using these tools.

If you have any advice on how anything here can be improved, please feel free to let me know 🙌

The initial Jekyll-to-Gatsby migration took me about 6 hours (including having to learn Gatsby and GraphQL).

## Source Code

The code for Dona Rita’s website is [public on Github](https://github.com/peduarte/dona-rita-website/). Feel free to browse around!

## More helpful resources and links

- [Moving to Gatsby](https://julesforrest.com/moving-to-gatsby/) _by [Jules Forrest](https://twitter.com/julesforrest)_
- [Migrate from Jekyll to Gatsby](https://www.gatsbyjs.org/blog/2017-11-08-migrate-from-jekyll-to-gatsby/) _by [Nahuel Scotti](https://twitter.com/@singuerinc)_
- [JAMstack website](https://jamstack.org/)
- [Smashing Magazine just got 10x faster](https://www.netlify.com/blog/2017/03/16/smashing-magazine-just-got-10x-faster/)
- [Image Optimization Made Easy with Gatsby.js](https://medium.com/@kyle.robert.gill/ridiculously-easy-image-optimization-with-gatsby-js-59d48e15db6e) _by [Kyle Gill](https://medium.com/@kyle.robert.gill?source=post_header_lockup)_
- Page loading bar with [*gatsy-plugin-nprogress](https://www.gatsbyjs.org/packages/gatsby-plugin-nprogress/\)\*
- Support for SASS/SCSS with [\*gatsby-plugin-sass](https://www.gatsbyjs.org/packages/gatsby-plugin-sass/)\*
- Default Netlify CMS implementation with [\*gatsby-plugin-netlify-cms](https://www.gatsbyjs.org/packages/gatsby-plugin-netlify-cms/)\*
- React Google Analytics module with [\*react-ga](https://github.com/react-ga/react-ga)\*
- Code images by [Carbon](https://carbon.now.sh)

Thanks for reading. Find me on [Twitter](https://twitter.com/peduarte) 🐤

👋

## 📣 Update

Since writing this Gatsby v2 has been released, including some awesome improvements 🎉

Please refer to the official [migration guide here](https://www.gatsbyjs.org/docs/migrating-from-v1-to-v2/).


JAMstack with Gatsby, Netlify and Netlify CMS?


This is a case study on Dona Rita and how we started a food business from scratch, knowing nothing about the food industry. Here I’ll cover our initial process, obstacles, learnings, end product and hopefully loads of tips.

<Image src="/posts/starting-food-business-from-scratch/hero.jpeg" width="1080" height="720" />

## Background

Dona Rita is a new food start-up with a mission to bring Pão de Queijo to London.

Let’s start by introducing ourselves:

- **Rita **moved to the UK with her family in 2002. Since then she’s always baked Brazilian cheese bread at home. Throughout the years she tried many different recipes until she cracked the perfect one.
- **Pedro **is Rita’s son. He works as a web developer and likes to take photos. Sometimes he [writes articles](https://medium.com/swlh/building-the-ui-for-the-new-the-times-website-26dc4e6569e) about things he builds or makes. He’s the one writing this.
- **Clara **is Pedro’s girlfriend. The idea to start this venture is hers. Being allergic to gluten meant it was pretty much impossible for her to eat nice-tasting bread. When she tried Rita’s cheese bread for the first time she could not believe they were gluten free and became obsessed with them.
- **Pão de Queijo **translates to “Cheese bread”. From now on I’ll start using this term.

## The idea

It never crossed my mind to try and make a business out of selling Pão de Queijo. I guess it’s because I grew up eating them and pretty much always had some at home that my mum used to make.

After Clara became addicted with Pão de Queijo she was always saying that we should start selling them. She was convinced that everyone would love them, and the fact that they’re naturally gluten free would change the lives of many coeliacs out there.

One morning Cara came across [this post](https://www.instagram.com/p/BKKncHVh4L1/?taken-by=alanshuster) on Instagram. It was uploaded by our friend Alan from New York, quoting:

> I can’t get enough of [#paodequeijo](https://www.instagram.com/explore/tags/paodequeijo/)

Clearly this was the moment Clara had made up her mind to introduce my mum’s Pão de Queijo to London. I guess our work started there and then. Thanks Alan 👋

## The Strategy

With a little hand from [Raphael Campos](https://www.instagram.com/raphael__campos/) we started putting together an initial strategy for our business. Why are we doing this? How are we gonna do it? Who are our competitors?

<Image src="/posts/starting-food-business-from-scratch/wall.jpeg" width="2575" height="1931" />

This helped us get a broader vision of what our branding and tone of voice would be like, who our target audience would be, where we would position ourselves in the market, etc…

It also served as a reference point, everything we did from then on should be inline with the initial strategy.

## Initial learning curve

The skillsets that Clara and I have could cover some of the work, for example: we could do the initial strategy, branding, website, social media, a bit of advertising and anything digital/tech related.

Rita knew exactly how to make the most delicious Pão de Queijo, her secret recipe was already spot on. So our product was pretty much ready.

But we didn’t now anything about the food industry. Where should we start? Apart from creating a virtual brand, how can we put it out there? What sort of licenses do we need? Can the kitchen in our home be used as the kitchen for the business? The list of questions went on…

We spent a fair amount of time researching, reading articles and figuring out the right way to get this business going. And this was the biggest learning curve for us.

**Note **you can find all the links I’ve found helpful at the end of this article.

## Minimum Viable Product

As this is a side project Clara and I decided to go MVP with everything. We only had a couple of hours each week day and the weekends to work on this, so time was precious.

When building your own product, it can be quite easy to become emotionally attached to it and allow perfectionism to get in the way of productivity. We had learned that from our day jobs and decided to apply our learnings to this. We started with something that we liked and shipped it. If needed we could always go back and iterate.

### Name

One of our first tasks was to choose a name. We shared ideas with our friends, as we thought this was a great way to come up with a name. In the end we decided to go ahead with **Dona Rita**, thanks to our friend Kaue 👍

### Branding

Clara took a weekend to work on the branding. That was enough to get us going. We had a temporary logo, a typeface, a slogan and a colour palette.

### Photography

We did a mini-photoshoot that took roughly 4 hours. My mum came round and we baked some Pão de Queijo, luckily for us the weather was good and the perfect amount of sun was shining through our window. The natural light helped give the photos a really nice colour and tone.

<Image src="/posts/starting-food-business-from-scratch/shoot.png" width="1260" height="1062" />

At the end we had about 12 photos that would serve as our initial content for social media and the website 🎉

### Website

It took us about two days to have something live. We considered using a [Squarespace](https://www.squarespace.com/) or [Wordpress](https://wordpress.com/) theme but ended up using a simple custom solution. At this stage we didn’t have much content and we weren’t ready to sell online. We went with a one page approach, where all your content lives on one page rather than many different pages with little content. Clara designed the website in [Sketch](https://www.sketchapp.com/) and I built in [Atom](https://atom.io/). I bought the domain on [Namecheap](http://namecheap.com/) and hosted the site on [Github Pages](https://pages.github.com/).

Overall, the website was well received. It even had the pleasure of being featured on some [inspirational](http://thegallery.io/inspirations/dona-rita) [websites](https://onepagelove.com/dona-rita):

> Lovely, minimal One Pager promoting the “Brazilian Cheese Bread” by Dona Rita. A good reference to how less-is-more with only 4 quality (well selected) images used in the whole site.
>
> — onepagelove.com

### Packaging

Here’s where things started to get a little trickier. Packaging consists of two parts — the design and the physical packaging. Although they’re different, they’re closely dependant on each other.

We decided to go with a “Stand up pouch” type of packaging and we spent a few hours researching where to buy them from. We started off by trying to buy them from websites such as AliExpress or Alibaba but their Minimum Order Quantity (MOQ) was too high for us. So in the end we found some decent UK based companies (will share the links at the end).

Ideally we wanted to have the branding printed on the packaging, however the MOQ struck again. In order to do that the we’d have to purchase a hell of a lot of pouches. So our MVP solution was to go with a label and manually stick them on the pouches.

We also had some help from the great guys at [Granola for Gangsters](http://granolaforgangsters.com/) who gave us the name of the companies they were using for their packaging. Be sure to check them out!

<Image src="/posts/starting-food-business-from-scratch/packaging.jpeg" width="1080" height="1350">
  An actual photo of our bake-at-home pack
</Image>

### MVP conclusion

We found that the important thing is not to be blocked. Sometimes you may not be satisfied with how things are turning out, but progress is important. As long as you can keep moving you can always go back and improve.

## User testing

<Image src="/posts/starting-food-business-from-scratch/ux.png" width="1162" height="1058">
  Packaging user testing
</Image>

Our initial users were our friends. Every step of the process so far we asked them for their opinion. We created different spreadsheets for different topics where we kept a record of their response. We always chose the most voted option.

Getting opinions from others proved to be very helpful to us. The main thing is to try and detach yourself from the things you are testing and take every criticism into account.

## Product awareness

In order for people to want to buy our product, they needed to know what it was. So we had to find a way to introduce a brand new product to the UK.

### Digital appearance

We created [Instagram](http://instagram.com/oidonarita), [Twitter](http://twitter.com/oidonarita) and [Facebook](http://facebook.com/oidonarita) profiles, started sharing some posts and followed some people who we thought might be interested in our product. After some time, we started getting some followers that were within our target audience. Other Instagram users shared photos of our product (thanks so much [theglutenfreesuitcase](https://www.instagram.com/p/BS56Q3PjMx7/?taken-by=theglutenfreesuitcase), [eatnlondon](https://www.instagram.com/p/BTget_rBgF6/?taken-by=eatnlondon), [myglutenfreeguide](https://www.instagram.com/p/BThWPUuAuzZ/?taken-by=myglutenfreeguide), [lorileysesh](https://www.instagram.com/p/BT55b-lAfIW/?taken-by=lorileysesh), [scottcaneat](https://www.instagram.com/p/BUHneCAFewz/?taken-by=scottcaneat)) and this helped spread the word.

### Physical appearance

We contacted some [WeWork](https://www.wework.com/l/london) offices and arranged to do some pop ups there (thanks for the tip Marina). The idea of doing those pop ups was to get a little bit of experience on how to bake them at a larger scale and to gather feedback from people.

<Image src="/posts/starting-food-business-from-scratch/hero.jpeg" width="2400" height="1600">
  Our first ever pop up at WeWork Chancery Lane
</Image>

Then after contacting some food markets, we heard back from [Druid St Market](http://www.druid.st/). We went there to demo our product to [Miranda](https://twitter.com/mirandayork_) who’s running the show. After doing a trial period of 2 weeks, she offered us a permanent spot and now we’re trading there twice a month.

<Image src="/posts/starting-food-business-from-scratch/stall.jpeg" width="1080" height="720">
  Our first ever food street market at Druid Street
</Image>

Finally, we rented a stall at Old Street Station for 2 weeks. This is where we are right now (as of the time of writing this). This is by far the biggest event we’ve done so far. It’s so intense that I’ll dedicate a whole post just for it.

<Image src="/posts/starting-food-business-from-scratch/oldstreet.jpeg" width="2639" height="1956">
  Our first ever... pop up in a tube station?
</Image>

## Press

We wrote a [Press Release](http://donarita.co.uk/pr) and sent it out to some journalists. Luckily for us we had a couple of mentions that really helped us get some awareness. The Sunday Times posted a photo on their [Instagram](https://instagram.com/p/BTo1qaajvIP/), Evening Standard wrote [an article](http://www.standard.co.uk/goingout/restaurants/p-o-de-queijo-in-london-brazilian-cheese-bread-comes-to-old-street-a3530296.html) and Timeout London also [wrote one](https://www.timeout.com/london/blog/a-brazilian-cheese-balls-pop-up-is-coming-to-london-050917).

> Pão de Queijo. ‘What’s that?’ I hear you cry. A wheat-free Brazilian cheese bread, duh: a staple snack found across the country, made from cassava flour and cheese, a crunchy outside giving way to a cloud-like interior. Sounds ace, right? Right
>
> — Timeout London

## **Where can I try it? I want some!**

Great! You can now buy via [our website](http://donarita.co.uk/buy) but we’re currently only delivering to certain areas of London (MVP) as we’re having to do the deliveries ourselves.

You can also find us at:

### Druid Street Market

We trade at this lovely food market twice a month. We always announce the dates on our [website](http://donarita.co.uk) and [social media](http://instagram.co.uk/oidonarita).

### **Old Street Station Underground**

We’re here until the 20th May! Check out our [Instagram](http://instagram.com/oidonarita) for opening times and updates.

### Free from and Allergy Show

From the 7th till the 9th of July 2017. We’ll be exhibiting at the [Allergy and Free From Show](http://www.allergyshow.co.uk/london/) at the Olympia Grand in London.

## Helpful links

If you are here because you’re starting your own food business I hope the links below can save you some time and headache:

### Articles

- [Start up guide by Gov.uk](https://www.food.gov.uk/sites/default/files/multimedia/pdfs/publication/starting-up-booklet.pdf)
- [How to start a street food business](http://www.thejabberwocky.co.uk/how-to-start-a-street-food-business/)
- [Getting started in Street Food](http://www.streetfood.org.uk/start-a-street-food-business.html)

### Tools

- [Github](http://github.com) — I used this as a Task Management tool, Version control repository and hosting provider. But feel free to use your preferred set up. If this is outside your area, then I recommend at least using [Trello](https://trello.com) as a task management tool, it’s a simple and very powerful tool.
- [Sketch](https://www.sketchapp.com/) — Clara’s design tool of choice 👌

### Packaging

- [Swisspac Pouches](http://swisspac.co.uk/‎)
- [Pouch Direct](https://www.pouchdirect.co.uk/)
- [Labels](https://www.flyeralarm.com) (they also offer many more things)
- [Nutritional Information](http://www.nutritionalinformationsolutions.com/)

### Certificates

- [Food hygiene certificate](https://www.food-hygiene-certificate.co.uk/)

### Accountancy

- [FreeAgent](https://www.freeagent.com/) — we’re using [Chandler Wells](http://www.chandlerwells.co.uk/) as our accountant and it comes with a FreeAgent subscription.

## Credits

We’d like to say a huge thank you 💛 to everyone who helped us, gave us advice, tips, shared with their friends.

## Stay in touch

This is just the beginning and if you want to tag along, follow us on [Instagram](http://instagram.com/oidonarita), [Twitter](http://twitter.com/oidonarita) or [Facebook](http://facebook.com/oidonarita). If you want to chat, you can email us at [oi@donarita.co.uk](mailto:oi@donarita.co.uk)

<Image src="/posts/starting-food-business-from-scratch/thanks.jpeg" width="1280" height="1366" />


Starting a food business from scratch


The shiny new The Times and The Sunday Times has just been released. I thought it would be a good idea to write an article about the UI structure.

My name is [Pedro Duarte](http://pedroduarte.me) and I’m a front-end developer specialising in UI and user experience. News UK hired me to focus on the UI development overhaul of the new The Times & The Sunday Times websites. And for the last year, this is what I’ve been up to…

In this article, I will write about the following:

- Overview
- Collaboration
- UI Structure
- CSS
- Refactor
- Visual QA
- Styleguide
- Conclusion

## Overview

The redesign of The Times and The Sunday Times is all about content. It is about showing the right piece of news in its dedicated amount of space on the screen. The challenge of keeping this sort of strict hierarchy in a responsive layout determined by content can be difficult.

Redesigning and rebuilding a new website for such a large organisation is not an easy task. I don’t mean this in a technical sense. With so many people who care about the product, conflicting opinions and ideas are part of day-to-day. The key here is to not let yourself become emotionally attached to your code. [Kill your babies](http://www.urbandictionary.com/define.php?term=kill+your+babies).

## Collaboration

To build the UI in the most appropriate way, I wanted to _really_ understand the design. The first thing I did was sit down and go through all the designs with [Kyle Wheeler](https://uk.linkedin.com/in/kyle-wheeler-a7a1a717) — the lead designer of the project.

<img src="/posts/building-the-ui-for-the-times/wall.jpeg" width="1816" height="1054" />

We printed and annotated the designs, creating a common language between design and tech. This would help us communicate better and establish consistency through our components.

By working closely with the design team I was able to define the UI structure, especially for the homepage.

Collaborating with visual and UX designers is such an important step! I ❤ collaboration.

## **UI Structure**

The goal was to keep the UI structure as simple as possible. Unfortunately this is not as easy as it seems but I’m confident that we’ve achieved an impressive level of simplicity.

The UI is separated into Components, Modules and Global elements.

### **Components**

Components are very low level, they can be used in a variety of different places and in different context. Ideally, we’d want a component to have very similar rendering wherever it’s used. Components don’t usually have a heavy impact on the layout. For example, a component wouldn’t necessarily be aware of how many grid columns it is spanning.

Examples of Components are:

- Buttons

- Labels

- Headlines

### **Modules**

Modules are more complex than Components. Modules can have a significant impact on layout, they are usually aware of how they sit on the grid and how they need to respond on different breakpoints. Modules are not always reusable, for example, the Global Nav module will only ever be used once.

Examples of modules are:

- Sections

- Slices & Slice Items

- Related links

- Key facts

### **Globals**

Global files are where we would set some default rules for certain elements, utility helpers and variables.

### Markup

There are two different ways to use a Component:

1. Good ol’ plain HTML
   As our Components are essentially “CSS classes”, you can use it by writing HTML with the right class(es).

1. Component helper
   We are using [Dust.js](http://www.dustjs.com/) as our templating language as it can render our views on the server and client side. Dust.js allows us to create custom helpers, so we took advantage of this to create an uiComponent Helper.

In the following snippets, I share the Dust.js uiComponent Helper

```js
/**
 * Function to render a ui component
 * @param  params - any available parameters allowed
 * @param  params.name
 * @return {partial}
 */
dust.helpers.uiComponent = function (chunk, context, bodies, params) {
  var name = context.resolve(params.name);
  return chunk.partial('components/' + name + '/' + name, context, params);
};
```

Here’s is an example of including components as HTML and via the Dust.js Helper:

```liquid
<div>
  <h2 class="Headline Headline--m">News headline</h2>
  {@uiComponent name="byline" text="Tim Shipman, Political Editor" /};
  {@uiComponent name="dip" text="First paragraph of news content will go here..." /};
  {@uiComponent name="link" text="Read full story" modifider="primary" /};
</div>
```

Having a uiComponent Helper is great because it ensures that every instance of each component will be using the exact same markup. Furthermore it creates a single source of truth for each component and if we need to update the markup, we only need to update one file.

## CSS

I wanted to share with you some of the CSS structure we utilised and the approach we took.

### **Naming convention**

For the CSS naming convention we are using [SUIT CSS](https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md). Here are some examples of SUIT CSS syntax:

```
ComponentName
ComponentName--modifierName
ComponentName-descendentName

is-*
u-*
```

We have also slightly extended it to support the following classes:

```
has-*
no-*
js-*
```

### **Breakpoints**

We tried to keep the number of breakpoints down to a minimum to avoid unnecessary complexity, however, we wanted a flexible solution which would allow us to scale up, or define custom breakpoints if a specific module needed one.

As we decided to use [Susy 2](http://susy.oddbird.net/) to power our grid system, the way we define the breakpoints is using a mixin called [susy-breakpoint](http://susydocs.oddbird.net/en/latest/toolkit/#susy-breakpoint), this is built on top of the famous [Breakpoint](http://breakpoint-sass.com/) Sass plugin.

Below is a snippet of our breakpoints:

```scss
// Defining breakpoints
$bp-medium: 768px !default;
$bp-wide: 1024px !default;

// Defining container widths
$container-medium: 860px !default;
$container-wide: 1024px !default;
```

And here is an example of our Susy settings:

```scss
// Defining grid columns
$g-small: 6 !default;
$g-wide: 12 !default;

// http://susydocs.oddbird.net/en/latest/settings/
$susy: (
  columns: $g-small,
  gutter-position: inside,
  gutters: 0,
  global-box-sizing: border-box,
  debug: (
    image: hide,
    color: rgba(blue, 0.1),
  ),
  use-custom: (
    box-sizing: false,
  ),
);

$susy-medium: $container-medium $g-wide (0) inside;
$susy-wide: $container-wide $g-wide (0) inside;
```

We also created some helper mixins to help us use the mixins easily and efficiently. Below is an example of our breakpoint settings:

```scss
// Defining media query helpers
// Aliases for susy-breakpoint
// http://susydocs.oddbird.net/en/latest/toolkit/#breakpoint
@mixin medium {
  @include susy-breakpoint($bp-medium, $susy-medium) {
    @content;
  }
}

@mixin to-medium {
  @include susy-breakpoint(0 ($bp-medium - 1), $susy-small) {
    @content;
  }
}

@mixin medium-only {
  @include susy-breakpoint($bp-medium($bp-wide - 1), $susy-medium) {
    @content;
  }
}

@mixin wide {
  @include susy-breakpoint($bp-wide, $susy-wide) {
    @content;
  }
}

@mixin to-wide {
  @include susy-breakpoint(0 ($bp-wide - 1), $susy-wide) {
    @content;
  }
}

@mixin wide-only {
  @include susy-breakpoint($bp-wide($bp-huge - 1), $susy-wide) {
    @content;
  }
}
```

### **Grid**

The grid is powered by [Susy 2](http://susydocs.oddbird.net/en/latest), if you haven’t heard of it, I’d highly recommend you go check it out. In the past, I’ve built dozens of grid systems from scratch, but in this case, using Susy has saved tons of time. Susy is extremely flexible, you can literally build any grid you want on top of it, Susy just does the maths!

I created some mixins around the default Susy API though, as I wanted a custom setup to support a fallback for browsers without flexbox support. More on this in a bit.

The grid is pretty straight forward, it’s 6 columns on mobile and 12 columns on larger devices.

Here is a demo usage:

```scss
@mixin tt-span($pattern) {
  width: span($pattern);

  // For no flex browsers...
  .#{$no-flex} & {
    float: left;
  }
}
```

```scss
/**
 * dummy-module.scss
 *
 * This example shows a module which spans:
 * 3 columns on mobile (mobile first approach)
 * 4 columns on tablet
 * 3 columns on desktop
 */

.DummyModule {
  @include tt-span(3);

  @include medium {
    @include tt-span(4);
  }

  @include wide {
    @include tt-span(3);
  }
}
```

### **Slices and Slice Items**

The homepage of The Times is essentially a combination of different Slices. We created about 20 different variations that will display news content in a different way, based on number of stories and importance.

**Slices
**A slice is simply an element that wraps a Slice Item. Slices are built to be as dumb as possible.

**Slice Items
**A Slice Item must always live inside a Slice element. Essentially, a Slice Item is where the news content lives. Each Slice Item is extended with a Slice Item Identifier, these identifiers are also used in the designs, you’ll see them labeled below as _Nl1, T2, S1a, T1, etc_.

Below is an example of how Slices and Slice Items look like in their simplest form.

<img src="/posts/building-the-ui-for-the-times/slices.jpeg" width="2264" height="2000" />

Using the pattern above meant we could have a consistent structure for all the slice items and a very simple approach.

The code below demonstrates how to replicate the **first Slice** (*NL1 + T2) *from the design above into code:

```html
<div class="Slice">
  <div class="Item NL1"></div>
  <div class="Item T2"></div>
</div>
```

```scss
/**
*
* NL1 Module
*
**/

.NL1 {
  @include medium {
    @include tt-span(9);
  }

  @include wide {
    @include tt-span(10);
  }
}
```

```scss
/**
*
* T2 Module
*
**/

.T-2 {
  @include medium {
    @include tt-span(3);
  }

  @include wide {
    @include tt-span(2);
  }
}
```

As mentioned above in the **Grid** section, it consists of 12 columns for Medium and Wide breakpoints. With that in mind, all we need to do in the CSS is to specify how many columns each Slice Item spans, bearing in mind the addition of the columns must equal 12.

In plain english, the code above is doing this:

**NL1 Slice Item\***
\*Medium breakpoint = 9 columns
Wide breakpoint = 10 columns

**T2 Slice Item\***
\*Medium breakpoint = 3 columns
Wide breakpoint = 2 columns

For mobile both modules span 100%. Here’s a GIF illustrating the final result:

<img src="/posts/building-the-ui-for-the-times/slices-gif.gif" width="2264" height="1500" />

## Refactor

Refactor, refactor, refactor… in my opinion this is by far the most crucial step to get things done right. Adding a refactoring step to our process meant that we could clean up after ourselves. It’s common that the first time you write some code, it’s not going to be perfect or it’s not going to reflect the logic very well. By giving yourself some time to refactor your code, you can make the code more concise, optimised and maintainable.

## Visual QA

Another really important step in our process is to do Visual QA. This is basically as simple as sitting down with a designer and going through the UI components, making sure they’re looking and working as expected. This is a great workflow, because it means you can build the component as per the design, but it allows you to “refine in the browser”. It really doesn’t take a long time to do Visual QA, as the changes expected from this are minimal, but it does make a huge difference in the overall result.

## Styleguide

With every great build there is a [Styleguide](http://www.thetimes.co.uk/styleguide/). It is currently WIP, but you can get an idea of our components and how they can be used.

## Conclusion

Websites like The Times will be live for many years to come and who knows how many developers will work on it, so setting up the initial structure can be scary. By defining a convention and a structure you can make it much more maintainable and scalable.

A huge benefit of creating Components and Modules is that your code is encapsulated. In my opinion, this is one of the most important things about large builds. It ensures that a change in a specific CSS file will only affect that Component/Module and not have any side-effect on other elements.

Overall, the approach used in this project is extremely simple. What makes it powerful is how we structure our code. Choosing a naming convention and going for a component based approach will automatically forced us to think in a more object oriented way.

And finally, here are some screenshots of the live [version](http://beta.thetimes.co.uk):

<img src="/posts/building-the-ui-for-the-times/homepage.jpeg" width="2600" height="1569" />

<img
  src="/posts/building-the-ui-for-the-times/homepage-responsive.jpeg"
  width="2620"
  height="1604"
/>

Thanks for reading. Find me on [Twitter](https://twitter.com/peduarte) 🐤

👋


Pedro Duarte

I'm a UI developer interested in design systems, jamstack, user/dev experience and under engineering.

Writing

PD