When you log into Alpine Chorus, the first view displayed is the user's home page.
The legacy home page was acting as an aggregate information page, but was cluttered, embedded the application navigation within the content, and was awkward to use. It delivered little value in the day-to-day user experience.
The redesign project (see Alpine Chorus Redesign) extracted the application navigation and replaced it with a ubiquitous navigation menu. Once this was done, the home page could be torn down, reconceived, and refashioned anew.
“Dashboard” was construed to be a location (a page) that provides the user with an overview of what they are doing and what is happening in the application, as well as access to the work they are doing in the application.
This aligned the dashboard with the business value of the platform as a collaborative environment for data analytics, and defined it as a specific class of dashboards — rather than displaying strategic or operational information, it should be personal and activity-centric.
The concept of the page was then distilled into two clear principles.
From this formulation, the solution coalesced.
The new dashboard was designed as a modular arrangement of information with a single column for simplicity (it would be easier to add additional layouts in later iterations). Customization allows the user to change what appears on the page.
The first feature in Alpine Chorus to allow the user to configure their own experience, home page customization was designed to be simple and uncomplicated.
The default view of the dashboard consisted of all five of the initial widgets, so that a new user would not have an empty home page when they logged in, and to give a starting point for changing the page to suit their needs.
When the customization action is invoked (via the gear glyph in the top right), two groups are displayed: widgets that are currently displayed on the page, and widgets that are available to add to the page (i.e. are therefore not currently being displayed). Each widget is shown symbolically (and rectangularly) in a diagrammatic version of the dashboard page itself, creating a clear correspondence between the configuration view and how the actual dashboard page will be composed.
The dashboard owner can drag any widget representation from one group to the other. Reorganization is possible by the same method: grab a widget in the “Displayed” group, and move it up or down to the desired position.
A modular page needs modules. These are the widgets, each displaying specific information and content. Five widgets were initially designed and shipped with the (first) dashboard release.
These first content modules were either tools personalized for the specific user, or “Signs of Life” measurements of project and work activity across the entire application.
Overview of workspaces you are connected to. By default, “Your Workspaces” are displayed, and the ad-hoc filter can select between three views:
An easy-to-access list of the files you were most recently working on.
Metrics for projects and collaborative work activity. This widget is the most straightforward instance of “Signs of Life” measurements.
Ranking of collaboration and activity in projects (aggregate). The ranking is calculated by using a simple measurement of actions that happen within workspaces.
A feed of comments and discussions pertaining to projects you are connected to.
Because the dashboard system was designed to be flexible and to grow, the infrastructure was in place to build and add new widgets at any time.
A backlog of potential widgets was populated initially with ideas from the initial product ideation sessions and added to when a new idea presented itself, such as when watching users at work in the application. Some of the future possibilities included:
Subsequent product changes also spawned new widgets that integrated the new features into the dashboard (see: Touchpoints).
The personal dashboard page was designed as a very specific page in Alpine Chorus. It was also conceived and designed as the basis of a sustainable system for application growth, where the home page is only the first instance.
At the application architecture level, the home page established a model and the infrastructure for other locations in the application to evolve from static pages to dynamic presentations with an improved user experience. On any individual page, the built-in flexibility enables configurations that can be determined automatically by role, location, and other contextual parameters. Or, the configurability can be turned off to use a predefined layout and set of modules.
Within the page, the modularity supports adding new widgets that are relevant to specific contexts (and limiting them to those contexts), while opening expansion to community invention as well as internal development.
Some of the high-value locations in the application suitable for transformation:
To provide a summary of the current progress and the project work within the workspace.
To provide a summary view of what the person has been working on, projects they are involved with, and the data they use.
To provide an overview similar to an individual user’s profile page, but for project teams.
Whether or not a view would be a good candidate for conversion to a configurable, modular format – in Chorus, and for enterprise applications in general – can be assessed with a few qualifying questions:
Defining what should be on a transformed page is accomplished by looking at the needs of the users crossing paths with the page.