Wireframe some front end views

[nathanielrindlaub]

• user login page
• user home page
• UX for setting deployment deliniators
• image review page
• upload page

[nathanielrindlaub]

Alright, I took a crack at this and also re-thought the whole front-end concept per the conversation @postfalk and I had last month in response to my initial ideas. The take-away from that conversation was that we should keep the backend simple, unopinionated, and generally free of complex business logic, and we should use the front end as a way for users to explore and enrich the data. I had initially also wanted to require users to first register each camera deployment and use those records as a way to route incoming images and manage permissions. In this updated version I still have the concept of a deployment but it's not required and doesn't play such a central role in the app architecture. Anyhow, here's my thinking as it stands:

Concept of a "Team"
I don't feel strongly about this part and haven't really thought through all the details, but I started with the assumption that at some point, sharing images might not be that useful between certain groups of people, and there should be some concept of a "team" (or maybe it's a "preserve"?) that represents a self-contained bucket of images and set of users who have varying levels of access to them. So for example, Santa Cruz Island might be its own "team", Dangermond might be another "team", maybe something not tied to one specific place like some state wide beaver camera project warrants its own "team", I don't know. Maybe we don't need this at all - I'm curious what you think about it. At any rate it's probably not something I'd implement for the prototype.

Concept of a "Team admins " and "views"
So I'm imagining each team would have their own "bucket" (maybe literally their own s3 bucket or maybe just a sub directory within one that they share), and all the "team admins" would have access to all of those images. On SCI, Christie and Juli would definitely be admins, probably others too.

But there needs to be a way to manage subsets of images within those buckets. Maybe you want to pick only images coming off a handful of specific wireless cameras to run automated machine learning jobs on (see #13). Or maybe you want to be able to quickly access all the images from just a handful of cameras that were used for one purpose (like a list of all the images from biosecurity cameras vs. some one-off skunk survey). And maybe you want to grant access to a volunteer reviewer to just a smaller subset of the images rather than grant them permission to see the whole bucket...

So I thought ok you could do this all through a concept of a "view" - a view would basically be just a bunch of filters on the data that admins can save, revisit, share, manage permissions on, set automated workflows on, etc. I mocked-up a wireframe for a view to give you a sense of what I imagine it looking like:

Animl wireframe v1.pdf

Pretty self explanatory. After some research and thinking about how I might implement this I found out that MongoDB also has a concept of a view, which I think would help, but I would love any thoughts you have on the idea in general or the implementation!

Concept of "label review mode"
When a user clicks on on of the images in a view, I am imagining a modal would pop up that gives you the full size image and the ability to see and edit the labels and bounding boxes. Here's another wireframe of that idea:

Animl wireframe v1 - Label Review mode.pdf

This is also pretty self explanatory, other than this concept I had for a "label review mode", which is something the user could toggle on or off. Basically I'm thinking when it's on, users could use their arrow keys to rapidly iterate through each label in each image, with a right arrow "validating" the label and a left arrow either "invalidating" the label or adding a "needs review" property to it (maybe that behavior is something users could set too). At any rate, if you're on the last label in an image, pressing the arrow key would validate or mark the label for a second round or review then move on to the first label of the next image.

This also made me think that we need some way for users to be able to validate when there is no object in the image, for example when Megadetector fails to detect any objects, we should have some mechanism for users to review and validate whether that is in fact the case. One solution is that maybe no-object is it's own label that gets automatically added or removed to images that don’t have any other labels. The bounding box would just be the full frame of image, and when a user is in "label-review-mode" and they get presented with a new image with a 'no-object' label, they could validate/invalidate it like any other label with the arrow keys and move on.

Alright that pretty much sums up my new working concept. I'd love any thoughts you have on it @postfalk, and if we can get it to a place we're happy with, I'd like to present it to Juli, Christie, and Kelly (maybe other potential users?) and meet for a crit session before starting to implement.