Adding SVG images to cards

[Neicudi]

Thanks! Will take a good look this weekend

[jprspereira]

There are only 47 prefectures, the binge will be a short one

I binged Toradora! in 1 day too

[Neicudi]

addclass doesn’t add a class, so you don’t know what answer is expected in (1.). You can see it by inspecting the input field

Fixed this one

for type (1.), a click shouldn’t do anything, but it counts as a (always wrong) answer.

I changed it to not do anything when there is a type field, but imo the problem was that you used class='kitsun-click' in that layout while it is not needed?

I like placeholder texts for the input box

Incoming relately soon (read: after launch)

Always lightning mode for (2.) at the moment

I thought this is what it had to be? Before it acted normally and you would get a “next” button on the backside. Should it advance to the next card upon correct click and show the backside upon wrong click or something else? ^^

I think that addclass is not powerful enough, you only get one customstyle across all your layouts. It would be good to have either a clue which layout you are on during the reviews for appropriate styling, or add an arbitrary classname in the {{addclass}} to style in an arbitrary way.

Hmm… I get where you are coming from. Although you could always solve it like this:

Give a separate id/class to the wrapping element of your content PER layout. So layout 1 has class='lay1' while layout 2 has class='lay2' and so forth.

Then you will be able to style it like this:

.lay1 .customstyle{
   //layout 1 specific style here
}
.lay2 .customstyle{
   //layout 2 specific style here
}

I will update Kitsun soon, please let me know what you think and thanks for preparing the test scenario! Very handy

[acm2010]

Thanks for the update!

I changed it to not do anything when there is a type field, but imo the problem was that you used class='kitsun-click' in that layout while it is not needed?

Hmm maybe But I like the way of thinking that the clicking functionality is activated by using {{click}}, and not editing the SVG so much

Incoming relately soon (read: after launch)

I hope to have the deck ready shortly after launch then

I thought this is what it had to be? Before it acted normally and you would get a “next” button on the backside. Should it advance to the next card upon correct click and show the backside upon wrong click or something else? ^^

A Next button would be perfect, my problem was that it goes to the Know/Don’t Know button, so you can click the wrong thing and then say “I totally knew that” … I wanted it to go directly to the right/wrong state on the back, because you already know if the answer was right or wrong coming from the front side. The click card should be an input card.

Give a separate id/class to the wrapping element of your content PER layout. So layout 1 has class='lay1' while layout 2 has class='lay2' and so forth.

Thanks, that already does what I want. I guess I initially got the wrong idea what should go into a single layout, and I should maybe also use several templates. I was maybe reusing too many things

[Neicudi]

I hope to have the deck ready shortly after launch then

hahaha maybe I’ll try to get it in there sooner then

A Next button would be perfect, my problem was that it goes to the Know/Don’t Know button, so you can click the wrong thing and then say “I totally knew that” … I wanted it to go directly to the right/wrong state on the back, because you already know if the answer was right or wrong coming from the front side. The click card should be an input card.

Oh you are totally right… I mixed them up! I can make it so that you have a next button instead of the know/dont know buttons when utilizing the kitsun-click feature

[acm2010]

Oh you are totally right… I mixed them up! I can make it so that you have a next button instead of the know/dont know buttons when utilizing the kitsun-click feature

I think this will probably be included in your change, but just to mention it: on the front side you can skip the clicking altogether by using Show or space, which would probably be counted as wrong

---

For the scenario (2.), was your plan to style the backside only using {{addclass}} (for example to show the correct answer on the map), or adding .correctclick on the backside as well? [The changelog sounds like it should be on both sides: To make it easier to show the user what the correct choices were, each ‘correct’ element will also get the correctclick class added to them.] At the moment .correctclick is only added on the front, even when I’m using {{click}} on both side.

And is there a way to remember what the user clicked? Like “you clicked X (shown in yellow) but it was actually Y (show in green) …”

[Neicudi]

I think this will probably be included in your change, but just to mention it: on the front side you can skip the clicking altogether by using Show or space, which would probably be counted as wrong

