Revision as of 13:45, 8 October 2007 (view source) Fpe (Talk | contribs) ← Older edit		Revision as of 13:23, 13 October 2007 (view source) Andreasma (Talk | contribs) (→‎HOW_TO) Newer edit →
Line 135:		Line 135:
	| Andreas Mantke		| Andreas Mantke
	|		|
−	| Updated german version (PDFExport) from 24.09.2007.	+	| bgcolor=#BCFFA6 | Update is in the wiki (finished by Andreas Mantke)
−	| Transport to the wiki and then update to new german version (Andreas Mantke works on it.)	+
	|-		|-
	| movies_without_java		| movies_without_java

---

Revision as of 13:23, 13 October 2007

Template:Documentation/BeingEdited

Status Quo/Inventory

Website Content

Situation

The documentation web site repository contains a total of around 5700 files organized into different subdirectories. The following list is an incomplete tree of the documentation/www repository:

.
|-- HOW_TO
|-- Samples_Templates
|-- articles
|-- book_reviews
|-- contests
|-- faqs
|-- id
|-- it
|-- manuals
|-- online_help
|-- quickstart
|-- setup_guide2
|-- testdir
|-- tutorials
|-- user_faq
`-- zh

Conclusions/Recommendation

Issuetracker

Situation

The master issue list has a total of 151 issues, 129 (85%) of which are owned by issues@documentation, i.e. no-one.

Age Distribution This tables shows how old the issues are (day of creation and day of last modification). Age Distribution Age in Years Creation Date Modification Date Issues  % Issues  % <1 7 4.6% Template:Documentation/hbar 26 17.2% Template:Documentation/hbar 1-2 12 7.9% Template:Documentation/hbar 14 9.3% Template:Documentation/hbar 2-3 5 3.3% Template:Documentation/hbar 5 3.3% Template:Documentation/hbar 3-4 124 82.1% Template:Documentation/hbar 106 70.2% Template:Documentation/hbar >4 3 2.0% Template:Documentation/hbar 0 0%

Status Distribution This tables shows the distribution of the status values for the issues Status Distribution Status Issues  % NEW 131 86.8% Template:Documentation/hbar STARTED 17 11.3% Template:Documentation/hbar UNCONFIRMED 2 1.3% Template:Documentation/hbar REOPENED 1 0.7% Template:Documentation/hbar

Conclusion/Recommendation

• Abandon issuezilla as tools to track documentation tasks
• Use issuezilla to track small bugs/RFEs only
• Implement a dashboard/roadmap to track documentation progress
• Implement a wishlist

Proposal for new Organization

Organize By the Most Transparent Way of Approaching a Program

It is tempting to organize the same way Microsoft Office does because people are very familiar with Microsoft Office. The advantage is people will understand and use features more quickly if they are already familiar with concept and location. The disadvantage is there may be a completely new way to doing something which is far more efficient and intuitive then the way Microsoft Office handles a feature.

All of your various ways of learning (multimedia, etc.) can be incorporated into the following wiki structure.

Collaborative Wikis

• Wikis are great for collaborative development. Perhaps restrict access somewhat in order to develop good quality information? Or leave open to everyone, but do not allow changes to become permanent until they've been approved by someone who is able to determine if the information improves the wiki or not. Using the wiki as primary source for all information which can be downloaded locally and even printed as a manual is a good idea.

• Perhaps save OpenOffice.org wiki by version. Primary versions only. Updates can be incorporated as updates to the primary version. When a new primary version comes out users should be recommended to upgrade and the previous wiki should be closed. This will encourage users and developers to put their efforts into maintaining and updating information in the current wiki while still leaving the previous wiki available. Previous wikis can be maintained as an historical record.

Structured Learning

Most users approach a program by looking at what they can see first. If they can make sense of what they see, they will gradually learn more advanced concepts from this starting point.

So the best way to teach a program is to start with what the user sees and explain it in every way possible (text, spoken, multimedia, etc.). If you want to reinforce concepts even more, then include exercises so the user gets hands-on experience.

Do a review of each concept covered as a way of adding repetition - a summary of the material.

After you've covered what a learner sees, then begin to take them into what they don't see (the menu items and what they mean and do).

This is a thorough approach for non-emergency users and will result in a thorough understanding of OpenOffice. As a training mechanism for a company or educational institution, organizing information this way would be ideal. In addition because the information is organized in line with actual program components, updating information and placing it correctly will become much easier.

Your other common type of user will be the emergency user who just has to get something done right away and needs to know how to do it. To my mind, this information can be incorporated into the wiki structure discussed above and made searchable.

Outline of Wiki Concept for OpenOffice

OpenOffice

Base/Calc/Draw/Impress/Math/Writer

• Users

• • First deal with what a user sees when they first start the program
    • Layout
    • Default Toolbars

• • Then deal with every option in detail
    • Menu Bar

• Developers

• • List the requirements to work on software development.
  • Perhaps a "wizard" to assess background and help determine where a person's skills may be most useful.
  • Provide in depth resources and tutorials and contacts for those who want to train themselves to help develop the software. The strength of open source development is the community. Provide tools and know-how to the community and you rapidly increase the pace of your development cycle. I would suggest this is probably one of the most important if not THE most important aspect of open source development. Make it easy for people to learn how to help. Provide tutorials on every aspect of development and watch your development cycle soar.
  • Procedure to develop software. People to contact to get involved – depends on results of "wizard"?
  • Suggestions for development of software
  • Projects currently under development – Lists of people who are currently working on specific projects. Contact information for project leader.
  • Completed Projects – Recorded changes by date and how they will change the wiki help file. These should be linked directly into the wiki for someone to update easily and quickly.

Adding Value to OpenOffice.org

There are other people who are working on projects which will add value to OpenOffice. Clipart and templates are two of these areas. I would suggest perhaps someone be asked to collect all of these together onto a page of links. Put a link in OpenOffice that connects to these pages, so a user can rapidly find new resources instead of hunting for them on the OpenOffice.org website. This will have the added utility of simplifying the website as well. Maybe put a template link and a clipart link under the “Help” Menu?

As a user, one of the first things I looked for was templates and clipart. It took some digging to find the following:

• http://openclipart.org/media/downloads
• http://documentation.openoffice.org/Samples_Templates
• http://www.worldlabel.com/Pages/openoffice-template.htm

Unfortunately the clipart is not easy to get at as the low quality images are png thumbnails and the good quality images are svg which do not automatically open up in OpenOffice. It would actually be a very nice feature to add svg support to OpenOffice with basic editing ability such as resize/rotate/placement, etc. I have no idea how hard this would be. I believe computer art will tend more and more towards vector graphics as time goes on however, because of resize flexibility, quality of image, and better storage. Also computers will be able to handle the calculations involved with greater ease as time goes on.

I'm helping a lot of people with OpenOffice right now. I've set up several businesses with it and I also install it by default for everyone who is not interested in buying Microsoft Office. There are a couple of things which I think could be changed to give more visibility to OpenOffice.

Automatically delete installation files from desktop after installation

Place folder with shortcuts in it on desktop as well as in Program Folder Menu. This will make OpenOffice far more visible and easier to access for new users. If they want to delete the folder containing the shortcuts from their desktop they can. In the meantime it makes OpenOffice.org far more visible.

Question: Firefox is making money for Mozilla by starting with a Firefox Google search page. I'm not sure what kind of mandate OpenOffice has in this area, but what if there was an additional link under the help menu to “Search for Resources” for OpenOffice which takes the user to an OpenOffice Google search page? This would generate additional income for the project without being obnoxious or useless.