Website Basics

Network services required for (most effectively) running a website

A webpage is a page that you can visit on the internet that has it’s own address (e.g., https://www.steventammen.com). Webpages are collected into websites. Websites require various services to make them publicly accessible and functional.

Domain name registrar

Each web address is unique: you cannot have more than one steventammen.com. For this reason, web addresses must be registered with people known as domain registrars. You can think of domain registrars as having a similar function as the government entities that are responsible for the license plates of cars. Just how each car has its own unique license plate, so too does each website have its own web address.

There are various “kinds” of domains, such as .com, .net, .org, and so on. These are called top level domains (TLDs). General computer users are most familiar with .com, and for this reason there is much competition to register short and mnemonic .com domains. As long as you stick with the three most common TLDs (as listed above), it does not matter so much. More exotic TLDs (like the .io domains that some startups use) cost more to keep registered (around $35 USD per year as opposed to $12 USD per year), and they are also harder for less tech-savvy people to recognize, so I would avoid them.

All domains must have certain information about the person registering the domain available. This is called WHOIS information. It is best not to use your own information directly as doing such will lead to spam. Instead, you should purchase domains from a reputable registrar that either includes or lets you purchase WHOIS protection that masks your own contact information, instead using email addresses that will filter incoming messages.

I use and like Namecheap.com. It is one of the large, well-respected registrars, and it offers WHOIS protection.

DNS provider

When a user visits the web address of your website, a translation happens from your nice, human-readable web address to something called an IP address, which is a collection of numbers separated by dots. As an analogy, your web address is like your street address, and the IP address it gets translated to is like your house’s GPS coordinates of latitude and longitude. The IP address to which your web address gets translated is the precise address of the web server hosting your website (see below for web hosts).

The thing performing this translation is called a DNS server, and the people providing these servers are called DNS providers. After registering your domain name, you have use a DNS provider to “point” your domain at something, otherwise nothing will show up on your site.

There are plenty of good, free DNS providers, but I personally use Netlify. Your DNS provider may influence Content Delivery Network (CDN) performance.

Mail provider

If you want to be able to use a custom email address like me@mysite.com, you will need to set up a mail server and set up MX records with your DNS provider to point to your mail server. This is not as hard as it sounds.

I am a big fan of Mailgun as a mail provider, and it’s what I would suggest for most people since you can keep using what you are used to (e.g., Gmail, Yahoo mail, etc.) via forwarding, instead of having to get accustomed to some new interface.

Host

A web host is the place where your website is built. To keep extending our analogy from above, if a DNS provider takes your web address (street address) and translates it into an IP address (GPS coordinates), then we can think of web hosts as the lots of land on which houses are built (websites being houses).

When someone visits your website, your web host sends them a copy of the page they are visiting – a page written in the web’s markup language called HyperText Markup Language (HTML) – using something called the HyperText Tranfer Protocol (HTTP).

The more traffic your website has, the more stress it puts on your web host. Static websites (discussed below) are constructed in such a way that they inherently take far fewer server resources to deploy, and for this reason can generally be hosted completely for free.

I would suggest using Netlify for web hosting, set up with a static site generator.

Encryption certificate

Things being sent over HTTP are not private. If you are on a WiFi network, any person with enough knowledge to set up something called a packet sniffer can see what pages you are visiting. They can also “hijack” web sessions (depending on what websites you are visiting), and do other various nefarious things with the information.

To protect the security and privacy of people visiting your site, it is necessary to set up something called an encryption certificate. Basically, you can think of this certificate as a token to set up a secret code between your site and people who visit it, just how you might use a secret code to communicate with your friends.

Once you have a certificate set up, your site will be accessed over HyperText Tranfer Protocol Secure (HTTPS) rather than HTTP, and you will protect the privacy and security of people who visit your site.

For most people setting up their own websites, I would recommend Let’s Encrypt for getting an encryption certificate.

Content Delivery Network (CDN)

A Content Delivery Network (CDN) is a system to minimize the time it takes for your page to be sent over the internet.

Imagine that webpages are analogous to pizzas, and a user visiting a site is like someone ordering a pizza. If there were only one pizza place in an entire city, people living far away from the pizza place might get their ordered pizza much slower than people that live near the pizza place. A wise pizza company would have multiple store locations in the city so that when someone ordered a pizza, a delivery guy from the nearest store would be sent to fulfill the order, rather than a delivery guy from a faraway store.

Setting up a CDN is basically like building more pizza places. You let your webpages be delivered from servers around the world rather than a single server that might be very far away geographically from someone visiting your website.

As we’ll discuss below, CDNs work best with websites that are completely static.

Netlify is the CDN I use and recommend most strongly. Cloudflare is another good free option.

Creating what goes on the website

Version control and content types

Version control is something that is heavily used in computer science, but it can also be used for text files containing prose (or whatever else). Imagine if you had a log of all the changes you made to a webpage, and could at a click see how you changed the page over time. Version control lets you do exactly this.

Now, there’s a catch. Most people are used to writing in a form of so-called “rich text,” like .docx files opened in Microsoft Word. These files don’t do so well in version control because they contain a lot of information that is not directly related to the text.

For this reason, most websites that are constructed from files under version control use something called a markup language to denote bold text, links, and so on. By far the most popular markup language is called Markdown. I personally use a different markup language called Org within my text editor (Emacs) specifically. I would recommend Markdown for most people. If you are familiar with Emacs (and/or mouseless text editing more generally – I actually use Vim bindings within Emacs), and want some of Org mode’s special functionality (like collapsible sections and dynamic plain-text tables, among other things), then you can give Org mode a try.

Typora is a good cross-platform Markdown editor. Many websites (e.g., forums, stack exchanges) also use Markdown for their own content editors, and as we shall see below, you can also use Markdown with Netlify’s Content Management System (CMS).

Static site generators

Now, since web browsers and web servers deal with HTML files not files written in Markdown or Org, if you want your files to be written in these markup languages, you need to convert them to HTML somehow. This is the job of the static site generator.

Static site generators turn files written in markup languages into HTML. What makes these generators “static” is that they build these HTML files… and then these HTML files don’t change over time. This works just great for webpages that are acting like text documents, but if you have an interactive web application (where a webpage might need to change depending on who is logged in and what their settings are, for example), then you really do need to support dynamically building webpages on the fly.

Fully static websites can be very easily cached since the webpage seen by one user will always be the exact same as the one seen by another. When pages change depending upon different variables, they become harder to cache: every new web request leads to a new web page being built from scratch, that must then be sent from the web server building the page to the user. If you recall our discussion of CDNs in terms of pizza places, the slowdown here is twofold: having to build webpages (pizzas) upon every request is slower than having webpages (pizzas) already built and ready to send, and having to send webpages (pizzas) from a single location leads to slower delivery times for people who live far away from the place where the webpages (pizzas) are made.

Some static site generators have their own test server that you can run on your local browser (i.e., not the internet), to see how your webpages will look after being transformed from markup languages into HTML. Aside from this, the most important variable for static site generators is speed: you want your site to be built quickly!

Since it has a local webserver for testing and is really fast, I like Hugo as a static site generator.

Templating

One of the things that makes websites great is that they have things like menus and footers that provide information and navigation links no matter what page you are on (as contrasted with physical books for which navigation is much more laborious).

It is really inefficient to have to specify the “boilerplate” part of a webpage for each new webpage you make. Templating takes care of this inefficiency by letting you define a template (“pattern”) for a webpage, that simply gets filled in with your content for each new page you make. You might think of templates like picture frames: while you can change the picture in a picture frame (analogous to how content changes across webpages), the frame itself is the same for all pictures (just like a template).

It is common to have several different templates depending on content type. For example, maybe there is one template for blog posts, another for individual design projects, and so on. Content is placed in the most appropriate template, keeping automation intact, but allowing for more flexibility.

Most all static site generators allow for good templating.

Themes

Themes specify what your site should look like, and can be switched out with a little work. Websites are analogous to car paint jobs: they don’t change the underlying function of a site (car), but they do change how it looks.

Themes are built on a concept called Cascading Style Sheets (CSS). While HTML specifies what content is to appear on a webpage, CSS specifies how the content appears.

To say that themes are just CSS is a bit of a simplification. Most themes have website navigation (menus), headers, footers, and custom home pages built-in, and all of these things require HTML to implement. In reality, themes are simply a collection of templates with some additional styling on top with CSS. It is typical to add some additional templates to an already-existing theme, as your content requires.

Most all static site generators have a good selection of themes to choose from when constructing a site.

Design areas focused on practical functionality

Having a functioning website is quite a different thing from having a site that performs optimally. I will say that I have been personally surprised to find how suboptimal most websites across the internet are. Much of what I say below is opinionated, and some people are bound to disagree. This section is also, of course, necessarily incomplete in scope; the idea is simply to give an idea of the complexity of thoughtful website design.

My ideas are implemented in my take on an optimal theme, the Spartan Theme for Hugo.

RSS support

RSS as a concept is the idea of having an XML page on your website that a program can read to tell a user what content on your site is new. Users then have the option of subscribing to your website (rather than having to manually check your site for updates), and they can also aggregate many such subscriptions using an RSS reader like Feedly to keep up with new material on multiple sites.

RSS makes a great deal of sense, and saves a lot of time for readers. I use it extensively to keep track of various blogs I follow, and it baffles me that as few people support RSS for their sites as do in practice. It is not difficult to set up, and is a great boost to site functionality.

Sidebar navigation, flat navigation

The vast majority of websites make poor use of the screen real-estate available to them. You actually don’t want to take up the entire horizontal width of a portrait monitor at normal font sizes (like 14 or 16), much less a landscape monitor. This is because humans read optimally within a certain character range, and exceeding this range is just as bad as having columns of text that are extremely narrow.

Since all people using a landscape orientation and most tablet users using a portrait orientation have horizontal space to spare, it makes sense to make use of this space by using a narrow sidebar for navigation rather than a top bar that takes up precious vertical space (and what’s worse, also doesn’t let you fit as much).

Within this sidebar, sections make sense, but it is silly to hide navigation items and require a click or hover to get to them. Doing such is inefficient because of a concept called information scent: navigation works best when it is dead obvious where to find a particular link. (You can get a feel for the concept in James Archer’s cogent criticism of the hamburger menu). You can’t get better information scent than not hiding anything to begin with, as long as things are logically arranged.

Icons for navigation links

Icons, such as Font Awesome icons, help make it more obvious what a link is associated with, and in many ways are a superior system for comparing navigation links at a glance since they are easier to scan than complete words (and especially multi-word links than may not be cognitively processed as a single morpheme).

Responsiveness

Now, this one is not controversial, but I am still horrified at the number of websites that break in a significant way at narrow widths. Responsiveness is essentially the degree to which your site can accommodate different screen sizes. For example, a phone has a much smaller screen than a laptop or monitor, but you still want your site to look and function well even on the smaller screen.

This typically involves making sure your menu navigation works on smaller screens, and that your main content window is set up to scale proportional to the screen width so that content does not get cut off when the screen gets narrow.

Bottom bar mobile navigation

Having mobile navigation is one thing, but making its use optimal is another level above the navigation simply existing. Since both iOS and Android place their main menu bars at the bottom of the phone screen, people are accustomed to having their thumb near the bottom when using their phone with one hand. For some inexplicable reason, I have not come across websites other than my own that put their mobile menu bar at the bottom of the screen to make use of the typical hand position of mobile users holding their phones with one hand. The design principle seems rather self-evident to me, but I suppose it is not “normal” and that is why other people do not do it.

As an additional consideration, since most people are right-handed, it makes sense to put more frequent items on the left side of bottom bar since it is easier to use one’s thumb to touch the opposite side of the screen when it is at the bottom of the screen (you have to scrunch up your hand less – feel free to try it out for yourself). My menu bar contains 4 items: Menu, TOC, PgUp, and PgDn. Since the first two are probably used more by most people than the PgUp and PgDn buttons, they are on the left.

PgUp and PgDn buttons

Scrolling through text takes time and leads to higher cognitive load than reading paginated text (although it is unquestionably better than reading paginated text for scanning through webpages, as opposed to reading them all the way through). If you have page scrolling work like normal, but also dynamically calculate the height of the viewing window so that users can go back and forward one screen height, you can have the best of both worlds: when scanning, scrolling operates seamlessly, but when reading, you can use PgUp and PgDn buttons to minimize the time and cognitive load of reading.

You can find my thoughts concerning reading on screens on this page.

A back to top button

It is fairly common to want to go back to the top of a page after you have scrolled down some. This is easy to do automatically at the press of a button, so why not make sure that a button like this is included on all pages?

A well-designed table of contents

The lack of widespread use of TOCs on websites is a big pet peeve of mine. For any site that is primarily text-based, a table of contents is absolutely mandatory in my book. But having the TOC at the top of the document is no good since you then have to go back to the top every time you want to change position within the document. A TOC should always be visible as appropriate (i.e., as long as the page width is wide enough to allow it without taking away from useful content width).

Moreover, what you are interested in with the table of contents is most often “where you are” in the document. In other words, you want to make sure you know what section and subsection you are in (and the sections around this one) rather than needing to see all the TOC information at once. So why not make these things front-and-center while hiding the rest?

If you make the hierarchy clear (I am partial to showing this using levels of indentation with colored lines serving as additional markers of nesting – as active on this very webpage, for example) and bold the currently active section and subsection(s), the TOC can serve as an automatically-updating “map” of the webpage, and your current location in it.

There is absolutely no excuse for a site not to have a table of contents, since the JavaScript project that the TOC on this site is based on (the Table of Contents plugin for Bootstrap) can dynamically generate a table of contents based on content headers, requiring no manual work on the part of a content creator.

Other notes and recommendations

Page rank

Google, as the largest search engine in the world, has a say in whether or not your site gets high visibility. Like other search engines, Google has something called page rank. Essentially, page rank determines how far up in the search results your site will appear relative to other sites (as in the top of page 1 versus the bottom of page 6). We want this to be as high as possible. Google uses many variables in determining page rank, but support for HTTPS is an especially important one.

There are other design considerations relating to so-called search engine optimization (SEO) that deal with how search engines score your site in their page rank algorithms. For most people, ensuring that your site is responsive, running over HTTPS, with content not duplicated across subdomains (most notably the bare domain and the www subdomain) will help your pages rank well enough that you probably shouldn’t worry so much about finer points. You should also strive not to delete pages or change their names as this makes it hard for your website to build up link traffic, which factors into page rank.

The real key to SEO success is creating valuable content that people actually want to read and share.

Paying for web design is unnecessary for text-centric websites

If you are building a text-based content-focused website – one that does not need fancy interactive functionality (that would be implemented in a programming language called JavaScript) and probably does not require an overly complicated content layout – it is easily possible to use a free theme and avoid paying anyone for web design.

Moreover, it is possible to select a DNS provider, mail provider, host, encryption certificate provider, and CDN such that your website’s initial setup cost is free and only recurring cost is domain name registration through a registrar (usually on the order of $12 USD per year).

User-friendly editor frontends

With this being said, setting up a website is something that is daunting if you have no knowledge of computer networks and computer science tools like Git (a version control system). A great deal of what we have discussed thus far can be completely abstracted away from content creators using something called a content management system (CMS). I have several times now mentioned the Netlify CMS, a very good CMS using version-controlled Markdown to produce static HTML pages served over a fast CDN.

An ideal situation, to my mind, is to find a friend or family member who is computer-savvy enough to help you with an initial website setup via Netlify (e.g., registering a domain name, setting up nameservers and mailservers, configuring the CDN), and then interacting with the live site using the Netlify CMS. Your computer-savvy buddy will not ever have to intervene once things are set up initially unless you decide you want more templates for new content categories or want to tweak something about the appearance of your site, and you won’t have to deal with any of the complicated programmer bits, instead making use of a slick, easy-to-use frontend.

There is no reason why a CMS workflow cannot make use of offline Markdown files for drafting content, just pasting the finished Markdown into the CMS. I will here again plug Typora as a good cross-platform Markdown editor.

Making resources available in a wide variety of formats

While this post has focused on creating content for a website, it is best to make your content available in multiple different file formats. The two other kinds of formats that are most important after HTML, to my mind, are printing formats like PDF (used by people for printing writing out to read it on paper) and eReader formats like ePub (used by people with eReaders).¹

You can streamline the generation of these other formats from your markup language files (or even HTML files or .docx files) using an excellent tool called Pandoc. Pandoc is a command-line tool, making it perhaps somewhat harder for ordinary people to use, but this is also an advantage as it can easily be scripted to export to other formats completely automatically.