I don;t know if this is the right place to post a few remarks but it’s better to write them before I forget
1. Fig2. is cropped on the bottom, the camera description is not seen
2. FTIR adv/disadv. (pp. 20) should be updated. For advantages the fact that FTIR devices can use IR-blocking foils as opposed to other techniques limiting the IR pollution of the environment. REgarding disadvantages, more and more ppl use Led-Ribbons so soldering is not a must anymore, it should be noted since it cancels this con. Self iluminated fiducials can be easily made so maybe this is not an issue anymore.
3. Projector chapter (pp. 24) should include mirror folding techniques (prolonging the optical path through more than 1 mirror), mirror types (FS/nonFS, ghosting issues) and/or possibly advantages of using them
4. A paragraph on proper ventilation for enclosed boxes might be added, we all know what heat can do to our systems…
5. Protection foils, low-friction foils, projection surfaces types (since there are many tests on the forum for different materials) are all important for the professional feel and look of a multi-touch system. Maybe a few paragraphs for them too…
6. MUlti-touch devices connectivity, cable management, minimal requirements for computer specs, video card issues (integrated/dedicated), general description, not as much as related to one technique
7. Figure caption inconsistency (different fonts, different placement of the caption). THere should be a unified way of writing the caption for tables and figures so that it feels more scientific.
8. I noticed there is no annex on building a FTIR setup. I could write one if there is the need for it.
9. 3rd bullet on the 5th pp has a missing phrase.
10. Proper reference for figures that are not our own should be added to avoid copyright issues. It depends on the type of book the community wants to create. If it’s more scientifical than playful then credit should be due.
11. pp 7 on the 7th row states that “The wave length of IR light is around 880 nm” since NIR is conventionally described as being between 700...1000nm or even 1400nm the description is not accurate.
12 pp7 last row “Playstation 3 camera (640x480 at 30 FPS)” PS3 EYE cams can go higher than 30 fps at this resolution (60)
I am not just throwing this out to the community If you feel my remarks are legit, I would gladly assist on writing /modifying them.
P.S.
Instead of figure 1 which does not show the whole spectrum, the following figure that shows the typical response of a CCD over the human eye might be more appropriate:
I’d really appreciate if you can enter your bug reports one by one there. We’ll keep a log of the issues and report them as a changelog file pointing to the issue tracker, so we’ll know what happens between each update. Otherwise there’s a risk to forget your important post in the dark deepness of the forum.
The release versioning sounds fine, Gorkem (though maybe you want to go with a 1.1, 1.2, 1.3 for the in between revisions, and then increment the major version number, like to 2.0, when you combine the changelogs - again, idea based on std. software dev. practice), just wanted to point out that the development use of the repository was a bit confusing and not standard usage of SVN.
Ty gorkem and sorry for the wrong place to post them it’s better to write them down first and ask questions later
Added all to the nuicode page. Unfortunately they are all under anonymous but if you need my help on those feedback/feature proposals just let me know.
Thanks for adding them to NUI Code, madian.
Ya sorry about the confusion rpavlik Cleaning up now..
-rbedi100
edit:: ok, i got rid of old versions and stuff..how does it look now?
Looks pretty good - the only change I’d make now is rename the .indd and .pdf files to the title of the book so that getting “Nui Community Book.pdf” or whatever from the latest repository has the latest “development” version of the book. You can keep the changelog as a growing file in SVN, as well, so that when it’s time for a release, you make sure everything is up to date, create a ‘tag’ in subversion for that version of the tree, then copy out the PDF file, adding a version number, into the downloads section. Google around for a tutorial on how to use svn to manage an open source project - there’s a good free book (also in print) called “Producing Open Source Software” that should give you a nice intro: http://producingoss.com/en/vc.html - since what you’re basically doing here is managing a publishing product as an open source project, using OSS dev tools, it’s just that your source code is an indesign file and your binary is a PDF.
Thanks for catching that, timominous - tbeta.nuigroup.com redirects to ccv.nuigroup.com, but you’re right, it should reflect the updated link.
-rbedi100
rpavlik - Okay, I’ll take a look at that..what exactly should go in the changelog? Just updates? Or a full log of NUI Code bugs/feature requests that were fixed? We can get the data about tasks that are resolved/still open/etc., with any combination of filters, in Atom, CSV, and PDF so they can easily be included in the changelog.
-rbedi100
I’d say before a release you should put all the tasks for the book that were fixed since the last one - look at http://abisource.com/changelogs/2.6.8.phtml for an example (you’d put the whole changelog in one file, and just have sections for each version, in reverse chronological: that is, put newest release at the top and so on.) The other alternative, is if you can get a nice “fixed since x” pdf from the nuicode system, is make a changelogs directory and put a pdf in each time you make a new release (monthly, say - Don’t do it every time you commit a change, mind you - you should commit a change every time you make an edit, like fix a bug, etc, so that your commit message describes the edit)
it’s better to write them down first and ask questions later 
Cleaning up now..
