Surface customization hooks required

[cmungall]

• Title
  • Phenote
• All
  • "Noctua Preview" in top-left
  • Monarch colors nice but lower priority
• Landing
  • Note that the front page in generic Noctua is now a selection table, so we have a data-driven way of customizing the landing page. We just need content! Not a developer issue
  • "Learn more" - we will have a custom md file here, I can specify, use a skeleton for now
• Browse
  • AmiGO labs link should be suppressed <-- the analog for monarch here is simply the monarch site
  • This is kind of an odd tab anyway, and may end up being shuffled in core
• Create
  • 'model from process and taxon' doesn't quite make sense. We will have an analogous operation for phenote in the future, but for now suppression is best
  • Need some way of getting to form interface here, but this is less a surface issue and more a deeper one of how we handle the form vs causal model interfaces
• About
  • Needs customized but this tab may go away in core, @kltm to comment
• Danger Zone
  • Unfortunately the monarch instance can probably get away with less cuteness and geekiness than the GO instance. "Danger Zone" is not good advertising here...

Not sure whether new app vs yaml vs fork is the best long term/ short term fix, this is just to give a rough idea

[DoctorBud]

"Noctua Preview" in top-left

I assume you mean WebPhenote in top left.

Note that the front page in generic Noctua is now a selection table, so we have a data-driven way of customizing the landing page.

I am currently filling the selection table with data from the Minerva response enumerating the GitHub models directory. It's a hack where I just fill the selection table with data gathered from the Minerva response intended to fill the Danger Zone table. A better way is to separate the model from the view code so that we can just pass in a model object (in the MVC sense) and have the selection table render itself. I started down this road but backed out.

Not sure whether new app vs yaml vs fork is the best long term/ short term fix, this is just to give a rough idea

Currently deploying from my fork, but want to go home to Noctua master.

I think that establishing a WebPhenote-mode configuration flag (e.g., in the startup.yaml) would be a quick way to move forward and allow two presentations (GO and WebPhenote) of the same codebase. I'm already using such a flag (hardcoded) to determine whether to fill the selection table with GOLR data or GitHub data. By default, this is going to be my approach so that I can get my code integrated back to the Noctua repo. I have some other fixes that would be good for Noctua.

Any suggestions on what such a startup.yaml flag would look like? Options:

• WEBPHENOTE=1 (0 is the default, implying GO theme)
• THEME=webphenote (with THEME=go the default)
• Other?

[kltm]

Preferred would be

NOCTUA_CONTEXT=(go|monarch|<string>)

[DoctorBud]

I'm adding a logo for Monarch, I can add one for GO Noctua, or we can continue without a logo with some conditional code. Here's the logo I was thinking of adding as the navbar-brand logo in the upper left corner: https://s3.amazonaws.com/go-public/image/go-logo-icon.png

[kltm]

@DoctorBud yes, that's the correct GO logo right now. If it's going up top there, probably no reason not to add them at the same time.

[DoctorBud]

@kltm @cmungall @hdietze I have a big PR here: https://github.com/geneontology/noctua/pull/307 and a supporting PR here: https://github.com/berkeleybop/bbop-client-barista/pull/1

I need one other human to try to build and run Noctua in GO mode to make sure I didn't break anything. The startup.yaml file will need to have a NOCTUA_CONTEXT=go line added (WebPhenote uses NOCTUA_CONTEXT=monarch).