Tag: Open

How Building in the Open Can Change Our Industry

I have to admit, I’m a developer who hasn’t built a website. When I first read Chris’s question, I sat in silence for at least a minute. Which technical topic did I want to discuss? A new library, programming language or best practice? Nothing, in particular, came to mind. Is that because I’m a new developer?

I’ve been coding for about one year now and got my first job a month ago. Even though I’ve been coding for that time, I wouldn’t say I’ve built a website. I’ve contributed to a couple of open-source projects whose output was websites, but I’ve spent a lot of time practicing technical tests in order to get into the industry and now I’m writing Kotlin for the Guardian Newspaper’s Android application.

After a couple minutes thinking about this question, I realized I wanted to write about who gets to build websites and how and where we choose to build them in order to welcome new people. I’ve spent this year giving conference talks on this topic because I have first-hand knowledge of what it’s like to become a developer with little time and money. It’s not easy being on the “outside” trying to get into our industry. How can we make it easier for new people to join us here? How can we welcome under-represented groups to the table? In 2020 you can make a huge difference to our industry by welcoming new developers, especially those from under-represented groups.

It’s been five years since the most well-known tech companies first released diversity reports, revealing that workforces were overwhelmingly white or Asian men. Despite their business successes, though, none of these big tech companies have made much progress in diversifying their workforces.

In 2014, Apple, one of the largest tech companies by revenue, had 20% women in its technical staff. This increased to only 23% in 2018 (Apple). At Google, the share of US technical employees who are black was 2.0% in 2014 and only rose to 2.8% in 2018 (Google). At Facebook in the US, there were 3% Hispanic technical staff in 2014. Last year there were 3.1% (Facebook).

Continuing our homogenous engineering community is a risk. We are less likely to build products best for our diverse user groups. For example, there have been numerous reports of facial recognition systems misidentifying black people. A US Government study found a top-performing system misidentified black people 5-10x more than white people. In addition, “according to a 2011 study by the National Institute of Standards and Technologies (Nist), facial recognition software is actually more accurate on Asian faces when it’s created by firms in Asian countries, suggesting that who makes the software strongly affects how it works” (Guardian 2017).

Thankfully, there are a number of things you can do in 2020 to contribute to a more diverse engineering community. Building websites in the open, in ways that welcome new people, can have a hugely positive impact on our industry and on the websites that we as an engineering industry produce.

First, how can building open source websites help us welcome new people? You can help with this by being a great open-source citizen and upholding best practices by giving positive and constructive code reviews, keeping documentation up to date and useful, offering help to new contributors and remote pairing with them if at all possible. Some amazing developers like Suz Hinton (@noopkat) live stream their open source contributions, which is phenomenal.

GitHub’s research has shown that documentation is highly valued, but frequently overlooked. As a new contributor, I really value clear and useful documentation, especially on installation, raising a PR and where to get help if I get stuck. Mozilla found that the most significant barrier to engaging in on-ramping others is unclear communications and unfriendly community. Using positive language in your documentation can really encourage first-time contributors to your project. For example, by expressly indicating that you welcome new contributors with instructions on how they can get involved.

We want to create an engineering community highly attractive to under-represented groups. One of the ways that we can do this is by supporting new developers to get a foothold into the profession. There are so many ways we can do this!

The first thing we can do with new developers is to help them by pairing and giving code reviews. Open source projects are perfect for this! By giving constructive code reviews you can help newbies level up their coding skills. You can also set up a Slack channel for your repo where you can answer technical questions. I have met superstar open source heroes who spent time pairing with me, which, if available to you, is an amazing way to help new people.

The greatest challenge I faced when teaching myself to code was finding a job. You can give new developers an insight into your company or your day to day working life by writing an article on Medium, posting a Twitter thread, or making a YouTube video. Some developers offer their own office hours which they do on a live stream or some offer a few one-off mentoring calls with new developers.

