Difference between revisions of "Strikeforce:Content Strategy"

From SkullSpace Wiki
Jump to navigation Jump to search
(Content Strategy)
 
(10 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
* To redesign the information architecture of the SkullSpace wiki (this wiki) and design a proper content management strategy that others can use to update the wiki.
 
* To redesign the information architecture of the SkullSpace wiki (this wiki) and design a proper content management strategy that others can use to update the wiki.
 
* Leader: A. Michael
 
* Leader: A. Michael
* Members: A. Michael
+
* Members: A. Michael, Nate, Phoul
 
* Status: Initial Planning
 
* Status: Initial Planning
  
==Main Site==
+
==Information Architecture==
Our main presence is skullspace.ca.
 
  
Links:
+
The information structures of our sites need to be constructed. What is our most important information? Why are people using our sites? What are individual elements grouped under?
* Calendar
 
* Wiki
 
* Facebook
 
* Twitter
 
* Code
 
* Store
 
** Page not found
 
* FAQ
 
** Wiki Category: Required Reading
 
* Contact Us
 
** Silly mailto link
 
  
* No link to the blog
+
The final structure we reach will be the framework that informs our content strategy. Without it, we won't be able to organize the information, which will increase the risk of lost or duplicated content.
* The store needs to be checked up on
 
* The Twitter panel needs to be fixed
 
  
Immediate suggestions:
+
* Main Page and intro
More grouping. Facebook, Twitter, and Github (any external link) should be separated from the main navigation and possibly replaced by icons.
+
** FAQ?
There should be simple icons beside Calendar, Blog, Wiki, FAQ, and Contact Us.
+
** What SkullSpace is
FAQ should be renamed, or an FAQ page should be created on the wiki. (Context: "What is SkullSpace? Why would I want to join? What is available? What kinds of things has SkullSpace--or have SkullSpace members--done?") If this page remains on the wiki, there needs to be an easy link to get back to the home site.
+
** Map, phone, address, etc.
 +
* Projects
 +
** GitHub page
 +
** Cook all the Things
 +
** SkullBrew?
 +
* Events
 +
** Hackathons
 +
** Standalone events
 +
* Archives
 +
** Meeting Notes?
 +
** Old tenancy stuff
 +
** Random pages specific to the old space
 +
* Information
 +
** Bylaws
 +
** Member info
  
A good idea would be to load page content directly from wiki pages and into the bodies of skullspace.ca pages.
+
==Content Strategy==
  
 +
Content Strategy refers to the procedures followed in the creation and dispersal of new content. Without a strategy, old content will proliferate and stagnate.
  
 +
How should we manage our content? We need rules by which we can add new content to our data structures, and adapt that raw content into forms suitable for different media.
  
Additionally, we need a content strategy. We have several channels:
+
Here are some of the media we use to disperse content:
 
* Skullspace.ca
 
* Skullspace.ca
 
** Wiki
 
** Wiki
 
** Calendar
 
** Calendar
 +
* Meetup
 +
* Flickr
 
* Twitter
 
* Twitter
 
* Facebook
 
* Facebook
 
* Mailing Lists
 
* Mailing Lists
 
** Many of them
 
** Many of them
* Meetings
+
* Tuesday Meetings
* Billboards at the Space
+
* Billboards/Ads at the Space
* Postings at external websites
+
* Postings on external websites
  
We can create some content categories and think of ways to tailor updates to those various formats.
+
==Wiki Protocols==
 +
===First Steps===
 +
When creating content from the wiki, first make sure you know where you're putting it. You might need to include information from your new page in the curated list for that category (e.g.: [[Strikeforces]]), or you might need to include a category tag at the bottom.
 +
To-Do: Make a page detailing the structure of the Wiki. It will act as both a directory and a reference of where to include new content.
  
 +
===Archiving sets of items under an archived page===
 +
All obsolete pages should be archived, even if there is only one page that links to it. Those pages might be linked to in later documents.
  
 +
To archive a page, add the following tag to the top of it:
  
==Wiki==
+
<code>{{<nowiki />Archived}}</code>
  
Main links:
+
===Categories===
* Wiki Main Page
+
All categories should have a corresponding page of the same name that is not a category. This makes it easier to link to categories, because then a normal link wouldn't include the category into the page that contains the link, and it allows us to link to both categories and false sub-category curated pages (like "Archived Events") in the same way.
* Blog
 
* Chat
 
* Community Events
 
** (Put this in 2nd place?)
 
* Facebook
 
* Photos
 
* Twitter
 
* Videos
 
* Recent Changes
 
* Random Page
 
* Help
 
  
Chat:
+
===Handling subcategories of categorized items===
No content.
+
The easiest way to manage individual items is to put them in subsections of their category parent page. For example, "[[Cook All the Things]]" contains each recipe under different headings for the courses, rather than just listing the names of all the recipes.
  
Community Events:
+
This becomes harder when things need to be included in more and more subcategories. In that case, adding each of them as categories will automatically add it to those category pages, so they're all easy to find.
Broken calendar
 
  
Recent Changes:
+
What's the best default? Will members always include their new entry into the appropriate list on the parent category? Or can we expect them to know the differences between all subcategories and apply all the right ones?
Move to toolbox?
 
  
Random Page:
+
===Events===
Useless?
+
A wiki page might be for one event, or could be about a recurring event.
  
Help:
+
For a single event, either the title should include the ISO 8601 date at the beginning, or the page should include a tag at its bottom which rewrites how it's categorized in each category. Following this example with your date in place:
Load with good content.
 
  
From the main page:
+
<code>{{<nowiki />Date|1999-12-31}}</code>
* Main_Page -> SkullSpace
 
(Can this be changed so that SkullSpace *is* the main page?)
 
* Category: Required Reading
 
  
Should there be a logo in the upper left corner?
+
This would sort it under the heading "*" with proper date sorting.
  
 +
Time-based items should be separated from the informational items. Unfinished time-based items like events should belong to a category that can routinely be sorted through to archive items as they expire.
  
 +
===Projects===
 +
Informational items and projects should have owners. When a member leaves, any projects and information led by that member must be reassigned or archived.
  
==Cleaning up==
+
An audit should be performed every so often (twice a year?) to determine whether or not the active projects are up to date. If they are not, they should be brought up at the next meeting and either revived, reassigned, or archived.
  
Fill out the Help page with a short page detailing simple formatting and the use of things like templates and sections.
+
===Archives===
  
Make sure the main page is a proper table of contents for the entire wiki.
+
The link to the archives should be in a prominent place on the front page. Create an Archives page to curate examples of archived pages and tell stories around them, with a generic link to the Category:Archives for a complete list.
  
Go through orphaned pages and figure out what needs to be deleted and what needs to be included in other pages or archived.
+
Archived articles become our history. For improved context, archived files should have pertinent future-tense or present-tense words changed to past-tense. (This isn't a requirement.)
http://wiki.skullspace.ca/Special:LonelyPages
 
  
Take an audit of all pages. Make sure they're categorized properly. I can think of a few types:
+
If a page to be archived is incomplete (usually because it's missing its date), place the following template at its top with the reason inserted into the placeholder:
 
 
* Old archived things, which must be clearly archived and dated (and should be sortable)  
 
* Lists of items that belong under one main umbrella
 
* On-going projects
 
* Updates, which perhaps don't belong on the Wiki (or should be immediately archived)
 
 
 
 
 
 
 
==Content Strategy==
 
 
 
===Archives===
 
 
 
The link to the archives should be in a prominent place on the front page. Perhaps create an Archives page to detail specific archived pages and tell stories around them, with a generic link to the Category:Archives for a complete list.
 
 
 
For improved context, archived files should have pertinent future-tense or present-tense words changed to past-tense, but this isn't a requirement.
 
  
 +
<code>{{<nowiki />Unfinished | Text=Additional information goes here.}}</code>
  
 
===List Items===
 
===List Items===
Line 121: Line 102:
 
Lists of items like the recipes should all fall under a parent topic like Cook All The Things, which falls under a main category like Projects. We need clear locations for the top-level items. The really important ones, like Projects, should be front and center. If there are a whole lot of subcategories that can fall under one or two main categories, put them there and give those main categories a good spot on the front page.
 
Lists of items like the recipes should all fall under a parent topic like Cook All The Things, which falls under a main category like Projects. We need clear locations for the top-level items. The really important ones, like Projects, should be front and center. If there are a whole lot of subcategories that can fall under one or two main categories, put them there and give those main categories a good spot on the front page.
  
Informational items should be separated from the time-based items. Unfinished time-based items like events should belong to a category that can routinely be sorted through to archive items as they expire.
+
===Updates===
  
Informational items and projects should have owners. When a member leaves, any projects and information led by that member must be reassigned or archived.
+
Updates either should be immediately archived or should be put in dated threads in dated categories for pseudo-archiving. For example, the meeting minutes have the dates in the title, and a large list of them can easily be browsed.
  
An audit should be performed every so often (twice a year?) to determine whether or not the active pages are up to date. If they are not, they should be brought up at the next meeting and either revived, reassigned, or archived.
+
==Other Questions==
 +
===Curated pages and category pages===
 +
In some cases, a full description is not necessary. The events, for example, only need a curated selection of event descriptions in the main body, with a link to the full category. Does it matter whether we redirect from a given page to its category, and include all content there? If we do, we can post what we want on that page and there'll automatically be a list of all category items at the bottom.
  
===Updates===
+
# We have the standalone [[Events]] page, which looks nice, and links to Category:Events, which is fairly bare.
 +
# We create the Events page, but redirect it to Category:Events, which will contain both the curated content and the list of all events. It's harder to link to categories (the page becomes part of that category), so this way lets us easily link to categories, too.
  
Updates either should be immediately archived or should be put in dated threads in dated categories for pseudo-archiving. For example, the meeting minutes have the dates in the title, and a large list of them can easily be browsed.
+
So far, the second one sounds best.

Latest revision as of 22:35, 1 June 2014

  • To redesign the information architecture of the SkullSpace wiki (this wiki) and design a proper content management strategy that others can use to update the wiki.
  • Leader: A. Michael
  • Members: A. Michael, Nate, Phoul
  • Status: Initial Planning

Information Architecture

The information structures of our sites need to be constructed. What is our most important information? Why are people using our sites? What are individual elements grouped under?

The final structure we reach will be the framework that informs our content strategy. Without it, we won't be able to organize the information, which will increase the risk of lost or duplicated content.

  • Main Page and intro
    • FAQ?
    • What SkullSpace is
    • Map, phone, address, etc.
  • Projects
    • GitHub page
    • Cook all the Things
    • SkullBrew?
  • Events
    • Hackathons
    • Standalone events
  • Archives
    • Meeting Notes?
    • Old tenancy stuff
    • Random pages specific to the old space
  • Information
    • Bylaws
    • Member info

Content Strategy

Content Strategy refers to the procedures followed in the creation and dispersal of new content. Without a strategy, old content will proliferate and stagnate.

How should we manage our content? We need rules by which we can add new content to our data structures, and adapt that raw content into forms suitable for different media.

Here are some of the media we use to disperse content:

  • Skullspace.ca
    • Wiki
    • Calendar
  • Meetup
  • Flickr
  • Twitter
  • Facebook
  • Mailing Lists
    • Many of them
  • Tuesday Meetings
  • Billboards/Ads at the Space
  • Postings on external websites

Wiki Protocols

First Steps

When creating content from the wiki, first make sure you know where you're putting it. You might need to include information from your new page in the curated list for that category (e.g.: Strikeforces), or you might need to include a category tag at the bottom. To-Do: Make a page detailing the structure of the Wiki. It will act as both a directory and a reference of where to include new content.

Archiving sets of items under an archived page

All obsolete pages should be archived, even if there is only one page that links to it. Those pages might be linked to in later documents.

To archive a page, add the following tag to the top of it:

{{Archived}}

Categories

All categories should have a corresponding page of the same name that is not a category. This makes it easier to link to categories, because then a normal link wouldn't include the category into the page that contains the link, and it allows us to link to both categories and false sub-category curated pages (like "Archived Events") in the same way.

Handling subcategories of categorized items

The easiest way to manage individual items is to put them in subsections of their category parent page. For example, "Cook All the Things" contains each recipe under different headings for the courses, rather than just listing the names of all the recipes.

This becomes harder when things need to be included in more and more subcategories. In that case, adding each of them as categories will automatically add it to those category pages, so they're all easy to find.

What's the best default? Will members always include their new entry into the appropriate list on the parent category? Or can we expect them to know the differences between all subcategories and apply all the right ones?

Events

A wiki page might be for one event, or could be about a recurring event.

For a single event, either the title should include the ISO 8601 date at the beginning, or the page should include a tag at its bottom which rewrites how it's categorized in each category. Following this example with your date in place:

{{Date|1999-12-31}}

This would sort it under the heading "*" with proper date sorting.

Time-based items should be separated from the informational items. Unfinished time-based items like events should belong to a category that can routinely be sorted through to archive items as they expire.

Projects

Informational items and projects should have owners. When a member leaves, any projects and information led by that member must be reassigned or archived.

An audit should be performed every so often (twice a year?) to determine whether or not the active projects are up to date. If they are not, they should be brought up at the next meeting and either revived, reassigned, or archived.

Archives

The link to the archives should be in a prominent place on the front page. Create an Archives page to curate examples of archived pages and tell stories around them, with a generic link to the Category:Archives for a complete list.

Archived articles become our history. For improved context, archived files should have pertinent future-tense or present-tense words changed to past-tense. (This isn't a requirement.)

If a page to be archived is incomplete (usually because it's missing its date), place the following template at its top with the reason inserted into the placeholder:

{{Unfinished | Text=Additional information goes here.}}

List Items

Lists of items like the recipes should all fall under a parent topic like Cook All The Things, which falls under a main category like Projects. We need clear locations for the top-level items. The really important ones, like Projects, should be front and center. If there are a whole lot of subcategories that can fall under one or two main categories, put them there and give those main categories a good spot on the front page.

Updates

Updates either should be immediately archived or should be put in dated threads in dated categories for pseudo-archiving. For example, the meeting minutes have the dates in the title, and a large list of them can easily be browsed.

Other Questions

Curated pages and category pages

In some cases, a full description is not necessary. The events, for example, only need a curated selection of event descriptions in the main body, with a link to the full category. Does it matter whether we redirect from a given page to its category, and include all content there? If we do, we can post what we want on that page and there'll automatically be a list of all category items at the bottom.

  1. We have the standalone Events page, which looks nice, and links to Category:Events, which is fairly bare.
  2. We create the Events page, but redirect it to Category:Events, which will contain both the curated content and the list of all events. It's harder to link to categories (the page becomes part of that category), so this way lets us easily link to categories, too.

So far, the second one sounds best.