This month, we welcomed the newest member in a long line of Uncle Cheese’s brainchildren – the Dashboard module. Dashboard is for SilverStripe 3 only, and with a highly extensible API and frictionless interface, it’s likely that you’ll find more than a few reasons to use it on your next SilverStripe project.
Why Dashboard?
One of the disadvantages of being a developer is that we rarely get to play the role of an end-user in the software we create. When clients and project managers ask me what I love so much about SilverStripe 3, I usually rattle off a bunch of technical things – the new ORM, the improved templating, the GridField API – things that mean nothing to a content editor. What most upgrade-fearing users are wondering is how SilverStripe 3 makes content editing easier, faster, and more powerful than ever before.
There’s no doubt that SilverStripe 3 does all of those things. That much is clear from the feedback I get when showing the product to end-users. There is, however, one criticism common to both SilverStripe 2 and 3 that I hear too often to ignore – the lack of an action-oriented splash screen (read: dashboard).
In typical end-user fashion, they don’t come right out and ask for a “dashboard.” Most of them are not familiar enough with the lexicon to describe the idea with such precision. Rather, I hear a lot of desire for features that only a dashboard could offer.
- “How do I get back to the page I was working on yesterday?”
- “Where is the button to write a new blog?”
- “How do I get to the calendar?”
- “Where can I see how many people signed up for the seminar today?”
All of these user stories send them on a journey of multiple clicks through trees and tables to find what they are looking for. A dashboard view would bring these actions to the surface, and offer a single-click, intuitive, user-biased path to a CMS action.
So Why Not Dashboard?
If the feature is of such high value, then why isn’t it already part of SilverStripe? To me, it makes a lot of sense to leave it out. SilverStripe is not a single-purpose application like WordPress or Magento. In fact, out of the box, it’s hardly an application at all. Until a developer builds something with the robust set of tools it offers, there’s not much you can say about what the needs of an end-user will be for a SilverStripe web site. Offering a pre-cooked dashboard risks capturing only a small number of common needs and leaving many more underserved.
An Open Solution
When I started building the Dashboard module, I knew the last thing I wanted was to offer a handful of static widgets that may or may not serve each user’s needs. Rather, like the SilverStripe platform itself, it should offer just enough out of the box, and invite developers to create custom solutions. Knowing that every developer understood the basic design pattern of creating a custom page type, I followed that template and offered an API that gave dashboard panels their own model, view, and controller. This means that each dashboard panel is self-contained and can render virtually anywhere, with any content you want it to.
How It Works
When you install Dashboard, the first difference you’ll see right away is that the “Dashboard” menu item is first in the list, usurping the Pages tab as the default view in the CMS. The dashboard is empty by default.
By clicking “New Panel,” you are offered a choice of several different panel types that come baked into the Dashboard module.
They include:
- Recent Edits: Shows a list of recently edited pages, with links to edit each.
- Recent Uploads: Show a list of recently uploaded files, with links to edit each.
- Quick Links: Builds a panel of arbitrary links, either internal (in the CMS) or external (on the web).
- Google Analytics: Shows the Google Analytics data for your entire site or a specific page on the site.
- Section Editor: Shows a given section of the site, e.g. “blog” or “calendar”, displaying all of its child pages and offers links to create a new page or view all pages.
- ModelAdmin Editor: Shows the list of a given ModelAdmin view and offers links to edit each record, view all, or create a new entry.
- GridField Editor: Shows a GridField of a given page and allows direct linking to create and edit on the grid.
- RSS Feed: Show an RSS feed from any public URL.
- Weather: Shows the current weather of a given city
After choosing the panel type you want to create, the panel is installed on your dashboard. If it needs immediate configuration, it will flip over automatically. Otherwise, you can click on the gear button to enter this view.
On the back of the panel, you will find all of the metadata that defines how the panel looks and behaves. All panels have settings for their title and width.
Creating Default Dashboards
As a developer, you may want to offer each client a default dashboard so that users aren’t logging in to a buzz-killing blank page. You can apply a default dashboard in two different ways:
1. Retroactively: Apply this dashboard to all existing users, overwriting whatever dashboard configurations they may or may not have presently.
2. Proactively: In the future, all new users receive this dashboard configuration by default.
If you want to exert even more control over your users’ dashboards, the Dashboard module also offers a granular assortment of permissions, allowing you to specify which users can create, edit, sort, delete, and administer dashboard panels. By revoking all privileges, you can essentially give users a static, immutable dashboard view.
Creating Your Own Flavor
As mentioned earlier, one of the primary goals of the Dashboard module was to make it easy to extend and inviting for developers. There are only a few simple steps.
1. Create a subclass of DashboardPanel, e.g. “MyDashboardPanel.php”
2. Populate the $db array with any custom fields used to configure the panel, e.g. “NumberOfRecords”
3. Create a getConfiguration() function that returns a FieldList to for the edit form. This works just like getCMSFields() on a page type. Remember to call parent::getConfiguration()!
4. Create a template of the same name as your panel, e.g. “MyDashboardPanel.ss”
5. Create the view using any template accessors you have defined in your model, e.g. <% loop MyRecords %>
6. Include any JavaScript or CSS dependencies in the PanelHolder() method. Don’t forget to return parent::PanelHolder()!
There’s a lot more you can do when building a custom dashboard panel. The module is full of great APIs to help you create exactly what you want.
Data Visualization
The Dashboard module comes with a charting API, albeit fairly primitive. Using the Google visualization JavaScript API, it allows you to create charts for dashboard panels that display arbitrary data over a given span of time. Just add data in X/Y pairs, and return the chart to your template.
More Information
- Download it here
- Read the Documentation
- Check out the screencasts
