Wiki reloaded

Hi,
I need to be sincere here: I dislike the current wiki very much.

1. I don’t like the big download button. It takes most of the page and waste a lot of space.
2. Black theme background is not good for the Synfig shield.
3. Top image banner is not completely achieved. It is not resizable and covers the search entry.
4. The current default theme doesn’t have the standard buttons when edit a wiki page.
5. There are some links at the bottom that are not accessible unless you scroll down.

I know that it is not an easy task but I’m a completely dumb in those kind of modifications. In fact I’m not in the list of authorized people to administrate the wiki engine (I don’t belong to the wikimonkey group although I believe that I have rights to join to it).

What are the thoughts of you to fix this situation?
What do you think about the current wiki design (the English version of course, because to make it worse, each language has different styles…)

Not necessarily before the release, but taking the advantage of it, I think that we should consider to rework the wiki. Even I would like to learn how to do it if someone guides me.

Yaco did an awesome work but I personally prefer other more simple and clear style.

-G

I’ll add my 3 cents:

• The pages are not split/categorized into namespaces. The developer documentation pages are mixed with user documentation and with site pages. That’s not good.
• No proper multilanguage support.

My proposition is:

• Move wiki to sf.net to MediaWiki hosted app.
• Use it for documentation only.
• Reorder and restructure pages while moving them.
• Don’t use any special theme for it - because it’s documentation.
• Setup CMS in sf.net webarea for generic site contents (download, gallery, news, etc.)

Critique, other suggestions?

I agree to most of what you say.

The wiki is for documentation and can use some standard design template.

It is now a bit confusing to navigate, it needs to be clarified with user documentation, developer documentation etc. A few clear menu items.

Integrated forum and wiki. In design and as it is now there are no easy way to go from forum to wiki.

Ok, after some discussion on the chat it seems that the following will be the correct steps:

1. Setup a mediawiki engine at sourceforge. Initially this engine should have a plain style so it will only include content. It must have plugins to support multi language natively without the need of the hack of suffixes on the web pages. I don’t know if it will be possible but is desired.
2. In an ordered way, copy each page from the current wiki to the new one. Organize them in proper categories, namespaces and languages. Only the documentation for the user and the documentation for the coder should go there. None related to download, galleries, news, press references, donations, etc. should go there. This classification is pending.
3. Once a page is transfered to the new wiki the page will be locked and a link to the new page will appear in the header of the page. In this way all the wiki should be transferred to the new place.
4. Setup a cms engine for the non applicable content that goes to the wiki. This web should be more dynamic and express continuous changes of what’s happening around synfig. It seems that wordpress is one good engine (as Yaco likes it). The cms engine must be defined. Please express your preferences.
5. Allow other voluntaries to be able to edit new website.

My preferences for the cms engine:

1. Friendly tools to edit the pages and add new entries.
2. Allow to have same skin in forum and wiki than the website. This means that the new forum engine should be able to import the phpBB database. Same for mediawiki.
3. Username and password integration with sourceforge, website, forum and mwdiawiki. If not possible everything then at last as many of them that were possible.

There are some remaining problems/issues:

1. Wiki and forum usernames and passwords. We should be able to move the users database from one host to other. If not it will be nasty. If we use the same engine (forum and wiki) I think it wouldn’t be a problem.
2. There are some persons that can edit the insight of the wiki. They are controlled using the wiki gitosis that pabs did set up on synfig.org host. I think that we should keep it. Anyone has other opinion on this? synfig.org/gitweb/

Please add more thoughts on this.

-G

I did a research about wiki structurization and multilanguage support and suggesting to reuse Blender Wiki Model for Synfig: wiki.blender.org/index.php/Meta: … iter_Guide .

There are reasons for this.
Instead wasting our time on inventing something new, it’s better to concentrate on reorganizing pages to already known model. They have good templates, already written guidelines for documentation, multilanguage model. The blender and synfig communities look similar for me, and we making step to make synfig documentation process more friendly and familiar for blender contributors. That makes our communities closer and in some meaning that looks like joining efforts.

I have some experience with wordpress (zelgadis.profusehost.net/blog/). I like ti very much but think that blog software (which is wordpress) will not fit good as synfig cms.

Other few random notes:

• Native language support in mediawiki is imply setting up separate wikis for each language. That’s probably not our way.
• Username and password integration with sourceforge, website, forum and mediawiki. That’s problem is hard to solve, because at the moment ofintegration forum and wiki usernames we probably will need completely drop one of them. But we want keep both. So I suggest leave them separated for now.
• I can transfer wiki and forum usernames and passwords when I will install mediawiki and forum to sf.net, but I need VPS access for that.

