Talk:LSL Portal Guidelines: Difference between revisions

From Second Life Wiki
Jump to navigation Jump to search
Strife Onizuka (talk | contribs)
No edit summary
Strife Onizuka (talk | contribs)
Line 13: Line 13:


===[[User:Strife Onizuka|Strife Onizuka's]] Comments ===
===[[User:Strife Onizuka|Strife Onizuka's]] Comments ===
Of the proposed solutions I can only support #3. The first and second solutions proposed marginalize a sizable portion of the community for the only reason of making (LSL Portal) content creation easier. The fourth solution, isn't a solution at all, and so far it has only made people unhappy.
Of the proposed solutions I can only support #3. The first and second solutions marginalize a sizable portion of the community for the only reason of making (LSL Portal) content creation easier. The fourth solution, isn't a solution at all, and so far it has only made people unhappy.


The layout I was thinking of would provide a mechanism for finding information easily (a right side ToC) and have information written in such a way that it wasn't too dense or too diluted. The best way I think to do this is to have the information repeated, ideally in separate sections. The first section would provide it in a short accessible fashion and later sections would be more detailed, ideally with a higher information density but not required.
The layout I was thinking of would provide a mechanism for finding information easily (a right side ToC) and have information written in such a way that it wasn't too dense or too diluted. The best way I think to do this is to have the information repeated, ideally in separate sections. The first section would provide it in a short accessible fashion and later sections would be more detailed, ideally with a higher information density but not required.


Here is a proposed layout, [[User:Strife_Onizuka/LSL_Style]]. The transition to the new layout would only require reworking the appropriate templates but implementing the changes in wording would be time consuming and labor intensive.
Here is a proposed layout, [[User:Strife_Onizuka/LSL_Style]]. The transition to the new layout would only require reworking the appropriate templates but implementing the changes in wording would be time consuming and labor intensive.

Revision as of 13:54, 19 May 2008

The Mission Statement and Goal Statement appear to be cross purposes

The mission is to provide accurate documentation, the goal is to provide documentation suited for scripters of all skill levels. There are two perceived cross purposes that appear to become manifest in the implementation:

  • Accurate documentation can't be phraseologically accessible to new users.
  • Documentation can't help scripters of all skill levels at the same time (the help the new scripter needs is different then that of the expert scripter).

There are a few solutions to this:

  1. Eliminate the Mission Statement and re-target the Goal Statement to new users only, cutting expert users off.
  2. Eliminate the Goal Statement, effectively eliminate both cross purposes but cutting new users off.
  3. Find a content layout solution that mitigates the cross purposes.
  4. Do nothing and let the edit wars rage.

Strife Onizuka's Comments

Of the proposed solutions I can only support #3. The first and second solutions marginalize a sizable portion of the community for the only reason of making (LSL Portal) content creation easier. The fourth solution, isn't a solution at all, and so far it has only made people unhappy.

The layout I was thinking of would provide a mechanism for finding information easily (a right side ToC) and have information written in such a way that it wasn't too dense or too diluted. The best way I think to do this is to have the information repeated, ideally in separate sections. The first section would provide it in a short accessible fashion and later sections would be more detailed, ideally with a higher information density but not required.

Here is a proposed layout, User:Strife_Onizuka/LSL_Style. The transition to the new layout would only require reworking the appropriate templates but implementing the changes in wording would be time consuming and labor intensive.