This story is the third in a series of articles sharing a design framework for dashboards and portals.
Part 1 of this series, “The Challenge of Dashboards and Portals,” discussed the difficulties of creating effective information architectures for portals, dashboards, and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using such standardized components allows for the creation of a library of tiles that can be shared across communities of users.
This wireframe shows the structure of a Tile with an attached Control Bar. The Tile Header offers several types of convenience functionality (print, e-mail, and PDF export of the Tile). The Control Bar offers a single selector. The Tile Body contains a chart and table, each with a title and footer or key. The Tile Footer contains four links, to a mixed set of destinations.
Tile Group definition
Mandatory components: Tile Group Header, Tile Group Body
Optional components: Tile Group Footer
Stacking size: 2
Tile Group description:
Tile Groups consist of two required components – a Tile Group Header and Tile Group Body – and may include an optional Tile Group Footer. Tile Groups may include multiple Control Bars (note: adding multiple Control Bars can quickly increase development complexity and lower usability levels). The Tile Group Header contains a mandatory Title, optional Subtitle, mandatory source indicator, and may include buttons or links for Convenience functionality.
A Tile Group typically combines two or more Tiles together–likely from different sources or perspectives–into a larger unit of information or functionality that allows the combination of resources to answer more complicated questions, or achieve more complicated tasks. A Tile Group might answer the question, “How are my daily sales vs. my competitor’s daily sales?” by presenting a Daily Sales Tile and a Competitor Sales Tile next to one another, under the combined title “‘Daily Sales vs. Competitor Sales’.”
In this scenario, these two Tiles likely present information that comes from different data sources (perhaps one internal, and one licensed from a third party market metrics service), and different organizations that used the building blocks system to coordinate user experience design and development efforts that rely on a common enterprise portal or platform foundation. The consumers of the individual Tiles are likely affiliated with separate business units or operating groups, and may not need or be aware of the other Tiles, or the Tile Group. The consumers of the Tile Group could easily be part of a third element of the organization–or perhaps they are affiliated with the originating groups for the separate tiles, but share a common management perspective or performance incentive that requires a comparative presentation of the source information.
Stacking note: Tile Groups stacked inside larger building blocks retain their individual Tile Group Header, Tile Group Body, Tile Group Footer, and any optional components.
Design note: While Container definitions mandate some components to maintain the structural integrity of the building blocks system (always a Tile Header, etc.), they do not mandate constant visibility or display of all the structurally required components. Excess chrome is the enemy of a good user experience at all levels of structure, and should be avoided. Many existing interaction patterns, control mechanisms and design principles can help eliminate excess chrome, and minimize the presence of chrome in general to that which is necessary for a high quality user experience, without increasing the effort or cost of relying on the building blocks.
Figure 13 shows an example rendering of a Tile Group
Figure 13: Tile Group components and structure
This wireframe illustration shows the structure of a Tile Group with an attached Control Bar. The Tile Group Header offers several types of convenience functionality (print, e-mail, and PDF export of the Tile as rendered). The Control Bar offers two selectors. The Tile Group Body contains two stacked Tiles; one Tile offering text, the other offering the combination of a chart and table seen previously. Note that both stacked Tiles retain their individual Tile Headers and Tile Footers. In this rendering, neither stacked Tile offers convenience functionality, though it is possible for stacked Tiles to offer convenience functionality.
Mandatory components: View Header, View Body
Optional components: View Footer
Stacking size: 3
Views consist of two required components–-a View Header and View Body–-and may include an optional View Footer. Views may include multiple Control Bars (note: adding multiple Control Bars can quickly increase development complexity and lower usability levels). The View Header contains a mandatory Title, optional Subtitle, mandatory source indicator, and may include icons for accessing standard convenience functionality.
A View typically combines Tiles and Tile Groups together to present a comprehensive set of information resources that address a single perspective within an area of interest. In common use, Views allow Dashboard or Portal users to see the most logical subsets of all available Tiles related to one aspect of an area of interest. For example, many Tiles might provide information about a single product–too many to appear on one Page–but the Customer View of a product presents only those Tiles that show information about a single Product in relation to major Customers. Another defined View could offer marketing information for that same product, and a third might allow executives to check inventory levels for the product at various storage facilities.
Views stacked inside larger building blocks retain their individual View Header, View Body, View Footer, and any optional components.
Figure 14 shows an example of rendering of a View.
Figure 14: View components and structure
This wireframe shows the structure of a View with an attached Control Bar. The View Header offers several types of convenience functionality (print, e-mail, and PDF export of the View as a single unit). The Control Bar offers two selectors. The View Body contains two stacked Tile Groups, one Tile offering text, the other offering the combination of a chart and table seen previously. The stacked Tile Groups retain their individual Tile Group Headers, but do not include Tile Group Footers. In this rendering, neither stacked Tile Group offers convenience functionality, though it is possible for stacked Tiles to offer convenience functionality. The View Footer contains links to a variety of documents, applications, and destination sites.
Mandatory components: None
Optional components: None
Stacking size: 4
It’s best to talk about Pages in two senses; first as building blocks or Containers, and second as browsable destinations for users navigating dashboard or portal environments. In the first sense, as part of the hierarchy of building blocks in the dashboard or portal system, Pages are simply a larger kind of Container without mandatory components. They are governed by the same principles of portability, openness, independence, etc. as the other blocks, which means individual Pages may not be visible to some types of users, depending on security restrictions, and could consist of a mix of smaller building blocks and elements of free-form content. I considered calling them ‘nodes,’ to emphasize the distinction between their building block system role and their browser navigational role, but that felt too abstract.
In the second sense, Pages take on their traditional role as presentation canvases for content and functionality, linked together by navigation mechanisms: they serve as the single-screen units of display and interaction familiar from the Web browsing paradigm. In this role, Pages become the delivery vehicle for combinations of Containers and Connectors that allow users to work with content, and move through the dashboard or portal environment. Pages typically combine collections of Tiles, Tile Groups, and Views with a set of accompanying Connectors (Section Connectors, Page Connectors, Crosswalk Connectors, Geography Selectors, and Utility Navigation) to create a navigable user experience. Pages–following the principle of Openness–may include free-form content or navigation mechanisms. Common examples of free-form content include search functionality, global navigation, links to intranets and extranets, feedback forms for requesting new features, and branding elements.
A Page can consist of a single Tile, or only free-form content, may or may not have a Page Header or Page Footer managed as building blocks assets, and might not be connected to or accessible from other areas of the Dashboard or Portal. For example, a Page dedicated to account administration functions might only be visible to members of the user group Account Administrators, who themselves cannot see other areas of the Dashboard or Portal, and thus would not require navigation connections to other Pages in the Dashboard or Portal.
Figure 15 shows an example rendering of a Page.
Figure 15: Page components and structure
This wireframe shows the structure of a Page that mixes free-form content with building block content. The free-form elements appear in the form of a typical dashboard page header that contains a stock ticker and market summary, and a staff directory search box. Branding elements such as logos identifying the individual dashboard often appear as free-form content.
The building block content includes a navigation cluster made of a Section Connector and a Page Connector, two stacked Tiles, and a View that contains two stacked Tile Groups (Tiles not shown). On this Page, the two independent Tiles and the View are stacked at the same level within the containing Page. The layout of this Page places the Tiles above the View to ensure they remain visible without scrolling, but this layout is not necessary by the rules of the building block system. The individual Tiles on this Page do not include either Control Bars or Footers. The View includes a Control Bar with two selectors. None of the blocks offers Convenience Functionality, though of course this is possible across all levels of the stacking hierarchy, and is commonly available for the Page itself.
Mandatory components: 1 Page
Optional components: None
Stacking size: 5
The Section is primarily an organizational building block, but it does have a mandatory component of at least a single Page; this is to define an explicit context for navigation, user role. Sections typically consist of collections of Pages related to a core conceptual element of the information architecture or mental model for the Dashboard or Portal. It is not uncommon to see broadly defined Sections such as “Products,” “Customers,” “Supply Chain,” or “Sales.” Deep or complex Sections offering a considerable number of Pages or a large amount of content commonly include summary style Pages that condense or introduce the full contents of the Section in an overview. Shallow sections offering few Pages often do not require a summary style Page.
Figure 16 shows an example rendering of a Section.
Figure 16: Example Section
This site map style rendering shows a Section, titled Products, which contains five Pages that offer a variety of content related to the two types of Products produced and sold by a fictional company. The Section begins with a summary Page titled Products Overview. The four additional Pages are titled Branded Products, Product Focus, Co-Branded Products, and Co-brand Product Focus. The five pages contain a mixture of stacked Tiles, Tile Groups, and Views. The summary Page, titled Products Overview (P.3), offers the following: two stacked Tiles, Daily Sales (T.1) and Top 10 Products by Volume (T.12); and a stacked View, titled Products Sales Briefing (V.3).
By personal preference, only the blocks stacked at the level of the Page–level 3–are individually identified on this map-style rendering; the Views and Tile Groups would obviously include further Tiles stacked within. I use this rendering convention to cut down on visual clutter in maps of large dashboards or portals. For your own renderings, feel free to itemize every stacked block at every level on the Page, or even list the dashboard or portal contents in simple outline fashion without pictures. Each stacked block in the rendering is identified by its Title, and a unique ID code or label, to allow synchronization with a master list of building blocks available across all dashboards. The numbered lines indicate that each Page includes a standard Page Connector, offering navigation between all the numbered Pages in the Section.
Dashboard or Portal definition
Mandatory components: 1 Section
Optional components: None
Stacking size: 6
Dashboard or Portal description:
The Dashboard or Portal is the largest single unit of meaning possible to assemble from stacked building blocks. A Dashboard or Portal must consist of at least one Section (itself made of at least a single Page). Dashboards or Portals typically consist of several connected Sections, assembled from connected Pages that contain a variety of stacked building blocks, combined with a smaller number of stand-alone Pages dedicated to utility functionality or administration. Most Dashboards or Portals rely on a variety of Connectors to link assembled building blocks into a cohesive and navigable whole. A Dashboard or Portal’s information architecture often aligns with a single mental model, or a small set of closely overlapping mental models, though this obviously depends on the needs and goals of the expected users.
To most users of internal tools situated withing an enterprise, a Dashboard or Portal is the total set of Sections, Pages and other stacked building blocks their security and access privileges permit them to see and use when they visit a URL or some other user experience destination (note: for web-delivered Dashboards or Portals, it is common practice to create a URL and expose this address via an intranet or other internal gateway). Since each user has an individually determined and potentially different set of security and access rights to each possible Section, Tile, View, and Page, each user will likely see a different combination of Dashboard or Portal content that is tailored to his or her own needs.
In this way, individual Dashboards or Portals often draw from a pool of defined Tiles and blocks which:
- Serve a group of executives running a large organizational unit within an enterprise, such as Marketing, Manufacturing, or Information Technology.
- Provide a class of information resources giving insight across an enterprise, such as inventory monitoring, sales forecasting, financial reporting, and quality control assessment.
- Offer functionality in support of specific roles that entail responsibilities across the enterprise, such as regional directors, account managers, or human resources directors.
I recommend labeling or branding these kinds of internally focused Dashboards or Portals clearly, to help communicate their contents and purpose to users and administrators who will likely have to work with many different tools and environments, and may easily suffer disorientation as a result. A simple title such as “Corporate Finance and Accounting Dashboard” can help distinguish one Dashboard or Portal in a Suite from another for busy users. I also recommend creating a log-in or destination page that orients users and confirms they are accessing the correct Dashboard or Portal to meet their needs.
In more public and social settings, the patterns of architecture, usage, and design at this level of size and complexity naturally differ.
Design note: Depending on the depth and complexity of the assets offered within any one Dashboard or Portal, it may make sense to create a separate Home Page that introduces the structure and contents of the Dashboard, and offers unique content. Home Pages in this style commonly provide trend charts with roll-ups of more granular metrics, score-card style visualizations that communicate status for major areas of interest, alerts that require business attention, and high-level summarizations of the more extensive information available deeper inside.
Figure 17 shows an example rendering of a Dashboard.
This sitemap style rendering shows a medium-sized Dashboard or Portal designed to meet the information and business functionality needs of a large enterprise with multiple operating units and business lines. In this context, the Dashboard provides cross-unit summaries of many important metrics for senior managers, and could even provide them business functionality to alter business processes, change supply chain structures, or revise finance and resource allocations.
This Dashboard or Portal consists of a dedicated Home Page, and five major sections: Marketing, Finance, Products, Supply Chain, and Administration. The first four sections–S.1 through S.4–are linked via a Section Connector, offering direct navigation between these Sections. Each of these Sections includes a summary style Page. The Administration Section is not linked and navigable via the Section Connector: access to this Section would come via another path, generally direct URL entry or at the Dashboard or Portal log-in prompt (not shown). Within the major sections, all Pages are linked and navigable via Page Connectors.
Dashboard or Portal Suite definition
Mandatory components: Dashboards
Optional components: None
Stacking size: 7
Dashboard or Portal Suite description:
A Dashboard or Portal Suite consists of a group of stacked (though at this high level of structure, the construct is more akin to a collection of interlinks rather than hierarchically arranged) Dashboards or Portals sharing integrated content and common infrastructure. Stacking Dashboards or Portals as a Suite allows design and support teams to organize and manage distinct but related Dashboards or Portals as a single unit, and can help users by giving them quick and direct access to the collection of interconnected Dashboards or Portals. These Suites generally serve a diverse population of users who draw on a variety of business intelligence resources or other functionality to execute job functions at a variety of levels within the enterprise. The goals or purposes of the Dashboards or Portals in a Suite may vary dramatically; hence their individual content offerings will also vary dramatically. Users whose business needs or functions require them to work with single Dashboards or Portals in a Suite may not realize the commonalities underlying the various individual Dashboards or Portals they use. Users whose needs span multiple Dashboards or Portals in a Suite typically rely on a Dashboard or Portal Connector to move from one Dashboard or Portal to another within the Suite.
From an enterprise level architectural or IT administrative viewpoint, the Dashboard or Portal Suite can become the connection point to other enterprise level systems, such as metadata registries and repositories, ERP and SCM applications, enterprise data stores, security and authentication platforms, intranets, extranets, etc. The Dashboard or Portal Suite is also a useful unit for enterprise level perspectives including IT portfolio management, business process management, strategic information management, and knowledge management.
Figure 18 shows an example renderingof a Dashboard Suite.
Figure 18: Example Dashboard Suite
This sitemap style rendering shows an enterprise level Dashboard Suite made up of seven individual Dashboards that share assets. Five of the seven provide depth of content in major domains of a global enterprise: Supply Chain, Human Resources, Product Development, Knowledge Capital, and Finance. Each of these domain Dashboards has a distinct internal structure, with the individual Sections identified on this map.
The remaining two Dashboards–Global Leadership and Regional Leadership–aggregate assets for presentation to the different levels of executive leadership within the enterprise. Within this scheme, the information architecture of the two leadership Dashboards is closely parallel, but the scope of the assets shown in each would differ; users of the Regional Leadership Dashboard would have a view of Finance assets for their individual regions, and not globally, as in the Global Leadership Dashboard.
In this Suite, the five domain Dashboards are linked to the two Leadership Dashboards via a Dashboard Connector, meaning that each of these is navigable directly from the Leadership Dashboards. The Regional Leadership Dashboard is also linked to the Global Leadership Dashboard via another Dashboard Connector. Whether these Connectors allow two-way access is dependent on the individual access rights of the various Dashboard users. The Dashboard Connector here ensures that the members of the respective leadership teams can literally see what their colleagues see when discussing a course of action.
Coming soon: Building Block Definitions (Connectors)
The fourth installment of the series will define the Connector components in detail.