Closed pigoz closed 6 years ago
Hi, thanks for reaching out. For the issue you mentioned of scrolling while the whiteboard is enabled, I believe it's effectively solved by 8223d04.
As for the idea itself, I can see the appeal, but I'm not really convinced that the benefits and user interest would be significant enough to justify the extra maintenance burden that it would introduce. We recently had #4832 also, where I rejected a UI enhancement for the same reason, and I would give the same advice here as I gave there, i.e. to make a kind of add-on app that provides a reviewer that gives a lot of different customization options not available in the mainline AnkiDroid.
I'm not sure whether or not @lucwastiaux is proceeding with that, but if so you might consider working together.
@timrae thanks for your speedy reply! Is the webview for the card using the same html document for front and back card, or if otherwise allows to share data between the two?
If it does, I could actually implement the drawing area in javascript and html canvas and embed it in my card layout, without any change to AnkiDroid.
Hi @pigoz - unfortunately it seems that the WebView is reloaded from front to back but if I have understood correctly, that is not a requirement, it is just the way things are done now. It might be possible to author a PR that maintains state front to back and have that merged in?
There is actually a separate issue that may be solvable if the WebView state was maintained during the card flip, which is where I got this information: https://github.com/ankidroid/Anki-Android/issues/4828
See also discussion here: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/anki-android/BGXfuhixpRw/TYoWbbwoAwAJ
@pigoz
That would be ideal to avoid code changes. I believe you should be able to share state via cookies, please let us know if that does or doesn't work well, or if you have any other ideas
Just a heads up for anyone interested in this feature. I made a proof of concept using HTML5 canvas and use the HTML sessionStorage to persist the data of the drawn lines across page reloads.
Everything works beautifully (except that you have to disable touch events in AnkiDroid, otherwise touch events from drawing get picked up by AnkiDroid, but that is something I can happily live with).
When I have some time I will clean everything up, and publish my sources and an example card layout.
After two evenings of coding I finally published my sources [1] (and some screenshots), they are still work in progress but definitely usable.
Now I will stop spamming this thread with more replies :)
Awesome! I think it would be more useful if you publish it as a shared deck with a note type and some example cards.
I don't think I'll ever look at the character 九 the same again... Lol
Awesome! I think it would be more useful if you publish it as a shared deck with a note type and some example cards.
Yes that's the plan, but I want to dogfeed it a little before that.
I don't think I'll ever look at the character 九 the same again... Lol
Not my mnemonic, it's an example deck. I reckon it's pretty effective though :)
Hi @pigoz , do you think your solution is applicable to the following topic as well?
Hi, yes you can share state between the card front and back through sessionStorage
On Wed, Jun 20, 2018 at 11:06 PM, Arman Shahrisa notifications@github.com wrote:
Hi @pigoz https://github.com/pigoz , do you think your solution is applicable to the following topic as well?
4828 https://github.com/ankidroid/Anki-Android/issues/4828
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ankidroid/Anki-Android/issues/4868#issuecomment-398896746, or mute the thread https://github.com/notifications/unsubscribe-auth/AABgaeUMVzVlpVhHiKZdkJ4fv44ML5jlks5t-rlAgaJpZM4Uid8r .
@pigoz - I just looked through your project, and while it looks super-tidy and very maintainable, I couldn't find any technical overview on (for instance), exactly how to initialize the session storage, what HTML-level accessors you use to store/retrieve information etc. I'm personally pretty good with Java but kind of useless at the HTML/Javascript level so any pointers there may help move @armanshahrisa along in finding a solution for what would be a pretty neat feature for Anki decks - multiple-choice cards...
@mikehardy fair point. sessionStorage
is a key-value store (it is string based, so to store json data you have to stringify it first). Documentation for session storage is here on MDN. The API is identical to localStorage
, if you are familiar with that, but local storage must be enabled on WebView instantiation.
What I do is I have 2 javascript files. The former is included in the front card's HTML (whiteboard.ts
), the second one is included in the back card HTML (result.ts
). In the first file (front card's one) I save the data after user interaction, in the second file (back card), I load the data I just saved on init (in my case the kanji shape data drawn by the user, but this could be any kind of data, in the example from #4828 it would be the all
variable).
load and save are defined here
That is great information @pigoz, thank you very much replying and sharing it
Hey @pigoz I can see you've continued development on your project and it looks pretty amazing. If you could package it up in any way that made it easy for others to integrate, and put some docs in the AnkiDroid wiki maybe with the template as an attachment you'd be internet famous among flashcard enthusiasts :-)
Hey @pigoz I can see you've continued development on your project and it looks pretty amazing. If you could package it up in any way that made it easy for others to integrate, and put some docs in the AnkiDroid wiki maybe with the template as an attachment you'd be internet famous among flashcard enthusiasts :-)
Hi @mikehardy! I have been using it daily for the past months since I'm going through a Kanji book, and I must say it served me well :) There is a known bug I have to fix and I'd like to add a button to clear all the state.
Not sure how to go about adding it to the wiki. Maybe I could add a new section to Other documentation for users
called Drawing area for Kanji practice
. There I would add a basic readme, link to download the deck and link to sources. Sadly a one-click install process is not possibile AFAIK, since JavaScript files have to be manually added to the Anki media collection folder to be uploaded to Ankiweb
Could more general than that - it's anyone that needs to draw anything, maybe not just Kanji - imagine kids drawing basic shapes for instance? But otherwise, your general plan sounds great
I'd keep the bulk of your documentation centrally on your GitHub repository, and add some minimal instructions or explanation to the advanced formatting wiki. We could also have a sticky thread on the forum for it if you like because it's pretty cool.
I did a little revamp of my project: fixed pending issues, and added better documentation to the project's README so that it's focused on users and not developers.
I also added some brief introduction and a link to the project's page here in the advanced formatting wiki as suggested by @timrae.
That looks great - I proposed what I think is just a typo fix on your README.md but other than that, all seems to check out.
Hello, this is a request for feedback on a feature I want to implement for myself, I would like to implement it in a way that can be merged on master, for other people to use, so I am seeking out some feedback on my idea.
What I have in mind is a way to limit a whiteboard to a particular screen area in the card. This is a mockup I made in Anki (see the front side)
The whiteboard would be inserted in the card template with a special field
{AnkiDroidWhiteboard}
, and draw events would be limited to that area. This area would share it's state between Front and Back layout, so that the user can draw in it in the front of the card, and check if the sketch is similar to something in the back side (i.e. a kanji stroke order diagram).Moreover making it's area limited, allows the user to scroll the card content, which I believe would be a great user experience.
To control the whiteboard size, the special field would try to fill it's container, so the user can limit it's size like so:
This opens the possibility to make the whiteboard (and it's content) smaller on the back side.
Any feedback is welcome.