Revamp question component by ang-zeyu · Pull Request #1274 · MarkBind/markbind

ang-zeyu · 2020-07-13T14:04:03Z

What is the purpose of this pull request? (put "X" next to an item, remove the rest)

• [x] New feature
• [x] Enhancement to an existing feature

Resolves #1184

What is the rationale for this request?
Total redesign / rewrite of question components, while preserving backward compatibility (though somewhat awkwardly since questions are always marked as 'correct').

External libraries: Suprisingly there aren't any ready made vue quiz components that suits our requirements (though an abundance of tutorials), also backwards syntax compatibility is a must

What changes did you make? (Give an overview)
Added various <question type="">s:

Mcq
Checkbox
Text (or old components with hasInput)

Added <quiz>, which strings multiple <question>s together

to be done: (WIP)

polish usage / design
snapshot tests
investigate updating vue bundle to 2.6 in a separate PR before this one (test files vue.min.js aren't updated here as well so ci fails for now)
add deprecation warnings in another PR after this one

Is there anything you'd like reviewers to focus on?

any suggestions / comments on design / usage / docs / bugs
would avoid looking at the implementation since it's a huge rewrite, but if you have the time any comments are welcome ^^

Testing instructions:

npm run build:components on this branch then markbind s to play around with it
netlify preview https://deploy-preview-1274--markbind-master.netlify.app/userguide/usingcomponents#questions-and-quizzes

Proposed commit message: (wrap lines at 72 characters)
Revamp question component

Question components serve as a thin syntax wrapper on top of panel
components, and don't provide any form of answer checking.

Let's rewrite and redesign the question component, using bootstrap
cards as the design basis.
Let's also provide 3 types of questions - mcq, checkbox and text, which
allow for simple answer checking.

Educational websites may also want to build mini quizzes consisting of
multiple questions.
Let's provide the quiz component for this, which can string multiple
questions together with a simple scoring mechanism.

ang-zeyu · 2020-07-15T12:38:53Z

could use some opinions here 😁 @damithc @acjh @marvinchin
https://deploy-preview-1274--markbind-master.netlify.app/userguide/usingcomponents#questions-and-quizzes

damithc · 2020-07-15T13:49:26Z

could use some opinions here 😁 @damithc @acjh @marvinchin
https://deploy-preview-1274--markbind-master.netlify.app/userguide/usingcomponents#questions-and-quizzes

Looks nice. The questions feature has value in terms of nicer presentation. It can have even more value if we separate check from show answer so that the reader can try multiple times. Can add a reset button too.

I'm not sure if the quiz feature has enough value to make it worth the cost. One can always list the questions one after the other to form a quiz. Adding up the correct answers doesn't add a lot of value unless the quizzes are long.

Side note: In my current use of MarkBind I use LumiNUS for all my quiz needs. The questions I currently have in my MarkBind sites were added before I moved to using LumiNUS for quizzes. Hence, my low enthusiasm for this feature (wouldn't want to spend resources on a feature I'm not going to use much).

Perhaps we strengthen the question feature but put the quiz feature on hold for now?

ang-zeyu · 2020-07-15T14:36:22Z

I'm not sure if the quiz feature has enough value to make it worth the cost. One can always list the questions one after the other to form a quiz. Adding up the correct answers doesn't add a lot of value unless the quizzes are long.

Cost in terms of maintainability? I separated how a <question> functions with / without a <quiz> wrapping it into an easily unpluggable file actually (QuizQuestionMixin.js), it should be pretty decoupled. I may be a little biased here though, would be nice to have a few more eyes on it

In terms of client side rendering performance it would actually improve it as opposed to listing the questions one after the other, as the dom and virtual dom for unseen questions is not rendered.

It can have even more value if we separate check from show answer so that the reader can try multiple times. Can add a reset button too.

These functions are provided in the quiz already, I avoided putting in <question>s as well as:

it encourages spamming / brute forcing the answer especially for mcq / checkbox questions, which defeats the purpose
- using a series of questions in a <quiz> in contrast reinforces the learning points better as the reader is forced to remember the answers to each of the questions when clicking retry
for text questions it can easily lead to frustration when the user keeps retrying due to spelling errors / using synonyms, which again encourages simply jumping to show instead of check
it should be left for more gamified learning platforms (not luminus), where each question poses considerable difficulty

This is just imo though, it's highly subjective to individual learning styles. I'm not opposed to having it as an opt-in thing like <question has-check> or the reverse either

Side note: In my current use of MarkBind I use LumiNUS for all my quiz needs. The questions I currently have in my MarkBind sites were added before I moved to using LumiNUS for quizzes. Hence, my low enthusiasm for this feature (wouldn't want to spend resources on a feature I'm not going to use much).

Perhaps we strengthen the question feature but put the quiz feature on hold for now?

Yup the aim isn't to replace fully fledged learning platforms with a backend, but simply to provide a more interactive experience, as well as

a more performance friendly way to display a whole bunch of questions
a simple scoring mechanism to encourage retrying the quiz to reinforce the learning points

If it helps, my intended use case for the quiz component was somewhat of the following:

OOP.md
- quiz on oop at the very bottom
Gathering Requirements.md
- quiz on methods of gathering requirements

damithc · 2020-07-15T15:44:43Z

Cost in terms of maintainability?

Yes, plus the effort needed to go from here to production., which could be a lot.

This is just imo though, it's highly subjective to individual learning styles. I'm not opposed to having it as an opt-in thing like <question has-check> or the reverse either

As this is self-study mode without any oversight from instructor, we have to assume the reader will choose whatever works for her. We simply provide all the possibilities. The reader choose correctly, we reveal everything. If the answer is wrong, the reader can try again or give up and ask for the answer. I don't think there is any downside of giving that choice to the reader.

ang-zeyu · 2020-07-16T12:05:35Z

Yes, plus the effort needed to go from here to production., which could be a lot.

Just need some snapshot tests and it should be good to go. Also any other minor design / feature tweaks and additions.
Code wise, again, it should be pretty decoupled. Rather, the below feature request likely adds even more coupling between <q-option>/<question> than <quiz>/<question>

I don't think there is any downside of giving that choice to the reader.

Presentation wise there may be value in having a clean ui, especially if the page is already heavy

Also for mcq questions, you very quickly exhaust all the possible options (even if you're not intending to brute force out the answer) by just clicking check. Having show just feels like feature bloat / duplication to me.

For checkbox questions, I feel that it quickly becomes a tiresome guessing game if we don't show which option(s) were correct / wrong, since there are 2^n possible answers. If we show which option(s) were correct / wrong, it leads to inconsistent behaviour with mcq questions, and also it is pointless - because unchecked answers can be correct we need to show whether all options were correct / wrong. (check would just become show)

How about just having it for text questions? It may be difficult to get the correct keyword sometimes.

How it looks from some in browser edits:

damithc · 2020-07-16T13:23:07Z

Consider this analogy:

Scenario 1:

Teacher asks a question.
Student gives an answer.
Teacher says that answer is incorrect. Possibly also explain why it's incorrect.
Student can either try again, or say "I give up, give me the right answer"

Scenario 2:

Teacher asks a question.
Student gives an answer.
Teacher says if the answer is correct or wrong and also gives the right answer.

The value of this process comes from the student thinking about the question and trying to find the answer. This is why teachers don't give answers right away and instead try to guide the student towards the answer by giving more and more hints. The answer itself is less important than the attempts to get at the answer. The more attempts the better. Of course this doesn't work if the student is randomly answering without thinking about it. In that case might as well give away the answer.

Consider these buttons:

check answer: only reveals if the answer is correct. For MCQ, can also reveal the explanation of the currently chosen option as an additional information.
show answer: reveals all info. If an answer is given, also shows if the answer is correct or wrong.

The reader can choose scenario 1 or 2 by clicking on one of the two buttons. This is something the old version cannot do.

Having said that, I'm fine with the current version too as it behaves the same way as existing questions and look nicer. Try not to break the legacy syntax because I might not have time to migrate to the new syntax right away.

ang-zeyu · 2020-07-16T14:15:08Z

The value of this process comes from the student thinking about the question and trying to find the answer.

On second thought, that probably has more priority than trying to make the behaviour consistent from an author standpoint, or minor feature duplication. To reconfirm what you meant (the 1's):
a1. Mcq questions - check (also equals retry) - explanation for the selected answer, correct or wrong, is displayed, and a show button

or

a2. Mcq questions - check (also equals retry) - explanation for the selected answer, correct or wrong, is displayed, no show to avoid minor feature bloat

b1. Checkbox questions - check (also equals retry) - no explanations are displayed at all unless all options are correct, this is necessary since unchecked answers can be correct, and show

or

b2. Checkbox questions - check (also equals retry) - explanations for checked answers (correct or wrong) are displayed, and show

c. Text questions - check doesn't display anything, show does

When <question>s are wrapped by <quiz>s however, the current netlify behaviour is followed, except check is renamed to show for consistency:
a. Mcq questions - only a show, however all explanations are immediately displayed
b. Checkbox questions - only a show, however all explanations are immediately displayed as well
c. Text questions - only a show here

Is there a better naming for show and check to reflect the purpose better as well? (since show also 'checks' the answer)
show -> check
check -> try / ??

Having said that, I'm fine with the current version too as it behaves the same way as existing questions and look nicer. Try not to break the legacy syntax because I might not have time to migrate to the new syntax right away.

The only weird part currently would be the addition of the check button which always ends up being correct. I'll remove it for <question>s without types or text questions without keywords (hasInput), should be fully compatible otherwise.

On syntax, would it be better to just have <template #answer> for consistency? Although it's somewhat of a misnomer for mcq / checkbox questions.

damithc · 2020-07-16T14:49:51Z

Haven't looked at the syntax yet. Let's nail down the behavior first.

a1, to allow the reader to give up up after checking
b1. no need to show explanations

text questions can have keywords that should be in the answer and a separate explanation, which means it too can have both buttons.

What do you think of this alternative?

Only a check button is present. If the answer is correct, everything is revealed. If the answer is wrong, a dialog prompts the user with retry and show answer options.

ang-zeyu · 2020-07-16T15:13:36Z

text questions can have keywords that should be in the answer and a separate explanation, which means it too can have both buttons.

yup

What do you think of this alternative?

good idea, this would make the initial UI more consistent with questions in quizzes as well.
by dialog, do you mean a popup dialog? how about just transitioning the buttons out for less disruption? (the current transition between check and next in quizzes)

I'm ok with retry. show answer seems a little long for a button though, should we just stick with show?

damithc · 2020-07-16T16:36:14Z

by dialog, do you mean a popup dialog? how about just transitioning the buttons out for less disruption? (the current transition between check and next in quizzes)

Yes, button transition better.

I'm ok with retry. show answer seems a little long for a button though, should we just stick with show?

Sure.

damithc · 2020-07-16T16:37:50Z

On a separate matter, is it smoother to make the hint appear just above the button rather than far away from the button? Less travelling for the eye.

ang-zeyu · 2020-07-17T10:31:07Z

On a separate matter, is it smoother to make the hint appear just above the button rather than far away from the button? Less travelling for the eye.

like this? works too.

damithc · 2020-07-17T10:35:33Z

like this? works too.

Yes, let's do that then.

damithc · 2020-07-19T13:43:28Z

Regarding the syntax, possible to avoid introducing a # to the syntax? It's not used anywhere else in MarkBind.

ang-zeyu · 2020-07-19T14:15:16Z

the old slot="..." syntax works too (in the deprecation notes).

eventual deprecation of all slot="xx"s to a more succinct #xx is almost a must though (#1078), as vue 3.0 is dropping it as well (https://vuejs.org/v2/guide/components-slots.html#Deprecated-Syntax)

If preferred I could use it in the examples for now still instead, to avoid inconsistency with the other components

damithc · 2020-07-19T14:16:59Z

the old slot="..." syntax works too (in the deprecation notes).

eventual deprecation of all slot="xx"s to a more succinct #xx is almost a must though (#1078), as vue 3.0 is dropping it as well (https://vuejs.org/v2/guide/components-slots.html#Deprecated-Syntax)

If preferred I could use it in the examples for now still instead, to avoid inconsistency with the other components

I see. I guess we'll use the slot syntax for now until we changeover to # syntax later.

ang-zeyu · 2020-07-20T15:07:45Z

Made the changes, I also changed <template slot="answers"> to <template slot="body"> for all question types.

Placing <q-option> into any of these slots is entirely optional, it can be placed as a direct child of <question> as well.
In this sense, should we instead make body the default slot (ie. no slot) and header an optional slot?

The downside would be needing to manually format the question everytime, ie.,

<question type="checkbox">

Which of the following is true?

<q-option correct>
  20 + 20 = 2020
  <template slot="reason">
    lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum
  </template>
</q-option>
<q-option>
  1 / 0 = infinity
  <template slot="reason">
    Division by zero is <md>**undefined**!</md>
  </template>
</q-option>
<q-option correct>
11 / 11 = 1
</q-option>
<template slot="hint">
This is the question hint, you can use markdown here as well.
</template>
</question>

results in a really plain question text (unless you format it manually with markdown or put it into <template slot="header">)

damithc · 2020-07-20T17:00:43Z

In this sense, should we instead make body the default slot (ie. no slot) and header an optional slot?

The downside would be needing to manually format the question everytime, ie.,

Yes, I think it's fine. It's actually better to let the author format the question in any way rather than force a specific format. Bolding the question by default is not appropriate in some cases e.g., when the questions is very long.

Pros and cons of using simpler tags <option>, <reason> instead of slots?

ang-zeyu · 2020-07-21T12:40:36Z

Pros and cons of using simpler tags <option>, <reason> instead of slots?

<option> is a html element already https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option

For <reason>, I think it's inconsistent with our syntax in other components. How about adding:

reason prop for <q-option>
header prop for <question>s
hint prop for <question>s
answer prop for text <question>s

all of which allows markdown like our other components?

damithc · 2020-07-21T12:50:04Z

For <reason>, I think it's inconsistent with our syntax in other components. How about adding:

reason prop for <q-option>

header prop for <question>s

hint prop for <question>s

answer prop for text <question>s

all of which allows markdown like our other components?

Do you mean these can be specified as either properties (supports inline markdown) or using the slot syntax (if block markdown is needed)? Like this?

<q-option reason="that _works_">
  20 + 20 = 2020
</q-option>

<q-option>
  20 + 20 = 2020
  <template slot="reason">

#### reason heading
* sub-reason 1
* sub-reason 2

  </template>
</q-option>

ang-zeyu · 2020-07-21T12:54:53Z

Do you mean these can be specified as either properties (supports inline markdown) or using the slot syntax (if block markdown is needed)? Like this?

Yup much like most other components

damithc · 2020-07-21T12:58:29Z

Yup much like most other components

Sounds fair. In the documentation, give a simple example first (i.e., using props) and mention that slot syntax can be used too (with a smaller example). Otherwise the syntax can appear too verbose at first glance. Alternatively, use slot syntax only for one option of the example.

ang-zeyu · 2020-07-21T15:10:55Z

Done, features and behaviour should be more or less locked down. Also added tests for transforming the mentioned attributes into slots.
I'll add snapshot tests this weekend as they take a while to inspect

In the meantime, any comments / suggestions on the docs are welcome 😄

damithc

Added some comments for the documentation.

docs/userGuide/syntax/questions.mbdf

damithc · 2020-07-21T16:38:40Z

docs/userGuide/syntax/questions.mbdf

+  :pizza: :pizza: :pizza: :pizza: :pizza: :pizza: :pizza:
+
+  </template>
+</question>


Any mention of whether all keywords need to match?

added a mention, there's a threshold option to configure it as well

I forgot to mention the checking algorithm, currently it just does case normalization + a naive substring search, so if you have a keyword xx, yxxy would also match.

Not sure if it should be more restrictive:

splitting by whitespace + case normalization

remove leading + trailing punctuation only: \[](){}&|\'\"<>#:;~_^=\\-‑+*/\\\‘’“”，。《》…—‐•\

then checking each token against the keyword

So far I can't really think of a use case that has leading and trailing punctuations, but to be safe, we could also provide an exact prop that skips step 2.

What do you think?

This is not easy to do -- not sure if we should even try. Validation of text questions is not going to be that useful for most cases. Given the risk of false negatives (as well as false positives), as an author I'm likely to just give the answer in the explanation and let the reader figure out.
Something related: It can be misleading to mark answer as correct when no keywords are specified. The reader might think the answer was validated when it was not.

I'm likely to just give the answer in the explanation and let the reader figure out.

I suspect this would be the majority use case as well, for questions that have long answers. Hence it's somewhat ok for the matching to be naive.

I was thinking more of mathematical / numerical questions with a single definite text answer, which the current algorithm may break (imagine a keywords="1.99" and the answer provided is 1.999 -- still correct by substring matching). Using the 1,2,3 above would fix this, but also makse the checking for long answers slightly stricter.

I'm not sure if we should advertise text questions as supporting mathematical / numerical questions as such, or defer it entirely to another pr and just use substring matching here 😮

It can be misleading to mark answer as correct when no keywords are specified. The reader might think the answer was validated when it was not.

fixed. it will still count toward the score in quizzes though.

I'm not quite sure. 'Works for most cases' isn't very reassuring. We need to specify precisely the class of answers that works 100% and inform users to use the feature only for that class. We can't expect authors to experiment trial-and-error to find out whether to use the feature for each question.

For example, something like the following is safe:

The validation works only if the expected answer is a precise phrase e.g., an equation (case insensitive, white space variations ignored)

Anything else that works 100%? If there is, we can add it to the above.

Supporting percentage matches is problematic because not rewriting and rewriting can both match the keyword rewriting.

The validation works only if the expected answer is a precise phrase e.g., an equation (case insensitive, white space variations ignored)

this dosen't work actually, in either algorithm, it's not the intended case

I'm not sure if we should advertise text questions as supporting mathematical / numerical questions as such, or defer it entirely to another pr and just use substring matching here 😮

I think we should defer those types of questions to another type of question, with a smaller input box.

I intend for the matching to be only correct 80-90% of the time. It's difficult by nature to match this 100% like you mentioned, and to reach 99% of matches we likely need some other complex language processing which is out of scope. There's also the show button as a fallback so readers can always view the answer.

I was wondering if a simple substring match that matches potentially more things but also risks more false positives (xx -> yxxy) would be better or a slightly more restrictive one with tokenization and punctuation removal as mentioned above as such would be better in achieving that 80-90%, but,
having just realised there's also the issue of non whitespace tokenized languages 😱, I think we could just stick with the former.

to further clarify I intend to add something like that to the docs:

Warning: Keywords are validated by simply looking for the keyword as a pattern in the user's answer!
This works well for some cases but not all. (and then a popover giving one good and one bad example)

Can go ahead.

docs/userGuide/syntax/questions.mbdf

ang-zeyu · 2020-07-25T09:32:36Z

Added tests, and resolved the above documentation nits. @damithc anymore comments about the documentation?

I'll give the tests one more look tonight before merging this if not, then I think we can get started with the release 😄 @marvinchin

damithc

Some questions added.

docs/userGuide/syntax/questions.mbdf

damithc · 2020-07-25T13:19:38Z

docs/userGuide/syntax/questions.mbdf

-    Question answer. <md>:pencil:</md>
-  </div>
+<!-- Insert markdown into the header and hint using the respective attributes -->
+<question ... header="Which of the following is correct? (**Header**)" hint="Think out of the box! :fas-box:">


Should this be an mcq question instead?

What's this ... here?

I made this checkbox for the purposes of the later more elaborate example with slots (Challenge: Try to get all the options correct in your first try!).

changed ... -> type="checkbox"

In that question, the question itself can be rephrased to fit a check-box type. The current question is an equation that can only have one answer. Hence, the reader will wonder why we are using check boxes.

not sure I follow, isn't the snippet above the same question with two answers?:

My bad. I didn't read the question closely. In fact, I read the last line only and thought it's a simple addition question for primary kids.

docs/userGuide/syntax/questions.mbdf

damithc · 2020-07-25T13:24:53Z

docs/userGuide/syntax/questions.mbdf

+header | `String` | `''` | The markup to insert into the question header. The header is omitted if this is not provided.
+header | Slot | empty | Functions similar to the `header` option, and overrides it if both are present.
+hint  | `String` | `''` | The content to display in the hint box.
+hint  | Slot | empty | Functions similar to the `hint` option, and overrides it if both are present.


I think we should some other way to indicate which attributes support the alternative slot syntax, rather than add one row for each. e.g., use a header^[s]

hmm, I was thinking we should actually introduce slots upfront in the components section and not all the way below in advanced tips and tricks, since they are widely used in the examples. (don't think we should forward reference in user guides). How about cleaning and standardising this in that PR?

No need for forward reference. e.g., we can make it a modal/popover. Define in one place and <include> everywhere needed. No matter where the reader encounters it first, the definition is just a hover/click away.

Sounds good. I'll add it in a pr after the one fixing the rest of the comments here

docs/userGuide/syntax/questions.mbdf

damithc · 2020-07-25T13:31:09Z

docs/userGuide/syntax/questions.mbdf

+  <template slot="hint">
+  How do you figure out which inputs are wrong? (or correct)
+  </template>
+</question></variable>


We don't use template anywhere else. Why not <div slot="...">?

updated, note that it introduces an additional wrapper <div> though.

perhaps we could build a shorthand syntax feature for <template slot="xx"> -> <t slot="xx>? (noting that vue 3.0 already shortens slot="xx" to #xx

docs/userGuide/syntax/questions.mbdf

damithc · 2020-07-25T13:38:28Z

docs/userGuide/syntax/questions.mbdf

-    Question answer. <md>:pencil:</md>
-  </div>
+<!-- Insert markdown into the header and hint using the respective attributes -->
+<question ... header="Which of the following is correct? (**Header**)" hint="Think out of the box! :fas-box:">


Alternatively, the intro section can simply give an example of each question type without code?

It feels a little repetitive as questions are pretty big

ang-zeyu force-pushed the question-component-revamp branch 2 times, most recently from 5233255 to cab592a Compare July 21, 2020 15:06

damithc requested changes Jul 21, 2020

View reviewed changes

ang-zeyu force-pushed the question-component-revamp branch from 6471525 to 284a9b0 Compare July 25, 2020 09:16

ang-zeyu changed the title ~~[RFC/WIP] Revamp question component~~ Revamp question component Jul 25, 2020

ang-zeyu added 2 commits July 25, 2020 17:27

Bump @vue/test-utils from 1.0.0-beta.33 to 1.0.3

5b0bb02

Revamp question component

f14a048

Render question, quiz, q-option attribute markdown

227508f

ang-zeyu force-pushed the question-component-revamp branch from 284a9b0 to 1f2c47b Compare July 25, 2020 09:28

ang-zeyu added 2 commits July 25, 2020 21:11

Add snapshot tests for questions and quizzes

0ef877c

Update questions section in user guide

def7e6b

ang-zeyu force-pushed the question-component-revamp branch from 1f2c47b to def7e6b Compare July 25, 2020 13:12

ang-zeyu added this to the v2.15.0 milestone Jul 25, 2020

ang-zeyu merged commit 077abb8 into MarkBind:master Jul 25, 2020

damithc reviewed Jul 25, 2020

View reviewed changes

This was referenced Jul 26, 2020

Touch up user guide questions section #1286

Merged

Misc doc updates #1294

Merged

jovyntls mentioned this pull request Mar 26, 2022

Deprecation of slots, attributes and syntax #1854

Closed

Conversation

ang-zeyu commented Jul 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ang-zeyu commented Jul 15, 2020

Uh oh!

damithc commented Jul 15, 2020

Uh oh!

ang-zeyu commented Jul 15, 2020

Uh oh!

damithc commented Jul 15, 2020

Uh oh!

ang-zeyu commented Jul 16, 2020

Uh oh!

damithc commented Jul 16, 2020

Uh oh!

ang-zeyu commented Jul 16, 2020

Uh oh!

damithc commented Jul 16, 2020

Uh oh!

ang-zeyu commented Jul 16, 2020

Uh oh!

damithc commented Jul 16, 2020

Uh oh!

damithc commented Jul 16, 2020

Uh oh!

ang-zeyu commented Jul 17, 2020

Uh oh!

damithc commented Jul 17, 2020

Uh oh!

damithc commented Jul 19, 2020

Uh oh!

ang-zeyu commented Jul 19, 2020

Uh oh!

damithc commented Jul 19, 2020

Uh oh!

ang-zeyu commented Jul 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

damithc commented Jul 20, 2020

Uh oh!

ang-zeyu commented Jul 21, 2020

Uh oh!

damithc commented Jul 21, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ang-zeyu commented Jul 21, 2020

Uh oh!

damithc commented Jul 21, 2020

Uh oh!

ang-zeyu commented Jul 21, 2020

Uh oh!

damithc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ang-zeyu commented Jul 13, 2020 •

edited

Loading

ang-zeyu commented Jul 20, 2020 •

edited

Loading

damithc commented Jul 21, 2020 •

edited

Loading