[Bf-docboard] About the last e-mails received in the bf-docboard list.

Raindrops From Sky raindrops.fromsky at gmail.com
Wed Nov 17 03:56:34 CET 2010


HI Jason,

You have summed it up nicely!

Also thanks for giving a glimpse about the roundtable (I wish someone wrote
about what was proposed/decided there...)

BTW you wrote-
"It ultimately lead to a lot of dead ends and outdated content... and the
only people who were aware of that were mostly new people who were unable to
fill in the blanks and update the content themselves."

While I will look forward to your suggestions on this, IMHO the sandbag does
not solve these issues at all.

   - If no one writes about a topic, empty sandboxes are no better than
   stubs.
   In fact, empty stubs invite even amateurs to try their hand at the topic.
   A sandbox poses a forbidding barrier. So with stubs, we are likely to
   attract more contributors.

   - Wikipedia uses
hatnotes<http://en.wikipedia.org/wiki/Wikipedia:Hatnote>extensively to
warn the user about potentially
   outdated/contentious/unreliable contents. But it does not block such content
   from viewers till it is "perfect".

   At the beginning, a new stub will have a hatnote like "There is no
   information on this stub.", and later when it has some information, another
   hatnote like "The contents of this page are not reviewed yet. It may have
   incomplete/inaccurate information. Use with caution!"

   Thus the viewers get to see the content early, which is always WIP in a
   wiki by definition.

   I prefer this "get it done" approach to the sandbox's "get it right"
   approach.

Wikipedia also has a catscan
<http://toolserver.org/%7Edaniel/WikiSense/CategoryIntersect.php?wikilang=en&wikifam=.wikipedia.org&basecat=&basedeep=3&mode=cs&tagcat=&tagdeep=5&go=Scan&format=html&userlang=en>tool
to find empty (or even nearly empty) stubs.

****
*@What does this button do?*

In a 380-page pdf help file that I wrote, I  made a separate appendix with
tables (separate for each menu). (It ran into 30 A4-size pages). I made a
separate appendix for context-menus in each window of the application (a
further 7 A4-size pages).

Each record of a table contains one menu item, its equivalent button (if
any), equivalent default keyboard shortcut (if any), what it does (only in
brief) and hyperlink to the article that explains it in detail.

When a user has to locate anything, he can simply come to this appendix and
search. Only the button has to be searched visually - He can search the rest
with CTRL+F in the pdf.

I used the resource file sent by author (exported from MS Visual Studio) to
make sure that I don't miss any of the controls. Python would have its
equivalent trick.

In case of Blender, we can make separate tables for each type of window, and
then cover all controls starting from top.


Regards,
Narayan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-docboard/attachments/20101117/2a42aa58/attachment.htm 


More information about the Bf-docboard mailing list