Tim, I managed to write our ideas on how to link question engine to lesson module (and potentially any other), creating a place to query question about every property it could report. I still beleive that it'll allow for greater flexibility than existing one. http://docs.moodle.org/dev/Question-lesson_link
Could you write what do you think of it? If you'll like it we may spend efforts implementing it.
I *like* this very much.
Then all we need is to convince Tim so he agrees to add this to the question engine.
I just created MDL-29647, so anyone who like it could vote in it's favor. Please vote.
No, you don't need to convince me. I have been saying for years that I would be delighted to help anyone who wants to make the lesson module work with the question bank/question engine.
What you do need to do is write a specification that is technically sound, and then write code that is of a high enough quality.
Your specification is currently inadequate. Despite our discussions in August about making the regex question type work, you still clearly do not understand the role of behaviours and question types, which is important here.
Also, you jump straight from a vague description of the problem "The problems of linking the lesson module with the question engine" to proposing an API. You really need to explore the problem in more detail before you get to API design.
There are 12 question types and 7 behaviours that can be used in most of the 84 possible combinations. Obviously you don't need to consider every single combination, but you should analyse about half a dozen representative examples in detail saying that "for this example question of this type, with this behaviour, we would expect there to be these properties." Some good examples would make your spec much more understandable, and so would be easier to discuss. It would also demonstrate that you have considered everything of significance (or not).
You also make no mention of how the Lesson module works in your specification. There is no point adding this new API unless it does what the Lesson module requires. Therefore, you should include some analysis of what use the lesson module would make of this new API, and the big picture of how you plan to convert the lesson to use the question bank/engine. That is, some lesson UI mockups for student attempting and teacher editing. Also, outline any necessary DB structure changes.
Only once we understand the full range of data that the lesson needs to get out of the question engine, and what the lesson is going to do with that, can we design the right API.
Tim, either I don't understand you, or you don't understand me, or this is a polite form of "No, thanks".
I am going to create an interface for the question to report things to module flexible enought that any 3d party question (and behavour too?) author could throw in new properties - and even a data types for them - easily, right from his plugin, without modifiynig question engine or activity module (e.g. lesson). It would be equally easy for you (or me, or Pierre) to add a new property for standard question types, so we really shoudn't know all them from the beginning. I'll write an interface for datatype class that would allow anyone to add almost anything - actually anything, that could be serialised to DB column and even a little more. And I dare say with the types of data current core question type uses anything about them could be serialised - you could throw on me a pair of particulary hard cases if you want, I'll do examples for them.
You want me to do something contrary. Careful analysis of current examples would only serve to lock in current situation, not to add a flexibility for the 3d party authors and the module. That's the way I don't like to take. I want to go away from API that reports only what is hardcoded into functions, when adding new property means changing the code that uses it.
I want to desire a way to report ANY (almost) property, so the right things to ask for me is "HOW the properties will be supplied" and "HOW they will be used", but not "WHAT properties we expect from this qtype under this behavour". If you'll agree on my way of "HOW", finding the properties will be next step. If you don't like the HOW, then looking for WHAT is useless. Could I please hear you opinion on the HOW part? I strongly doubt there is something about core qtypes/behavours that coudn't be serialised into a DB field, and that is the only restrictions I know about my API.
In our country, we have a step in software development called a "blueprint project". It is an outline of main internal features of what's going to be done, so the people could agree or disagree on them (often several concurring blueprint projects are done and the best is selected). If they agree, then there is a "technical project" step, where all details are worked out. "Blueprint project" is what I try to do now, but you expect a full technical project well before you even says do you like idea in general or not.
P.S. As you probably well understand, there will be no change to question engine DB at all. It only a way to report things, it doesn't store (on question part) or change them.
I understood that you want to expan the inteface of the question engine with a view to getting more data out.
And I think we agree that the main motivation for this is so that the lesson module can be converted to use the question bank.
However, we seem to have a fundamental difference of view as to how one should go about that sort of thing. I think that the right way to go about desinging an API involves principles like
All of generality I done is on purpose and all get one root: if we want question types to be completely pluginable, the link with the lesson should be completely pluginable too.
Actually there are two levels of generality in there:
All of them should be kept if we want a question to be truly pluginable regarding lesson. Just try to get "WHAT data needed" answer, and you are in position where 3d party question authors must plead to you to make their questions compatible with lesson (does you really want all this shortcircuited to you?), since they need new "WHAT". I try to make one change so general, that you woudn't need to change it after it was done whatever question type people would write.
Does this justify the generality level for you?
P.S. One example how easy to be catched with defining "exactly WHAT". Preg question could report the length of the correct part of the student's answer, and sometimes even how many characters it would take to complete it. A teacher may want to give different jumps depending of how much of the answer student wrote, or what parts he wrote correct. Shortasnwer doesn't have this capability (thougth it could do that much easily than preg). If you plan you "WHAT data you need" based on current shortasnwer implementation, you'll miss that one easily. And similar little, but useful to the teacher in different circumstances properties are quite numerous. You'll be constantly adding to you API unless you abstract from them.
OK, so that is one example of the kind of thing you want to communicate. An iteger.
And, you have finally said what we need to be able to do with this data. We need to control branches in the lesson.
Doesn't that kind-of imply that the only data-type we need here are enumerations. That is, the lesson lets the teacher create navigation structures that would be a switch statement in code?
Now, it is absolutely vital to think about user-interface design. To know what properties each element of this enumerated type must have, in order for us to build the lesson, we need to think about what UI will be presented to the teacher when they try to use this property (rather than another) to build the lesson; and we need to think about what the student will see as they attempt the lesson.
For the teacher, we presumably need some sort of name, by which they will identify what this property is, so they can choose it. Moodle will also need some sort of unique identifier to use to refer to this property.
Then, similarly, each possible value will need an internal, and an external, representation. But, going back to the external representation. What about internationalisation? Are these strings typically user-input, in which case they need to be processed by the multilang filter; or are they lang strings, in which case where in the process do they get looked up in the current langauge?
I don't know how much information students are given about why the lesson is taking the path it is taking. Perhaps they don't need to know about these properties at all.
Now, do you see why I think UI considerations are important when we talk about lower-level API design? Although the code should evenutally end up nicely layered, we need to see the big picture, and make sure that each layer servers the needs of the other layers, as we work out the detail of each layer.
To give an example from a completely different part of the API. Think about the $qa->get_state() method. You could argue that to give question behaviours and types as much flexibility as possible, we should let this method return anything at all. However, if we did that, it would be completely useless. The point of the get_state method is to allow other parts of the system to have some idea what is going on inside an attempt at a question. That is why the get_state method is only allowed to return one of the pre-defined qustion_states defined in this diagram: http://docs.moodle.org/dev/Overview_of_the_Moodle_question_engine#More_on_question_states (which as it happens is no up-to-date. For a difinitive list see question/ending/states.php). By restricting the flexibility, it makes it much easier for other parts of Moodle like the quiz or lesson to understand the answer it gets from the API. Of course, it took a lot of careful thougth to get the right state-diagram. (That is why it changed after the diagram was drawn.) However, the final state diagram contains all the flexibility that all the question behaviours so far concieved require.
Remember the quote "Perfection comes, not when there is no more to add, but when there is no more to remove." I am asking you to perfect your proposal by removing as much as possible.
P.S. Given you quote on perfection, the most imperfect act was done by the God in 6 days, when he created world from void - there was surely nothing to remove from void that was before
More seriously, there is sense in this quote, but it's partial - it doesn't mention what should stop us from removing everything. Occam said "don't add entities WITHOUT NEED" - but there is need for the flexibility I added to the proposed API.
Tim, should I take you silence as "no, you don't convince me that this level of flexibility is required" ?
To state my position short: teachers tends to be quite creative designing their lessons and conditions for jumps, and 3d question types may be creative too. So we need a way for them to interact that didn't hinder this creativity...
You can mostly take it as a sign that I am busy and tired, and this conversation does not seem to be going anywere.
I completely agree with "we need a way for [teachers] to [designing their lessons] that doesn't hinder this creativity", and that the lesson needs to be changed to use the question bank.
That is a statement about the overall funcitonality of the system, and how that is represented in the UI. You are drawing conclusions from that about implementation details, in ways that I think are wrong.
However, I don't see the point of arguing about this in words. If you are so sure you are right, write the code that proves it. Even if we still diagree, 99% of the work of converting the lesson to use the question bank is the same irrespective of the exact API used to get the outcome of a question interaction out of the question bank.
Tim, I'm not sure anyone (human) can be "right" or is that matters - it's decisions that matters, not rights or wrongs. I'm still sure the way I proposed it is better, but it is you who make decisions about questions.
Without you consent I should take another path: place this interface in lesson code and also be able to use it if it will be implemented on the question side. Then I could implement it fully for my own preg question, but do the bare minimum required for the core question types. And it would be an each question author's job to implement it if he wants full integration - up to you (or Pierre, or someone else) on the core question type behalf.
P.S. "in ways that I think are wrong". I still don't see how exactly. I replied to you example by showing difference: coded state diagramm for behavour versus user-created for lesson - which I think should lead to another level of flexibility. You may as well be right - been the better designer then myself - but you don't reply on that bit, showing me where am wrong, so I coudn't see it, sorry. I may see it if I'll be plainly shown thought.
One of the wisest things ever said about computer programming is the Perl motto: TIMTOWTDI (There Is More Than One Way To Do It).
Stop worrying so much about what I think. I would much rather you were worrying about what users of the lesson module wanted. If you build something that lets people create lessons using questions from the question bank; then people will almost certianly download it and start using it. If people are using it, and say that it is good, then it will get into Moodle.
If there is working code that lots of users like, and I still don't like the way you have hooked it it into the question engine, then it will be up to me to fix your code to work better, if I am able to.
Tim,
As you wrote in a preceding post "it as a sign that I am busy and tired".
You have a very high workload but this do not stop you to develop a beautiful and very complex question-engine that you know will increase your future workload.
So again, thanks from Moodle community for your new question engine.
Doing this engine code you build the necessary docs before building the first lines of code as you think it should be done when building a complex code structure.
Integrating lesson and questions is probably even more complex and a clearly defined code structure even more necessary.
Pierre
P.S. and even " busy and tired" you added "it will be up to me to fix your code to work better, if I am able to."
Tim, I managed to write more thorought description how this is supposed to work. I hope it would be enought for you to catch the idea.
I NOT placed any specifical property lists or mock-ups of editing interface, since the were all flexible part - adding new property or data type (and UI to enter it) wouldn't require to change API, only implementation. I'm sick of APIs that restricts what you specifically could know about the question so you should update lesson whenever a new property or question type pop out. That won't do at all. I want a lesson freely interoperable with 3d party question plugins (like my own one).
Could you please tell me now whether you agree with this idea generally or not? Getting the properties right is the next step, first we need to agree on a way they would be served...
In the preceding post Tim shows the way to integrate lesson with the new engine question types.
This is a big task.
Lessons are complex to build and personnally I prefer to use quiz.
This preference is enhanced by all the new engine options that with the hints and feedbacks can transform one question in a mini-lesson.
So if I have to vote to what should be done first, I will prefer Tim's project as expressed on his blog
http://tjhunt.blogspot.com/2011/09/what-i-want-to-build-next.html
and in
http://moodle.org/mod/forum/discuss.php?d=186638
Pierre
The great thing about open source is that anyone can do whatever they like, so you are not necessarily limited to one vote.
I vote for both things happening, providing I don't have to do more than one of them
"So if I have to vote to what should be done first,"
I vote for the two options (even if the probability that I use lesson is very low).
"providing I don't have to do more than one of them "
So I prefer that "the one of them" should be your project
Pierre
Pierre, there are one thing in Tim's new project I like: it's just a separate module (of no great importance IMHO), which will keep Tim for some time from making things more complex to the question type authors and give them time to digest his new engine
Thought personally I think if he spend some time working on automatic hints for basic question types, that would done more good overall.
Pierre, thing is somewhat more complicated than you think. Lessons - if they would be flexible enought tool - is the great thing, that cound't be superceded by quiz. I think our lectures should be turned from PDF to lessons (with all incorporated questions and small tasks), but inability to link my preg question to lesson hinders it.
And I don't want to take much of Tim's time. Tim must not do all the work on the lesson module part - this is our problem. But to do this we need incorporate a small addition to the question engine - to allow question to report various information for lesson jump - and that's exactly where Tim come's into play. At least in reviewing/applying this addition. Because if he tells "I don't like the idea at all and would never do it" (or leave it for ages to rot on the tracker) then there is no point in doing anything at all. Tim holds a tight control over a question engine, so this coudn't be done around him.
What I try to get now, is to get some general conclusion for the Tim, would he like the idea (if it will be properly planned and implemented pf course) or not.
P.S. I dare say the proposed addition is quite a safe thing since it's new reporting interface. I.e. it doesn't change anything, only report existing information in a new way, and coudn't possibly break something existing in Moodle at all.