Who we welcome into the room to build websites with us says something about who we are and our values. In 2020, let’s welcome new people, especially those from under-represented groups to join us. We’ve discussed how amazing open-source projects are for this and how we can practically contribute to supporting new people. Let’s challenge ourselves to support at least one person from an under-represented group trying to get into the engineering industry in 2020. Together we can change who has the privilege to build the web.

The post How Building in the Open Can Change Our Industry appeared first on CSS-Tricks.

CSS-Tricks

, , ,

Netlify CMS Open Authoring

I like the term “Git-backed CMS.” That term works for an emerging style of CMS that looks and behaves much like any other CMS, with a fascinating twist: it doesn’t actually store any data for you. These CMSs are connected to a Git repo where the data lives in flat files (e.g. Markdown). You teach the CMS where those files are and how they are structured. Then, as you use the CMS to create, edit, and delete things, those changes happen has commits (or pull/merge requests) are made against that repo. So cool.

For example, CloudCannon can do it specifically for hosted Jekyll sites.

But more in the Indie Web / JAMstack spirit, there are players like Forestry and the one I have the most experience with: Netlify CMS.

Lemme do a series of screenshots with captions to make the point very clear.

The site in question is our Serverless site. It happens to be Gatsby, but the important part is that that the content comes from Markdown files in a Git repo.
Here’s an example Markdown file (with Frontmatter) in the repo. I like Markdown fine, but I’d prefer to work with content in a GUI CMS honestly. The reason I went this way is so the data is in a repo, meaning I can take content-based pull requests.
I really do get content-based pull requests. That’s the magic right there. That’s exactly what I want.
Netlify CMS is basically two files. An index.html that loads up a SPA interface that literally does everything. And a configuration file to teach it about your content.
With Netlify CMS in place, I have my GUI CMS happy place. Any changes in here turn up as commits on the repo.

OK OK OK. What’s this “Open Authoring” thing?

As I write, it’s a beta feature.

Here’s the main thing: I can use Netlify CMS for my site. My team can also use it, because I can invite them specifically to the repo. But you, random person on the internet, cannot. If you wrote to me and told me you wanted to be a volunteer content manager on the site, then maybe, OK, I’ll invite you to the repo. (You being a member of the repo will allow you to auth into Netlify CMS, assuming you are using the GitHub back end, which is the only connection Open Authoring works with right now.)

But that’s a bummer that random internet people can’t submit pull requests on content via Netlify CMS. That would be way easier than the manual process of forking the repo and all that jazz — although to be fair, click the little pencil icon while looking at a Markdown file on GitHub and editing it makes the process pretty simple by opening a pull request automatically (but it doesn’t help you add new content or upload images or anything).

This is where Open Authoring comes in. In my Netlify CMS config I can basically flip it on with one line of config. They explain it well:

you can use Netlify CMS to accept contributions from GitHub users without giving them access to your repository. When they make changes in the CMS, the CMS forks your repository for them behind the scenes, and all the changes are made to the fork. When the contributor is ready to submit their changes, they can set their draft as ready for review in the CMS. This triggers a pull request to your repository, which you can merge using the GitHub UI.

Emphasis mine.

Wanna see the real beauty of this? Now we can put “Edit this” buttons on all the content, and if you click it, you’ll head straight into Netlify CMS to do the editing. It works if you are me, my team member, or you, random person from the internet.

That’s what I’ve always wanted. It makes the site into a wiki! But there is enough public accountability (they have to use a real GitHub account) that I wouldn’t worry about much spam or obnoxious behavior.

The post Netlify CMS Open Authoring appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

What happens when you open a new install of browsers for the 1st time?

Interesting research from Jonathan Sampson, where he watches the network requests a browser makes the very first time you launch it on a fresh install, and otherwise do nothing. This gives you a little insight into what kind of information that browser wants to collect and disseminate.

This was all shared as tweets, but I’m linking to an unrolled thread if there’s one available:

Looks like Brave is the cleanest and the most questionable is… Opera?

Direct Link to ArticlePermalink

The post What happens when you open a new install of browsers for the 1st time? appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Prevent Page Scrolling When a Modal is Open

