Installation Branding - Customize/configurable navbar logo + links, landing pg etc. #2003
Comments
pdurbin
added
UX & UI: Design
|
@mheppler @eaquigley @scolapasta @mcrosas what do you think of this? "Dataverse" is currently appended in various places, making it difficult for @bencomp to brand his installation the way he'd like. |
|
@bencomp this makes sense. So, to clarify, we would have a configurable label for the "Dataverse" displayed at the top menu bar which can be customized for each installation to distinguish "Harvard Dataverse" from "DataverseNL" or from any other name from another installation. And we would leave the "Dataverse" term used through the application (which applies to the Dataverse object, not the installation instance) as defined in the resource.properties ("Dataverse" ). Yes, if that's the case, I think this straightforward and will cause less confusion. Adding to In Review short term milestone, to first review with UI team @eaquigley @mheppler |
|
@mcrosas yes, I don't want to change the name of the Dataverse concept of a container for data containers and sets, I would like to be allowed to change the application (instance) name. |
|
This makes sense and seems pretty straightforward. I'm adding it to 4.0.1. |
|
Right now "About" in the nav bar is hard coded to http://dataverse.org but there's a discussion about making this configurable at https://groups.google.com/d/msg/dataverse-community/2WlHl8gD2q4/NSHELerTCAAJ In addition, I think small changes to the footer should be considered, such as #3379. |
|
Also make sure that as part of any customization changes to the Harvard Dataverse, we apply the same layout changes to the static maintenance pg (#2588). |
|
From #3401 @donsizemore -- would like to be able to set UNC's logo (in header navbar) à la Scholars' Portal |
mheppler
changed the title
|
per request of @pdurbin: I'd personally want the various "About," "Powered by" and "Hosted by" homepage links pulled together into an "About" drop-down in the nav-bar. whether that's a move or a duplication could be up to you all, but if I personally want to know something about a web site/service, that's where I'd look first. So, "About" could contain entries for the software itself, the dataverse instance, and the hosting/curating organization. |
|
I'm glad I asked (at http://irclog.iq.harvard.edu/dataverse/2016-11-07#i_44685 ) because the answer was different than what I expected! 😄 |
Depends on the following settings (via admin settings API at /api/admin/settings/): ":instanceBrandingHeader": "true" ":instanceBrandingFooter": "false" ":instanceNameFull": "My institution Dataverse Instance Name" ":instanceNameShort": "MI Dataverse" ":instanceNameFullClasses": "hidden-xs" ":instanceNameShortClasses": "hidden-sm hidden-md hidden-lg hidden-xl" ":instanceTextFull": "My institution full and slightly long name" ":instanceTextShort": "Inst Name" ":instanceTextFullClasses": "hidden-xs hidden-sm" ":instanceTextShortClasses": "hidden-md hidden-lg hidden-xl" ":instanceTextLink": "http://my.inst.edu/" ":instanceLogoFile": "http://dataverse.org/files/dataverseorg/files/dv-rings-tranparent.png" ":instanceLogoLink": "http://dataverse.example.org/"
Depends on the following settings (via admin settings API at /api/admin/settings/): ":instanceBrandingHeader": "true" ":instanceBrandingFooter": "false" ":instanceNameFull": "My institution Dataverse Instance Name" ":instanceNameShort": "MI Dataverse" ":instanceNameFullClasses": "hidden-xs" ":instanceNameShortClasses": "hidden-sm hidden-md hidden-lg hidden-xl" ":instanceTextFull": "My institution full and slightly long name" ":instanceTextShort": "Inst Name" ":instanceTextFullClasses": "hidden-xs hidden-sm" ":instanceTextShortClasses": "hidden-md hidden-lg hidden-xl" ":instanceTextLink": "http://my.inst.edu/" ":instanceLogoFile": "http://dataverse.org/files/dataverseorg/files/dv-rings-tranparent.png" ":instanceLogoLink": "http://dataverse.example.org/"
|
I took a stab at cleaning up the clunky way I managed the parameters for the JHU Data Archive branding customizations. These are much more amenable to adoption by other DV4 instances. There are two new branches for this on my Dataverse fork: Some notes in the commit message. |
|
This issue has been broken down into three new issues, so that it can be easily tracked through development.
Thank you for your input @bencomp @lmaylein @donsizemore @tdilauro! Please check those new issues to make sure that we covering your requested features. @tdilauro I will be following up with you regarding your branched code. |
|
The approach I mentioned in a previous comment on this issue is probably applicable to all three of the newly spawned customization issues(#3637, #3638, #3639). Representative changes are in this branch of my fork of dataverse. In addition, I just committed changes to a rough ansible role to accommodate changes in the above-mentioned branch. These changes are deployed in our production instance. |
At DANS we would like to upgrade our service DataverseNL (formerly known as Dutch Dataverse Network) to use Dataverse 4. We fiddled with a few settings, but they did not result in promising layout changes.
Our options seem to be:
Bundle.properties. It appears that the value for the localisable string Dataverse in Bundle.properties is used for both the application name in the top menu bar as well as most references to the word "Dataverse". For example, when we changed the Bundle.properties, the top menu bar shows "DataverseNL" (which is good), but the root dataverse became the "Root DataverseNL" (which is bad).We would like customising the application to be more a matter of configuration than programming. Allowing to change the "service" name (i.e. the application name) independently of the Dataverse concept seems a minimal requirement. This and other possible customisation configuration options should be documented.
(This appears unrelated to another issue called "Customization", #1768)
The text was updated successfully, but these errors were encountered: