ChRIS UI: Feed page

[NicolasRannou]

[NicolasRannou]

[mairin]

@NicolasRannou if I recall correctly - this feed page is basically a feed (kind of like an email thread) of the processing that occurred during a particular job? (or is it all jobs that occurred with respect to a single piece of data?)

how do you navigate to the feed UI page from the home page? you click on one of the grid items on the home page?

[NicolasRannou]

Yes-

In addition, the "note" (the right hand side panel) if "feed" specific (not "jobs" inside a feed specific).

[mairin]

Some more Q's :)

1) Once image data has been placed into a feed - the data set can't be changed right? so once you create the feed, you can't remove or add additional image data?

2) The 'Process data' popup above - is that the config for a 'Process data' plugin, or is the 'Process' dropdown in the upper right inside the dialog how you select a plugin?

[mairin]

And more:

3. Clicking the 'process data' button brings up the process data dialog, and once that is filled out, the data is processed and a new entry appears in the left most column, right?

4. Is there any notion / desire / thought around reordering the items in the left most column and reprocessing? Just a weird question but something about this reminds me of how you can apply layer blending modes or different filter layers in an image processing program like gimp or photoshop, and sometimes you want to reorder them so they apply in a different order to pull out different pieces of the image.

[mairin]

Here's an idea I've been playing with for the feed view:

Some issues / things to think about:

• I dropped the left global nav from this. Material UI standards aren't real strong on nav / workflow for non android platforms, although example google aps do keep a left global nav. It's much cleaner without though it is possible to add back. (Another option is to make it a slider?)

• I put the feed 'threading' nav on the right. it makes for a cleaner display, problem is maybe it makes more sense to have the nav on the left because of left=>right wider=>narrower specificity. however, that would also complicate bringing a left-side global nav. maybe a card set isn't the right way to display this kind of data? or maybe it's not too funky to have this on the right?

• I took each plugin run from the list of feed 'events' (<= is that the right term?) and created a card for it and made a chronological flat list. In the mockup I expanded some of the cards where I had a vague understanding of what they'd show, for others i left them 'collapsed'. imagine this like viewing a list of emails in gmail, the same concept you've had in ChRIS for some time.

• my thought for the viewer is you could launch it from a card that involved imaging data, and it'd be a modal thing (like when you view a doc in google drive)

• 'report creation' card at the end is the example of what a failed plugin run would look like. i'm guessing if a plugin failed in the middle all plugins following it would also fail? also, is there any example of what a report looks like?

• we probably at some point want to develop a set of standards for plugin displays like this, i guess borrowing heavily from material UI, so we have a clean consistent look to feeds!

• each feed can have multiple data sets, right? (eg in this example, flair cube, no value provided, sample series...) is the plugin run on every data set in the feed? or, to ask another way: is the set of data sets associated with a feed something that persists across all plugin runs? if so, maybe better to pull the set of data sets associated with the feed out some way / compartmentalize them separately from the chronological list of plugin actions.

• (say i have 3 datasets associated with a feed. can i add a 4th data set at some later date and have the same set of plugin actions run on it? does this make sense?)

[NicolasRannou]

BTW did you already think on a mechanism to write "notes" for a feed? the idea is to add more contextual information for the feed: why was it created, population, parameters, etc.

[mairin]

@NicolasRannou I did! I think I forgot to ask my question there - are the notes attached to the feed, or specific events in the feed? E.g. can I attach notes to any single plugin run or is a feed-wide thing? Also, it seems feeds can include multiple data sets, assuming the notes would be across data sets or could they be specific to one?

Simplest would be a feed wide notes field... I was thinking if that was the case, it could go in the right sidebar under the nav? I'm not 100% sure what type of notes the users would be writing though.

[NicolasRannou]

@mairin the notes a feed-wide, so yes on the right hand-side could work!

[mairin]

Let me look a little into material design guidelines to make sure it'll work, if not we could tab it too. Since the list of plugin events could get arbitrarily long vertically maybe better to have the notes above it, but then long notes can push the nav down... will poke at this today and see if theres a better solution :)

(I was thinking of something like this when thinking it would go in right sidebar):

[NicolasRannou]

I like that! Maybe just being able to collapse/expand notes could be enough to work around long notes (having it collapsed by default just showing the first lines of it)

[NicolasRannou]

Also, that may be a detail but do we want to present plugin from most ancient to most recent or the other way around? It seems the showing the feeds from the newest to oldest makes the most sense.

Edit: Thinking it through I think that makes a lot of sense. My current idea to run a new plugin: click the "+" button, that will create a new card at the top of the list where the user would select the next plugin he wants to run. It would look like the "plugin" cards but would have the specific purpose to create new plugins.

[mairin]

@NicolasRannou yeh, good call! Email clients have most recent threads at top, I guess i was doing it in chronological because once in a thread, the oldest is at top (but usually minimized.) But I think the way you've laid out the page above, where the control to add a new plugin at the top where the plugin info will go, is good. I think the put the newest emails at the bottom in the thread view in say gmail because the compose window is on / towards the bottom (usually, right?)

I would give the add plugin 'card' the same width as the ones below it if you can though. I'm thinking about the visual design here, how to differentiate the add plugin / newly-created plugin card at the top from the cards below it. (no answers at the moment. gut tells me maybe shading the card background color of the new ones, eg a super pale yellow or blue might be a material design friendly way to do it)

[NicolasRannou]

Yes please do not worry about the style, literally, no work has been done on this side. :)