Technical Writing Samples

This is a small collection of my technical writing document experience, and I'll be adding to it to flush it out more fully!

Bandzoogle Help Article Examples

When I was hired at Bandzoogle, one of my primary tasks was to rewrite the entire knowledgebase and help section. I worked with our Founder and Head of Support to create a style guide, tone, determine the best practice for article organization, and continued to be responsible for all help article content over the next four years.

I was responsible for writing tutorial content, inputting it into our proprietary knowledgebase system in markdown, creating and collecting graphics and screenshots, and keeping articles up-to-date with resulting changes.

How do I verify my site with Google or YouTube?

You can verify your site with Google Webmaster Tools, which will give you more information on which keywords Google associates with your site, see top search queries for your domain, see sites that are pointing back to yours, and more! Here's how to verify your site with Google:

  • Go to Google Webmaster Tools and enter your website's address in the field provided. Next, click the Add Property tab
  • On the next page, select the Alternate methods tab
  • Select HTML tag and copy the code text displayed
  • Come back to your Bandzoogle account, click the Edit content button. Scroll down to select Site-Wide Settings
  • In the left-hand menu, select Sitemaps
  • Next to Google verification, paste in your meta tag from Webmaster Tools and click Save.
  • Once you've saved the metatag information in the sitemap, return to Google Webmaster Tools and click Verify.

You can use this section to verify other Google products, like YouTube, Adwords, Google Apps, and more. Once one Google product has been verified, you can replace the tag in your control panel to verify a new service using the same steps. We have a video tutorial of these steps as well, for a visual walk through these steps!

How do I import my full WordPress blog feed?

If you've previously hosted your blog on WordPress, it's easy to import your history of posts to your website here!

  • First, log in to your WordPress account
  • Then in the left-hand menu of your WordPress site, move your cursor over Settings, and then click on Reading
  • Under the Syndication feeds show the most recent section, update that to the number of blog posts you have on WordPress. This will allow us to then import your whole post history!
  • Once that is set up, come back to your Bandzoogle account
  • Select the Page you'd like the Wordpress feed to display on, click the Add Feature button, and choose the Blog feature
  • Place it on the page where you'd like it to display
  • Enter a blog title and choose External feed
  • Click Add Blog Feed. Enter a name to identify your blog feed (this is not visible on the front end, so you can name it something like "Wordpress feed" to easily note the differences in blogs when editing your site.)
  • Select the blog feed setup
  • Click Save. Your full feed will display there for you!

How do I create a 301 redirect?

What is a 301 redirect?

A 301 redirect is a permanent redirect from one web page on your domain to another. So when a page link is visited, either directly by a visitor or a search engine, they will instantly be redirected to another page on your site.

Why would I use it?

You would utilize a 301 redirect if you’ve recently moved to Bandzoogle, and have an old page address with your previous host that ranks high in a search engine like Google. Adding a 301 redirect of the page on your previous host will direct both visitors and search engines to your new pages here.

For example, if you had a page on your site like http://yoursite.com/audio/music.php that ranks very high in a search, you could add a 301 redirect from that page to your new Bandzoogle page https://yoursite.com/music.

This would make sure that anyone who had http://yoursite.com/audio/music.php bookmarked can still access the page without an error, and would be directed to your new https://yoursite.com/music page.

Searches like Google recognize 301 redirects as well. So instead of broken links displaying in a search, and having to wait until Google re-indexes your site, adding a 301 will make sure that your site links keep working in a search result.

You can also use 301 redirects to provide addresses for visitors different from your page name. For example, if you wanted to share a link with your fans called https://yoursite.com/shows but already had a similar page called https://yoursite.com/events, you could add a 301 redirect from /shows to /events.

How do I add a 301 redirect?

To add a 301 redirect in your Bandzoogle account:

  • Click Edit content
  • Choose the Pages button, and click on the pencil to the right of the page you want to add a 301 redirect for
  • Here, choose Advanced settings
  • Enter the redirect path, like yourfolder/yourfilename.php
  • Click Save

Requirements to use 301 redirects

  • You must have a domain pointing correctly to your site in order to add 301 redirects.
  • You cannot redirect to pages that already exist in your Bandzoogle site. 301 redirects can only be applied to main pages in your site in Edit content - they can’t be applied to pages generated by features, like a blog feature.
  • You can include folder paths as well as file extensions, like .html, .php etc. in your 301 redirects like foldername/yourpage.html or pagename.php.
  • As a note, only one redirect per page can be added.