Please stop me if you’ve heard this one before. You open a modal, scroll through it, close it, and wind up somewhere else on the page than you were when you opened the modal.

That’s because modals are elements on a page just like any other. It may stay in place (assuming that’s what it’s meant to do) but the rest of page continues to behave as normal.

See the Pen
Avoid body scrollable in safari when modal dialog shown
by Geoff Graham (@geoffgraham)
on CodePen.

Sometimes this is a non-issue, like screens that are the exact height of the viewport. Anything else, though, we’re looking at Scroll City. The good news is that we can prevent that with a sprinkle of CSS (and JavaScript) trickery.

Let’s start with something simple

We can make a huge dent to open-modal-page-scrolling by setting the height of the entire body to the full height of the viewport and hiding vertical overflow when the modal is open:

body.modal-open {   height: 100vh;   overflow-y: hidden; }

That’s good and all, but if we’ve scrolled through the <body> element before opening the modal, we get a little horizontal reflow. The width of the viewport is expanded about 15 pixels more, which is exactly the with of the scroll bar.

See the Pen
Avoid body scrollable in safari when modal dialog shown
by Geoff Graham (@geoffgraham)
on CodePen.

Let’s adjust the right padding of the body a bit to avoid that.

body {   height: 100vh;   overflow-y: hidden;   padding-right: 15px; /* Avoid width reflow */ }

Note that the modal needs to be shorter than the height of the viewport to make this work. Otherwise, the scroll bar on the body will be necessary.

Great, now what about mobile?

This solution works pretty great on desktop as well as Android Mobile. That said, Safari for iOS needs a little more love because the body still scrolls when a modal is open when tapping and moving about the touchscreen.

We can set the body to a fixed position as a workaround:

body {   position: fixed; }

Works now! The body will not respond when the screen is touched. However, there’s still a “small” problem here. Let’s say the modal trigger is lower down the page and we click to open it up. Great! But now we’re automatically scrolled back up to the top of the screen, which is just as disorientating as the scrolling behavior we’re trying to resolve.

See the Pen
Avoid body scrollable in safari when modal dialog shown
by Geoff Graham (@geoffgraham)
on CodePen.

Boo!

That’s why we’ve gotta turn to JavaScript

We can use JavaScript to avoid the touch event bubble. We all know there should be a backdrop layer when a modal is open. Unfortunately, stopPropagation is a little awkward with touch in iOS. But preventDefault works well. That means we have to add event listeners in every DOM node contained in the modal — not just on the backdrop or the modal box layer. The good news is, many JavaScript libraries can do this, including good ol’ jQuery.

Oh, and one more thing: What if we need scrolling inside the modal? We still have to trigger a response for a touch event, but when reaching the top or bottom of the modal, we still need to prevent bubbling. Seems very complex, so we’re not totally out of the woods here.

Let’s enhance the fixed body approach

This is what we were working with:

body {   position: fixed; }

If we know the top of the scroll location and add it to our CSS, then the body will not scroll back to the top of the screen, so problem solved. We can use JavaScript for this by calculating the scroll top, and add that value to the body styles:

// When the modal is shown, we want a fixed body document.body.style.position = 'fixed'; document.body.style.top = `-$  {window.scrollY}px`;  // When the modal is hidden, we want to remain at the top of the scroll position document.body.style.position = ''; document.body.style.top = '';

This works, but there’s still a little leakage here after the modal is closed. Specifically, it appears that the page already loses its scroll position when the modal is open and the body set to be fixed. So we have to retrieve the location. Let’s modify our JavaScript to account for that.

// When the modal is hidden... const top = document.body.style.top; document.body.style.position = ''; document.body.style.top = ''; window.scrollTo(0, parseInt(scrollY || '0') * -1);

That does it! The body no longer scrolls when a modal is open and the scroll location is maintained both when the modal is open and when it is closed. Huzzah!

See the Pen
Avoid body scrollable in safari when modal dialog shown
by Geoff Graham (@geoffgraham)
on CodePen.

The post Prevent Page Scrolling When a Modal is Open appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]