It can be a daunting task to write a new page. Even more so to start a new wiki from scratch or reviving a dead wiki. This is a rather personal view of how to go about it, grounded in the idea that wikis should be collaborative and ongoing ventures. It is not necessarily the end-all and be-all for building a wiki, but it is hopefully a reasonable way to go about it. If nothing else, I hope it will help the reader to create their own approach to building up a wiki.
Write text[]
Wikis are a textual medium. Images, videos, and sounds have their place and can play great roles, but they are all supplementary to the text. Text is the primary information carrier and the element of the page most easily parsed by search engines and other machines. Text is what is primarily presented by search engines and is used in searches by readers.
A wiki with nothing but text can provide great value to readers and be easily handled by search engines. A wiki with only templates, a splendidly designed start page, lavish CSS, plenty of images, and a couple navboxes with redlinks is on the other hand a Potemkin village, devoid of any substance.
Make links[]
Links provide two different services to web pages. They allow the reader to go from one web page to the next and they provide context to the relationship between the two pages. The clearer this context is, the better.
The link text itself can provide a clue, but most links in wikitext will use the name of the target page as the link text. That means the primary context for links will be the words around it. Thus, links should preferably appear in sentences or with some form of label. Links that appear bare beside other links, for example in navboxes, provide much less context.
This does not mean that navboxes should not be used. It means that navboxes, if used, should be in addition to in-text links, that can present relations to other pages more richly.
Build in a spiral[]
It is easy to get caught on a quest for perfection and to focus more on improving the existing pages instead of adding new pages. That way lies endless editing of the same few pages and plenty of redlinks.
Instead the following can be used as a model for building a wiki.
Start with making two or three pages in different areas, e.g. one story page and one character page. They need not be perfect or complete, but treat them more as a learning experience. The next day, with the experience of writing those two pages, write another two or three pages, e.g. one story, one character, and one location page. Experiment with the new pages, and try a different structure and way of writing them to see if that can bring benefits that can be brought to the rest of the wiki. Continue to add pages until you have a critical mass, e.g. pages for all the major characters. Only then go back and edit the old pages, but continue to add more pages as well.
The goal here is to regularly add new pages to the wiki because new pages are the most visible form of new and added content. Writing more pages makes it easier to discover good ways to structure different types of pages through experimentation. It provides a supply of imperfect pages that can be improved later on. More pages means more entrance points for search engines. Old pages are steadily improved based on the experience gained from crafting new pages.
Building a wiki is much more like a marathon than a sprint. It is more important to do small regular improvements and additions than to do big editing sprees. Big editing sprees have their place, but small regular improvements and additions stack up over time and do not lead to editing burnout.
Notice templates or design elements can be started once there is a small core of pages of different types. One big benefit of the portable infoboxes used on fandom.com is that they are easily changed and edited, meaning that a similar iterative process used for exploring good page structures can be used on the infoboxes as well.
The value of imperfect pages[]
While imperfect pages may seem bad on their own, one can view them as a boon for a wiki as a whole. The reason is that they provide low-hanging fruits for new or inexperienced editors to improve. That is, easily improved pages are bait for finding and recruiting new contributors to the wiki.
An easily improved page must however have a certain base quality. A page that would require a large or total rewrite is not an easily improved page, nor does it invite later visits.
The goal of easy improvement here also implies that the structure and code of the page should be easily understood. A page dominated by fragile or complex templates is not easily improved. That does not mean fragile or complex templates should never be used, but it means that standard mediawiki code should be the primary element of most pages, and that complex templates should be the exception, not the rule.
This should not be understood as that pages should be left unimproved. Rather it means that there is no hurry with improving old pages, and that complex templates should be low on the priority list. Improving the wiki as a whole is a marathon. Regular and steady improvements are again more important than editing sprees.
The initial goal of any individual wiki page is to be good enough, not that it is perfect.
One object, one page[]
Each page should ideally either describe a single object (e.g. a character) or contain a list to other pages. They should not describe several objects, for example several characters with descriptions.
There are several reasons for this. One is that pages are the atoms of wikis, just as they are for most of the web. It is far easier to link to a page than to a fragment of a page, and there are many tools available for working with and handling pages, less so for pieces of a page. A new page is more noticable than an update to a page. Smaller pages are less unwieldy to edit than larger pages.
The goal of ease of linking means that page names should be chosen to be easily and naturally included as link text in other pages.
Less is more[]
It is easy to add stuff to pages, and we tend to think of more stuff, more information, more data as better. It is much psychologically much harder to remove things, and having more stuff on hand also means it is easy to lose track of those specific bits that are important.
The paradox here is that adding more images to the gallery or more data to the infobox past a certain point makes the already present information there less noticable and harder to find. While infoboxes are great for presenting structured data, they are not the only such tool. Basic tables and definition lists can be great tools for structured data, and especially tables provide much greater room for design elements and functionality than infoboxes due to their greater available size.
Style guides should be guides[]
Style guides should not primarily be normative documents. Rather they should describe and document the proven and established practices used to craft pages on a wiki. They should document any wiki-specific oddities, like complex templates or tools. Their primary role should be to be a help for new editors to get started and for experienced editors to look up specific details.
When style guides do not describe established practices they should set goals and ambitions rather than be normative. They should describe the desired state of the page, not the state the page must be in before it goes live. To require a perfect page from the beginning is to go against the collaborative nature of wikis.
Read more of my thoughts on style guides in Style Guides Should Be Guides.
Maximizing Your Community Mentor Knowledge