DEV.to Articles & Posts

Using Unsplash's API to Display a Random Image

About three years ago I bought a domain name, intending, as always, to launch a project with it. Here we are three years later and I've done exactly no work on the project.

To practice some JavaScript, I decided to explore Unsplash's API to create an interactive placeholder in the meantime.

Breaking It Down

const numItemsToGenerate = 1;

This just sets us up for the number of items we’ll request from the service.

function renderItem(){ fetch(`https://source.unsplash.com/1600x900/?beach`).then((response) => { let item = document.createElement('div'); item.classList.add('item'); item.innerHTML = `>img class="beach-image" src="${response.url}" alt="beach image"/>` document.body.appendChild(item); }) }

This actually pulls the photo in and passes it to the div it created (item). In the URL https://source.unsplash.com/1600x900/?beach you could remove the slug or input another search term instead. Use their documentation to further customize, including images from specific users, particular sizes of image, or lots of other parameters.

Because I just wanted to set the image as the full background, I’m appending the img to innerHTML, rather than targeting a particular div or section on the page.

If you wanted to target a specific ID or class, you’d add something like this to the script:

let item = document.getElementByID('existing'); item.existing = `<img class="beach-image" src="${response.url}" alt="beach image"/>`

Then to pass through and render the image:

for(let i =0;i

In Retrospect

At first, it was wild to think about using JS only and not building in any HTML to display the image, so first I tried building a div into the HTML body. I tried using class names and setting IDs, and I couldn't seem to target it, so I flipped to this different strategy using a tutorial as a guide.

Once I got the API working and displaying, the image dimensions were wild - turns out I was including the image dimensions in the source URL, so I pulled that out and created a CSS class for img since there was only going to be one displaying.

I made this just as a way to practice JavaScript and generate random images that would make me happy to look at. It's also the first time I've explored an API or read up on documentation for a purpose other than proofing/editing/writing.

In revisiting it now, I'm seeing another way I could have set the image as the body-background rather than creating a div and using a CSS class to size the photo which is kind of exciting - I'm ~ learning ~!

Developers: Delight Your Users and Co-Workers in Just One Day Per Year

Non-developers, have you ever felt misunderstood by your developer teammates? (Headline lifted from this excellent post by @kttravers on working with developers as a non-dev!)

When you're not on the developer team or in the engineering department at a company, there are a lot of ways to feel non-existent in tech - and once of those ways is feeling that your dev staff is out of touch with your users and fight back on some suggestions you make as someone who interacts with these people every day.

While there are always plenty of reasons why a user's want may not be feasible or advisable, there are also cases where building a feature or release a little differently could have a big impact on usability or user happiness. In an effort to better understand your users, rather than just the personas that your team might present, spend one day a quarter working with your support team.

In a typical work year of 261 days (not counting vacation or holidays), spending four days in support is less than 2% of your work days interacting directly with customers. Whether it's answering customer tickets or shadowing a support person while they pull a shift in live chat, this exercise can be hugely enlightening.

Our team does this by rotating schedules, so each month, one dev spends a day (or two half-days) answering support inquiries. The next month, someone else does it, so that there's always one person each month from the development team interacting directly with members. That way, no one is pulled away from their important engineering work for too long, and they'll see changes or trends over time.

At my company, every time we do this, there are developers that see things that are bugs and are an easy fix that support has just thought was the way a feature was intended to be built, and they fix it up quickly. Seeing a trend of confusion on a behavior can help shed light on why we might suggest that it be built a different way, or why we're often adding copy improvements. Interacting with user requests first-hand is also a powerful way to see what users want now - which might often be something different than what you had previously thought.

Most of all, when we've done this exercise, something our support team says is that they feel like these sessions not only improve their troubleshooting, confidence, and knowledge of the product, but also makes them feel like it's much easier to talk to developers. Customer support is so often the way that "non-tech" people break into the industry, and I think it's so important for them to feel comfortable interacting and show them that developers aren't intimidating people they should be scared of talking to.

For more on this, James Glazebrook just posted a great article and talk on Signal v. Noise!