Tut is a collaborative tutorial system that uses github as a host for community generated tutorials. It allows teachers and learners to connect online, and is based on scientifically proven principles in order to maximize learning.
Tut is an online learning system for teachers and learners. Tut is both an package manager designed specifically for online tutorials, as well as a learning system that sends you quizzes on your mobile device. The ultimate goal of tut is to take innovations from the world of collaborative software development use those insights to develop an open source tutorial creation system. But that's only half the story. We also make use of scientifically proven learning techniques, and study their effects within our ecosystem in the hopes of further refining them. By using the tut system as a learning, you not only expand your own knowledge, but contribute to what's known about learning and memory as well.
You can use tut as either a teacher or a learner.
I want to teach.
I want to learn .
Learning with Tut is easy. Just head over to the tutorials section to check out what the available tutorials. Learning with tut happens in two stages - the study stage and the testing stage. We recommend you read over the study materials in each tutorial three times, with a ten minute break in between. Then, when you're done, you can mark a tutorial as read. When you do this, we'll start texting you quiz questions (so be sure you fill in your mobile number on the profile page. Any time you answer a question, you'll be provided with instant feedback, so you can test your knowledge! Note: If you live outside the US & Canada, you may not receive the text message (we use Twilio to send the text messages, credits for this service were provided as part of the competition).
Twilio Mongoose Github Jade Backbone (associations, epoxy) Zepto Underscore Smoke.js Reddis (maybe) Mongo
Voting is now closed.
Hi Andrew, I'm readin what you're transmitting, and couldn't agree more that a non-coder is not going to be able to handle markdown. But here's the thing - when we do build a UI aimed at a general audience, we still need to build it on top of something, and we firmly believe github is an amazing backend for that, because it provides a framework for collaborative tutorial development. So due to time constraints, we didn't get a general audience UI built, but make no mistake - using github to host the tutorials will save us a lot of headache in the long run, and was a very deliberate choice on our part.
Hi strathmeyer, thanks for checking out tut. You won't receive the text messages right away, rather you will receive them over time (so if you STILL haven't gotten any, this is indeed a bug). The reason we do this is because it provides for better learning - distributed testing is more effective than being tested en masse at the end of studying.
That being said, we will be adding an in page testing for learners who want to take a quiz when they feel like it. However, we wanted to debut tut with a distributed testing feature, as we feel that's one thing that really sets us apart. As we move forward however, we will also bring in in-page testing (only so much you can do in 48 hours though).
You're also correct that the command-line publishing system is a barrier for non-technical users. However, we firmly believe that using a package manager to distribute tutorials is something that is sorely needed in the world of online learning. We'll be adding more user-friendly tutorial creation (we have had a schoolteacher already volunteer to act as a test case for this) but that will run on top of the package manager that was developed for tut. So building the package manager was a critical first step in tut's development (and again, only so much you can do in 48 hours).
Thanks again for your comments, and if it's not too much trouble, could you let us know whether you did ever receive the quizzes via text. It does seem to be working for users in the U.S. & Canada.
I did! I've updated my review.
Great. Regarding scheduling of quizzes - we will indeed add that feature our user profiles (tentatively called a QuizMe time) so that users can indicate when they want to get texts. The way we do it now (and so that you don't get a pile of unwanted messages from us) is that you'll only get the next quiz question after you've answered the previous one.
Hey there, thanks for the feedback. As we move forward, we will indeed make the quizzes available on the site itself so you can take them when you want (only so much you can do in 48 hours, thouhg).
However, we debuted tut with the SMS feature for a very deliberate reason. The purpose of the SMS quizzes is to distribute the testing over time - so you wouldn't be going in between computer and phone. You'd study, mark the tutorial as read, and then tut would send you quiz questions at semi-random intervals (so you never know where you'll be, hence relying on phone tech). Check out our science docs on the main page for the full rationale behind this, but the short story is, you tend to retain more information from that form of testing, rather than being quizzed all at once at the end of studying.
Thanks again for your comments, and yeah, we're going to keep going after the competition finishes. This is just the beginning for tut.
Uva Wellassa University of Sri lanka
Good call - we've updated the judging instructions.
Thanks, we are definitely going to be continuing on with this project. And as you've pointed out, scraping the READMEs and integrating them with the main site is definitely on our job list.
However, I'd like to take this time to explain the rationale behind the text messaging. We believe SMS quiz questions are really valuable, and why we chose to debut that feature during the hackathon - it's a better way of learning. When testing is distributed over a long period of time, and happens out of the blue, you tend to retain information better. So we didn't just do this because it's a fun feature, we did it so our users could learn more effectively (check out the science link on our main page for more about this).
Lastly, we apologize if the messages didn't reach you, and have adjusted the judging instructions to indicate the quizzes may not be received outside the US & Canada (for your information as well, we used the Twilio credits we got as part of the competition to make this happen).
Thanks again for your comments and taking the time to evaluate tut.
Hi Swaagie, thanks for your comments. We definitely agree that we need to put more time into the interface (only so much you can do in 48 hours), but we want to stress that the integration of github into our service was very deliberate.
One of our main goals was to provide a system for the collaborative development of online tutorials. As a scientist myself I'd rather work on document editing within github (rather than emailing around word documents as we usually do) - frankly, software developers are miles ahead of the game when it comes to working together, there's a lot that we in academia and research can learn from them.
So one of the things we are really trying to demonstrate with tut is that gitub doesn't just have to be for code. The version control, the commenting, the tagging, the creation of issues, all of these are just as important in the development of educational materials as they are in the development of software.
So certainly, the interface and flow could use some work (and we will get on that after the contest is over), but one thing that won't change is the use of github as a means to host the tutorials, because it really is a great tool for that. Thanks again for your comments and taking the time to check out tut.
Actually you got a very good point there, added 2 stars for design. I'm coming from an academic background myself as well and I often wondered why people don't use github to do collaborative scientific writing.
Fagbokforlaget V&B AS
Hi iapain, thanks for your comments! We couldn't agree more that most teachers would not want to write their own JSON files (and it's certainly true in the US and Canada as well).
However, there's only so much you can do in 48 hours. Since most of the people who would be evaluating tut would be avid JS coders, we figured this was a good solution for, plus JSON is a great format for what we're doing here.
However, as the project moves forward, we'll be partnering with teachers (we already had one elementary school teacher volunteer to help test it) in order to make sure we could create an easy to use UI allows them to create the quiz files, without having to touch the JSON themselves.
If you type in npm install tut -g we built a whole package management system. The json file is loaded from github to confirm ownership when updates are published, like Bower :)
The listing itself is just a pretty view of the tut.json files which we pas and store in a DB
I hop this clarification helps, we put a lot of work into the CLI package manager :) http://github.com/bcoe/tut
Wrote that from my phone, excuse the typos :) I implore you to checkout the tut CLI tool though, I think it's exactly what you said we are lacking.
Hi Zach, great comments. To say that implementation could be an improved is an understatement. We will eventually build in a web interface so that you can be quizzed online whenever you feel like it.
But here's why SMS-based quiz questions are really valuable, and why we chose to debut that feature during the hackathon - it's a better way of learning. When testing is distributed over a long period of time, and happens out of the blue, you tend to retain information better. So we didn't just do this because it's a fun feature, we did it so our users could learn more effectively (check out the science link on our main page for more about this).
Lastly, the 'How to make a tutorial' tutorial does provide more information about the files and learning system. Thanks again for your comments!
Ah, I probably should have read the tutorial more carefully then. :-) It'd be awesome in future versions to add that info on the tutorials page.
Your reasoning for SMS is great too. I've re-evaluated it now. Cheers!
The website itself does not have any realtime components. Having said this, I think Node.js was a natural choice for the application.
The package registry that we built can be installed via NPM, and uses a lot of great node libraries like Request, to pull information in from Github: https://github.com/bcoe/tut
The part of the app that schedules text-messages is a long-lived Node.js service, Node was a great choice for building this.
We do eventually plan on having more realtime components in the website itself, e.g., a leader's board. But I think we did put node to good use :)
Accourding to your explanation, I completely agree :) Thx!
Hi Jason, so would we! In the time we had, that's all we could come up with (the 'How to make a tutorial' tutorial is the only fleshed out one at this point.) Over the next few days we hope to see some more tutorials added by us and the community.
Thanks for your comments (and the tip about GVoice, can't say we've tested that).
Seems like it just took a bit - I got the text and it worked just like I thought! Bumped my stars a bit to reflect :)
I agree that it stinks that we ran out of time before we could publish any well polished tutorials. We'll be working on flushing these out over the next few days.