Hi,
I am implementing image occlusion with help of @dae and @glutanimate. I have implemented following UI/UX similar to Image Occlusion Enhanced. I have considered mobile first design so that it will be easier to use on AnkiDroid and AnkiMobile.
I have created this thread for UI/UX suggestions. (More tools shapes suggestion if required).
I have added Rectangle which can be used to add Square also and Ellipse so that it can be used to add Circle also.
Some of the features of Image Occlusion Enhanced I use the most are Fit image to canvas and the Align masks buttons. I find them both extremely convenient.
being able to make the masks temporarily transparent
being able to change the occluded image with one click
the ability to add text to images and to draw lines (e.g. to create arrows)
the ‘Labels’ layer, which allows for the creation of not-card generating masks (e.g. to hide some portion of the image on all the cards)
the ‘Remarks’ field, i.e. a field which is not displayed while reviewing and that can be used to e.g. store infos about the note. Since the notetype comprises mostly images and not text, manually adding a few keywords to the ‘Remarks’ field helps in keeping the notes well organized and easily searchable in Anki’s Browser.
I would caution against scoping in additional features while some core features are not in yet and the core UX is still in need of a lot of polishing. Generally speaking, I would vote for going deep on the UX side of things rather than wide, i.e.: Let’s focus on excelling at the core user experience rather than adding a lot of features that might work OK-ish. You will always find rarer user workflows that would benefit from additional tools, but supporting them can come at the cost of losing focus of the main path that 90% of all users are taking. The remaining 10% can be covered by add-ons.
Beyond implementation and maintenance costs, this is also important to make IO as easy to use as possible. One of the key faults of IOE in my opinion was that it was offering way too large and confusing of a toolset for what should be a fairly simple action: Just covering some labels on an image. In the spirit of my post on how to build a better IO than IOE, I think we should take heed not to follow too closely along with the add-on and break away from its complexity.
I think this is important in particular in light of now having to support both smartphone, tablet, and desktop use cases as I fear this is always a setup for leaving either one behind UX-wise (which is the case for desktop at the moment I fear – was planning on writing up a UX review on on that on the PR). IMHO, I think we’ve already got our work well cut out for us here and we should be careful not to underestimate the effort needed to make IO work equally well across desktop and mobile.
In terms of providing additional features that go beyond the typical use case: I do plan on updating IOE to support native IO and have already started working on a proof-of-concept add-on (+ a PR to make native IO more easily extensible) and things look very promising there.
With the core of IO being merged into Anki proper, IOE now has room to shine with features which are nice to have, but not essential. Going forward, I would imagine IO and IOE’s relationship to look like this: Native IO providing a highly polished core feature-set that works well across all platforms, and IOE providing additional tools for power users on desktop (and mobile in the future, once cross-platform add-ons are properly established).
Because of that, I think the point above on going deep on UX rather than wide rings even more true: We don’t have to include everything in native IO as tools like IOE can carry part of the implementation and maintenance cost. Again, I think this is particularly important if we want to create a sustainably easy-to-use & maintainable experience across both desktop and mobile.
With that in mind, I like @jcznk’s pick of features, but I think some of them are better relegated to the updated version of IOE.
For instance, while image annotation features like creating custom text labels and drawing arrows could make sense to scope into the core experience (as they are likely used frequently enough), I would say that’s much less so the case for things like wireframe mode (making masks transparent), changing the image within a session, shape alignment features, or a complex mask layers feature-set.
With that said, priority-wise, I would scope in any additional improvements to the masks editor after making notes editable as this is super important to the core experience of using IO.
Additionally, I still very strongly believe that the #1 improvement we can provide to IO’s user experience on the UI side of things is to move away from the multiple-window paradigm and integrate the masks editor with the regular editor, benefitting from the text formatting features that are already in the editor. If I had to choose between including additional editing tools and this, my choice would always fall on moving away from multiple windows.
At the same time, I can understand how working on new mask editing features is more fun and – in some ways – more straightforward. Still, I do believe that work on merging the editors would be hugely more effective in improving the IO user experience than any editing features we add. It would eliminate the “Add” button confusion, deck selection woes, lack of text formatting capabilities, and lacking support for tag sync and sticky fields.
I was planning on drawing up a couple designs here and writing up some thoughts. I think this could be more feasible to do than it looks like on the surface. Let me see if I can share them over the next week or two.
Some backend tasks remain as well of course, but let’s talk about that on the PR
Overall, I think we’re on a good path here (thanks to your great work, Mani), but we have to be careful about feature creep and keeping usability of the core workflow center.
I would caution against scoping in additional features while some core features are not in yet and the core UX is still in need of a lot of polishing.
I have created thread view the feedbacks for what additional tools should be added. I am exploring some other svg editor on play store to get know about UI that should be used in Anki.
We don’t have to include everything in native IO as tools like IOE can carry part of the implementation and maintenance cost.
I agree, we should use only basic tools that is frequently used.
I will check the editor and try to integrate masks editor in note editor window.
With that said, priority-wise, I would scope in any additional improvements to the masks editor after making notes editable as this is super important to the core experience of using IO.
I am thinking about adding the svg edit using this but this also required some improvement to make it work on mobile devices. I am still in process of integrating the features that is good UI/UX wise using fabric js.
I wanted to clarify because I think what I wrote might have been slightly confusing: What I meant was editing notes created by native IO, not notes created by Image Occlusion Enhanced (I would imagine SVG-Edit to only be useful in the latter case).
In other words, the situation where someone creates a note using the native IO editor, and then for example finds a mistake in the note and wants to correct it. Right now this is not possible because clicking on the native IO button in the EditCurrent window will launch you into creating a completely new IO note rather than editing the existing one.
As for existing Image Occlusion Enhanced notes: They can just continue to be handled by the add-on (Also, I am thinking of adding a feature to the add-on that would convert them to the native IO note type).
But generally speaking, if you are thinking about using SVG-Edit in some other capacity, I would advise against it because it’s really clunky on mobile. The large number of features it has are even more confusing on smaller screens, especially when you are using the touch screen.
I think that going with a custom masks editor (based on fabric.js) was definitely the right solution there.
I got it, I think may be integrating image occlusion into note editor will help in editing existing note. So that it will not open new window. I am testing implementation for it.
As others have said, implementing the core functions cleanly and in as integrated a way as possible should be the highest priority. But while we’re here, if it’s not too big a request, a setting to leave masks as defined by user rather than always stripping transparency and colour values would be nice - currently I have to edit this out of the addon code every time it updates.
Can the dimensions be set with percentages relative to the image instead of pixels? Otherwise the masks won’t fit after a batch-resize (some users do to shrink their collection size).
That’s a good point, though you’d want to retain a fair amount of precision to ensure things line up properly, which is going to make the numbers longer. Another possible approach would be to store the original image dimensions, and then modify the pixel coordinates by the ratio of the original and displayed image sizes.
I have already used svg.js in this project and I find it difficult to implement some basic features like panzoom and drag & drop etc. Also everything comes with addon in svg.js.
The fabric.js is easiest and it is easy to access to objects in layers.
