Upcoming changes for version 3.5 of Dataverse Network (Subnetworks)

In order to house disparate dataverse networks within one database we are going to implement the idea of “subnetworks” in version 3.5 of Dataverse Network. The main purpose for these subnetworks is to allow for separate home page branding, search and templates for each subnetwork. Here are some key points and mockups of what the subnetworks would look like. Please note that this information is subject to change.

Creation of Subnetworks
Any Network Administrator will have the ability to add and edit a subnetwork. This screen will allow the user to update the name, description and branding of the subnetwork.


Create a Subnetwork form 3.5 mockup

Manage Templates
The Network Administrator will be able to assign a template to a subnetwork. Once it has been used for a study within a particular subnetwork its subnetwork cannot be changed.

Subnetwork Manage Templates mockup

When a user is in the context of a subnetwork any search that is performed will return studies that are owned by dataverses in that subnetwork along with any studies from outside dataverses that are included in collections.

Dataverse classification functionality will continue to be available for the root network.

End User Experience
The application homepage will have links to any subnetworks created in the root network. If a user opens the application via a url that redirects into a subnetwork there will be a link from the subnetwork page back to the root network homepage.

Mockup of Dataverse Network root network page with a new section to access the various "Dataverse Subnetworks":

Mockup of what a Dataverse Subnetwork would look like (e.g. Astronomy Dataverse Subnetwork):
Astronomy Dataverse Subnetwork mockup

Questions/Call for feedback
Besides templates and branding are there any other “must-haves” for the subnetwork implementation? Is it necessary for a template to be available to all subnetworks? Any other comments or concerns?