The main benefit is the "chunking" of the work into small pieces which should allow anyone to make a contribution.
I hope this helps us to move forward with the documentation in a consistent and constructive manner!
The first thing on the agenda is to write the Style Guide ... please edit it as necessary!
I'm happy to chip in and I see no problem with the Style Guide.
However, I do see an overlap with moodle help, are there any guidelines as to what is a 'HowTo' and what should be a help object?
Since I've not long worked it out myself I'll have a go at how to add a new activity when the style guide is set in stone.
A "task" is "how do I do X"?
Hi to all,
what do you think about Ray's Tutorial http://moodle.org/docs/teacher-matt.html as basis for this project. He wrote abaout a lot of basic tasks for teacher and has a lot off screens integrated.
Ray's done tremendously good job creating his tutorial and it would be a great shame to waste his effort and duplicate the work.
I have some suggestions for moving forward here.
I think we should definatly use Ray's tutorial as a source of content (BTW is he still active? Does he want to be involved?), I used this material to get around moodle and still refer to it. However:
- There doesn't seem to be an index/contents page
- We need to enlarge this material especially as new features are added
I would therefore suggest that we could take this material and 'chunk' it into the HowTos Martin has outlined (I vote for HowTo rather than task purely on the grounds that I haven't heard of a howto before so it can't get mistaken for anything else ).
Once chunked, Rays material forms the basis to which other chunks are added as needed. Updating, expanding, rewriting, and indexing of the material as a whole all become much easier and the chunks can be fitted together with 'glue' material to build tutorials.
Anders, If I read your posts correctly then you are interested in building your own kind of tutorial as an experiment in constructive learning - with the chunks I guess you could do this by writing your own 'glue' fitting them together?
Does that fit in with the suggestions made already? Are there other points we need to consider?
It all sounds very 'learning object' ( pulls scowl like a bulldog sitting on a hot stove), a theory I am deeply suspicious of, but in this case it does seem like the best way to proceed.
All the best
Yes, it is a bit learning-object and I share your caution about that in general, but these really are very small definite objects without much leeway.
I thought this approach would see some collaboration straight away but I'm a bit dissappointed that no-one else has contributed a single item yet ... really, these take ten minutes to write.
Take a look at what Antonio Vicent has already done in Spanish! It has perhaps more screenshots than really necessary, but is a great set of work.
If one more person votes for HowTo I'll change everything to that. My main objection was just that the word HowTos looks funny, but I can definitely get used to it. Note that the most famous HowTos (for Linux) are in fact more like long tutorials.
I like the idea of chopping the tutorial into tasks and would like to contribute a few. Actually, I'll have to create a Moodle Orientation course for teachers by the end of March, so I thought I could just do at least part of the job here and then backup-restore it to my server.
However, I feel totally lost as to how to create those tasks in practice. These are some of the things I'm confused about:
- Each Task will have a unique number so we can refer to it unambiguously.
Do you mean the automatically-assigned resource number or should I set a number, and if so, where?
- All images must be referred to using relative pathnames...
Does this mean that you'd like these tasks to be created as uploaded resources? I created the Introduction for Teachers as an html resource and uploaded the images to the Files area, which means that the links to them are not simple paths like "screen1.jpg"
- Use a limited range of CSS styles
Where are those styles defined? I've had a look at http://moodle.org/theme/moodle.org/styles.php and http://moodle.org/theme/moodle.org/extra.css and haven't found them.
- Define the audience and module it applies to
Where do I define these?
Sorry if these are stupid questions
I see three main roles that map to three main steps to this process:
- Documentation Writers actually write the Tasks and create screenshots. They submit new Tasks in the New Tasks forum as new discussions, with images attached to the post (or a follow up post). Wording can be discussed, rated and refined here, but formatting details are not important at this stage. Authors can suggest keywords in their post.
- Facilitators check these over and approve them by moving them to the "queue" in the Finished
Tasks forum (by any of the facilitators here). They can revise further if necessary (perhaps combining some of the suggestions into a coherent single document or reformatting to help the maintainers).
- Maintainers (me and others) will take finished tasks from that forum and cut/paste the data as files in CVS, under cvs:/moodle/lang/en/tasks. The maintainers are responsible for creating final neat XHTML code and inserting all the correct styles etc.
- In the tasks directory will be one directory per task, named 0001, 0002, 0003 etc.
- Each of these will contain an index.html file and any supporting media files.
- Inside index.html, references to other Tasks should be written as Task0003.
- Inside index.html will be special XHTML tags that specify the list of modules this Task refers to, as well as the list of intended audiences.
This format will allow Moodle to scan all the index.html files to build up a nice database table that indexes the whole caboodle so we can build nice hypertext interfaces.
One small thing, though, I started out calling these HOWTOs and switched to Tasks - now I'm not so sure. Which name is better?
Hi Martin and everyone else involved in this project,
Some points of view...
I can understand that you (Martin) want this part of MoodIe to be consistent with the overall design of the whole system . I am also sure that the new guide lines represent very good computing practice . "chopping" this all up means that everyone's invited to leave small contributions in an organised way. That's great. As far as I can see (and as as far I can be an informed judge of that) the guide lines could also perform very well in relation to demanding criteria for an Information Architecture .
However , if looking at the new focus and the guide lines from a pedagogical perspective or in terms of a didactical strategy I am not quite that sure.
To me documentation is descriptive and in the first place directed to those who already know. What they are looking for is - what is this particular thing all about?
A tutorial is more explanative and intended for those who don't know too much about IT, IS, ICT but need to see and understand the system from another perspective and role (social constructivist thinking...).
I think that both documentation and a variety of tutorials are needed.
Tasks or HowTo ? To me these concepts don't mean the same. However, the didactical questions are why? what? and how? from a variety of aspects. Therefore HowTo sounds better to me and a HowTo can be formulated as a general instruction showing procedures and illustrating principles. Tasks (or assignments, which is a longer word but established in Moodle, I as a Swede, am not so good at differentiating them ) could be some concrete example(s) for the user to carry out. All in all this should be aiming at the following reaction in the user's mind : "Aha ! Now I see. This is obviously how it works." It is not easy getting there using mostly virtual text-only communication...
As for work already done I too recognise that no doubt. However (a longer) text produced could be "chopped" and reused in another design. Without having studied all of the screenshots in Matt's tutorial in detail, I still want to claim that screenshots in general often tend to become too small. Enlarging them takes a lot of time. Often they also cover too many details thus craving too much from the user's memory. In short, using such screenshots is not the best pedagogical practice. Furthermore screenshots are static, they tend to become outdated as the system described or explained changes. What design should they have? Mainly yellow like at moodle.org? They also need to be reproduced in various languages. A database with screenshots in different flavors might be constructed. Well, I don't know a good solution to all these problems but I suggest they be considered.
Finally I am working on a framework (prototype, template) of a tutorial using XHTML and client scripts that is intended to be easily edited (readme's, commented as clearly as possible etc) and easily downloaded to any computer without the necessity of installing all of Moodle (e g PHP/MySQL/Apache etc). Client scripts are used for e g navigation, search and tooltip popups. I will announce it here shortly and make it available through the Moodle "Course Exchange". It is intended to be a (editable) framework that everyone can use as a container for their own design, content and language. I don't claim to be the world's best developer so there may well be flaws in the basic design...
I did look at the sketched framework you sent me, and though it confused me a little (I still don't really "get" the Aha images ), it's a promising line of development that I encourage you to trial and pursue.
You may not have noticed that the Tasks (being an objective one assigns oneself) are only the building blocks from which longer tutorials can be constructed. The formats of these are not decided yet, and could well take the form of your tutorials. The smaller building blocks will be useful on their own, but are intended to make larger tutorials easier to construct, ranging from books to interactive pages with popups etc. So hopefully they can be useful to you too as raw material to draw from.
As for screenshots, I too would like to keep them to a minimum, but occasionally they are important (especially when describing a GUI). Colours don't matter, but they should be cropped appropriately rather than shrunk.
Well, Moodle is a pedagogical tool, right? Consequently Moodle's second broadest audience (Teachers) and the broadest (Learners) will have a lot to - exactly! - learn. Before learning anything else they will have to learn about this tool and about ICT in general. ICT poses specific challenges when it comes to choosing didactic strategies. The tables and figures regarding this in tut_0.zip (not published in Moodle yet, only Martin has seen them) are intended to illustrate the need to get people to understand (which is an important quality of learning). The images, apparently confusing you, need to be put into context though in order to make sense. I am not saying that I am the world champion on making people understand. On the contrary, the fact that you didn't "get it" might prove I am not. I do claim that this is a major challenge to more people than me though.
I don't know about everything that has already been done or what is happening in this field but I think we need development work, testing and research here. As for myself I study ICT (with pedagogy as a considered part) and pedagogy (in direct relation to technology and media) and from both these approaches I intend to produce papers concerning the issues described above. I am likely to use Moodle as a testing ground. This will take at least a year though even if there will be processes going on that I might be able to report about. I can't promise that I will come up with something useful except for shortcomings that others may come to show how to overcome. That on the other hand I can promise.
I knew that you had more things "up your sleeves". It is very interesting seeing the likes of that coming out.
Humour is serious business and so is pedagogy.