demo Improvements for summer

[tech4GT]

This is a list of ui improvements ideas for the demo for this summer

• Add sharing features to sharing services like facebook, twitter, instagram etc, people should be able to share result of one step or the complete sequence also adding support for saving it local device
• Improve the styling and UX of the UI like adding better progress overlay etc
• Adding support for offline mode and push notifications, this can be done with progressive elements like caching
• Enable processing on alternate threads, this can be achieved through service workers to run in background
• Add documentation for all steps so that user better understands what each step does and add an example for each one of them (made this much easier through Module info.json -based demo UI (WIP) #219's info.json-based description setting)
• Add a search interface for modules
• camera "input" module which uses WebRTC (like on http://infragram.org/sandbox) instead of file drag/drop to fetch an image (this is not just demo, but should be its own issue i guess, but would be great for the demo! -- breaking out into explore standard multi-source upload with Uppy package #212 )

[jywarren]

GitMate.io thinks the contributor most likely able to help you is @jywarren.

Possibly related issues are #118 (Assorted improvements to be broken into separate issues), #74 (Runkit.com demo), #142 (Add select dropdown for some module UIs in demo), #3 (CORS Image error on GitHub hosted demos), and #145 ("reader is not defined" error on demo).

[tech4GT]

@jywarren please have a look at this, we can keep updating this list list as we move along, i think this basic set will be enough for the summer, what say?

[jywarren]

I think we should be able to add some more detail to the UI/UX changes here too. It's a good list!

How about:

• improve the "add additional module" interface:
  • so you can read the description before adding
  • so you can search more easily for modules (not a dropdown) and learn about them
• maybe the "insert module between steps" from suggestions #196
• a camera "input" module which uses WebRTC (like on http://infragram.org/sandbox) instead of file drag/drop to fetch an image (this is not just demo, but should be its own issue i guess, but would be great for the demo!)
• a place to save "sequences" for sharing, even just by their URL links via the demo
• ensuring the URL generator saves module settings, not just the modules themselves (for true exact sharing of a sequence + settings)
• Displaying RGB values when hovering over images in the demo

@ccpandhare what do you think?

[ccpandhare]

Hi...!

I am a bit unclear about the multithreading part, offline mode regarding its implementation. Could you elaborate on that @tech4GT?

As Jeff said, these are completely different headings and some of them do need more detail.

I agree with @jywarren!

Nice start @tech4GT but we do need some more detailing here!

[tech4GT]

@ccpandhare I think we can use service workers for both of the them. First of all we can add support for caching and push notifications by using progressive elements and since we use a single script on the frontend that should not be an issue. Secondly since service workers run in background we can use them to perform the processing of steps in background

[tech4GT]

@jywarren I don't fully understand the sharing part with url, so are we trying to pack everything in the url so that the url is unique and can be user to share the image, so we need to upload the pictures to something like imgur and then pack that url in our url somehow so that we can fetch the image and apply steps on it, is this right?
Also what if user wants to share result of last step only, should we handle that separately, maybe we can add both share as image and share as sequence?

[jywarren]

Re: sharing - the idea is, if someone composes a sequence and tweaks the settings, they have a process which is really useful. And if we can concisely store that in the URL itself, then they can share that workflow (sequence + settings) with other people, or bookmark it, and we don't have to use a database to save it. We wouldn't save images, just the workflow itself. But we might want to start collecting these too -- they could in theory become "meta modules" with names of their own. Maybe that's a feature in its own right?

Another aspect of this is that if we have a consistent string-based way to save a sequence and its settings, that's a good format to use for remote REST commands down the road when we decide to do that -- #198 -- and also we could base a "meta module" system around such a string. A meta module could be a module which contains a string describing a set of modules and their configurations, that can itself be re-used.

Moved to: #200

[jywarren]

Sorry to dump my "meta module" idea here -- it ought to be broken out into its own issue, i guess. Will try.

On another topic, let's start compiling a list of nice "use cases" that demos could aim for -- a separate list from the features we want to build/fix on the demo itself. Maybe this is another issue as well, but to start it off:

• particle identification and sizing for air pollution blob/region detection and extraction for particle analysis #172
• color differentiation between two patches on a chemical test strip (i can add more on this later, but it's a common thing to want to do analysis!

...more I'm sure can be added!

[tech4GT]

@jywarren please do have a look at #172 i had a similar idea about meta modules or macros, we can even save them in cli using a macros.json file and it will be awesome coz region extraction itself can be our first met-module or macro, what say?

[jywarren]

Love that. Just read it. Super. Also opened #200 to track that idea.

[jywarren]

Lot of this just completed in #245! Checked off. Tracking more in #246 and assoc.

[jywarren]

Im going to close this and break out the remainder!!!