Menu restructuring

[dmytrotsko]

Changed "About" and "Epidemic Signals" sections

[netlify]

✅ Deploy Preview for cmu-delphi-main ready!

Name	Link
🔨 Latest commit	b760e15
🔍 Latest deploy log	https://app.netlify.com/sites/cmu-delphi-main/deploys/66d0de62e15b910008a05dbf
😎 Deploy Preview	https://deploy-preview-996--cmu-delphi-main.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[carlynvandyke]

Will the "NEW" tags show up when this is published on the live site? They seem unnecessary (but I guess they appear automatically?)

[dmytrotsko]

Will the "NEW" tags show up when this is published on the live site? They seem unnecessary (but I guess they appear automatically?)

@carlynvandyke yeah, that "new" tag appears automatically. But there should be way to remove it, so I can try to do that.

[carlynvandyke]

I think we should cut down on text in the first dropdown menu (this is probably more of an item for @RoniRos's review). Here's what I would propose:

• About
• About Delphi
• Delphi Milestones
• Our Team
• Publications
• Presentations
• Blog
• News
• Join Us
  • Faculty, students, and volunteers
  • Open paid positions
• Help Us
  • Suggest new data sources
  • Suggest additions or improvements
• Support Us
• Contact Us

We'll have a lot more detail on each individual page so I don't think we need to worry about including too much in the menu. I'm even wondering the two bulletpoints under "Help Us" could be combined into one page/form- seems like it might be easier to keep track of incoming messages that way.

[RoniRos]

I think we should cut down on text in the first dropdown menu

I agree.
Let's use Carlyn's layout above, and also eliminate the two items under "Help Us" (move them to inside the "Help Us" page).

[carlynvandyke]

Notes from 7/23:

• Window size/hamburger issues
• Dropdown menu issues — want sideways rather than down
• Pages to create
  * Join us: Faculty, students, and volunteers
  * Google Form
  * Who are they, how would they be helpful
  * Very open and inviting
  * Help us — > Feedback and suggestions
  * Google Form
  * Suggest a new data source
  * Improvements
  * Support us
  * Carlyn to figure out donations
  * Remove “Contact us”, replace with updated Feedback and Suggestions form
  • Open external links, links to tools in new tab
    • Add “new tab” icon?
  • Menu updates
    • Epidemic Signals
      • Add covidcast classic link, remove quotes, etc.
      • Add link to dashboard builder
      • Dmytro to review all links
      • Update CTIS links
      • “Report a problem” — new form
      • New data source — link to regular contact us form
      • Replace “Epidata API” link with “Signal Documentation” — link directly to data source & signals page on github.io, move to ?? (Roni to choose on layout document)
    • For Modelers and Developers
      • Consult with tooling team
    • Intranet
      • Remove for now

[nmdefries]

@dmytrotsko is this done and ready to review?

[nmdefries]

My initial thoughts on layout (CC @RoniRos). These could be added in a separate PR if we want to get the initial menu changes out sooner:

• "for modelers and developers" menu looks good
• "epidemic signals" menu -- general issues I see are large # of menu items, and I find the names to not be very descriptive
  • The link to the API documentation isn't easy to find. I think it should be higher up in the menu. Also the name is not clear -- "Epidata API" makes it sound to me like it's going to link to code. Better to call it "Use the Epidata API", "Epidata API Use", "Epidata API Documentation", "Epidata API Access".
  • [unsure] I see we link to another part of the documentation site under the name "Signal Documentation", but I'm not sure we need to link twice. Signal info is easy enough to find once you're on the doc site. The "Epidemic signals" menu is already pretty long, so better to compress.
  • "signal discovery & selection" link is broken. I'm assuming this goes to the signal discovery app.
  • "report a problem" and "suggest a new data source" links redirect to the home page.
  • "report a problem" should be renamed to "report a data problem", "report a problem with an existing data source", etc
  • "suggest or request a new data source" should be renamed to just "suggest a new data source"
  • "Terms of Use" I usually see this linked at the bottom of every page of a site. A little odd to have it in the menu
  • "dashboard builder" should be added to the "signal visualization" menu
  • rename "signal export" to "download a signal" or "signal download"
  • rename "signal availability, coverage & latency" to "signal health"?
• "About" menu
  • "join us" submenu only shows "open paid positions" right now. We were going to add a "volunteer/intern" item too?
  • rename "open paid positions" to "careers". Consider putting volunteer "position" among careers listing and just having a single menu item "join us" with no submenu.
• we should update the links at the bottom of page sometime. They see quite out of date ("contact" -> twitter)

[RoniRos]

Thank you @nmdefries , this is extremely helpful feedback.
I've made the changes in the layout doc, and am hereby asking @dmytrotsko to implement.

• "epidemic signals" menu -- general issues I see are large # of menu items, and I find the names to not be very descriptive

Ok. Your suggestions below will indeed shorten it by 3, and improve descriptiveness.

• The link to the API documentation isn't easy to find. I think it should be higher up in the menu. Also the name is not clear -- "Epidata API" makes it sound to me like it's going to link to code. Better to call it "Use the Epidata API", "Epidata API Use", "Epidata API Documentation", "Epidata API Access".
• [unsure] I see we link to another part of the documentation site under the name "Signal Documentation", but I'm not sure we need to link twice. Signal info is easy enough to find once you're on the doc site. The "Epidemic signals" menu is already pretty long, so better to compress.

Good catch, thank you.

Since this menu is for non-programmers, I'd leave the Signal Documentation, which should link directly to the signal documentation section (https://cmu-delphi.github.io/delphi-epidata/api/covidcast_signals.html), albeit currently only the COVIDcast endpoint).

I'd like to move the link to https://cmu-delphi.github.io/delphi-epidata/ to the "modelers and developers" menu. Maybe call it "Epidata API documentation"? But note that there is already a link there called "Epidata" under "API and clients" which links to the Epidata code (https://github.com/cmu-delphi/delphi-epidata). Any suggestions on what to call these two distinct links?

• "signal discovery & selection" link is broken. I'm assuming this goes to the signal discovery app.

Correct. For some reason the signal discovery app cannot be viewed in this staging website.

• "report a problem" and "suggest a new data source" links redirect to the home page.

@dmytro will add the relevant forms shortly.

• "report a problem" should be renamed to "report a data problem", "report a problem with an existing data source", etc

I like "Report a data problem". Thanks.

• "suggest or request a new data source" should be renamed to just "suggest a new data source"

Agreed. Will do.

• "Terms of Use" I usually see this linked at the bottom of every page of a site. A little odd to have it in the menu

Agreed. Will remove.

• "dashboard builder" should be added to the "signal visualization" menu

Agreed. Thanks.

• rename "signal export" to "download a signal" or "signal download"

I like "Signal Download", because it includes also downloading of multiple signals.

• rename "signal availability, coverage & latency" to "signal health"?

I think the current name is more descriptive, and and "signal health" leaves one wondering what is meant by that.

• "About" menu

  • "join us" submenu only shows "open paid positions" right now. We were going to add a "volunteer/intern" item too?

Yes, these forms are ready and @dmytrotsko will add them shortly. The plan is to have 3 separate categories, catering to very different use cases: paid positions, faculty, students & volunteers.

• rename "open paid positions" to "careers". Consider putting volunteer "position" among careers listing and just having a single menu item "join us" with no submenu.

It used to be "careers". I didn't like it, because I think of what we offer more as an invitation to join our mission rather than a career step. But we can talk about it.

• we should update the links at the bottom of page sometime. They see quite out of date ("contact" -> twitter)

Thanks. Yes! Do you want to suggest specific links? Should they follow the same high level structure as the menu? Or something different?

In the meantime, @dmytrotsko, can you replace the "Terms" link at the bottom with the new version of the "Terms of Use"?

@dmytrotsko I updated the layout document, you can see the requested changes in the version history (including some changes in order of pages, naming, etc.

[nmdefries]

I'd like to move the link to https://cmu-delphi.github.io/delphi-epidata/ to the "modelers and developers" menu. Maybe call it "Epidata API documentation"?

What is the goal of linking to the doc site landing page, specifically?

Right now in the "epidemic signals" menu, we have links to let users:

• find relevant signals ("signal discovery")
• plot signals without downloading ("signal viz")
• download data without coding ("signal download/export")
• understand signal availability/lag behavior ("signal availability/status")
• get detailed info about signals ("signal docs") (but only those in COVIDcast)
• get detailed info about CTIS ("CTIS")
• contact us about new data
• contact us about problematic data

Everything up to and including "signal docs" seems useful (except the "status/availability" -- useful, but I'm not sure how much the average user will look at it. Maybe "status/availability" should also go under the "viz" submenu?), and the flow of steps is logical. I think the piece that's missing is "download data using code" -- whether this should go here or in the developers tab depends on how much we think the average user will use code/the API clients to fetch data.

Second, if we wanted to provide users with a guide on how to fetch data using the API clients, the doc site landing page isn't what I'd link. Instead, it would be a good place to put the "quickstart" guide suggested in the layout doc. (The epidatr "Getting started" page actually isn't bad as a quickstart guide, but is of course R-specific.)

The doc site landing page is almost the opposite of a quickstart guide. In that sense, it is better suited for developers.

But note that there is already a link there called "Epidata" under "API and clients" which links to the Epidata code (https://github.com/cmu-delphi/delphi-epidata). Any suggestions on what to call these two distinct links?

The "developers" items link to a mix of code (GitHub repos; for epidatpy and Epidata/delphi-epidata) and documentation sites (for the R packages). I'd prefer to switch all of them to point to doc sites, since we also link our GitHub org.

In summary, I think the doc site landing page should replace the existing "Epidata" link in the developers submenu (and we should replace the epidatpy code link with a doc site when it becomes available). We should also probably add an API quick-start page to the main doc site, and consider linking it from the "epidemic signals" menu to show users how to fetch data using the clients.

[nmdefries]

RE bottom of page links, I don't have strong thoughts. Normally sites make them "about the org", terms of use, license, privacy policy, contact us, careers, etc. Kind of boring organizational stuff. Sometimes with big projects linked -- could be good to include our GitHub and the Epidata doc site.

Wikipedia

JHU CSSE

[RoniRos]

What is the goal of linking to the doc site landing page, specifically?

Right now in the "epidemic signals" menu, we have links to let users:
...

• get detailed info about signals ("signal docs") (but only those in COVIDcast)
  ...

I agree there should be only one link to signal documentation from the "epidemic signals" menu. As you pointed out, the current link is to the COVIDcast endpoint signals only, so I thought it might be better to point to the doc site landing page, where they will hopefully notice in the left-handed menu both the COVIDcast signals and the other signals. But if you think it's better to point directly to the COVIDcast signals, I'm okay with that.

Everything up to and including "signal docs" seems useful (except the "status/availability" -- useful, but I'm not sure how much the average user will look at it. Maybe "status/availability" should also go under the "viz" submenu?),

That's a reasonable alternative location. I have a slight preference for keeping status/availability in the main "epidemic signals" menu, but again here, if you have a strong preference for moving it to the "viz' submenu, I'm okay with that.

I think the piece that's missing is "download data using code" -- whether this should go here or in the developers tab depends on how much we think the average user will use code/the API clients to fetch data.

Maybe an even better place for it is within the "signal download" page, or in a "signal download" submenu?
Note also that we are planning to add example code to the follow-up page of the Signal Discovery app,
It's also okay to include "download data with code" in multiple menu locations (preferably under the same name).

Second, if we wanted to provide users with a guide on how to fetch data using the API clients, the doc site landing page isn't what I'd link. Instead, it would be a good place to put the "quickstart" guide suggested in the layout doc. (The epidatr "Getting started" page actually isn't bad as a quickstart guide, but is of course R-specific.)

I designed the "epidemic signals" menu for non-programmers. So my bias is to put the "quickstart guide" under "for modelers and developers" (I think of "developers" as almost synonymous with "programmers"). We can make this point slightly more salient by changing the order in the menu name, namely, "For Developers and Modelers". Or maybe even "For Programmers and Modelers"?

The doc site landing page is almost the opposite of a quickstart guide. In that sense, it is better suited for developers.

Got it. As I mention above, I was only suggesting it as the doc link in the "epidemic signals" menu as a common root to all signal documentation. I suppose the right solution is to change our documentation tree to merge the two signal menus. But I suspect this is a bit complicated, because there are bits of documentation that are relevant only to the covidcast endpoint. A fast, temporary solution is to put both signal menus under a common "signal documentation" menu, but that will increase the depth of the tree. Other menu rearrangements are also possible. Any ideas?

But note that there is already a link there called "Epidata" under "API and clients" which links to the Epidata code (https://github.com/cmu-delphi/delphi-epidata). Any suggestions on what to call these two distinct links?

The "developers" items link to a mix of code (GitHub repos; for epidatpy and Epidata/delphi-epidata) and documentation sites (for the R packages). I'd prefer to switch all of them to point to doc sites, since we also link our GitHub org.

Okay. I am happy to yield the "Modelers & Developers" menu completely to your design and preferences. Same btw with the "Nowcasting & Forecasting" menu.

In summary, I think the doc site landing page should replace the existing "Epidata" link in the developers submenu (and we should replace the epidatpy code link with a doc site when it becomes available). We should also probably add an API quick-start page to the main doc site, and consider linking it from the "epidemic signals" menu to show users how to fetch data using the clients.

I guess the only substantive disagreement we may still have is over the right place for a "quick-start" item. I view it as "quick start for programmers", and therefore feel it should be in their menu. I also love how sparse our top level menu is, so am leaning towards not expanding it. Would it help if we hash this out "in person"?

Notwithstanding this last unresolved point, can you please make choices about the first few points above, design the "Developers/Programmers and Modelers" menu as you see fit, reflect it all in the layout document, and ask Dmytro to make these changes. We can make a tentative decision about the Quickstart item, and change it in the next deployment. This new design is such an improvement imho that I would like to get it out sooner rather than later.

[RoniRos]

RE bottom of page links, I don't have strong thoughts. Normally sites make them "about the org", terms of use, license, privacy policy, contact us, careers, etc. Kind of boring organizational stuff. Sometimes with big projects linked -- could be good to include our GitHub and the Epidata doc site.

I don't have strong thoughts either. We definitely need to include "Terms of Use". Everything else seems like a re-hash of a subset of the menu items, which is fine with me, but I don't know what logic we should use to decide what to include, and how to organize it. In any case, I'd rather not delay our first release for this. I am adding a "Bottom of page" section to the layout document, with a tentative short list -- feel free to add or change as you see fit.

[nmdefries]

"epidemic signals" menu... But if you think it's better to point directly to the COVIDcast signals, I'm okay with that.

I have a moderate preference for pointing directly to the signal documentation subsection of the doc site. As I said above, I just don't think the main site is particularly useful for the non-technical user.

I have a slight preference for keeping status/availability in the main "epidemic signals" menu

Sounds good, I don't have a strong preference.

Maybe an even better place for ["download data using code" info] is within the "signal download" page

Sure

So my bias is to put the "quickstart guide" under "for modelers and developers"... I view it as "quick start for programmers", and therefore feel it should be in their menu.

Sure

... by changing the order in the menu name, namely, "For Developers and Modelers". Or maybe even "For Programmers and Modelers"?

I don't have a strong preference on the name. The current name is fine.

I was only suggesting [the main page of the doc site] as the doc link in the "epidemic signals" menu as a common root to all signal documentation. I suppose the right solution is to change our documentation tree to merge the two signal menus... A fast, temporary solution is to put both signal menus under a common "signal documentation" menu

I think it's fine for now to only link directly to the covidcast signal docs. They are of primary interest to users, and the non-covidcast signal docs are findable through the doc site menu.

At some point, we may want to combine covidcast and non-covidcast signal pages under one menu, but I'm imaginging that as a change to the doc site, not the main site.

We can make a tentative decision about the Quickstart item, and change it in the next deployment. This new design is such an improvement imho that I would like to get it out sooner rather than later.

Sure. We shouldn't wait on the quickstart guide, since we'd have to write it first.

[nmdefries]

I think the only new change is: "for modelers and developers" -> "API and clients" -> "epidata" link should go to https://cmu-delphi.github.io/delphi-epidata/

[RoniRos]

@dmytrotsko Can you please go over the current web layout document and implement any recent changes?

[nmdefries]

Linkchecker results shows that we have 4 broken (404) links, and many redirected pages.

Here are the full results. All errors are at the top.

linkcheck.txt

[RoniRos]

Linkchecker results shows that we have 4 broken (404) links, and many redirected pages.

Here are the full results. All errors are at the top.

linkcheck.txt

Thanks! All four of these pages are available in the deployed space, e.g. if you replace the path with https://delphi.cmu.edu .
I think this is known as something that is peculiar to the staging environment, and will work fine in deployment?

I don't know about the redirections (301s), or hos significant they are.

[melange396]

The 404 urls should all work in production.

AFAICT, the redirects are just from the tool checking "http" urls, which get redirected to "https" (which is a good thing).

[nmdefries]

issue: the blog main page and individual blog articles aren't loading in the preview (all other menu items and footer items load correctly). It looks to me like this is the only code change to the blog, so I'm wondering if this is causing the problem @dmytrotsko

[melange396]

Perhaps we could try commenting it out differently, with the comment inside the definition block instead of around it, as is done in:

www-main/themes/delphi/layouts/_default/covidcast_app.html

Line 7 in 3b55490

{{ define "breadcrumb" }}<!-- no breadcrumb -->{{ end }}

Alternatively, if we got rid of the breadcrumbs to squash the weird "COVID-19" text that showed up on pages underneath the epidemic-signals/ path, we can change that here:

www-main/content/epidemic-signals/_index.md

Line 3 in 5cc8c3e

linkTitle: COVID-19

[dmytrotsko]

@nmdefries @melange396 you both were right. Probably comment worked not as expected and caused wrong page rendering.
I don't understand why server does not show any issues/warning. Everything "works" properly, but blog and individual articles are not rendering at all. But sometimes that happens 👍