Converting user docs to a wiki and scope

[Gina Fevrier]

We've determined our content strategy for our user docs is to convert
them to a wiki. Are any of you doing this as well? I'm trying to
write our requirements doc and am looking for some examples. I just
posted on Sarah Maddox's blog as well (http://ffeathers.wordpress.com/
about/#comment-4410).

We're having some discussions on scope. I just want to focus on user
docs for now, and just be able to include our support knowledgebase in
search results from our Web page. I don't want to link to Marketing's
docs because I want to focus on "how to" topics.

If anyone else is working on something like this, I have to say it's
difficult getting past the bottlenecks. I admire the tech writers who
have gone under the radar to do the conversion -- sort of better to
beg for forgiveness rather than ask for permission.

I'm planning on presenting as part of our progression at the STC
Summit 2010 (Gina Fevrier (Numara) – Detours Along the Strategic Road:
Learning from our mistakes- http://stc-cs.org/).

[Anne Gentle]

Hi Gina -
The closest I got to requirement specifications was for a
collaborative authoring platform at my current company. I've posted
those on my blog and got some excellent feedback from others, so be
sure to read the comments. Don't let the "Agile" banner fool you - a
wiki may be the natural solution for collaborative authoring.

http://justwriteclick.com/2009/11/30/collaborative-authoring/

Our basic requirements were very simple on purpose. I took a "persona"
approach to the requirements and only two personas are needed in our
environment - you may have more, especially if you want to add an end-
user persona. I like using personas to get clarity for requirements
because it seems to focus people.

Consumer requirements

* Must get a known version of the docs that were delivered with a
particular software release
* Must output printed books – PDF is fine, previously we used
Word .doc files delivered in electronic format however
* Must enable draft content to be available internally for review
every week (even though we are on two-week sprints, three of six teams
are on alternating sprints so once-a-week publishing, really once a
day or on demand publishing would be required)
* Many other items like syndicated content, comments, ratings, web
analytics, but these are not “must haves”

Author requirements

* Must fit into budget constraints (this amount is four figures
currently)
* Must meet the existing server and client system requirements
(Windows-based, with a SQL Server installation available)
* Must be supportable by three tiers: author community of
practice, then the members of Agile teams, and then the corporate IT
team
* Must enable two authors per Agile team minimally (12-14),
ideally allowing all 47 members of production teams to create content
* Must enable concurrent use by authors in two different versions
of the product

Hope this helps!
Anne

[Gina Fevrier]

Hi Anne,

 

Yes, I found this on your blog this morning and struggled with posting the question, since I feel like I've been usurping your time.  You've been such a tremendous help to us between your book and presentation we purchased and the answers you've already provided.  I hadn't thought about using personas so thanks for the idea.  Our primary persona will be the advanced user of our software.  After our focus group this summer, they were the users who requested a wiki because they wanted to help contribute content, and they wanted a feedback mechanism, which we don't currently have with our Webhelp format.  They said our current Webhelp is fine for users just learning the software.  The other tech writer and I working on our wiki pilot have to submit a requirements doc.  Our product management team told me to write a combined but simplified marketing requirements document/product requirements document, and have provided a template.  I can't imagine beginning this project without such a document that clearly specifies such important elements as business requirements, scope, milestones, resources, stakeholders, research, workflow, and software requirements (wiki features).  It takes a lot of time upfront, but I think it will prevent miscommunication down the road. 

 

So far our main requirements are:

• Conversion from Madcap Flare/RoboHelp (or html)
• WYSIWYG editing
• Table of contents
• Search
• Page templates
• Stylesheets
• UI design capability to make the pages look like our current Web pages or Webhelp
• Comments (feedback)
• Change history
• RSS feeds of recent changes
• Statistics (most/least popular)
• PDF output (on demand topics by user)
• Security/permissions/anti-spam
• Low cost
• Support

Thanks again!

 

Gina Fevrier

 

--

You received this message because you are subscribed to the Google Groups "STC Content Strategy SIG" group.
To post to this group, send email to stc...@googlegroups.com.
To unsubscribe from this group, send email to stc-cs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/stc-cs?hl=en.