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.
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.
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.
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.
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.
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.
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.
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.
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 %>
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.