That’s cool. I like it. it is a good idea to do not reinvent the wheel. I vote for that.

So which are your preferences?

I wish something like inkscape has. It detects automatically the language and redirects the page to the proper language if it exists. I don’t know how it is done.

Ok, I just asked.

So for clarify the steps:

1. Mimmic blender structure. Which cms do they use, which wiki, which forum?
2. If we want to keep the wiki users and forum users we cannot use completely blender structure. Okay so does it mean that we will not have native multilanguage support?

Zelgadis, I’m a bit hard minded lately, so I need to know which are the steps we want to do with clear steps. Sorry for being so bothering.
-G

It is my understanding that this is done via PHP. See here for an example. (The script is GPL 3+ licensed).

Hello to all.

I agree about the problems of current site and mostly agree with all the ideas in this thread.

I think we should use Mediawiki for the wiki, Wordpress for the site and maybe we can keep the phpBB if can integrate it with the others (I know if it possible to integrate phpBB and Mediawiki user db). I suggest Wordpress for the site because its more powerfull than a blog but easy to mantein as a blog. I got high skills on Wordpress site design and offer hours of my time to create the site and a common theme for Wordpress and MediaWiki.

About language manage: we can use the Inkscape trick and also use language extensions for Mediawiki and Wordpress.

I think first step is to create a mockup for all the webpages(i imagine integrated interfaces between CMSs), deciding which content would be in the main site and which in the wiki.

I prefer a small skeleton for some pages than a mockup for all the webpages because it is exactly the badly organization of the pages what makes the wiki not useful.

I agree on define first what should be placed on wiki and what should be placed on website.
Let me start with a quick and rough classification:

Website:

• About
• News
• People
• Download
• Gallery
• Links of interest
• Press
• Challenges
• Meetings (ugh!)
• Screeshots
• Events
• Donations
• Contact

And to the wiki the rest.
I think that the wiki should hold:

• User Documentation
• Developer Documentation

as two main categories.
Then each page should be categorized properly with the following categories (non exhaustive):

• GUI (or synfigstudio)
• CLI (or synfig)
• Configuration
• Layer
• Tool
• Parameter
• Value Node
• Convert Type
• Tutorials
• Video
• Shortcuts
• FAQ
• Panels
• Dialogues
• Import
• Export
• Menu
• Caret
• Toolbox
• Canvas View
• Keyframe
• Waypoint

So a particular wiki page can belong to more than one category depending on its content.
For example:
synfig.org/TCB
should be categorized as:
Synfigstudio|Waypoint|Toolbox

-G

I agree with this proposal.

I agree with you genete on this.

I think the user manual can be further divided into two branches;

• User interface documentation - All icons, menus etc. listed and explained. As the main portion of the wiki is now.
• Using Synfig. - documentation on how to do different tasks and working with Synfig. Much of the tutorials overlaps here and much new material needs to be written.

Damn! Zelgadis, Yaco and I did a meeting using gobby and at the end we didn’t save the file! Arrrrgh!!!

I’ll write here what i remember for now:

======JOOMLA WEBSITE =======
==== SIDEBAR ========

• Home
• About
• News
• Download
• Gallery
• Join us
• Forums (simple link to forums)
• Documentation (simple link to wiki)

==== SIDEBAR END ========

==== FOOT BAR ========

• License
• Site map

==== FOOT BAR END ========
======JOOMLA WEBSITE END =======

(I think I miss some items above)
Of course each item in the side bar connects to a proper page content or to a sub menu depending on the size or complexity of the items.

======MEDIAWIKI =======

There are three Namespaces:

• User Documentation
• Developer Documentation
• Writer Documentation

User Documentation

• Manual
  [list][]Principles of Animation with Synfig (synfig particularities, keyframes, encapsulation, valuenodes)
  [list]
  []Introduction to Layers types

• Layer composition. Blending layers

• Encapsulation

• Synfig ducks

• Keyframes and waypoints
  [/:m]
  []Synfig workflow

• Preparation

• Creating artwork
  [list][*]Creating Shapes

• Adding Layers

• Importing image sequences.
  [/:m]
  []Animation

• Animation Basics

• Rescale Animations
  [/:m]
  []Render

• Previewing

• Rendering
  [/:m][/list:u][/:m][/list:u][/:m]
  []Reference (categorical list for quick reference)

• Layers

• Tools

• Panels

• Types and Convert types

• Dialogues

• Command line interface (exhaustive review of synfig CLI usage)

