I was tired of discovering and fixing bugs, so I decided to create new resource type - mutipage resource.
It is not finished, language file is missing. I have tested it only with latest CVS 1.4.2+
Here is a screenshot.
Tired? Creating resource types to take a break?
A M A Z I N G ! !
Ciao
A M A Z I N G ! !
Ciao
!
Looks simple and easy. Check it straight in to 1.5 whenever you feel it's ready!
Not sure about storing all the pages in one field ... you're welcome to add a new table like "resource_multipage" to do it more scalably.
Hi Petr!
How is this different from your really great "Book" mod??
WP1
Hi Petr, looks nice, but I have come to really like the print features of book, will those be included?
I know Martin has issues with printing, but we try to talk faculty into using book rather than word or acrobat, due to its very nice formatting and pagination issues. Faculty here anyway, often want their students to print, so they use acrobat or word, which are alot harder on the netword and tech support than html in book.
So for us it's one printable resource replacing another rather than adding print features to what should be read on the web.
Also, what about custom style sheets, will MP resource support those?
I know Martin has issues with printing, but we try to talk faculty into using book rather than word or acrobat, due to its very nice formatting and pagination issues. Faculty here anyway, often want their students to print, so they use acrobat or word, which are alot harder on the netword and tech support than html in book.
So for us it's one printable resource replacing another rather than adding print features to what should be read on the web.
Also, what about custom style sheets, will MP resource support those?
It took me only 2 hours to modify normal web page resource to get this. I have changed/added some 60 lines of code, the database structure is not changed. The internal storage is very simple, all pages+titles are merged into one string ($resource->alltext) with special tags. For decomposition is used regex magic.
It is very primitive, I do not intend to add features to it (such as printing, navigation, page reordering, etc.). I want to add some new features to my Book module, but it will be less user-friendly for new users - so I need something very simple. If Martin likes it, I could finish it and push it into 1.5dev.
skodak
It is very primitive, I do not intend to add features to it (such as printing, navigation, page reordering, etc.). I want to add some new features to my Book module, but it will be less user-friendly for new users - so I need something very simple. If Martin likes it, I could finish it and push it into 1.5dev.
skodak
Hi Petr!
I am still unclear. How is this different from the "Book" mod? What types of things could this be used for?
WP1
I am still unclear. How is this different from the "Book" mod? What types of things could this be used for?
WP1
Hi,
Petr, great addition that I know will have some definite use when I need to put up a collection of related web pages but not as organized as a book.
W, As I look at Petr's description and screen shots, (haven't installed code yet), I'm thinking of a multipage resource like a bunch of related articles stapled together, ie "a student handout".
To me a "book" has a definite topic or subject focus with some objective in mind containing a dynamic table of contents plus the ablity to add or link to other resources. ie "the textbook with self-tests at the end of each chapter and a CD in the binder". (I'm used to content modules in WebCT CE, learning modules in WebCT Vista and learning units in Blackboard, all which are similar to a Moodle book.)
As to a useful example, how about a multipage project assignment "handout"? When I taught horticulture I assigned projects where the handout detailing the project requirements was about 6 printed pages long. Too long to put into a single web page but not really appropriate for a content module/learning module/learning unit/book either. Petr's multipage resource would have been a perfect tool for this example were I need just a very basic navigation menu on the side and maybe but not necessary "previous/next" page links.
As another example, I used to have the students write one-page newsletters with very strict requirements that the article must fit on one printed page in a typical "newsletter" format. With the multipage resource, I could assemble all the newsletters in one "packet" for "distribution" to the students. Again, it's something that would not necessarily fit in a Moodle book.
Cheers,
Bob
Thanks!
I do welcome any usage scenario - please post it here. I did not think how to use it yet myself - I did it only because I thought it would be fun.
I have decided I will complete this new resource type and commit it to 1.5dev and prepare a patch for 1.4.3 too (in case anybody wants to use it now).
I will think more about the technical details today. IMO the benefits of storing multiple pages in one field alltext are:
I do not expect that people will use more than 20 pages, so the total limit 64kB should not be a problem.
skodak
PS: Shall I do a template for custom resource type that uses regex to store data in alltext field??
I do welcome any usage scenario - please post it here. I did not think how to use it yet myself - I did it only because I thought it would be fun.
I have decided I will complete this new resource type and commit it to 1.5dev and prepare a patch for 1.4.3 too (in case anybody wants to use it now).
I will think more about the technical details today. IMO the benefits of storing multiple pages in one field alltext are:
- no need to change database
- easier to program - one regex == several SQL selects
- faster - all pages must be loader anyway to construct TOC, less database iteractions
- no need to change backup routines
- very simple ordering of pages - this is the most complicated part(Book now uses some weird linear ordering, I am going to change it to tree structure in v2)
- very easy to maintain - the code is nearly identical to Webpage resource type
- fully compatible with 1.4.2+ and 1.5dev - AFAIK first example of custom type (is it?) there should be more of them
I do not expect that people will use more than 20 pages, so the total limit 64kB should not be a problem.
skodak
PS: Shall I do a template for custom resource type that uses regex to store data in alltext field??
Hi Petr!
Please reconsider about the "PrintFriendly" feature. It really makes life easier and uses less paper. Maybe you could make it an optional feature.
I agree with Michael Penney on this.
WP1
Please reconsider about the "PrintFriendly" feature. It really makes life easier and uses less paper. Maybe you could make it an optional feature.
I agree with Michael Penney on this.
WP1
Technically printing is not a problem, I did not know that people actually need it. I could recycle some book parts... I would like to know what Martin thinks about this first 
The visual design is now hardcoded, but could be incorporated into themes. Anyway it is only a list and table with two cells - it is extremely easy to customize.
skodak
The visual design is now hardcoded, but could be incorporated into themes. Anyway it is only a list and table with two cells - it is extremely easy to customize.
skodak
Probably just a "Show all pages" button which would remove the TOC and show everything concatenated on one long page would be the easiest way to satisfy the tree killers.
These are good advantages to be sure (but mostly advantages for the programmer)
I think we can assume that people are going to easily break that size limit (especially using HTML), and there will be complaints about it here within days of 1.5. Another reason might be later when we (finally) add decent searching - it will be better to have the pages separate.
It should be pretty easy to call this to get all the pages for display.
get_records('resource_multipage', 'resourceid', 5, 'sortorder');
Yes, this is the first new resource type and yes there should be more of them! Plenty of room in that menu!
I think we can assume that people are going to easily break that size limit (especially using HTML), and there will be complaints about it here within days of 1.5.
It should be pretty easy to call this to get all the pages for display.
get_records('resource_multipage', 'resourceid', 5, 'sortorder');
Yes, this is the first new resource type and yes there should be more of them!
Hi Petr,
I think this is a great idea--and could be used differently than the book. Whereas the book is a great tool for creating course resources with images, flash, and lots of "stuff"--I envision this tool as a good way to place "news" and articles on a site--or in a course.
I have been messing around with phpWebsite since its structure is very simple and similar to Moodle (I am using it as an "intranet" type of portal for Moodle). I have loaded an add-on module someone developed for it called Article Manager. Articles are added similarly to the way a book page is added--and each additional page is added as a new section which automatically creates navigation. A search box for Articles is added to the page also. For the settings, you have the option of allowing users to add comments or to submit their own articles. Your articles can have categories, and you can have "featured" "latest" or "most popular" articles appear as links in a box on the page also. You can choose a template--the default or add your own--for the article page style. And you can set a "future" publish date and an expirations date and other stuff.
Each article has a print and email link also. Here's a screenshot of a "test" article I created--the edit and delete links are when logged in as a teacher or admin, of course.
Petr--if you want to test this module out, or if you want me to send you the code, let me know.
Very nice and inspiring, again, like book, a great help for teachers starting with their first steps in Moodle. It again triggers my ("book") wish to have the opportunity to allow students to create resources with it.
Martin, I was wondering: How easy is it to implement the following Soc. Constr. mechanism on a level above the individual modules:
- Create a course and fill it as a teacher with resources and activities.
- Show always the edit button in the breadcrumb bar (remove the teacher check)
- When a student visits a course home page, he sees now also the "add resources button" on the right part of the breadcrumb bar.
- when he opens the page for editing, he sees the teacher created resources, but they stay closed!!
- ...But it shows him the add resources menu, allowing him to add resources/activities with edit-rights.
- When he - as a student - creates a res/act, Moodle adds the ID of the creator (new code part) but leaves the field empty when he is a teacher in that course*
- When he opens the page a next time for editing, he will see:
- the res/act of teachers still closed
- the res/act with the edit buttons on the right side if students were the creators.
- it allows him - as a student - only to edit student added resources/act.
In my humble knowledge of Moodle it only asks for a change in only small pieces of code (to add creator id to each new res/act*) and a small change in the "show the homegape in edit view":
- Show always the edit button. (remove check)
- change the "show course homepage" in edit view:
- IF you - teacher or student - push on the edit-button
- AND you are student in this course
- AND the res/act id is the same as your account ID,
- Then I, Moodle, show you that resourse in editview. (And allow you to follow the path to the edit that resourse page??**)
- ELSE: I show the page in normal teacher edit view (all editable)
In the next release you could - during resource creation - offer the teachers of that course (or even better: that student) the opportunity to make that resourse personal, group or course dependent?)
* to stay compatible with courses created in previous releases, a resource with no id is by default from the teachers)
** here are my doubts about Simple...
*** how can other students see, which res/act is student created? should they see only their own additions? (or the ones of their group)
Thanks for all the feedback from everybody!
IMO the multipage should be kept simple both from user/developer perspective.
To Martin:
The present editing layout (all pages displayed in one screen during editing) is not suitable for extensive texts. To prevent possible questions/complaints I can add some warning (in big red letters - WP1 style), that the MP resource is intended for text with less than 15 pages or 64kB total - it would be displayed only when there are more than 10 pages or 40kB.
To Chardelle:
Moodle is IMO missing Article module, I do like Mamboserver very much just because of articles. It should not be difficult to create new Article module, or better the Data module could be used for it. Articles would be great for moodle frontpage.
To Ger:
Books and Resources were intended only for teachers to bring some reading to courses. I had a brief look at Teemu's Form module, it is one way to go for new Data module. The data module should have IMO some custom templates that should solve your needs.
I will get to MP resources again after version 1.4.3 is released
IMO the multipage should be kept simple both from user/developer perspective.
To Martin:
The present editing layout (all pages displayed in one screen during editing) is not suitable for extensive texts. To prevent possible questions/complaints I can add some warning (in big red letters - WP1 style), that the MP resource is intended for text with less than 15 pages or 64kB total - it would be displayed only when there are more than 10 pages or 40kB.
To Chardelle:
Moodle is IMO missing Article module, I do like Mamboserver very much just because of articles. It should not be difficult to create new Article module, or better the Data module could be used for it. Articles would be great for moodle frontpage.
To Ger:
Books and Resources were intended only for teachers to bring some reading to courses. I had a brief look at Teemu's Form module, it is one way to go for new Data module. The data module should have IMO some custom templates that should solve your needs.
I will get to MP resources again after version 1.4.3 is released
I do agree Petr on keeping things simple. Actually, I really would rather spend my time/money developing a CMS to integrate with Moodle and do the stuff a CMS should do--e.g. article and newsletter management, etc. and see Moodle's development time/money spent on making the things that Moodle should do even better--e.g. the quiz module (multi-part quizzes with graded sections, final feedback based on total score, better page layout) and better user management and reporting (showing progress through a course, a page that shows all coures taken or in progress with grades, start/end dates, etc.).
Hi Petr!
"...I can add some warning (in big red letters - WP1 style)..." 
WP1
"...I can add some warning (in big red letters - WP1 style)..."
WP1
Hi Petr, and everyone else:
After looking at Petr's multipage resource, I discovered how much I needed it. Because I had concerns about scalability - we will use it for many large pages - I made the changes Martin suggested, and a few more. Here is the results of my mods.
Unzip the attached file into your '/mod/resource/type' directory to use them. You will also need to create the new data table. To do this, point your browser at: http://[yoursite]/[yourmoodle]/mod/resource/type/multipage/db/mysql.first.php' after unzipping the archive.
Changes:
Feel free to try it, and provide feedback.
Petr, I know you're busy, so I hope you don't mind me messing with your code.
mike
After looking at Petr's multipage resource, I discovered how much I needed it. Because I had concerns about scalability - we will use it for many large pages - I made the changes Martin suggested, and a few more. Here is the results of my mods.
Unzip the attached file into your '/mod/resource/type' directory to use them. You will also need to create the new data table. To do this, point your browser at: http://[yoursite]/[yourmoodle]/mod/resource/type/multipage/db/mysql.first.php' after unzipping the archive.
Changes:
- Created a new table ('resource_multipage') to hold each page's content.
- Added a 'pagenumber' field to the table to allow organization of the pages. FUTURE - add resequencing of existing pages.
- Added a 'reference' field to the table to allow for a page's content to be a reference to an existing URL (FUTURE).
- Added a page next and previous navigation to the top and bottom of each page.
- Added each page's title as a header for each page.
- Enclosed the each page in a tag with the class 'multipage' so that new styles could be applied to the title and page nav easily.
Feel free to try it, and provide feedback.
Petr, I know you're busy, so I hope you don't mind me messing with your code.
mike
Great! Go ahead.
The more people work on it the better
I hope I will return to my Book module soon after 1.4.3, I will improve caching and some other minor issues. If you wish you can use current printing stuff from it or I will implement it later myself
skodak
The more people work on it the better
I hope I will return to my Book module soon after 1.4.3, I will improve caching and some other minor issues. If you wish you can use current printing stuff from it or I will implement it later myself
skodak
Hi Mike!
I would like to ask you what is the status of your modifications? I would like to push this into 1.5
I could also finish my original code now (2 days work??), it would be still possible to replace it with your code later - the database update script would be quite simple.
Or we can make two different multipage resource types - mine could be multipage and yours minibook, handbook, manual, article or whatever else (any ideas anyone?).
What do you think?
I would like to ask you what is the status of your modifications? I would like to push this into 1.5
I could also finish my original code now (2 days work??), it would be still possible to replace it with your code later - the database update script would be quite simple.
Or we can make two different multipage resource types - mine could be multipage and yours minibook, handbook, manual, article or whatever else (any ideas anyone?).
What do you think?
Hi Petr -
I pretty much finished with it with the code above...
Do you want me to commit it to CVS?
mike
I pretty much finished with it with the code above...
Do you want me to commit it to CVS?
mike
I have several questions:
I did not test it on my server yet, I just went through the code. I am going to try it tonight.
IMHO it should be commited to contrib first and after all above is solved, it should be moved to 1.5 HEAD...
skodak
- how will be solved backup/restore?
- printing?
- are you going to add page reordering and inserting now?
- how to remove page?
I did not test it on my server yet, I just went through the code. I am going to try it tonight.
IMHO it should be commited to contrib first and after all above is solved, it should be moved to 1.5 HEAD...
skodak
Hi Petr -
Sorry. I didn't realize you were leaving those pieces to me. I haven't worked on it since I posted above. I can at some point, but I'm not sure when I'll get to it.
I agree: contrib is the place for it.
mike
Sorry. I didn't realize you were leaving those pieces to me. I haven't worked on it since I posted above. I can at some point, but I'm not sure when I'll get to it.
I agree: contrib is the place for it.
mike
No problem, I thought you wanted to finish it I do not want modify the database and backup/restore of resource module, it is lots of work/testing. I have done it before in Book v1.0, it took longer than expected. Anyway I got new ideas for Book v2.0, but I do not have time to do it now 
I think I will finish my former code for multipage resource and place it into contrib too. There is only one problem, we should use different names for it - which one do you want?
skodak
I think I will finish my former code for multipage resource and place it into contrib too. There is only one problem, we should use different names for it - which one do you want?
skodak
I don't think there is enough difference between the two to warrant different modules. What is there in the stuff that I did that you don't think is appropriate?
mike
mike
I do not like the extra database table, that's all. My approach is only a new Resource format. In your case you must change database structure and the Resource module itself.
IMO if somebody needs booklike resource, your solution is not good enough (yet?). Looking back at my Book v1.1 it is not optimal too, its internal structure is not good. I am still only dreaming about Book v2, but I think it is better not to extend Resource module - IMHO it is complicated enough.
Anyway I would like to encourage you to continue, competition can be very useful
skodak
IMO if somebody needs booklike resource, your solution is not good enough (yet?). Looking back at my Book v1.1 it is not optimal too, its internal structure is not good. I am still only dreaming about Book v2, but I think it is better not to extend Resource module - IMHO it is complicated enough.
Anyway I would like to encourage you to continue, competition can be very useful
skodak
What is your issue with the extra database table? This seemed to be the recommended way (http://moodle.org/mod/forum/discuss.php?d=16052&parent=76590).
Extending the resource module seems the optimal way to do this. That's the great advantage of OOP.
I think we're dealing with a philosophical issue here. In my mind, the book module really belongs as a resource type. Resources are pieces made available to the students to provide some information. They are by their nature, fairly non-interactive (unless you count page turning - which I don't). The other module/activities are interactive. The student is invited to participate and contribute to them.
For this reason, I would think it would make more sense to try and make the book module a 'book' resource - unless you are planning on making it an activity with student interactions.
In any case, I really don't think I want to develop a different multi-page resource. Competition may be healthy, but I think collaboration is better.
mike
Extending the resource module seems the optimal way to do this. That's the great advantage of OOP.
I think we're dealing with a philosophical issue here. In my mind, the book module really belongs as a resource type. Resources are pieces made available to the students to provide some information. They are by their nature, fairly non-interactive (unless you count page turning - which I don't). The other module/activities are interactive. The student is invited to participate and contribute to them.
For this reason, I would think it would make more sense to try and make the book module a 'book' resource - unless you are planning on making it an activity with student interactions.
In any case, I really don't think I want to develop a different multi-page resource. Competition may be healthy, but I think collaboration is better.
mike
Sure Book belongs to the resource section, but it does not need to extend Resource.
Why should be Resource the mother of all non-interactive modules??
Why not simply change the mechanism on course page that displays the two lists? You could have all resource types and n other non-interactive modules in one list and the interactive modules in the other.
Extending the resource module seems the optimal way to do this. That's the great advantage of OOP.
OOP is not about extending, inheritance or code reuse - it is about objects, instances, interfaces and the whole design. Extending of classes only removes repetitive code. Anyway I do not like classes in PHP4 at all, PHP5 is much much better. In case of your proposed code we can not speak about extending, it would be a major modification of Resource module.
The bigger the module the harder it is to maintain it. I do favour many small modules instead of one swiss knife Resource module. If you combine Book and Resource it will have 3 database tables instead of 1 and twice as much lines of code
Why should be Resource the mother of all non-interactive modules??
Why not simply change the mechanism on course page that displays the two lists? You could have all resource types and n other non-interactive modules in one list and the interactive modules in the other.
Extending the resource module seems the optimal way to do this. That's the great advantage of OOP.
OOP is not about extending, inheritance or code reuse - it is about objects, instances, interfaces and the whole design. Extending of classes only removes repetitive code. Anyway I do not like classes in PHP4 at all, PHP5 is much much better. In case of your proposed code we can not speak about extending, it would be a major modification of Resource module.
The bigger the module the harder it is to maintain it. I do favour many small modules instead of one swiss knife Resource module. If you combine Book and Resource it will have 3 database tables instead of 1 and twice as much lines of code
Hi Guys,
A multipage resource is great--definitely much needed. I like your definition, Mike, of a resource as a way to present information, and a Module as an interactive activity.
Please don't convert your Book module to a resource, Petr. I would love to see it develop into a Learning Object module. Kind of like a one-click link to an entire topic, including quizzes and other interactivity (maybe using flash
http://moodle.org/mod/forum/discuss.php?d=14822), and focused mini-discussions (maybe with "comment threads"
http://moodle.org/mod/forum/discuss.php?d=17533 ). The possibilites are endless!
Chardelle
Hi Chardelle,
IMO it would be much easier to implement book-like course format. I will remember it, maybe one day I find some free time to do it or a customer to pay for it
skodak
IMO it would be much easier to implement book-like course format. I will remember it, maybe one day I find some free time to do it or a customer to pay for it
skodak
Why should be Resource the mother of all non-interactive modules??
Not sure it needs to be. However, the current course layout of Moodle appears to built around two distinct types of modules - resources and activities. Resources are informational while activities are exercises of some kind.
Why not simply change the mechanism on course page that displays the two lists? You could have all resource types and n other non-interactive modules in one list and the interactive modules in the other.
I suppose we could, but this is no small change. I would think we'd want to enter into this carefully, so we can create some form of resource foundation to build on. That way, we can manage things like backups, searches, file storage, accessibility, etc., in some standard way.
OOP is not about extending, inheritance or code reuse - it is about objects, instances, interfaces and the whole design.
Okay. So change my statement to "That's one of the great advantages of OOP."
In case of your proposed code we can not speak about extending, it would be a major modification of Resource module.
Sorry. I'm really not sure why you are saying this. The code I provided doesn't touch the core resource module code. Its separated out in its own extension of the class in its own file.
Anyway, Petr, the decision to use my idea and/or code is really up to you. I don't plan on providing a separate resource that does pretty much the same thing as another. Martin seemed to prefer the use of a new data table, so I went that route - I also agree with it.
mike
Not sure it needs to be. However, the current course layout of Moodle appears to built around two distinct types of modules - resources and activities. Resources are informational while activities are exercises of some kind.
Why not simply change the mechanism on course page that displays the two lists? You could have all resource types and n other non-interactive modules in one list and the interactive modules in the other.
I suppose we could, but this is no small change. I would think we'd want to enter into this carefully, so we can create some form of resource foundation to build on. That way, we can manage things like backups, searches, file storage, accessibility, etc., in some standard way.
OOP is not about extending, inheritance or code reuse - it is about objects, instances, interfaces and the whole design.
Okay. So change my statement to "That's one of the great advantages of OOP."
In case of your proposed code we can not speak about extending, it would be a major modification of Resource module.
Sorry. I'm really not sure why you are saying this. The code I provided doesn't touch the core resource module code. Its separated out in its own extension of the class in its own file.
Anyway, Petr, the decision to use my idea and/or code is really up to you. I don't plan on providing a separate resource that does pretty much the same thing as another. Martin seemed to prefer the use of a new data table, so I went that route - I also agree with it.
mike
Sure your present code does not touch the code yet, but following parts need to touch it:
The one page layout for editing of multipage resource is not good if you have more than 10 pages. I had to separate module properties from individual page editing in Book. IMO this is one of the reason why people like it.
Without all the further changes above it will not be complete. IMO it is a lot of work.
The new grouping of activities by types seems possible to me. Two functions in module/lib.php:
Module authors could decide its type without hacking Moodle core.
- backup restore of the new table
- page reordering
- deleting of pages
The one page layout for editing of multipage resource is not good if you have more than 10 pages. I had to separate module properties from individual page editing in Book. IMO this is one of the reason why people like it.
Without all the further changes above it will not be complete. IMO it is a lot of work.
The new grouping of activities by types seems possible to me. Two functions in module/lib.php:
- xxxx_get_module_type() - that should return TYPE_RESOURCE or TYPE_ACTIVITY
- xxxx_get_submodules() - replacement for resource_get_resource_types(); giving list of resource formats
Module authors could decide its type without hacking Moodle core.
Just a proposal
In /course/mod.php one could override default resource types module_add_instance, module_update_instance and module_delete_instace call until one is sure these actions are ready to make:
eg in $_POST['course'] part
switch ($mod->mode) {
case "update":
if ($mod->type == 'moduletype') {
if (!$mod->readytoupdate) {
// do this block
your code
break;
}
}
......
So rest of the resource code would be untouched??? That would left the backing up and restoring to be solved.
- Janne -
In /course/mod.php one could override default resource types module_add_instance, module_update_instance and module_delete_instace call until one is sure these actions are ready to make:
eg in $_POST['course'] part
switch ($mod->mode) {
case "update":
if ($mod->type == 'moduletype') {
if (!$mod->readytoupdate) {
// do this block
your code
break;
}
}
......
So rest of the resource code would be untouched??? That would left the backing up and restoring to be solved.
- Janne -
I don't think the page reordering or the page deleting needs to make any changes to the resource core. These can be handled by the mutlipage resource code where it is edited.
But, you are right about the backup. I made an (incorrect) assumption that each resource type had its own backup interface that could be implemented. Without that, it would be impossible to make a backup routine without some change in the resource code. It might be a good idea though, to implement something in the resource module that allowed extensions or replacements to be provided to the backup and restore...
mike
But, you are right about the backup. I made an (incorrect) assumption that each resource type had its own backup interface that could be implemented. Without that, it would be impossible to make a backup routine without some change in the resource code. It might be a good idea though, to implement something in the resource module that allowed extensions or replacements to be provided to the backup and restore...
mike
I suppose we could, but this is no small change.
I second this, several of my faculty freaked when they found two menus on their screen when we upgraded to 1.4. IMO it's good to remember that many users memorize a sequence of steps to get things, and when you suddenly change some of the steps, they are frozen for a while until someone shows them a new sequence to memorize. (this is why for instance in gradebook_cdc, we made the initial interface pretty much the same as the old gradebook, while the advanced features of weighting, categorization, letter grades, etc. are available from the user preferences so folks can turn them on if they want them or keep grading the same old way if that is what they are used to).
IMO, it would be nice if major interface changes could be minimized, and if possible, new course formats created with the interface changes rather than changes to all formats, so that busy, non-technical users who are comfortable with the system can enjoy bug fixes and security upgrades behind the scenes, without have to relearn a new interface every few months, while the new interfaces could be available to the tech savvy and the adventurous by choosing a different course format (or 'advanced' in their course preferences.
I second this, several of my faculty freaked when they found two menus on their screen when we upgraded to 1.4. IMO it's good to remember that many users memorize a sequence of steps to get things, and when you suddenly change some of the steps, they are frozen for a while until someone shows them a new sequence to memorize. (this is why for instance in gradebook_cdc, we made the initial interface pretty much the same as the old gradebook, while the advanced features of weighting, categorization, letter grades, etc. are available from the user preferences so folks can turn them on if they want them or keep grading the same old way if that is what they are used to).
IMO, it would be nice if major interface changes could be minimized, and if possible, new course formats created with the interface changes rather than changes to all formats, so that busy, non-technical users who are comfortable with the system can enjoy bug fixes and security upgrades behind the scenes, without have to relearn a new interface every few months, while the new interfaces could be available to the tech savvy and the adventurous by choosing a different course format (or 'advanced' in their course preferences
I must agree Michael,
by coincidence I was just thinking about possible new course formats
by coincidence I was just thinking about possible new course formats
Thanks for the explanation Bob.
WP1
WP1
Great, Petr! I use the book module a lot, so this is a very welcome move!
But why have you decided to develop the book separately from the multipage resource? I think I remember Martin saying that the book might become a multipage resource.
Way to go Petr, thanks! 
I have resurrected the idea of multipage resource, because I needed it for my extreme customisation at www.rdv.vslib.cz.
I did not make any substantial changes in the code itself, just some minor patching for 1.5.2+.
Should it go into 1.6? (I still do not believe that full implementation with lots of tables, reordering, muliple levels, etc. should be part of Resource module)
I did not make any substantial changes in the code itself, just some minor patching for 1.5.2+.
Should it go into 1.6? (I still do not believe that full implementation with lots of tables, reordering, muliple levels, etc. should be part of Resource module
Looks interesting. I hadn't realized this had ever been proposed until this post appeared (I first saw Moodle in April), but I have thought I would like to try a multi-page resource. Is it available for testing in 1.5.2+?
Now I'm into a project where I could really use it. So again, is it available for download to use with 1.5.2+?
It is available in one of the posts above, but it is unsupported. If you know just a bit about PHP it should not be a problem
The tabs are not part of the multipage, but it is just a simple theme hack (a list styled by CSS).
The tabs are not part of the multipage, but it is just a simple theme hack (a list styled by CSS).
Thanks. I wasn't looking for tabs, just your current version:
I did not make any substantial changes in the code itself, just some minor patching for 1.5.2+.
The only versions I find here are an initial version you offered on Dec 9 and Mike's reworking on Dec 14, with new tables. I expect it would be better for backup/restore to use a simpler version that does not affect the database structure, especially since I only need 2-5 pages.
"Just a bit" is about my level with PHP so far, so could you attach a current (1.5.2+) zip?
Thanks,
Jim.
Or am I better off simply using the Book module and creating very small books? Also please see related TOC question in Book forum.
Those minor fixes were only for xhtml compliance. But I can not find any usable version, because I have erased my Eclipse workspace recently I only got CSS version which would not be suitable for you.
I like the idea of having a small version of the book module as a resource type. It's already difficult to explain all of the modules to new users. New assignment types / resource types make this easier.
Really impressive layout! It is indeed an extreme customisation. Glad you kept the little spot of orange. Otherwise I wouldn't have immediately recognized it was powered by Moodle
Thanks for all your work behind the scenes, fixing bugs and enhancing security. The outcome may be less visible than this magnificent layout, that's why I wanted to say it is really appreciated.
Did anything happen with this... I could really do with a resource like this at the moment
Hi, Petr S. and Mike W.,
What is the status of the multipage resource? Has this somehow merged with the presentation module? I am working on a very basic Moodle 101 type course and think it would be ideal for many new users.
Thanks,
Art
What is the status of the multipage resource? Has this somehow merged with the presentation module? I am working on a very basic Moodle 101 type course and think it would be ideal for many new users.
Thanks,
Art
I am working with someone who wants to use the multipage resource... He would like to specify the size of the slides (which are really images) in percentages, not pixels. Is this doable?
Thanks,
Art
Thanks,
Art