Contrast functionality should be made asynchronous.

sidntrivedi012 commented 5 years ago

Please describe the problem (or idea)

User has to click Apply even to make a slight change to his image which kinda slows down the process.

What happened just before the problem occurred? Or what problem could this idea solve?

What did you expect to see that you didn't? I expected to find the asynchronous feature in which image automatically gets updated as the user slides the bar.

Please show us where to look

http://sequencer.publiclab.org...

What's your PublicLab.org username?

sidntrivedi012

This can help us diagnose the issue:

Browser, version, and operating system

Browser- Mozilla Firefox 64.0 OS - Ubuntu 18.04 LTS

Many bugs are related to these -- please help us track it down and reproduce what you're seeing!

Thank you!

Your help makes Public Lab better! We deeply appreciate your helping refine and improve this site.

To learn how to write really great issues, which increases the chances they'll be resolved, see:

https://publiclab.org/wiki/developers#Contributing+for+non-coders

welcome[bot] commented 5 years ago

Thanks for opening your first issue here! Please follow the issue template to help us help you 👍🎉😄 If you have screenshots to share demonstrating the issue, that's really helpful! 📸 You can make a gif too!

sidntrivedi012 commented 5 years ago

Our user experience would be much better if we add an asynchronous feature to our slider of contrast, brightness etc. Right now, the user has to click Apply everytime he wants to see the changes which slows down the whole process in a way. @jywarren WDUT ?

jywarren commented 5 years ago

I think this is interesting, yeah! With text/number inputs, showing the current state is a bit more complex (would we have to show a spinner each time?) but with the sliders maybe each time you release it, it could recalculate automatically? What do other folks think? @publiclab/is-reviewers

sidntrivedi012 commented 5 years ago

Exactly @jywarren . I think that as we move the slider we can make asynchronous requests of the parameter that we have decided and the image can get edited accordingly.

Divy123 commented 5 years ago

I think the functionality is great to implement and I would like to work upon it.

sidntrivedi012 commented 5 years ago

Great @Divy123 . Even I would like to help anywhere if possible.

rexagod commented 5 years ago

@sidntrivedi012 This would definitely prove to be a nice addition to the image-sequencer. Also, you can ask @publiclab/is-reviewers if you have any doubts or so and we'll be happy to help. Thanks!

sidntrivedi012 commented 5 years ago

@rexagod Definitely. Currently, trying to get familiar with the code base.

jywarren commented 5 years ago

I had another idea on this. One reason we are hesitant to make /everything/ synchronous is that some modules take time to run, so if we are running them every time there's an interaction, it could bog down the UI.

But what if we opened a new issue, where we offered modules a function to display a "preview" rather than run on the main image. Kind of like how we do on the quick menu:

That could run really quickly and display a mini version of the step settings quite quickly, then you could say "Save" to apply it to the main image.

This idea would take some UI design work, but could address synchronicity issues a bit. Thoughts?

(and to be clear, this need not block this issue - for some types we could still do asynchronous, but if you like the "preview" idea better, i'd love to discuss more)

sidntrivedi012 commented 5 years ago

@jywarren Right, the asynchronous calls will surely take some time. So, it would be a nice go to first give the user a preview of the customization and when he finally decides he can click the add changes button. But, the issue is where will we add these features on the page without disturbing the UI?

One thing we can do is we can add a modal for every customization's preview. And when the user gets satisfied, he can apply changes and get back to the main page.

@rexagod @Divy123 What are your views on this?

harshkhandeparkar commented 5 years ago

I think this should not be implemented as every step after the step that is asynchronously updated will get uodated and all the previews will get updated and everything will stop working(almost) so saving changes when required is better I think.

Maybe we can create a preview only for a single step in a seperate sequencer in the Browser itself? Maybe on a downscaled example img with less res?

@jywarren @Divy123 @sidntrivedi012 @publiclab/is-reviewers

jywarren commented 5 years ago

Ah, Harsh has a point. If you're modifying early in a long sequence it could have serious performance ramifications. I like the idea of a preview; i think we had an issue open for this already, so let's try to find that and then make this proposal contingent on that. The issue could be renamed:

"Sliders for some module settings should live-update image preview" and we can resolve the preview generation first before finishing this. Thanks!

On Sun, Mar 17, 2019 at 3:58 PM Harsh Khandeparkar notifications@github.com wrote:

I think this should not be implemented as every step after the step that is asynchronously updated will get uodated and all the previews will get updated and everything will stop working(almost) so saving changes when required is better I think.

Maybe we can create a preview only for a single step in a seperate sequencer in the Browser itself? Maybe on a downscaled example img with less res?

@jywarren https://github.com/jywarren @Divy123 https://github.com/Divy123 @sidntrivedi012 https://github.com/sidntrivedi012 @publiclab/is-reviewers https://github.com/orgs/publiclab/teams/is-reviewers

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/publiclab/image-sequencer/issues/738#issuecomment-473708878, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ6LECH7H092z1b-FqLimAQ0ZQJY5ks5vXp4ogaJpZM4aeOz5 .

publiclab / image-sequencer