Ah! Right, I’ll just remove the button from the frontside then

I think the original plan was to have .correctclick on the back as well, although I might have changed it with one of the later changes… Would having that class on the back be good enough?

There currently isnt, but I can definitely make it. Just gotta think of what might be a good solution for displaying it inside layouts… perhaps a {{enteredanswer}} field which can be used by both “click” cards like these AND normal input cards?

[acm2010]

Ah! Right, I’ll just remove the button from the frontside then

Great! I don’t know how you handle it internally, but that input type should be mostly the same as the typing input. So the space key shouldn’t be doing anything as well

I think the original plan was to have .correctclick on the back as well, although I might have changed it with one of the later changes… Would having that class on the back be good enough?

Yes, I think it’s good enough, there is also {{addclass}} for more styling needs.

There currently isnt, but I can definitely make it. Just gotta think of what might be a good solution for displaying it inside layouts… perhaps a {{enteredanswer}} field which can be used by both “click” cards like these AND normal input cards?

I was considering to just add a .userclicked class to the clicked entity and then use it like .correctclick. Having access to an entered text or the string of the id of the clicked item would be cool as well (like “We wanted Aomori but you selected Saitama” We wanted {{name_en}} but you selected {{front:clicked_id}} or something).

But my idea was only targeting at clicking, with an additional class for a styling of the map.

[Neicudi]

Alright, I’ll put it on the list for this weekend!

Ah just having a class would be easy too… I think I might just implement both since it seems that the one i proposed could be handy as well

[acm2010]

Can you please put one more thing on the layout input whitelist, I was cleaning up the SVG a bit by hand. These tags look like this:

<use id="Akita-Akita" x="620" y="403" height="100%" width="100%" xlink:href="#CapitalMarker" transform="translate(-2.001)" />

You don’t need to repeat a group of shapes over and over again with use.

[Neicudi]

Sure! But do you need all the attributes on it as well?

[acm2010]

Sure! But do you need all the attributes on it as well?

Yes, most of them are mandatory, like the href specifies what SVG definition you want to reuse.

transform is good on everything

---

Unrelated note: trying to get prefecture information out of WikiData using SPARQL causes severe brain rot.

[Neicudi]

Just wanted to let you know that the tags/attributes have been whitelisted. Sorry about the wait!

As for the other points (both svg and import related, I ran out of time this weekend! I’ll probably be able to take a look next time (aka Wednesday or Weekend).

[Neicudi]

@acm2010 I’m sorry but I can’t find the exact things left to do for the SVG/“click” cards. Would you mind letting me know what they were again? I plan on finally finishing it today.

So far I think it’s still missing:

• Removing the next/know/don’t know buttons.
• Showing no button at the front and only a next button at the back?
• ?? (styling classes?)

[acm2010]

Yes, that’s basically it.

1. You should be forced to click somewhere, so the next button should be removed, and the hotkeys like Space, Enter disabled. [In lessons you may still go over the front with Enter anyway?]
2. From the IDs you know if a correct answer was clicked, so you should directly proceed to a .right or .wrong backside [instead of choosing know/don’t know yourself]. Lightning mode should skip the backside.
3. The added class for the styling on the backside is not applied, it works only on the front for both {{addclass}} and {{click}}.

Optional stuff: it would be also great to have a class added to the entity that was clicked, to show something like “you clicked the red one, but the answer is the green one.” Similarly, I was thinking to access the ID as a string of what was clicked, like “You clicked Saitama instead of Shimane!” or something.

Don’t know how hard that is, you can also put those on the waiting pile

[Neicudi]

Done with all the mentioned points (including optionals), will be live with the update later today

[Neicudi]

It’s live, let me know if it works as it should.

I changed your (old?) layout a little bit to test with by the way.

[acm2010]

Looks great so far, I will finish the deck soon.

However, after testing a bit, blocking the space and enter keys for the backside is too much, the front is enough. At the moment you always have to use the mouse to proceed.

[Neicudi]

Ah, that’s an unintended side-effect I guess I’ll put it on the list for the weekend

[jprspereira]

How’s this project going?