Hello Francis
I think you are talking more about developer experience than end-user
experience.
The wiki seems a good start for documentation to me but I agree that it
has some serious drawbacks.
For example: we can not easily include swf's and AS3 code formatting is
sub-par. But i think if those requests are
raised to the infrastructure team then they will be dealt with. This
would result in following documentation locations:
*) Wiki: edited documentation, documentation about concepts with example
section
*) Blog: Time-related documentation: Changes/News
*) API-Docs: Generated API documentation
It would be not so hard to provide something like the PHP Ninja manual
[1] that sets up on the online data.
The only problem I see with the wiki solution is the translation. I
personally think "just english" is enough. However: For some reason
japanese developers (as a example) seem to be really trying to translate
everything and I am not yet sure how this could be done with the wiki.
However: this raises another question:
@Adobe: I assume that the Flash Player AS3 documentation will stay at
the Adobe site:
Do you plan to submit the Flex documentation (not just api docs) to apache?
Might that include Tour De Flex?
What system/format does it use?
Can the community help with that?
yours
Martin.
[1]
https://chrome.google.com/webstore/detail/clbhjjdhmgeibgdccjfoliooccomjcab
On 11/02/2012 01:23, David Francis Buhler wrote:
I'd like to see the examples and documentation be part of an improved,
cohesive 'brand' outlined. The rest of the outline I agree with.
Someone else had suggested the idea of emulating the
examples/documentation Sencha/JQuery use, which I second. Likewise,
Google does an excellent job with http://tour.golang.org/
I always found Adobe to offer too many alternatives to finding information.
Examples:
-Adobe offered too many Flex examples in the help.adobe.com site made
accessing the information slow and painful. Future hiding of the
Examples until the user clicked a button made 'seeing' the examples
more involved.
-The Help Docs had poor SEO. Questions asked about technical problems
have a certain language, and the page-titles needed to reflect the
language developers use to search out solutions to problems.
-The Help Docs were longer than necessary.
-Tour De Flex's User Experience did not reflect how people seek out
information. It did not offer a linear evolution of 'challenges' or
'difficulty'. Examples often error out.
-Adobe Community Help provided too many search options, that did not
reflect an understanding of how people look for information.
-Buhler
