Your Ideal Tutorial Setup
Author
I started a tutorial series on advanced C++ structure (for learning purposes) a while ago and have decided to enlarge it with making it start from the beginning and carry out to being able to make a complete DirectX game (I have 12 done so far).
But, I need some help from you guys about the tutorials'' structure and setup so that I can utilize its goodness:
1. How do you learn best when reading a tutorial?
2. What do you like to see in tutorials?
3. What don''t you like to see in tutorials?
4. Do you like quick and to-the-point tutorials, or tutorials that get into the hardcore detail?
5. Anything else?
Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?"
- The Boondock Saints
Goody, I''m a newbie.
1.) I learn well by having something explained thuroughly. (In other words, go into detail about the code)
2.) Great examples, a showing of good programming practices. Stays to the point of the lesson. Somewhat of a sense that the author is trying to act like he is a student himself learning, and how he would want to learn. Questions to ask the users. Quiz''s, Tests, that sorta stuff.
3.) Same stuff I could have found in other tutorials. No examples, bad commenting.
4.) If you read above, you will get the answer. But, HARDCORE, DETAILS, and all that stuff.
5.) Where can I find the tutorials that you have started on? :D
1.) I learn well by having something explained thuroughly. (In other words, go into detail about the code)
2.) Great examples, a showing of good programming practices. Stays to the point of the lesson. Somewhat of a sense that the author is trying to act like he is a student himself learning, and how he would want to learn. Questions to ask the users. Quiz''s, Tests, that sorta stuff.
3.) Same stuff I could have found in other tutorials. No examples, bad commenting.
4.) If you read above, you will get the answer. But, HARDCORE, DETAILS, and all that stuff.
5.) Where can I find the tutorials that you have started on? :D
I think a good tutorial is not too long and focus on something, like the nehe tutorials.
------------------------
- Seby -
www.dfhi-bomber.fr.st
------------------------
- Seby -
www.dfhi-bomber.fr.st
I''m not a newbie but here''s some advice:
4) Combine this. Write the tutorial in such a way that it is quick and to the point. Put several separate textboxes in your tutorial that cover the hardcore details. You can reference these boxes from the main text. Make it so that I can understand the main text without having to read the boxes. That way people can quickly read and understand your tutorial. If they want the hardcore details like the advanced math behind it, they can read the textboxes.
Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]
GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!
4) Combine this. Write the tutorial in such a way that it is quick and to the point. Put several separate textboxes in your tutorial that cover the hardcore details. You can reference these boxes from the main text. Make it so that I can understand the main text without having to read the boxes. That way people can quickly read and understand your tutorial. If they want the hardcore details like the advanced math behind it, they can read the textboxes.
Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]
GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!
Most tutorials I have read always miss the 'Why I have shown it this way instead of the x number of alternative ways it could be achieved', personally I like to know the why as well as the how.
I think you just need to find a happy balance between short and to the point and hardcore information, so if you ever have to veer away from the tutorial topic then link to further reading material instead of trying to explain it yourself.
What would also be nice to have is a glossary of terms and again links to further reading material.
Malal
[edited by - Malal on August 15, 2003 7:24:02 AM]
I think you just need to find a happy balance between short and to the point and hardcore information, so if you ever have to veer away from the tutorial topic then link to further reading material instead of trying to explain it yourself.
What would also be nice to have is a glossary of terms and again links to further reading material.
Malal
[edited by - Malal on August 15, 2003 7:24:02 AM]
Author
quote:Original post by ChaosCommand
5.) Where can I find the tutorials that you have started on? :D
Once I complete a number more, I will begin releasing them one after another at weekly intervals (I think). That''s what my company suggested that I do. I will tell GDNet when that date comes.
quote:Original post by Malal
Most tutorials I have read always miss the ''Why I have shown it this way instead of the x number of alternative ways it could be achieved'', personally I like to know the why as well as the how.
That''s a good point. I will be sure to point out why you need specific things as well as two other ways to accomplish the same thing (that good enough for ya
).
1. How do you learn best when reading a tutorial?
I learn best when all the technical jargon is introduced as it's used. Sometimes it's very easy for an author to swamp the reader in terminology, because it comes natural to them and they expect the reader to be on par with them; I find this off-putting in some material where it makes reading it quite laborious.
2. What do you like to see in tutorials?
I like thinking of tutorials as journeys; you start out at the beginning with a goal, and by the end, you've accomplished that goal. For example, how often do you see someone asking, "How do I learn socket programming?".
Let's say that was the subject of a particular tutorial. It would be nice to have a rough overview of what a socket is and does (not swamping the reader with details as to how TCP/IP works and going into the OS model).
If you want to cover those sorts of extra details, then I feel it's better to demonstrate them once the reader has actually got something to work with first (i.e. You've walked them through making a simple server that listens on a specific port, and sends a message to any clients that connect on that port, welcoming them to the server).
The reason I prefer this approach is because I feel that too much theory without any practical in between, can not only make information difficult to read, but also difficult to remember and implement. How often have you come out of reading a tutorial, thinking that for 15,000 or so words, you've not really taken much from it?
3. What don't you like to see in tutorials?
As stated above, bombarding the reader with details that won't affect them, until they have something practical they can get stuck into - at which point detailed explanations are not only more worthy, but can have more benefits in terms of long-term remembrance.
4. Do you like quick and to-the-point tutorials, or tutorials that get into the hardcore detail?
It depends on the subject I guess. Again, sticking with the sockets examples, a simple tutorial on how to get a socket listening on a port, allowing someone to connect and sending them a message would be nice as a quick, to the point tutorial.
However, if it was supposed to be a tutorial aimed at making a simple chat server, then I'd expect more technical detail.
5. Anything else?
Diagrams can often be helpful for hard to visualise tasks (sorting/searching algorithms come to mind).
Small-scale real world application examples, I personally feel, are the most beneficial to the reader. It's very easy to describe what something is and does, but authors often overlook explaining *why* you would use something (pointers spring to mind - they aren't terribly difficult to understand or implement, just *why* you use them isn't always made very apparent).
Hope this helps, and I look forward to seeing the tutorials in the future.
--hellz
[edited by - hellz on August 15, 2003 3:54:45 PM]
I learn best when all the technical jargon is introduced as it's used. Sometimes it's very easy for an author to swamp the reader in terminology, because it comes natural to them and they expect the reader to be on par with them; I find this off-putting in some material where it makes reading it quite laborious.
2. What do you like to see in tutorials?
I like thinking of tutorials as journeys; you start out at the beginning with a goal, and by the end, you've accomplished that goal. For example, how often do you see someone asking, "How do I learn socket programming?".
Let's say that was the subject of a particular tutorial. It would be nice to have a rough overview of what a socket is and does (not swamping the reader with details as to how TCP/IP works and going into the OS model).
If you want to cover those sorts of extra details, then I feel it's better to demonstrate them once the reader has actually got something to work with first (i.e. You've walked them through making a simple server that listens on a specific port, and sends a message to any clients that connect on that port, welcoming them to the server).
The reason I prefer this approach is because I feel that too much theory without any practical in between, can not only make information difficult to read, but also difficult to remember and implement. How often have you come out of reading a tutorial, thinking that for 15,000 or so words, you've not really taken much from it?
3. What don't you like to see in tutorials?
As stated above, bombarding the reader with details that won't affect them, until they have something practical they can get stuck into - at which point detailed explanations are not only more worthy, but can have more benefits in terms of long-term remembrance.
4. Do you like quick and to-the-point tutorials, or tutorials that get into the hardcore detail?
It depends on the subject I guess. Again, sticking with the sockets examples, a simple tutorial on how to get a socket listening on a port, allowing someone to connect and sending them a message would be nice as a quick, to the point tutorial.
However, if it was supposed to be a tutorial aimed at making a simple chat server, then I'd expect more technical detail.
5. Anything else?
Diagrams can often be helpful for hard to visualise tasks (sorting/searching algorithms come to mind).
Small-scale real world application examples, I personally feel, are the most beneficial to the reader. It's very easy to describe what something is and does, but authors often overlook explaining *why* you would use something (pointers spring to mind - they aren't terribly difficult to understand or implement, just *why* you use them isn't always made very apparent).
Hope this helps, and I look forward to seeing the tutorials in the future.
--hellz
[edited by - hellz on August 15, 2003 3:54:45 PM]
Author
Great. Keep up all the input guys. I''ve taken some notes on what I need to improve apon. I''m on vacation for the next two weeks or so, but I will be back to tell you how the process is goin.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
