TWiki.org Doc Work 2006
Doc Team
Doc Team Meeting 2006-06-16
Things we've talked about:
- Restructuring static twiki.org homepage
- Make this a TWiki topic and publish it either manually or by cronjob
- First create a TWikiOrgHomepageStudy2006 topic to enter our ideas - this will be used as notepad
- Simplify the left bar (or eliminate) - put the contents in the content pane
- Links should not point to deep, difficult pages but to landing pages where things are explained
- For instance info about a plugin should first introduce the idea of the plugin: what can it be used for, where to find more information
- The landing pages can be part of a TWiki tour
- Important is that the tour exists of pages that can be linked to
- The structure of these pages can probably be used on other parts of the site where concepts are introduced
- New pages will be added to TWiki web
- Skin mod is needed:
-
To show the context of the web or set of pages. Example: Wind River TWiki
- Web title / description can be set in variable
- Use horizontal tabs? -- AC
- Support web:
-
Too much info on WebHome: overview of asked questions can be moved to separate page if this is given a good entrance
-
Estate of list of contributors can be used better
- Search improvements:
-
Use Google to search Support web
-
Add TagMePlugin tags to enhance search results
-
Add status of question to WebChanges - DONE 2006-06-16
- Entry form:
-
Add more questions so people get more specific
-
Make free text field bigger, or relay this to edit page
-
Use a wizard type of form: is your question about: installing/security/layout/etc, then offer questions related to the situation
- Use ImmediateNotifyPlugin to let users subscribe to their question post
- Give users this option in the Edit page
-
Add more links to documentation topics
- This could be a easy recognizable block + icon: easy when scanning the page
- In Doc topic: backlinks to show Support questions/answers
-
Group answers by subject
- Codev web: out of scope
- TWiki web / documentation:
- Group topics by subject. SupplementalDocument does a good job at this, although I wonder if the syntax:
- Plugins web:
Other ideas:
- Add ExternalLinkPlugin to show outgoing links -- AC
--
ArthurClemens - 16 Jun 2006
Doc Team Meeting 2006-07-14
- Open up doc plan to community:
-
Move doc workspace to Codev web after this meeting
- Custom skin on TWiki.org
-
Customize skin a bit to support the doc structure, but not too much (to keep it similar to distribution)
-
Separate web name and web display name
-
Separate topic name and topic display name
- Plugins home:
- Target users: TWiki administrators and extension developers
- Keep working on Arthur's layout proposal
-
Keep web name Plugins
-
Introduce new DISPLAYWEBNAME = Extensions
-
Use term "TWiki Extensions"
-
For reports that show more than one extension use icons to distinguish the type of extension (as done now in the Support web for the Support status)
-
Add tag cloud
-
Keep "Find extensions by type" grouping of extensions; needs enhancement:
- TagMePlugin with "or" tag search; replace underscore with space for display
-
Create SearchByTags topic that does a tag search, and shows a topic title that can be set by URL parameter (to e.g. Extensions about <tag title<, such as Extensions about Backend)
- For TWiki applications and components:
- Target users: End users, knowledge workers, application assemblers, application builders
-
Create new web since target audience is different from Plugins web
-
Name of web: Apps
-
DISPLAYWEBNAME = Applications
-
Do similar home page layout like for Plugins web
- Create 40x40 (bigger?) icon to visually distinguish webs
-
Establish packaging standard for useful reporting and easy install
- Standard screenshot size (similar to skins)
-
What's new section
-
Work out some details on layout / format / supporting apps before creating web
- Implement low hanging fruits:
-
Implement supplemental doc for hosting sites, possibly with Apache configurator
-
Support home: Replace tag cloud with FAQ links (existing FAQs or Support web specific?) - DONE in Support.WebHome
-
Support home: Replace answered questions with picklist of category to see answered questions of that category (with one supporting page that listens to URL param for category) - DONE in Support.AnsweredByCategory (picklist shown in Support.WebHome and Support.AskedQuestions)
--
PeterThoeny - 14 Jul 2006
Support WebHome Redesign
-
Simplify Support.WebHome with user-action based content
- Simple layout with "I need..." questions
--
PeterThoeny - 22 Jul 2006
Plugins Web Doc Work, Week of 2006-09-18
-
Customer focused Plugins.WebHome layout, based on ideas in Plugins.WebHomeStudy2006
- Added several reports to make it easier to find and download extensions:
-
All reports contain extension info and a link to download the package
-
Note: AddOnPackage maintainers should update their add-on with a SHORTDESCRIPTION
--
PeterThoeny - 23 Sep 2006
Discussions
My first reaction is there's
far too much content on that
WebHomeStudy2006 page. An idea rather than "featured extensions" -which requires maintenance - would be to just to show the extensions with the top 5 appraisal scores.
--
CrawfordCurrie - 25 Sep 2006
The changes to
Plugins look good! The only design element that seems really lacking - in terms of the first thing
I look for on sites that list a whole bunch of extensions - is a list of recommended extensions based on popularity (# of downloads), rating (user reviews/votes), or "editor's choice".
The "highlighted plugins" almost matches "editor's choice" but needs to be expanded and should be called something closer to the familiar "editors' choice" phrase. How about "Core team's choice"?
Could we possibly utilize the download statistics to generate a "most popular" list? Unless we get much more activity in reviewing plugins, I don't see much possibility for a "top-rated" list but maybe adding this list would encourage folks to rate more plugins.
--
LynnwoodBrown - 25 Sep 2006