ChRIS UI: Home page

[NicolasRannou]

[NicolasRannou]

[NicolasRannou]

@mairin current CUBE mockups for the home page

[mairin]

@NicolasRannou is each item in the grid right now a particular job, or is it a particular image set? e.g., right now is the currency of the grid specific jobs or data?

[mairin]

Another random question :) The grid icon with the '3' emblem in the upper right - where does that go? is it a notification queue? and three dots to the right - what does that do? is it a menu?

[NicolasRannou]

So 2 ideas are mixed and need to be splitted:

1- maybe we want to allow the user to go back and forth between "card" and "table" view. Cards look nicer and may give more visual feedback but table is more compact and efficient. Not sure if we need both or not.

2- we want to notify the user if one of the "processing" inside a feed has finished. When the user clicks on the notification, we may want to redirect him to the relevant "feed/processing".

Does it make sense?

[mairin]

1 - card vs table view toggle - I think this is a good idea, but probably not a high priority at this point? (but yeh being able to find a feed by table col sorting is good!) the search box searches the feed cards, yeh? if so i think just cards for now is ok?

2 - 100% makes sense. Maybe in the notification have something like, "Processing of $foobar has completed. View it now."

[mairin]

More questions :) For the (+) add button in the bottom corner:

1) Upload local data / Find data on ChRIS / Pull data from PACS => these all essentially allow the user to select imaging data to work with, and then I am guessing start a feed for the selected data set?

2) Real-time collab => I remember seeing a version of this in earlier ChRIS screenshots - does real time collab create a feed too?

[mairin]

Hey @NicolasRannou so I haven't played around with notifications yet, but I played around a bit with list / table vs tiles... here's what I have. The tiles are maybe overly huge. :) Hopefully more tomorrow.

[mairin]

@NicolasRannou the Categories on the left - bookmarked, waiting for feedback, completed case, etc. - those are basically clinical / researcher states right? For the hackfest, I think the states of concern for the feeds might be different (or maybe they're of concern to both groups) - i was thinking:

• Processing completed, results seen (no notification, you already saw it)
• Processing completed, results not seen (triggers notification)
• Processing in progress (eg processing not completed, job running)

Of the first two, each has two states:

• Processing completed, no errors
• Processing incomplete, errors

So I guess five total states:

1. Completed, no errors (seen)
2. Completed/Incomplete, errors (seen)
3. Completed, no errors (not seen)
4. Completed/Incomplete, errors (not seen)
5. Processing in progress

I'm thinking about how to flag these in the list in the home page. And how that would differ from the page for a specific feed.... e.g., if one piece of a feed is incomplete with errors, on the home page, fair enough to mark the whole feed as having an error?

[mairin]

(Also, as I'm playing around with things but before I'm posting PNGs here, you can see my work in progress in the SVGs if you want, I auto commit to the repo here)

[NicolasRannou]

The current categories where just "ideas" and the 5 categories you suggested make sense! Yes I think the plan now was as you said, if a piece of a feed "errored", mark the feed having an error.

[mairin]

OK cool! Here's an update to the home page mockup with the new states and some visual design around the state conditions - I'm trying to follow material design as closely as possible. Haven't designed the notification dropdown yet.

I wonder if we can bubble any excerpt of the error text up to the error row item in the home page?

[NicolasRannou]

Nice!

At most we will be able to say which "plugin" of the feed "errored", i.e. "pacs_pull" failed or "mri_convert" failed. but we can not say more than that at this point!

Does it make sense?

[mairin]

Yep it does. I think its useful info so we should show on home.

[rudolphpienaar]

Hey all --

This is looking really good.

I do have one or two suggestions/reactions. Historically, CHRIS organized "feeds" in a chronological order -- emulating a "feed" like a twitter or facebook feed. I see also that in the mockup that it looks like there are per-column ordering, too.

One thing that I never really was able to figure out was the idea of organizing along "projects". This is more akin to a file-browser type metaphor, where a time-based organization is less important. I think for research-type use a user will have many projects and seeing a project-based view might make more sense than a strictly per-feed time ordering.

What do you guys think? I'm assuming that the "projects" in the left gutter can be user-created, in which case it lends to the idea of clicking a project will filter only feeds related to that project. Is that what you are thinking, too?

Best

[mairin]

@rudolphpienaar Yeh! The projects item in the left gutter was in @NicolasRannou's original version; my thinking was having a mechanism to allow users to tag a feed with a project name (user-created names makes sense), then all feeds that share that same tag would be viewable under that project by clicking on it in the left gutter.

A question for you - do you think one feed would be part of multiple projects? Or is it usually 1:1?

I was thinking projects would be really light weight: just make them tags you apply to feeds so there's no admin overhead around what can or can't be accepted into a project. I don't know if a typical research user would want stronger control (for privacy, security, or whatever else reasons) over what feeds could get added to a project. Do you think that would be a concern?

Here's a quick very rough wireframe mockup of how the general flow would work if projects were the default view / primary item in the UI (I'm still working on the individual feed page design so that one is just filler here):

