RE: [dita-fa-edboard] DITA wiki

[Bruce Esrig <esrig-ia@esrig.com>]

Subject 1. Different wiki technology.

Hmm ... DITA Storm ... seems like a good idea, but it would be nice to have 
more detail about Alex's offer and how much of the site it would take over. 
The idea of user-generated structure is still unclear to me ... would this 
be completely organic, or is the main content of the suggestion to use DITA 
map capabilities as the mechanism by which the site structure is generated?

What would the role of Drupal be?

I was going to suggest a halfway measure ... We could start a tree of pages 
on site redesign and see what it's like to try to collaborate through the site.

Subject 2. Design methodology

Perhaps this is an over-reaction, but I've been going to lots of meetings 
about design and usability. Should we back out all the way and start a 
fundamental redesign?

I can offer some questions that we can explore if we decide to undertake 
more formal design work. Once we have our own answers, we can do user 
research with 1 up to 8 or so users per audience to find out what the 
members of each audience want the site to contain and how they would like 
to interact with it.

1. Who are the users and what are their goals?
1a. Persona: technical writer using DITA within a known structure
1b. Persona: content architect deciding on templates
1c. Persona: manager seeking to develop better authoring skills in staff
1d. Persona: systems architect designing an environment in which to author 
documents
1e. Persona: business analyst comparing authoring environments to determine 
whether to commit to DITA
1f. Persona: integration engineer building an environment that includes 
authoring in DITA
1g. Persona: any of the preceding roles offering services on a consulting basis
1h. Persona: organizer seeking to build community among practitioners
1j. Persona: manager or recruiter looking for capable staff
1k. Persona: language designer seeking feedback on proposed changes

2. What scenarios would support each persona in achieving their goals?

3. What functionality is required to support the key scenarios?

4. How should the functionality be offered, considering the relationships 
among the scenarios and the underlying capabilities and limitations of the 
technology?

Best wishes,

Bruce

At 11:36 AM 6/27/2007, Carol Geyer wrote:
>I realize our original goal was for the KB to represent the organized thoughts
>of the EdBoard, but I fear those pages have grown stagnant (and many remain
>stillborn). Empowering "contributing users" to add content (in the self
>policing spirit of wikipedia) might help the DITA community feel more 
>ownership
>of the site.
>
>I'm also not sure it's clear to users why some information is in the KB and
>other information is in the wiki pages.
>
>I think Drupal 5.1 will give us more options WRT navigation and menus. We can
>explore this once the site has been transitioned. Maybe we could add an
>expandable left nav back into the theme.
>
>If we can improve the navigation, would it make sense for the Editorial Board
>to spend time composing a more comprehensive hierarchy for the site and adding
>"stub" pages in places where we don't have content but would like to encourage
>it?
>
>Carol
>
>-----Original Message-----
>From: Bruce Esrig [mailto:esrig-ia@esrig.com]
>Sent: Wednesday, June 27, 2007 9:56 AM
>To: Carol Geyer; 'DITA Editorial Board'
>Subject: Re: [dita-fa-edboard] DITA wiki
>
>1. I think this should be done in the wiki, not in the knowledge base.
>
>The knowledge base is constructed as a tree of book pages. It has a
>definite hierarchy, which the user can navigate using the up, prev, and
>next links at the bottom of the page. (Also, the knowledge base represents
>the organized thoughts of the editorial board, for better or worse. If we
>want to allow certain people to edit the knowledge base, we should make
>them "contributing users" and use those permissions to enable their
>activities within the knowledge base.)
>
>The areas that we have divided the wiki into are not separated in this way.
>The relationships are quite fluid. How you get to a wiki page matters less
>than what links you see when you get there. We don't have a way right now
>to show the user how to navigate back from a wiki page to the wiki pages
>that point to it, so if someone arrives on the site at a wiki page, they
>have to do their own work to find out where they are. That's why I've been
>advocating format standards for wiki pages that emphasize the value of
>links from a page to the context for the page.
>
>2. I don't know where we stand with regard to Zak and his proposed
>contribution. I might have left him with a choice that he doesn't know how
>to answer.
>
>Best wishes,
>
>Bruce
>
>At 08:37 AM 6/27/2007, Carol Geyer wrote:
> >Should we consider allowing registered users to directly edit and add 
> pages to
> >the Knowledge base (essentially merging our Knowledge base and Wiki 
> sections)?
> >This would be a simple matter of changing permissions on the registered user
> >role. The Editorial Board could review new posts on a regular basis and 
> adjust
> >the site's navigation to accommodate them (or work out something similar
> >to the
> >way wikipedia uses "stubs" to embrace navigation to new pages).
> >
> >We could put the spec itself in a different section where only appended
> >comments (not direct edits) would be allowed.
> >
> >Does that make sense? What would a wiki give us that this approach would 
> not?
> >
> >--c
> >
> >_________________________________
> >Carol Geyer
> >Director of Communications
> >OASIS
> >+1.978.667.5115 x209
> >
> >
> >---------------------------------------------------------------------
> >This publicly archived list is provided by OASIS for the use of the 
> Editorial
> >Board of DITA XML.org. Subscription and posting privileges are reserved for
> >members of the Editorial Board; others should contact
> >communications@oasis-open.org for assistance.
> >
> >[Un]Subscribe: dita-fa-edboard-[un]subscribe@lists.xml.org
> >List archives: http://lists.xml.org/archives/dita-fa-edboard/
> >XML.org DITA Focus Area: http://dita.xml.org
> >Committee homepage: http://www.oasis-open.org/committees/dita
> >List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
>---------------------------------------------------------------------
>This publicly archived list is provided by OASIS for the use of the Editorial
>Board of DITA XML.org. Subscription and posting privileges are reserved for
>members of the Editorial Board; others should contact
>communications@oasis-open.org for assistance.
>
>[Un]Subscribe: dita-fa-edboard-[un]subscribe@lists.xml.org
>List archives: http://lists.xml.org/archives/dita-fa-edboard/
>XML.org DITA Focus Area: http://dita.xml.org
>Committee homepage: http://www.oasis-open.org/committees/dita
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php