Dataverse Header/Theme - New layout, default colors

[mheppler]

Changes to the default header layout with gray background at the top of page should be more minimal, removing some of the spacing/padding as well as the background color (or changing it to "white").

From a comment by @TaniaSchlatter on #4190

This would not affect themes that have already been created:

An additional change will be to disable the dataverse theme header for the root dataverse. If they choose to utilize the new customization features, which also for easier branding in the navbar and the space above it, then it lessens the need for the theme header directly below the navbar. Here is a screenshot for how it would look on a dataset pg that belongs to the Harvard Dataverse.

[pdurbin]

I just pushed 7795e70 to kick off a new branch, changing the default header background from gray to white.

[pdurbin]

In 8eccacd I made it so only non-root dataverses show the header.

I went ahead and made pull request #4277 but I have questions.

If we aren't showing the header for a root dataverse, should we hide the "Inherit customization from Root" checkbox from dataverses that are direct children of the root dataverse? Here's a screenshot of the "Birds" dataverse, whose parent dataverse is the "Root" dataverse:

[mheppler]

The disabled theme for the root dataverse should be an option added to the Theme + Widget pg for the root, not a new default setting. Moving back to develop.

[pdurbin]

The disabled theme for the root dataverse should be an option added to the Theme + Widget pg for the root

Oh, I didn't realize we were building a UI for this. (Does anyone remember how this got estimated as a 2?) It would be easier to add a database setting called :DisableRootDataverseTheme if that's ok. Assuming we are building a UI, I could use some design input. For now I threw a "disable theme" checkbox on the top of the page like this:

Again, I would prefer to not build a UI at this time and implement a database setting instead. Let's talk about it during or after standup.

[scolapasta]

Let's remember our general guideline that we want to consider the root dataverse the same as any other dataverse as much as possible.

With that guideline in mind, I agree with @pdurbin it makes more sense for this to be a setting.

If we want this to be an option for any dataverse (I could imagine any dataverse might want to streamline and not have a block header), then it should be in the UI. But that seems potentially out of scope for this issue (i.e. we could make it a setting now, and make it a db column for any dataverse for a future issue)

[pdurbin]

@mheppler @scolapasta @TaniaSchlatter and I met after standup and made some decisions. Here's a todo list.

• Implement :DisableRootDataverseTheme (or some such name) as a database setting rather than a UI checkbox. Done in 28f705c
• When the root dataverse theme is disabled, render some explanatory text on the "Theme" tab with a "Done" button that takes you back, just like how the "Done" button works on the "Widgets" tab. Done in 28f705c but explanatory text could be improved.
• When the root dataverse theme is disabled, don't show it on the home/dataverse page when you're looking at the root dataverse. Done in 28f705c.

Not discussed, but implied:

• When the root dataverse theme is disabled, do not offer the "Inherit customization from Root" checkbox from dataverses that are direct children of the root dataverse.

Thanks for getting me unblocked, all.

[matthew-a-dunlap]

I've reviewed it, looks good, and I will move it for real!

[kcondon]

-Gray background for root dataverse still present in default customization, works/white for all sub dataverses.
-Inherit from root still appears/works on sub dataverses when :DisableRootDataverseTheme is set to true. Not sure what is supposed to happen but it changes the sub dv header to the gray background mentioned above.

[pdurbin]

I fixed the gray background bug in 624922f

@mheppler @kcondon and I have been talking about this issue all morning.

I'm fine with the code as is (unless more bugs are found) but @mheppler was thinking about looking at how FFFFFF (white) is now hard coded on the front end and @dlmurphy may want to look at what's written in the guides about inheriting themes because @kcondon and I agree it's a bit confusing. There's a drawing on my whiteboard that might help.

[mheppler]

Worked with @dlmurphy @pdurbin and @kcondon to get the documentation more explicit when describing how the disable config option impacts inherited themes. That should clear the way for this to get through QA.

Also, noticed that the Theme + Widgets pg referred to the root's "customization" for the inherit feature, so I went ahead and corrected that to refer to the root's "theme" instead.