Problem with question type pluings

Problem with question type pluings

by Tim Hunt -
Number of replies: 7
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

When implementing question types in the mobile app, the approach adopted was to use exactly the same rendering code to render the question HTML that is then sent to the app is used when the quiz is attempted in a web browser.

If what we wanted was identical display of questions in the app and in the browser, this would be great, and would save plugin developers a lot of work.

Unfortunately, we don't want identical display. We want things in the web browser to look like thinkgs normally do in HTML, and we want things in the mobile app to look like native browser apps. For example, a multiple choice question:

Web view Mobile view

So, regrettably, what we have ended up with is code like this in the app. That takes the HTML sent by the web service, parses it to extract the question stem and the choices, and then that is re-rendered client-side using an ionic template.

This is surely far from ideal. If what the mobile app acutally needs is structured data (the question stem, and the separate choices) the surely it would be far more robust and performant for the web service to send the the data that is needed, rather than to be parsing HTML in JAVA script.

There is then the quesion of whether this could be implemented in a backwards compatible way. I think yes:

(All the variable/method names in the following are horrible, and need to be improved, but hopefully they make my suggestion clear.)

  1. Change the web service to return, in addition to the existing ->html, a new field ->displayedquestionstructure.
  2.  ->displayedquestionstructure is set by a new call ->render_for_web_service(...). There probably also needs to be a new boolean method ->supports_separate_render_for_web_service() - returns false be default in the base class.
  3. For efficiency without breaking backwards compatibility, add a new optional argument to that web services $nohtmlifdisplayedquestionstructure default false.
  4. Then, in the mobile app, we start calling the web service with $nohtmlifdisplayedquestionstructure = true, and if we get ->displayedquestionstructure in the data for a particual question, then we just use that directly, and we don't call the method like initMultichoiceComponent to parse the HTML. Instead we feed displayedquestionstructure directly to the template. If ->displayedquestionstructure is null, then we continue to parse ->html like at present. This means that all the question types that currently work keep working.
Thoughts?
Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Problem with question type pluings

by Dave Perry -
Picture of Testers

I'm all for backward compatibility and a 'use new super mode' toggle setting.

I'm not familiar with developing for the mobile app, but generic developer experience says there is logic to the outlined change in approach.

Average of ratings: -
In reply to Tim Hunt

Re: Problem with question type pluings

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Tim,

thanks for your feedback.

I agree with you that the current view for displaying question types is far from being ideal (it was the safer and quicker option at that time and has proved to work well), so any suggestion for improvement is welcomed.

Your solution sounds reasonable the only issue I see is that Web Services do not support dynamic structures when returning data (it has to be a pre-defined data structure) so we will be needing a superstructure able to return any question type data (question and answers required data).

Just checking all the different question types db/install.xml files you can image that it won't be easy to created a pre-defined structured supporting all the required structured data for any question type.

I feel there are several approaches:

- Use just one field for the questionstructure where will be storing the question information in JSON format. So the app can decode it.

- Create a standarised structure able to support the most common data and any kind of extra data

- Return the questions already rendered in an ionic compatible way.

Thoughts?

Average of ratings: -
In reply to Juan Leyva

Re: Problem with question type pluings

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Thanks Juan. I agree that what was done so far was bat seemed like the best option at the time, and it did allow the app let students attempt quizzes in the app as of a few versions ago. This was a really important milestone to reach, and I don't want to underplay the amount of work that took.

However, I disagree that what was done "has proved to work well" in anything but the simplest cases. For example, here is a Cloze question in the app:

Cloze question in the app

It is using HTML radio buttons, not app-native ones.

For background, I am working on making the STACK question type work in the app (clearly a sensible choice of simple question type for me to start learning with wink). Last night I got I reached the conclusion "this is probably impossible". Then this morning, I thought "Acutally it can't be impossible, they must have dealt with this issue when they implemented Cloze question type in the app". Now I have time to investigate, I see that actually, you could not make it work the way one would want it to work either, so at least I am not missing anything simple.

You make a very good point about web service return values needing to be fully defined. I had forgotten that, and that means that my suggestion clearly requires more work.

There is no "standarised structure able to support the most common data" for differnt question types. That is why we have different question types.

So, I think your third suggestion "Return the questions already rendered in an ionic compatible way" sounds like the most promising option. (Returning a JSON is clearly just cheating to get around the rule about having to define the structure.)

However, clearly my suggestion needs more work, and I will continue to think about it. I will probably get back to you when I have a better worked out idea. Thanks again for your feedback.

Average of ratings: -
In reply to Tim Hunt

Re: Problem with question type pluings

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I think of the way question types work on mobile as 'screen scraping' the web output. I know that is not an exact analogy, but it give s a feeling of something that will work, but you might have done it differently if you were starting from scratch. When I did the first version of Gapfill for mobile it was nice that the changes I had to make to the web output were trivial and reflected things I should have probably done anyway.

Average of ratings: Useful (1)
In reply to Marcus Green

Re: Problem with question type pluings

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

'screen scraping' is a very good way to describe how it currently works.

Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Problem with question type pluings

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Thanks Tim,

I agree with your analysis, and we plan to do some work to solve some existing issues and to reduce the amount of "screen scraping" we do.

I'll create a couple of issues in following weeks to start retrieving more structured information about questions (like the question options)


Average of ratings: -