Strikeforce:Content Strategy

From SkullSpace Wiki
Revision as of 23:41, 11 March 2014 by AMichael (talk)
Jump to navigation Jump to search
  • 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
  • Status: Initial Planning

Main Site

Our main presence is skullspace.ca.

Links:

  • 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 store needs to be checked up on
  • The Twitter panel needs to be fixed

Immediate suggestions: More grouping. Facebook, Twitter, and Github (any external link) should be separated from the main navigation and possibly replaced by icons. There should be simple icons beside Calendar, Blog, Wiki, FAQ, and Contact Us. 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.

A good idea would be to load page content directly from wiki pages and into the bodies of skullspace.ca pages.


Additionally, we need a content strategy. We have several channels:

  • Skullspace.ca
    • Wiki
    • Calendar
  • Twitter
  • Facebook
  • Mailing Lists
    • Many of them
  • Meetings
  • Billboards at the Space
  • Postings at external websites

We can create some content categories and think of ways to tailor updates to those various formats.


Wiki

Main links:

  • Wiki Main Page
  • Blog
  • Chat
  • Community Events
    • (Put this in 2nd place?)
  • Facebook
  • Photos
  • Twitter
  • Videos
  • Recent Changes
  • Random Page
  • Help

Chat: No content.

Community Events: Broken calendar

Recent Changes: Move to toolbox?

Random Page: Useless?

Help: Load with good content.

From the main page:

  • 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?


Cleaning up

Fill out the Help page with a short page detailing simple formatting and the use of things like templates and sections.

Make sure the main page is a proper table of contents for the entire wiki.

Go through orphaned pages and figure out what needs to be deleted and what needs to be included in other pages or archived. 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:

  • 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.


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.

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.

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 pages are up to date. If they are not, they should be brought up at the next meeting and either revived, reassigned, or archived.

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.