Order and Flow

[mikewesthad]

I think it would be a good time to start talking about chapter order and the flow of reading.

After the reading the outlines, I see there are a few core chapters that need to be read in order, and then the others can be read in whatever order the reader prefers. (I'm thinking about absolute beginners here.)

Here's a suggested order of chapters to get people making openFrameworks apps as quickly as possible (important), while also covering the cores:

1. Intro
2. C++ Basics
3. Setup and Project Structure
4. Introduction to Graphics
   • I won't be using much that isn't already covered by C++ and Setup other than vectors
5. OOPs!
6. Animation
   • @ofZach, this chapter has OOP I assume; otherwise, it could come before the OOP chapter
7. Advanced Graphics
8. Memory
9. Network
10. Threads

The rest of the chapters can be explored however the reader feels like exploring. There is probably some sort of progression in terms of difficulty that could be used to organize these chapters, but I'm just listing them arbitrarily:

• Image Processing Computer Vision
• Game Design
• Hardware
• Sound
• iOS
• Android
• Version Control
• Shaders
• Project Elliot
• Project Eva
• Project Joel
• Project Memo

Some chapters are currently blank, so I left them out:

• Media
• Interaction Leaving the Screen
• Data Vis
• Arm Linux
• C++11

[mikewesthad]

Forgot to include Omer's chapters. I don't think those made their way into the collective outlines doc either.

[Onna-no-hito]

OOP should come before c++ shouldnt it, as its an even broader overview?

topics like memory and threads are less sexy-- shouldnt they go nearer the end of the book? chapters that make use of those topics could refer to them as a way to go deeper into the subjects if one chooses?

or-- put both right after 'setup and project structure'?

data vis is in-- will check and make sure the outline is in the chapter folder...

[mikewesthad]

@Onna-no-hito Hmm, I thought C++ Basics should come first because it explains enough of the logic of coding - variables, functions, control statements - so that people could dive into making an oF app without needing OOP. I could be off base here, but it seems like we should enable readers to start doing oF things as early as possible and have them pick up coding concepts on more of an as-needed basis. (If all that seems agreeable, then maybe OOP could be excluded from C++ Basics and covered completely in the OOP chapter @jtnimoy @ruxrux?)

As for memory and threads, those could be later. I put them in core because they are good to read before tackling iOS and sound (respectively). Like you are saying, though iOS, sound, etc. could just have a disclaimer that the reader should be familiar with the memory/threads chapter before reading.

Sorry if I missed data vis, I read through the outlines folder by folder rather than checking the combined doc.

[bilderbuchi]

I wonder how you want to explain basic C++ without touching OOP? Is that even possible? Maybe the two shouldn't be separated at all? If you want them separately, I'd also think OOP should become before C++

[ofZach]

I think you need functions, variables etc before objects, (which leads itself to c++ then OOP). I think it's easy to see how they'd fit since both Josh and Rui have versions of their chapters around.

[admsyn]

Well, there's OOP as in "define a class named Shape and then instantiate one. Then make class Circle that's a subclass..", or OOP as in polymorphism and virtual and message passing and etc...

The former is pretty much just basic C++ syntax, but the latter is more like OOP-as-in-comp sci 101. So, if the OOP chapter is more of the latter stuff, then it's definitely distinct enough for its own chapter IMO :)

[mikewesthad]

I think some of this discussion hinges on who the target audience is (as well as what depth of OOP knowledge we are talking about, like @admsyn says).

If it's a new programmer, then I would say you need variables, control statements and functions before OOP. You can make simple sketches in oF without needing to really grasp OOP. If a reader understands that whatever you put into setup() runs once at the start of your app, and that update() and draw() run once a frame (in succession), then you can start doing things with ofCircle, ofRect, etc. After that you can deepen the readers knowledge with 'OOP-as-in-comp sci 101' so they can start creating more advanced structures.

I think that having the reader make things in oF as early on in the book as possible lowers the barriers to entry for oF as a platform and will help entice readers to dive deeper. Or at least, that's my experience teaching artists who want to start learning code.

(Okay - scratch the idea about leaving OOP out of the c++ basics. It was just looking like a place where we could backload a concept to after getting readers coding with oF.)

[ruxrux]

hi all

the proposed OOOPs chapter is def more on the lines of a practical approach to creating a simple class and making objects from it, a tangible approach to oops and reaching out to polymorphysm - this is based and expanding on the oops tutorial: http://www.openframeworks.cc/tutorials/first%20steps/003_ooops_object_oriented_programming.html I think the difference between mine and Josh approach (pls correct me if i'm wrong) is that Josh is pure c++ based while i take a practical OF approach, there might be redundancies so lets carve them out and make it shine!

looking forward .r

---

http://www.rux-werx-here.net + http://www.vimeo.com/rux + twitter: @rux_twitts_here

On Tue, Feb 4, 2014 at 4:38 PM, Michael Hadley notifications@github.comwrote:

I think some of this discussion hinges on who the target audience is (as well as what depth of OOP knowledge we are talking about, like @admsynhttps://github.com/admsynsays).

If it's a new programmer, then I would say you need variables, control statements and functions before OOP. You can make simple sketches in oF without needing to really grasp OOP. If a reader understands that whatever you put into setup() runs once at the start of your app, and that update() and draw() run once a frame (in succession), then you can start doing things with ofCircle, ofRect, etc. After that you can deepen the readers knowledge with 'OOP-as-in-comp sci 101' so they can start creating more advanced structures.

I think that getting to actually having the reader make things in oF as early on in the book as possible lowers the barriers to entry for oF (and will help entice readers to dive deeper). Or at least, that's my experience teaching artists who want to start learning code.

(Okay - scratch the idea about leaving OOP out of the c++ basics. It was just looking like a place where we could backload a concept to after getting readers into oF.)

Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/ofBook/issues/12#issuecomment-34110159 .

[arturoc]

yeah i agree that basics c++ first then oop makes sense, you don't need to know about polymorphism to be able to use a vector object

[arturoc]

btw, i think the game design chapter sounds more like a project breakdown?

[arturoc]

i've added a couple of new chapters in the original commnet, one for advanced graphics right after animation that should cover ofMesh, ofPath, ofVboMesh... and another about network that would cover some general aspects about network like the basics of tcp vs udp and then an introduction of osc without entering into much detail about the addons which are easy enough to use once you understand the basics and will be covered in some of the project breakdowns

[jtnimoy]

hey there,

I don't think we need to be teaching any polymorphism in order to get the reader up to speed for core OF -- but I'm sure there are parts of our community for which understanding OOP is pretty essential. if i get into structs, then touch classes, it's only because i'm presenting an extension of namespace or "organizing your functions", so i don't consider what i'm teaching to be OOP even though it introduces classes in the most basic way. If Rui wants to get into OOP architecture in an entirely separate chapter, i think that's awesome but yes -- i am uncertain about where my chapter ends and where his chapter begins. @rui i would love to synchronize with you on Skype or IRC or Jabber or something. Do you IM at all?

As I had suggested before, the "language/syntax" chapters need not be adjacent. For breath reasons, perhaps we go into some of the elementary subject matter that clearly omits the need for OOP knowledge, then when the reader is already comfortable with non-OOP programming, we can hit them with OOP as a level-up, and then continue on with polymorphism-heavy chapters after that.

thanks J

On Wed, Feb 5, 2014 at 12:43 AM, arturo notifications@github.com wrote:

i've added a couple of new chapters in the original commnet, one for advanced graphics right after animation that should cover ofMesh, ofPath, ofVboMesh... and another about network that would cover some general aspects about network like the basics of tcp vs udp and then an introduction of osc without entering into much detail about the addons which are easy enough to use once you understand the basics and will be covered in some of the project breakdowns

Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/ofBook/issues/12#issuecomment-34146980 .

[ruxrux]

hey

I can see the ooop's chapter not being a standalone but actually integrated with other content as it's a practical approach, maybe graphics? @Josh let's skype! (it's a bit hard for me to do it after 6pm EST but can always run from the office for a little bit during the day!) Let me take a closer look at your chapter today and I'll ping you for a time slot!

.r

---

http://www.rux-werx-here.net + http://www.vimeo.com/rux + twitter: @rux_twitts_here

On Wed, Feb 5, 2014 at 9:58 AM, Joshua Nimoy notifications@github.comwrote:

hey there,

I don't think we need to be teaching any polymorphism in order to get the reader up to speed for core OF -- but I'm sure there are parts of our community for which understanding OOP is pretty essential. if i get into structs, then touch classes, it's only because i'm presenting an extension of namespace or "organizing your functions", so i don't consider what i'm teaching to be OOP even though it introduces classes in the most basic way. If Rui wants to get into OOP architecture in an entirely separate chapter, i think that's awesome but yes -- i am uncertain about where my chapter ends and where his chapter begins. @rui i would love to synchronize with you on Skype or IRC or Jabber or something. Do you IM at all?

As I had suggested before, the "language/syntax" chapters need not be adjacent. For breath reasons, perhaps we go into some of the elementary subject matter that clearly omits the need for OOP knowledge, then when the reader is already comfortable with non-OOP programming, we can hit them with OOP as a level-up, and then continue on with polymorphism-heavy chapters after that.

thanks J

On Wed, Feb 5, 2014 at 12:43 AM, arturo notifications@github.com wrote:

i've added a couple of new chapters in the original commnet, one for advanced graphics right after animation that should cover ofMesh, ofPath, ofVboMesh... and another about network that would cover some general aspects about network like the basics of tcp vs udp and then an introduction of osc without entering into much detail about the addons which are easy enough to use once you understand the basics and will be covered in some of the project breakdowns

Reply to this email directly or view it on GitHub< https://github.com/openframeworks/ofBook/issues/12#issuecomment-34146980>

.

Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/ofBook/issues/12#issuecomment-34182611 .

[jtnimoy]

ok, attempted to add ruxrux on skype. i hope that is you.

[mikewesthad]

@ruxrux @jtnimoy thanks for expanding upon what you both are doing (both in this issue and in #7) - that was quite helpful

[tpltnt]

Is this still an issue given that there is a "order.txt" file in the "chapters" directory? If there isn't any veto, this issue should be closed.

[bilderbuchi]

I think this can safely be closed, chapter order is pretty mature already.