We don't want to display all the glossary terms on one page, because there are too many. Would it be possible to create a navigation with separate pages in e.g. for A-C, D-F, G-L, etc?
Nice idea - especially if the glossary is very long. I'd propose to have a new element in the config file where you can specify on how many separate pages the glossary should be shown (e.g. 1 - all terms on one page or 26 - a single page for every letter of the alphabet).
Where and/or how should we define how the new pages are named in the navigation and the title (automatically or defined by the lesson author?)
What happens if a subpage contains no entries (especially for many subpages)?
In the config file we could allow a set of numbers of new pages to be specified - e.g. 1 (all on one page), 2 (A-M, N-Z,), 4 (A-F, G-M, N-S, T-Z), 8 (A-C, D-F, G-J, K-M, N-P, Q-S, T-V, W-Z), 13 (two letters on each page) or 26 (every letter on a separate page).
This way, the naming of the new pages could be predefinded/hard coded.
Any opinions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The swahili project I am working on uses popup windows for glossary term. So in this case EVERY glossary term would have to be a single HTML page.
I also like the idea but we would have to find a sensible and logical way to define if you want your glossary on one page (like it is now), every term on a single page (that would be the other extreme, like in the swahili project) or something in between (for every letter, for a group of letters etc.). I find Susannes suggestion a bit too complicated. Also I dont like the idea of using numbers as codes since they make only sense if you know what each number stands for. I suggest the following values:
- OnePage
- MultiplePages
- PagePerLetter
- PagePerTerm
Where MultiplePages would be e.g. what Susanne suggested with 8. We can always expand it if we see that it works.
One more comment: I can see that PagePerTerm is technically no problem but the other two values MultiplePages and PagePerLetter, I dont really know how to solve that with XSLT. So we can discuss what would be best but I dont know yet if I can implement it :-) As far as I know there is no "group by A-C" etc. function in XSLT...
Naming, navigation etc. should all be automatically in my opinion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We could use your suggested values instead of numbers, no problem. But I don't think, that it is much clearer.
As for the XSL - I might work with the standard sort and one or several test for starts-with('term','A') etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alberto, is there a hurry for this request? Can we postpone it until after the IMS conference? First of all because I am busy with eLML 6 release and second because for the Swahili project I will have to come up with a good glossary solution (they used popups...). So from that project I will learn a bit and gain new insights about grouping glossary terms and displaying them differently. My suggestion: Wait until the end of May with this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nice idea - especially if the glossary is very long. I'd propose to have a new element in the config file where you can specify on how many separate pages the glossary should be shown (e.g. 1 - all terms on one page or 26 - a single page for every letter of the alphabet).
Where and/or how should we define how the new pages are named in the navigation and the title (automatically or defined by the lesson author?)
What happens if a subpage contains no entries (especially for many subpages)?
In the config file we could allow a set of numbers of new pages to be specified - e.g. 1 (all on one page), 2 (A-M, N-Z,), 4 (A-F, G-M, N-S, T-Z), 8 (A-C, D-F, G-J, K-M, N-P, Q-S, T-V, W-Z), 13 (two letters on each page) or 26 (every letter on a separate page).
This way, the naming of the new pages could be predefinded/hard coded.
Any opinions?
The swahili project I am working on uses popup windows for glossary term. So in this case EVERY glossary term would have to be a single HTML page.
I also like the idea but we would have to find a sensible and logical way to define if you want your glossary on one page (like it is now), every term on a single page (that would be the other extreme, like in the swahili project) or something in between (for every letter, for a group of letters etc.). I find Susannes suggestion a bit too complicated. Also I dont like the idea of using numbers as codes since they make only sense if you know what each number stands for. I suggest the following values:
- OnePage
- MultiplePages
- PagePerLetter
- PagePerTerm
Where MultiplePages would be e.g. what Susanne suggested with 8. We can always expand it if we see that it works.
One more comment: I can see that PagePerTerm is technically no problem but the other two values MultiplePages and PagePerLetter, I dont really know how to solve that with XSLT. So we can discuss what would be best but I dont know yet if I can implement it :-) As far as I know there is no "group by A-C" etc. function in XSLT...
Naming, navigation etc. should all be automatically in my opinion.
We could use your suggested values instead of numbers, no problem. But I don't think, that it is much clearer.
As for the XSL - I might work with the standard sort and one or several test for starts-with('term','A') etc.
Alberto, is there a hurry for this request? Can we postpone it until after the IMS conference? First of all because I am busy with eLML 6 release and second because for the Swahili project I will have to come up with a good glossary solution (they used popups...). So from that project I will learn a bit and gain new insights about grouping glossary terms and displaying them differently. My suggestion: Wait until the end of May with this.
There is no urgency! This will be just a nice feature.