There are many ways to structure content globally. All of GlobalContentStructuringMethods can be relevant in wikis.
Some of them:
Structuring by chronology. A chronological structure might present topics linearly based on:
Structuring by alphabetical order. Frequently used in various lists. Alphabetical ordering is usually an index, which is commonly omitted in favor of search. However, indexes can also provide readers with a way of learning the official terms used. Once they know the right terms, readers can quickly move to the place that provides those terms. Readers are usually familiar with referring to indexes as a way to find content.
Structuring by popularity. Popularity established usually by
content/feature/software/service. Readers know that if a topic is popular for others, it’s probably relevant to their needs too. Often the drawbacks of these methods are that they are self-enforcing (popular items stay popular irrespective of quality) and that they lead to filter bubbles (not being exposed to new material).
Structuring by subject:
Subject-based structuring may not always be the best method. Subjects frequently overlap with each other and can be grouped in myriad ways depending on the perspective. The terms used to describe the subjects are also often unfamiliar to readers. As a result, when readers open the wiki to find information, they see an intimidating array of subjects to look through, with names that don’t mean much.
Structuring by reader's goal. Many times readers have general goals in reading a content. These goals don’t often translate into task or topic titles. For example, a reader may want to do work in less time, optimize for time or space, decrease or increase something, or encourage communication among others. Understanding your reader’s goals is key to writing content in the first place, but we often forget these larger goals and get mired in more technical specifics. When you organize by goal, you can connect the larger goals of the reader to specific how-to tasks.
Structuring by format. Format can be grouped by videos, quick references, manuals, online help, diagrams, tables, or other formats. This helps readers looking for material based on their learning preferences.
Structuring by audience. Audience may be identified by their role, discipline, or department. The idea is the same: by identifying the audience, you can present the topics most relevant to that audience.
Structuring by level. Content can be divided into a series of levels, similar to the way video games or karate lessons move readers from one level to the next, providing more advanced information as the levels increase. This structuring scheme is more of a course-based structuring pattern.
Structuring by skill level. Skill level can be divided into beginning and advanced tasks. Readers new to the system can see a list of topics appropriate to beginners, while advanced readers can see the more difficult topics.
Some subgenres: skill / experience / access / authorization level.
Structuring by related information. Related information contains a series of logically related links placed at the end or along the side of each topic. This method provides navigation directly within the topic, where readers often spend the most time. To reduce cross-reference errors, related links might be grouped in relationship tables.
Structuring information in-context. In-context structuring groups the topic in the location where the reader needs it. This is often referred to as context-sensitive help or on-screen help. Help icons in the interface, pop-up modals when a reader opens a new screen, or embedded on-screen text can help readers find information when they need it.
Structuring by ordering. Order established usually by price, maintenance cost, size, power, speed, performance, reliability, lifetime, or other measurable parameter.
Structuring by location. Location refers to the geographical context of where the reader is located:
If some information might be specific to readers in, for example, Africa, Japan, or South America (such as time zone notes, terminology, translated material, etc.), this structuring scheme can help them locate what they need. Remember that usage of an application often varies based on one’s location. For example, the European Union has specific data privacy laws that might affect what information you can show in your application.
Structuring by problems. Problems/issues could include frequent support requests or knowledge base articles. This problem/issue-based structuring might contain titles highlighting
Highlighting problems is the reverse of traditional documentation: rather than explaining the features, you’re calling out areas of broken/non-existent functionality.
Structuring by next steps. Next steps is similar to related information, except that the next steps are more sequential and appear directly below the last paragraph of the topic. In a modular authoring, because each task is chunked from other tasks, individual tasks may build on each other but be discrete topics. If each task is chunked as a discrete topic, search results may spread them out in a disconnected way. The next-steps link below each topic gives coherence to these discrete-but-connected topics.
Structuring by story. Stories might include persona-driven workflows described for various roles. In the stories, as yoehanced & structured.)
Interesting page. I never thought about it that way …