As this is the place for quick comments, questions and answers, I’ll try to establish a discussion about my diploma project.
all the information currently available can be found here
Please give me feedback and tell me, If you would be interested in having such a printed manual and if you would like to feature yourself in it by contributing.
In the next 2 weeks I have to get a concrete idea, what will be possible in the next three months and discard unrealistic features.
And for this, I need your feedback!
for an endeavor like this i would really like us devvvvelopers to go over some of the introductory texts. or even add some on topics that are still missing. so i would like to hear a list of topics you patchers think are still missing or need some tuning.
Which content would be reasonable for a printed manual?
I’d suggest three things:
- An introduction for the bloody newbie. Similar to the hello world tutorial perhaps, maybe better illustrated or just more fun to read. Could also be a bit shorter, in the style of “don’t exlain everything, for now just follow my steps”. To give fast, satisfying first results. General topic: Introduction
- A “Coffee-Table Book” of great examples, well illustrated and tastefully curated, that you like to browse through like you’re watching MTV. General topic: inspiration
- A regular (say, every 3 months) Newsletter/Digest with the most important updates (new projects, new features, and some “tips of the day” for continuing users), in order to a) improve your existing knowledge b) inspire for your future work c)read about the news. This would also be a place where to publish colums (=subjective texts by one specific author with a secific bias, like ‘usability’, ‘aesthetics’, ‘performance’ etc). The regular interval provides you with an ongoing lure and does not take up too much time at once. Which is what we generally like about periodicals. General Topic: education
Which content is better not printed?
- Reference material. I need that while i work. and this should be heavily hyperlinked material. Better to have online or in the help patches.
- open Discussions and community-related info. Obviously.
- In depth technical knowledge. See ‘Reference’.
d if you would like to feature yourself in it by contributing.
You name the time & place and I’d be there.
by the way, you should set up the rules for contributors: I’ve been editing parts of your diploma wiki pages first, now I’ve posted to this thread. Can be confusing. Determine clearly which goes where.
one more thing: Have you checked out the “structures” feature of tikiWiki? (admin menu-Wiki-structures) Could be useful.
I agree with all of the things said below!
- Tonfilm’s ideas should be considered. But someone has to wirte all the stuff! I’ll see what can be done…
- The structure Max suggests, is similiar to the idea I have about the content of the vvvv manual. We have to elaborate this!
- Contribution rules are coming soon!
I did some research about the dynamic creation of xml documents and did the first few steps…
after further research I can tell you the following facts:
Automatically altering a simple xml structure is quite easy!
Even if it’s too complex to create the entire layout automatically, the asset management will be much easier to handle and thus it wont be possible to use the wrong text or images in a document. Because InDesign shows all Elements (images, text, footnotes) specified by an xml file but not jet placed in a document, the editor has only to arrange all elements. All text extraction, image editing, etc. can be done with automated mechanisms.
In the next days I will make some suggestions about the structure of the print manual. Maybe a first sketch of a table of contents. Preliminary advices are welcome!
Working with the xml templates made me think about the various formatting styles we may need to use in the manual.
Add more items and comments to this list here in the forum or on my Diploma page!
- Big Headlines for Chapters
- Smaller Headlines inside Paragraphs
- The style for long texts
- a style for hyperlinks
command lines / tty renderer output
what are bold/italic for? there should be a VERY strict (semantic) convention of how to use these
bold for really important warnings etc, which need to be seen from the distance
italics to markup special terms or citations, which need to be noticed while reading, but not from the distance.
famous source book for technical documentation:
Apple Publications Style Guide
quite well worth a browse.
and a nice linklist on the way: http://www.usernomics.com/documentation.html
(posting as anonymous because of this anonymous tiki-forum-bug i have yet to find when i find some time to find it)
I allowed myself a nice vacation at home with lots of snowboarding and not much working, but next week I’ll be back in Vienna and then the work begins.
Thanx for the links for techical documentations!