Development guidelines
Introduction
Sitevision Marketplace is a great way for partners to reach out with modules to Sitevision customers in Sweden and around the world. The marketplace makes it easy for customers to discover new modules (your modules!) and add them to their website.
If you build a module that’s just intended for a single customer, Sitevision Marketplace isn’t the best place for you. Consider installing your module as an addon directly on the website, for more information see developer.sitevision.se.
You are responsible for making sure everything in your module complies with these guidelines, including and third-party SDKs, so review and choose them carefully.
Before Submitting Your Module for Review
Make sure you:
- Test your module for crashes and bugs.
- Ensure that all module information and metadata is complete and accurate.
- Update your contact information in case Sitevision needs to reach you.
- Provide an active demo account and login information, plus any other resources that might be needed to review your module (e.g. login credentials).
- Enable backend services so that they’re live and accessible during review.
- Include detailed explanations of non-obvious features in the review notes, including supporting documentation where appropriate.
- Ensure that the module support the trial-period (14 days) and works seamlessly if a license is installed.
Safety
When customers install a module from Sitevision Marketplace, they want to feel confident that it’s safe, that the module doesn’t contain inappropriate content, and that it won’t damage their website.
User Generated Content
Modules with user-generated content present particular challenges, ranging from intellectual property infringement to anonymous harassment. To prevent abuse, modules with user-generated content or social networking services must include:
- A method for filtering objectionable material from being posted to the modules.
- A mechanism to report offensive content and timely responses to concerns.
- The ability to block abusive users from the service.
- Published contact information so users can easily reach you.
Developer Information
People need to know how to reach you with questions and support issues. Make sure your module and its Support URL include an easy way to contact you. Failure to include accurate and up-to-date contact information not only frustrates customers, but may violate the law in some countries.
Data Security
Modules should implement appropriate security measures to ensure proper handling of user information collected pursuant to the App Development Agreement and these Guidelines and prevent its unauthorised use, disclosure, or access by third parties.
Performance
Module Completeness
Submissions to review should be final versions with all necessary metadata, placeholder text, empty websites, and other temporary content should be scrubbed before submission.
Make sure your modules has been tested for bugs and stability before you submit it, and include demo account info (and turn on your back-end service) if your module includes a login.
Please don’t treat the review as a software testing service. We will reject incomplete modules that crash or exhibit obvious technical problems.
Accurate Metadata
Customers should know what they’re getting when they download or buy your module, so make sure your module description, screenshots, and previews accurately reflect the module’s core experience and remember to keep them up-to-date with new versions.
Module Implementation
Design your module to be efficient and in a way that does not risk compromising the plattform.
The implementation of the module should strive to comply with known principles of good software design and avoid known anti-patterns, like iteration of large collections of data during page-rendering etc.
Modules should never suggest or require a restart of Sitevision or modifications to system settings unrelated to the core functionality of the module.
Modules must be self-contained, modules should not install code or resources in shared locations.
Strive to implement modules that, in the same way as existing modules in Sitevision, does one thing, e.g. Text, Image, etc.
Modules may only use public APIs and must run on the currently shipping version of Sitevision. Learn more about public APIs (developer.sitevision.se). Keep your modules up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of Sitevision. Modules should use APIs and frameworks for their intended purposes and indicate that integration in their module description.
Modules must be fully functional on IPv6-only networks.
Modules must comply with the Web Content Accessibility Guidelines (WCAG) 2 AA (https://www.w3.org/TR/WCAG22/)
Modules must not force users to rate the module, review the module, download other modules, or other similar actions in order to access functionality, content, or use of the module.
Modules that alter or disable the functions of standard features, such as the layout controls etc, or other Sitevision native user interface elements or behaviors will be rejected.
Performance
Module Completeness
Submissions to review should be final versions with all necessary metadata, placeholder text, empty websites, and other temporary content should be scrubbed before submission.
Make sure your modules has been tested for bugs and stability before you submit it, and include demo account info (and turn on your back-end service) if your module includes a login.
Please don’t treat the review as a software testing service. We will reject incomplete modules that crash or exhibit obvious technical problems.
Accurate Metadata
Customers should know what they’re getting when they download or buy your module, so make sure your module description, screenshots, and previews accurately reflect the module’s core experience and remember to keep them up-to-date with new versions.
Module Implementation
Design your module to be efficient and in a way that does not risk compromising the plattform.
The module may only use client side rendering. Server side rendering is not allowed and modules using it will be rejected.
The implementation of the module should strive to comply with known principles of good software design and avoid known anti-patterns, like iteration of large collections of data during page-rendering etc.
Modules should never suggest or require a restart of Sitevision or modifications to system settings unrelated to the core functionality of the module.
Modules must be self-contained, modules should not install code or resources in shared locations.
Strive to implement modules that, in the same way as existing modules in Sitevision, does one thing, e.g. Text, Image, etc.
Modules may only use public APIs and must run on the currently shipping version of Sitevision. Learn more about public APIs (developer.sitevision.se). Keep your modules up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of Sitevision. Modules should use APIs and frameworks for their intended purposes and indicate that integration in their module description.
Modules must be fully functional on IPv6-only networks.
Modules must comply with the Web Content Accessibility Guidelines (WCAG) 2 AA (https://www.w3.org/TR/WCAG22/)
Modules must not force users to rate the module, review the module, download other modules, or other similar actions in order to access functionality, content, or use of the module.
Modules that alter or disable the functions of standard features, such as the layout controls etc, or other Sitevision native user interface elements or behaviors will be rejected.
Design
Sitevision customers place a high value on products that are simple, refined, innovative, and easy to use. That’s what we want to see on Sitevision Marketplace. Coming up with a great design is up to you, but the following are minimum standards for approval to Sitevision Marketplace.
Remember that even after your module has been approved, you should update your modules to ensure it remains functional and engaging to new and existing customers. Modules that stop working or offer a degraded experience may be removed from SiteVision Marketplace at any time.
Module Considerations
Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular module on Sitevision Marketplace, or make some minor changes to another module’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes Sitevision Marketplace harder to navigate and it isn’t fair to your fellow developers.
Do not recreate existing Sitevision standard modules.
Minimum Functionality
Your module should include features, content, and UI that elevate it beyond a repackaged script. If your module is not particularly useful or unique, it doesn’t belong on Sitevision Marketplace. If your module doesn’t provide some sort of lasting business value, it may not be accepted. Your module should work on its own without requiring installation of another module to function.
Your module must declare all required Sitevision features in the module manifest.
Module Description
Any third-party software used must be included in the module’s terms and conditions.
Detailed module description must be provided in accordance to the instructions on the Sitevision Marketplace administration website (apps.sitevision.se).
User Interface and User Experience
An Envision theme is included in the parent document (https://envisionui.io/). The theme will be used as a base for all styling of a widget. An extension to the theme — Envision for Dashboard Widgets — is also available for styling of elements and components (https://envisionui.io/dashboard/).
The theme font (Inter) should be used for all text in the module.
Envision components, markup and styling should be used when possible.
The text styles availble in the theme and its extension should be used when a fitting option is available.
When using stylesheets, all colors must use the color palette variables available in the theme and its extension. Other colors and hard coded color values must be avoided as far as possible.
Most modules should be wrapped in the CSS class "env-dashboard-widget" to set the standard container appearance with background, borders etc. Some very simple widgets may exclude the wrapper, but must in that case be placed directly against the document background. No custom wrapping containers may be used.
The developer must declare which size or sizes that are supported by the module in the module manifest. The module should use Container queries – not Media queries – for a responsive design that fits all supported sizes. See table for available sizes.
Make sure that the configuration UI seamlessly integrates with Sitevision and other modules. Module configuration experience must be consistent with out-of-the-box modules.
Sitevision uses Bootstrap 3 for configuration UI rendering and so should you.
Do not create your own selection components if there is one in the SDK. (https://developer.sitevision.se/docs/webapps/configuration/html-components)
Manifest example
Below is an example of what a manifest.json looks like for an Marketplace app.
Marketplace specifics:
- tags - used to describe your app and will be used for Marketplace searches
- requirements - used to inform that your app uses a licensed Sitevision feature. Valid values:
- data-storage
- intranet-2
- search-advanced
- search-enterprise
- licensingType - used to specify pricing model (mandatory)
- free
- commercial
- category - module category in Sitevision (mandatory)
- StatisticsAndAnalysis
- SystemStatus
- SupportAndHelp
- CalendarAndEvents
- UserManagement
- IntegratedTools
- ContentManagement
- Other
- policyUrl - link to app's policy page
{
"id": "marketplace.sitevision.someWidget", // must match: marketplace.<organization>.<appId>
"version": "0.0.1",
"type": "Widget",
"name": {
"en": "Widget name",
"no": "Widget navn",
"sv": "Widget namn",
},
"description": {
"en": "A short description of the widget",
"no": "En kort beskrivelse av widgeten",
"sv": "En kort beskrivning av widgeten"
},
"author": "Example AB",
"helpUrl": "https://developer.sitevision.se/widgethelpurl",
// Marketplace specifics
"tags": ["Media", "Socialt"],
"requirements": [],
"licensingType": "free", // or "commercial"
"category": "StatisticsAndAnalysis" // must match one of SiteVision's module categories,
"policyUrl": "developer.sitevision.se/policy",
"requiredSiteVisionVersion": "2023.07.1",
"contactEmail": "developer@sitevision.se", // used to get notfications about downloads
// Marketplace Widget specifics
"supportedWidgetSizes": ["small", "medium", "large", "extra_large"]
}Legal
Modules must comply with all legal requirements in any location where you make them available. It is your responsibility to understand and make sure your module conforms with all local laws, not just the guidelines below.
Privacy
Protecting user privacy is paramount in the Sitevision ecosystem, and you should use care when handling personal data to ensure you’ve complied with applicable laws (including the European Union’s General Data Protection Regulation, “GDPR”) and the terms of the App Development Agreement, not to mention customer expectations. More particularly:
Data Collection and Storage
(i) Privacy Policies: All module must include a link to their privacy policy in the module metadata field. The privacy policy must clearly and explicitly:
- Identify what data, if any, the module collects, how it collects that data, and all uses of that data.
- Confirm that any third party with whom a module shares user data (in compliance with these Guidelines) — such as analytics tools, advertising networks and third-party SDKs, as well as any parent, subsidiary or other related entities that will have access to user data — will provide the same or equal protection of user data as stated in the module’s privacy policy and required by these Guidelines.
- Explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data.
(ii) Permission: Modules that collect user or usage data must secure user consent for the collection, even if such data is considered to be anonymous at the time of or immediately following collection. Modules must also provide the customer with an easily accessible and understandable way to withdraw consent.
(iii) Data Minimisation: Modules should only request access to data relevant to the core functionality of the module and should only collect and use data that is required to accomplish the relevant task.
Intellectual Property
Make sure your module only includes content that you created or that you have a license to use. Your module may be removed if you’ve stepped over the line and used content without permission. Of course, this also means someone else’s module may be removed if they’ve “borrowed” from your work
Any open source third-party software included in a module must use a permissive open source license or you must have the legal rights to use it for commercial software.