[NicolasRannou]

I like the mockups!

A question for you - do you think one feed would be part of multiple projects? Or is it usually 1:1? ... just make them tags you apply to feeds so there's no admin overhead around what can or can't be accepted into a project.

Tagging as you suggested is the approach we had in mind to create projects too.

I think usually a feed could be part of N project but I do not have strong opinion on this one.

I don't know if a typical research user would want stronger control (for privacy, security, or whatever else reasons) over what feeds could get added to a project. Do you think that would be a concern?

Very good point - we do not have a clear mechanism to handle that yet but ideally a user should be able to "share" a feed or a project with other people.

[jbernal0019]

I agree with @mairin.

@NicolasRannou in the current CUBE design a feed can be own by multiple users. A user can share a feed with another user (i.e make the other user an owner of that feed too) by making a PUT request to the feed and passing the new owner's username. Also a feed can have multiple tags and a tag can be applied to multiple feeds. Tags are user-specific (i.e other owners of the same feed won't see a user's tags)

[mairin]

@NicolasRannou cool, i think the flexibility of allowing a feed to be part of N projects is probably a good way to go.

@jbernal0019 do you thing tags being user-specific is problematic? It sounds like currently it's possible to share a feed but not a project - is sharing a project something researchers would want to do?

[jbernal0019]

Hey @mairin As we've been discussing here there is no such a thing as a project in the current CUBE design. The simplest way of including this concept in the current CUBE is just considering the project name as a simple user-defined tag. So tags are more general than projects in this setup. Tags are user-specific which means that each user decides how to tag the feeds she owns and those tags will not be visible by other users even when they share (own) the same feed. Given a project name each user working on that project should tag their feeds with that project name. But they must do it individually even for those feeds that are shared among all of them.

Outside this setup including a project as a new entity/concept would require complex changes to the system. We would need to define how the user would define a project (the project owner), what information would be stored about a project and what the relationship between a project and the rest of the entities in the system is. What are the permissions to access a project, etc... It has the potential to really increase the complexity of the Database design as well as the front-end UI.

[mairin]

@jbernal0019 i think it makes a lot of sense to overload the concept of a tag to allow researchers to group feeds together into project, i dont know if it's necessary to have a separate project construct. but what i am curious about is, this seems like a fairly collaboration-centric kind of space, and it seems like a single feed is shareable - would it be possible to share multiple feeds based on a common shared tag?

[jbernal0019]

@mairin In the current design a user can assign multiple tags to a single feed. And the same tag can be applied to multiple feeds (like a project name for instance). The feed is itself shareable between users but the tags are not.

Making tags shareable is also an important change in the current concept of a tag. It will need to be thought thoroughly. Maybe @rudolphpienaar and @NicolasRannou would need to think about this :)

If a tag is also shareable then it is possible for other users to inherit the tags that have already been applied to a shared feed (i.e they will also be owners of those tags in addition to the feed and able to change their names). We will need to think what the behavior would be if some users apply new tags to the shared feed, etc...The relationship between User and Tag will no longer be one-to-many but many-to-many like the relationship between User and Feed

Many-to-many relationships make the DB less efficient. So they must be really justified. The Database will be less efficient when it comes to speed of queries as well as space. But if it is a required feature it can certainly be implemented.

I any case to share multiple feeds the Front end will need to make multiple PUT requests to CUBE one for each feed.

[mairin]

It's probably fine to leave this issue for the longer-term... I am guessing we'll discover whether or not it's needed from user research with researchers / radiologists. If we don't have direct user data to justify it I would say let's not worry about it now?