Mapping Content

Chapter 1 argued that the site should be split. Before building anything, you need an answer to a simpler question: which content goes on which site? Get this wrong and every later decision (navigation, redirects, builds) inherits the mistake. This chapter works from the real content/ folder, builds a map from top-level folders to sites, and turns that map into data a script can check.

Start from What Exists

The content/ folder has 48 top-level subject folders, plus a special sidebar/ folder that holds link pages, tools, standalone lessons and cheat sheets for several subjects. Here are a few of them, to show how varied the content is:

This is the raw material. Some folders are obviously related (web-development, web-servers, web-platforms), some belong to a clear audience (france, germany, hungary, japan are all someone learning a language), and some are on their own (cookery, football).

Principles for Grouping

Use these in order, and expect to adjust rather than get it perfect first time:

1. Group by audience first. Who comes to this content, and what else do they want? A language learner and a Linux administrator are different visitors.
2. Group by shared design. Content that uses the same components (dialog blocks, code blocks, timelines) belongs on one site, so the design package serves it well.
3. Keep cross-links short. If two folders link to each other constantly, put them on the same site. Cross-site links work, but they are absolute URLs and a different origin (Learning Website: Framework & Architecture 1).
4. Balance size and growth. A site that is ten times bigger than the others has not solved the original problem. Neither does a site with one course in it.
5. One home per page. Every page lives on exactly one site. Other sites link to it and never copy it.

A Proposed Map

The map below is a starting proposal, built by applying those principles to the real folders. It is a judgement and not a law: you will move some folders after you see it laid out, and that is the point of writing it down.

Special Cases

The sidebar folder

sidebar/ is organised by subject, with links, tools, lessons and cheat sheets for each. It is not a subject itself, so it does not get a site of its own. Instead, route each page by its subject folder: sidebar/linux/ goes with the systems site, sidebar/web-development/ with the webdevelopment site, sidebar/football/ with humanities, and so on. A Linux cheat sheet then appears next to the Linux courses.

Folders that could go either way

databases is useful for web and non-web work. projects mixes web projects with a database engine and an operating system kernel. culture (Japan) could sit with languages or with the humanities. Pick one home for each, write down the reason, and let the other sites link to it. Exercise 3 asks you to do exactly that.

Shared pages: the landing page and tools

A few things belong to no area: a site-wide search page, an “about” page, and a list of every site. These live on the main osztromok.com domain, which Chapter 1 suggested becoming a portfolio and landing page.

Make the Map Data, Not Prose

A table in a document is for people. The build needs the same information in a form a script can read. Put the map in one file and let everything else (navigation, builds, redirects) read it:

Two properties make this map trustworthy. It is complete: every folder on disk appears in it. And it is unambiguous: no folder appears twice. A short script can check both every time the folder tree changes, which is the first exercise below.

Naming the Sites

The site name becomes a subdomain label, so it has to be a valid one: letters, digits and hyphens, no spaces or underscores, and at most 63 characters. Beyond that, follow the same rules you use for folders:

• Short and recognisable. languages is clearer than langs and shorter than language-learning.
• Stable. Renaming a site later means changing every cross-site link and every redirect.
• One style. If you use a hyphen in one name, use hyphens in all names. The names above are single words, which avoids the question.
• Describe the content, not the technology. webdevelopment will still be right if you change framework.

Keep the Path the Same

When a folder moves to a new site, keep everything after the site name unchanged. The page that lives at japan/hiragana-1/ under content/ would live at languages.osztromok.com/japan/hiragana-1/. Three benefits follow. The redirect rule is a mechanical rewrite of the host name. Links inside the content need little change. And you can predict a page's new address without looking it up.

Hands-On Exercises