You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A simple card could be provided to make working with images explicit. This could be real useful for kids, to Storify their revision cards. ⚠️ I need to be explicit about what is allowed in each card's field.1
Draw! #50 I've been meaning to do something with this for ages.
Image could come up top (under the header) and have a reveal?
Realistically, do you need multiple occlusions on one image?
Group cards together as a sort of "story" with images.
I feel like adding an image can be a bit messy combined with the pre block — an image can be a useful aid but might be worthwhile splitting out into a Draw! #50 note type.
I'm not convinced by the image occlusion (forces you to add a box to cover parts of the image, or it won't let you save the note). The reasons being:
It has no ability to add tags (so no grouping of "stories")
It's quite fast to create multiple occlusions (with same image) but ...
The photo "editor" is pretty basic in what it can do ...
It's nothing that couldn't be done with Mac's preview app
Testing them on a subject
The bigger the function or program, the harder it becomes to visualise.
I remember sketching things out on a massive whiteboard, and you need
room to take it all in. What's mobile Draw! cards best for?
Should some cards be better suited to desktop full-screen mode?
You could say the same about big programs in general for all the cards in Anki Programming Themes. Once it becomes sizeable, how do you break it down into manageable chunks for cards? Is this the point that some other method is preferable?
Early Racket finger exercises
The typewriter function would be better if I can dig it out, but this visualises the layer order perhaps better than (image (image (image ...)))
Json Decoders
Getting Json from the server
Decoding it
Doing something with it (a list of photos)
Elm Lang's decoders could be a pretty good test subject. They're kind of tricky to understand with text alone, and need broken up into chunks to understand the whole. I'm currently reading Programming Elm, but the Beginning Elm book has a pretty good section on Http.get and Json.Decode too.
Footnotes
For instance, it's sometimes handy in the sample code or keypoint code to add in some example (written) code, as well as (or rather than) and <image>. Should I be very strict and only allow images in these fields? Should we just link to the full program or keep it to small lines of code in the keypoint notes? These things need more thought — especially if the Draw! card is headed where I expect it to head (code stories, puzzles, drilling practices, multimedia, etc). ↩
I'm going to say "YES" to this, tentatively. I think it would be a good idea to have a dedicated card for images, to do something interesting. You'll still be able to add an image technically, but for missing and simple cards, they will be discouraged. ↩
The text was updated successfully, but these errors were encountered:
badlydrawnrob
changed the title
Remove the ability to add an image to the pre block?
How can we make images and drawings more relevant in cards?
Jul 4, 2024
badlydrawnrob
changed the title
How can we make images and drawings more relevant in cards?
Make images and drawings more relevant in cards?
Jul 4, 2024
I've decided #66 that I'm going to create a dedicated `img` (image) card instead of allowing the `pre code` block to have images.
It won't actually _stop_ you from adding an image to a `pre` block, so it's backwards compatible, but I'm going to _discourage_ people from doing it.
Perhaps have an optional image occlusion (if it doesn't complain like thecloze
note type)pre
block?2 (DONE)Gathering Draw! cards together
A project, for instance, could be grouped with tags (there's not really a way to link cards together)
We're already:
HTML
mode by default forpre block
and other fields #62I feel like adding an image can be a bit messy combined with thesplitting out into a Draw! #50 note type.pre block
— an image can be a useful aid but might be worthwhileI'm not convinced by the image occlusion (forces you to add a box to cover parts of the image, or it won't let you save the note). The reasons being:
It has no ability to add tags (so no grouping of "stories")Testing them on a subject
You could say the same about big programs in general for all the cards in Anki Programming Themes. Once it becomes sizeable, how do you break it down into manageable chunks for cards? Is this the point that some other method is preferable?
Early Racket finger exercises
The typewriter function would be better if I can dig it out, but this visualises the layer order perhaps better than
(image (image (image ...)))
Json Decoders
Elm Lang's decoders could be a pretty good test subject. They're kind of tricky to understand with text alone, and need broken up into chunks to understand the whole. I'm currently reading Programming Elm, but the Beginning Elm book has a pretty good section on
Http.get
andJson.Decode
too.Footnotes
For instance, it's sometimes handy in the sample code or keypoint code to add in some example (written) code, as well as (or rather than) and
<image>
. Should I be very strict and only allow images in these fields? Should we just link to the full program or keep it to small lines of code in the keypoint notes? These things need more thought — especially if theDraw!
card is headed where I expect it to head (code stories, puzzles, drilling practices, multimedia, etc). ↩I'm going to say "YES" to this, tentatively. I think it would be a good idea to have a dedicated card for images, to do something interesting. You'll still be able to add an image technically, but for
missing
andsimple
cards, they will be discouraged. ↩The text was updated successfully, but these errors were encountered: