Question interaction

[superdweebie]

At present the three question slide types (pick, slider, and sort) simply wait for some kind of interaction, and then enable the next button.

Do we need to add functionality for a correct answer?

What should happen if users select a wrong answer?

ping @90084

[90084]

Hey Tim,

Thanks for prompting this. I thought about it but didn't want to dump 'feature requests' while you're still developing the demo.

But yes, in time we'd need:

• Feedback field for each option.
• A 'score' for each option (so can allocate the 'marks' for each question across options.
• Feedback fields for the question overall, when correct, partially correct, and/or incorrect.
• Perhaps a 'general feedback' field shown after each question regardless of score.

At the moment I could hack some kind of feedback with the .bso file, so we can demo it at least (my priority at the moment).

BTW- I haven't used github before, so let me know if I'm doing something suboptimal (eg ok to reply to these via email?).

m

On 08/12/2014, at 9:08 AM, Tim Roediger notifications@github.com wrote:

At present the three question slide types (pick, slider, and sort) simply wait for some kind of interaction, and then enable the next button.

Do we need to add functionality for a correct answer?

What should happen if users select a wrong answer?

ping @90084

—
Reply to this email directly or view it on GitHub.

[superdweebie]

Marty,

Replying via email works great.

Regarding 'feature requests', we now have a solid core up and running, so now is the time to start dreaming and planning. I think it will work well if we open a new issue for each feature. We can then disucss, and if it takes some time to implement, that's ok. We'll end up with a bit of a road map as we prioritise what to do first, and discussion will become documentation about why certain decisions were made.

Regarding this feature:

• Feedback field for each option.
  So, each answer option also needs a text/html string that is displayed when that option is chosen?
• A 'score' for each option (so can allocate the 'marks' for each question across options.
  What data type do you want fo the score? Integer/float. Is there a minimum/maximum value?
• Feedback fields for the question overall, when correct, partially correct, and/or incorrect.
  How should correct, parially correct, incorect be defined? Is it based on the answer score? Is it an absolute value (eg: score of 10 always equals correct), or a relative value (eg: the answer with the highest score is the correct one)?
• Perhaps a 'general feedback' field shown after each question regardless of score.

So we have three types of feedback - individual answer, correct/partail/incorrect and general. How should they be presented? A bubble over the question? Three separate slides after the question? Will a user be allowed to re-attempt a question after they have read the feedback?

[90084]

Regarding 'feature requests', we now have a solid core up and running, so now is the time to start dreaming and planning.

super

Regarding this feature:

Feedback field for each option.
So, each answer option also needs a text/html string that is displayed when that option is chosen?

Yes please
A 'score' for each option (so can allocate the 'marks' for each question across options.
What data type do you want fo the score? Integer/float. Is there a minimum/maximum value?

int is fine, with all options in a question adding up to 100. For bonus points, we could have negative scoring, but that's not worth worrying about just yet.
Feedback fields for the question overall, when correct, partially correct, and/or incorrect.
How should correct, parially correct, incorect be defined? Is it based on the answer score? Is it an absolute value (eg: score of 10 always equals correct), or a relative value (eg: the answer with the highest score is the correct one)?

Yes, it's the adding of the option scores.
Incorrect: 0 score
Correct: 100 score
Partial: anything in between.
Perhaps a 'general feedback' field shown after each question regardless of score.

So we have three types of feedback - individual answer, correct/partail/incorrect and general. How should they be presented?

It's good if they can see the feedback in the context of the question. But I realise the small screen issue. It's great if the option feedback can be shown beside/below the option itself.

Will a user be allowed to re-attempt a question after they have read the feedback?

Yes. In some cases they will have to, until they get it right, to progress.

Moodle does all this well, so I'm happy to show you how it works there if it's helpful.

And as always, I don't want to implement any features that make this inaccessible to our audience, with their basic feature phone with expensive data downloads. So this will guide our prioritising.

Thanks,
Marty

[superdweebie]

@90084 I'm free if you want to give me a call - it's Thursday morning.

[superdweebie]

@90084 could you please take a look at the following:

• The new json format that adds scores, multiple question attempts, and feedback. I've tried to make it as simple as possible. Basic doc is here: https://github.com/superdweebie/demo/blob/feedback/docs/slides.json.md. The json for the full demo is here: https://github.com/superdweebie/demo/blob/feedback/data/ep1/slides.json
• An updated version of the demo is here: http://superdweebie.github.io/demo. It contains a few small changes. If you activate the console, then you will see the feedback strings being generated. I haven't added the UI for feedback yet.

Looking forward to your comments and suggestions.

[90084]

The new json format that adds scores, multiple question attempts, and feedback. I've tried to make it as simple as possible. Basic doc is here: https://github.com/superdweebie/demo/blob/feedback/docs/slides.json.md. The json for the full demo is here: https://github.com/superdweebie/demo/blob/feedback/data/ep1/slides.json

Thanks.
The 'complete' object felt a bit convoluted to me, but I can see what you're doing. Having an 'allowNext' attribute with a single value of correct|partiallycorrect|always (and defaulting to 'always' or 'correct' if not stated explicitly) is all we need - but I might be missing a scenario you have in mind? It seems the simplest scenario ('always') would require the most text in the current setup.

An updated version of the demo is here: http://superdweebie.github.io/demo. It contains a few small changes. If you activate the console, then you will see the feedback strings being generated. I haven't added the UI for feedback yet.

The loading bubbles show and nothing else - tried FF and Chrome on OS X. Also Android tablet Chrome.

[superdweebie]

I just tried to load the updated demo from my work pc - same problem as you. Will look into it.

I like the suggestion about simplifying the complete object. Will do, although I don't think I'll change the name to allowNext. I'd like to keep slide idependent from each other if possible, and avoid things that create or imply relationships between them. A slide manages itself, and doesn't know or care about navigation. Navigation is handed at a higher level in the code.

Also, with a another look over the slides.json I think we could drop the author property. I don't see it having great benefit. And, we should probably add a series property so we can have:

{
  "series": "Bible Overview",
  "title": "Episode 1",
  "subtitle": "In the beginning..."
}

[90084]

I like the suggestion about simplifying the complete object. Will do, although I don't think I'll change the name to allowNext. I'd like to keep slide idependent from each other if possible, and avoid things that create or imply relationships between them. A slide manages itself, and doesn't know or care about navigation. Navigation is handed at a higher level in the code.

Yes, agreed, sounds good.
Also, with a another look over the slides.json I think we could drop the author property. I don't see it having great benefit.

Yes, me neither.
And, we should probably add a series property so we can have:

{
"series": "Bible Overview",
"title": "Episode 1",
"subtitle": "In the beginning..."
}

Yes, like it.

There's a wider question of inter-episode flow. It would be good to have the ability to restrict going to next episode until current one is 'complete' (for some definition of complete!). Would this be specified in the json? eg conditions for this episode to be played, and a message when it's not met.

[superdweebie]

For inter-episode flow I think we need to define a series.json that will list the episodes in a series. Then it becomes a question of where to put the complete definition. Should it be placed in series.json or slides.json? I think it probably belongs in series.json - we want to be able to determine if the episode is accessble before loading the episode itself.

[superdweebie]

I've found and fixed the bug, the link above should work now.

I've also simplified the complete property in line with your suggestions.

Regarding inter-episode stuff, I'll ref #12, because that's probably the best place to nut out our ideas.

[superdweebie]

@90084 Could you please cast an eye across this link (same as above). I'd like to get your approval before I merge it into Master. I have further work ready to merge waiting on this. Ta

http://superdweebie.github.io/demo

[90084]

All good mate, thanks.

On 15/06/2015, at 9:50 AM, Tim Roediger notifications@github.com wrote:

@90084 Could you please cast an eye across this link (same as above). I'd like to get your approval before I merge it into Master. I have further work ready to merge waiting on this. Ta

http://superdweebie.github.io/demo

—
Reply to this email directly or view it on GitHub.