On the Site Dashboard page, Weebly includes a number of default dashboard cards that display important information to site owners, such as site stats, tips, and form entries.
You can create a dashboard card to display dynamic, app-related content to site owners that have installed your app. When users click on different components of the card, a takeover opens displaying more detailed information in an iFrame using a provided URL to the content.
For example, the dashboard card for the Pinpoll app shows the number of votes for an active poll you created, over a period of time.
When you click the arrow in the header, a takeover displays a dashboard where you can create and manage your polls.
Dashboard cards are a great way to increase customer engagement, as they are displayed on the Site Dashboard page every time a user logs into Weebly. But don’t automatically assume your app needs a dashboard card - not every app does. Read further to understand what dashboard cards are and the types of apps that are best served by them, the anatomy of a dashboard card, and how the cards are dynamically updated.
When to Create a Dashboard Card
Because dashboard cards are seen immediately when the user logs into Weebly, they can greatly improve discoverability and engagement for the site owner’s installed apps. That said, not every app needs this type of exposure.
Here’s a list to help you determine if your app needs a dashboard card:
- Your app’s only presence in Weebly is the Manage button on the My Apps page
- You have site-specific data to display in the card. If your card would be the same for every site, then a card may not be needed.
- Your app collects data for a site owner, and you need a way to display this data.
- Your app requires interaction with the site owner outside of the editor.
- Your app provides real-time, personalized, actionable data
For example, an app that handles scheduling for a site might have a dashboard card that allows the site owner to review and manage scheduled appointments made via her web site. Another example might be an app that provides analytical data about a site and displays it on a dashboard card. An example of an app that does not need a dashboard card might be an element that displays static content on a site. Dashboard cards are meant to be an integral part of the app itself, and not a way to advertise or to communicate with site owners.
How Dashboard Cards Work
Dashboard cards are built by adding JSON entries to the app’s manifest to create a default version of the card. This is the card that every user will see when they first install your app (you change it later when you update your card).
A dashboard card includes a title bar that by default displays the app’s name, an icon, and an arrow that when clicked, links to content displayed in a takeover. Below the title bar are a number of components that can display different types of data, like text, stats, and links. When the user clicks a component in the card, a takeover displays more detailed data to the customer.
The card below is for a fictitious forum app. At the top, it has a heading in a title bar. When the user clicks it, a takeover displays overview information about the forum. The next component is a Text component that displays a message that a user needs to respond to. Clicking the text component leads to a takeover where the user can upgrade. Below that is a Stat component showing the number of forum posts this week and a sparkline chart depicting post trends for the week. Clicking that link leads to a takeover showing full data for the week’s posts. Below that is a group of Link components that provide information about the forum’s posts. The orange circle tells the user that the information might require some attention. The blue circle tells the user that it’s important information, but doesn’t require immediate attention. Both have links to view the posts in a takeover. The last component in the card is an Action component that allows the user to take action and create a new post. At the bottom of the card are navigation controls that tell the user the card contains two panes. Clicking the control brings up the second pane.
As you can see, dashboard cards are made up of a heading and then one or more the following components, each described in more detail in a separate topic.
- Text: A line or two of text - good for a tip or promotions. You can optionally set a style, such as alert, that changes the styling of the text.
- Link: Text with a link to a takeover. You can optionally set a notification or warning style that changes the styling of the text.
- Stat: A single statistic (usually a number) with an optional secondary display that can be either a sparkline chart or a delta.
- Action: A clickable button or link with an actionable icon that opens a takeover.
- Event: A time-based event.
- Progress: Displays progress a user has made towards completion of some action. For example, you might display a progress component to show how complete a user’s profile is.
- Welcome: Onboarding info to guide the user to a setup process for your app. This component takes up the whole card - no other components display with the Welcome component (unless on another pane of the card).
- Group: Groups two or more components together with an optional label.
When an app includes dashboard cards, they are installed when the app is installed and removed when the app in uninstalled. Newly added dashboard cards are added to the bottom of the Site Dashboard page. You define the default display of a new card in your manifest.
The data on the card is updated whenever the user returns to the Site Dashboard page and whenever the user closes the card’s associated takeover. Weebly sends a request to your endpoint and you respond using the provided POST endpoint to send updated data. You can also proactively update the data on specific card instances. When you update a card, the entire card is overwritten with the new data. See Create a Dashboard Card for all the details.
Review Process for Dashboard Cards
Dashboard cards go through a review as part of the app review process. However, because they are so visible to site owners, the card review process is a bit more stringent. To help with that, feel free to email firstname.lastname@example.org with a screenshot of a prototype card, including update changes. We’ll get back to you with feedback which, if followed, should help you get through the review process more quickly.