• Graphical User Interface (exhaustive review of each piece of the gui)
  [/:m]
  []Tutorials (better tutorial for common task, better categorized)[/:m]
  []FAQ & TIPS[/:m]
  []More help (link to contact page)[/*:m][/list:u]

Developer Documentation

• Join to the Team.

• Coding Synfig
  [list]
  [*]Code policies

• Creating Layers

• Creating Panels

• Creating Tools

• Bugs

• Patches
  [/:m]
  [] Building Synfig

• Source code

• Build instructions

• Packaging instructions

• Release instructions
  [/:m]
  []Synfig file format [/*:m][/list:u]

Writer Documentation (this is a copy of Blender guides)

• Synfig Wiki guidelines
• Internationalization
• License(s)
• Style Guide
• Templates
• Custom Styles: css
• DPL Bare Minimum Guide

======MEDIAWIKI END =======

Our reference for wiki:
wiki.blender.org/index.php/Main_Page

Zelgadis, Yaco please use this as reference for the next trial.

To anyone. comments are welcome.
-G

I have gobby session saved:

I think it should be merged with genete’s trial above.
…and here’s a part of conversation:

Thanks for posting Zelgadis - sorry I missed the get together. Give me some warning next time, and I’ll see if I can sneak in the lab and use the non-firewalled network drop when no-one’s looking.

======JOOMLA WEBSITE =======
==== SIDEBAR ========

• Home
• About
• News
• Download
• Gallery
• Join us
• Forums (simple link to forums)
• Documentation (simple link to wiki)

==== SIDEBAR END ========

==== FOOT BAR ========

• License
• Site map
• Standards validation

==== FOOT BAR END ========

====== PAGE CONTENT BY SIDE BAR MENU ==========
Home

• Last news titles (with RSS feed link)
• Last forum posts (with RSS feed link) << I don’t know if it is possible with phpBB
• Link / Button to last version
• Current challenge information and link

About

• http://www.synfig.org/About

News

• Irregular news
• Releases
• News Draft

Download

• Source Code
• Windows
• Linux
• MacOs
• Other

Gallery

• Community [Screenshots|Stills|Videos]
• Voria [Screenshots|Stills|Videos]

Join Us

• IRC
• Forums
• Mailing Lists
• Wiki
• Code
• Debug
• Translate Synfig|Wiki
• Write Wiki
• Promote|Donate

======JOOMLA WEBSITE END =======

======MEDIAWIKI =======

There are three Namespaces:

• User Documentation
• Developer Documentation
• Writer Documentation

User Documentation

• Manual
  [list][]Principles of Animation with Synfig (synfig particularities, keyframes, encapsulation, valuenodes)
  [list]
  []Introduction to Layers types

• Layer composition. Blending layers

• Encapsulation

• Synfig ducks

• Keyframes and waypoints

• Exporting, Linking, Connecting and Disconnecting
  [/:m]
  []Synfig workflow

• Preparation

• Creating artwork
  [list][*]Creating Shapes

• Adding Layers

• Importing image sequences.
  [/:m]
  []Animation

• Animation Basics

• Rescale Animations
  [/:m]
  []Render

• Previewing

• Rendering
  [/:m][/list:u][/:m]
  [*]Advanced Techniques

• Referencing external files

• Exported Canvases

• ValueNode Conversion

• IPO Drivers

• Templates
  [/:m][/list:u][/:m]
  [*]Reference (categorical list for quick reference)

• Layers

• Tools

• Panels

• Types and Convert types

• Dialogues

• Command line interface (exhaustive review of synfig CLI usage)

• Graphical User Interface (exhaustive review of each piece of the gui)
  [/:m]
  []Tutorials (better tutorial for common task, better categorized)[/:m]
  []FAQ & TIPS[/:m]
  []More help (link to contact page)[/*:m][/list:u]

Developer Documentation

• Join to the Team.

• Coding Synfig
  [list]
  [*]Code policies

• Creating Layers

• Creating Panels

• Creating Tools

• Bugs

• Patches
  [/:m]
  []Building Synfig

• Source code

• Build instructions

• Packaging instructions

• Release instructions
  [/:m]
  []Synfig file format [/*:m][/list:u]

Writer Documentation (this is a copy of Blender guides)

• Synfig Wiki guidelines
• Internationalization
• License(s)
• Style Guide
• Templates
• Custom Styles: css
• DPL Bare Minimum Guide

======MEDIAWIKI END =======

Our reference for wiki:
wiki.blender.org/index.php/Main_Page

Ok, I’ve managed to copy wiki to synfig.com/wiki/.
While I’m installing templates and extensions It’s open for editing reorder operations.

The “Recent Changes” link points to an invalid address (“http://www.synfig.com/Special:Recentchanges” instead of “http://www.synfig.com/wiki/Special:Recentchanges”).