Let's review the types of pages available for use in an application. Then we will create several examples for our WDTU Radio Station system.
Each time we work on an application design, we need to carefully consider which page type is best to use for the functionality we are creating. Types of pages available include RoleCenter, List, Card, ListPart, CardPart, ListPlus, Document, Worksheet, Navigate, ConfirmationDialog, and StandardDialog. Pages can be created and modified by the developer and can be personalized by the administrator, super user, or user.
A user's assigned Role Center page is their home page in NAV, the page where they land when first logging into NAV 2015. The purpose of a Role Center page is to provide a task-oriented home base which focuses on the tasks that the user typically needs in order to do his/her job on a day to day basis. All the user's common tasks should be no more than one or two clicks away.
The standard NAV 2015 distribution includes twenty-three predefined Role Center pages, including generic roles such as Bookkeeper, Sales Manager, and Production Planner. Some of the provided Role Centers are richly featured and have been heavily tailored by Microsoft as illustrations of what is possible. On the other hand, some of the provided Role Centers are only skeletons, acting essentially as place holders.
Role Centers that are specific to the customer's organization structure and user role profiles should be created for every NAV implementation. We should take advantage of the guidance for the design and creation of Role Center pages that is part of the Microsoft MSDN documentation (such as https://msdn.microsoft.com/en-us/library/jj128066(v=nav.80).aspx and its See Also references) or is in various blogs. Even though this material is brief, it provides much useful information.
Central to each Role Center page is the Activities area. The Activities area provides the user with a visual overview of their primary tasks. Central to the Activities part are the Cues. Each blue Cue icon represents a filtered list of documents in a particular status, indicating the amount of work to be handled by the user. The grey Cue icons display a calculated value.
The following screenshot shows a Role Center page for the user role profile of Sales Order Processor:
List pages are the first pages accessed when choosing any menu option to access data. This includes all the entries under the Home Button on the Navigation Pane. A List page displays a list of records (rows), one line per record, with each displayed data field in a column.
When a List page is initially selected, it is not editable. When we double-click an entry in a List, either an editable Card page or an editable List page entry is displayed. Examples of this latter behavior are the Reference table pages such as Post Codes, Territories, and Languages. A List page can also be used to show a list of master records to allow the user to visually scan through the list of records, or to easily choose a record on which to focus.
List pages may optionally include FactBoxes. Some NAV 2015 List pages, such as Customer Ledger Entries (Page 25), allow editing of some fields (for example, Invoice Due Dates) and not of others.
The following screenshot shows a typical list page—the Item List, Page 31:
Card pages display and allow updating of a single record at a time. They are used for master tables and setup data. Complex cards can contain multiple FastTabs and FactBoxes, as well as display data from subordinate tables. An example of Card page image for the Customer Card – Page 21 follows, with the General FastTab expanded and the other FastTabs collapsed:
Document (task) pages have at least two FastTabs in a header/detail format. The FastTab at the top contains the header fields in a card style format, followed by a FastTab containing multiple records in a list style format (a ListPart page). Examples are Sales Orders, Sales Invoices, Purchase Orders, Purchase Invoices, and Production Orders. The Document page type is appropriate whenever we have a parent record tied to a subordinate child records in a one‑to‑many relationship. A Document page may also have FactBoxes. An example of Sales Order Document page follows (Sales Order – Page 42):
FastTabs, as shown in the preceding Customer Card and Sales Order screenshots, are collapsible/expandable replacements for traditional left-to-right forms tabs. They are often used to segregate data by subject area on a Card page or a Document page. In this Sales Order image, the General and Lines FastTabs are expanded and the remaining FastTabs are collapsed. Individually important fields can be Promoted so they display on the FastTab header when the tab is collapsed, allowing the user to see this data with minimal effort. Examples appear on all the Sales Order's collapsed FastTabs. Promoted field displays disappear from the FastTab header when the FastTab is expanded.
A ListPlus page is similar in layout to a Document page, as it will have at least one FastTab with fields in a card type format and one FastTab in a list page format. Unlike a Document page that can only have a single list style subpage, a ListPlus page may have more than one FastTab with card format fields and one or more FastTabs with a list page format. The card format portion of a ListPlus page often contains control information determining what data is displayed in the associated list, such as in Page 113 – Budget, shown in the following image:
A ListPlus page may also have FactBoxes. Other examples of ListPlus pages are Page 155 – Customer Sales and Page 157 – Item Availability by Periods.
Worksheet pages are widely used in NAV to enter transactions. The Worksheet page format consists of a list page style section showing multiple record lines in the content area, followed by a section containing either additional detail fields for the line in focus or containing totals. All the Journals in NAV use Worksheet pages. Data is usually entered into a Journal/Worksheet by keyboard entry, but in some cases via a batch process.
The following screenshot shows a Worksheet page, Sales Journal – Page 253:
This is a simple display page embedded in a process. It is used to allow a user to control the flow of a process. Following is a sample ConfirmationDialog page:
The StandardDialog page is also a simple page format to allow the user to control a process, such as Copy Tax Setup (Page 476). The StandardDialog page allows the entry of control data such as that shown in the following screenshot:
The primary use of the NavigatePage page type in NAV 2015 is as the basis for Wizard pages. All the instances of Wizard pages in NAV 2015 are in the Marketing functionality area of the system. Some Wizard page examples are pages: 5077 – Create Interaction, 5097 – Create To-do, 5126 – Create Opportunity, 5129 – Update Opportunity, and 5146 – Assign Opportunity. A Wizard page consists of multiple user data entry screens linked together to provide a series of steps necessary to complete a task.
Two screens from a Wizard page (Page 5126 – Create Opportunity) are shown in the following screenshots:
The Navigate function has been a very powerful, unique feature of NAV since the 1990s. Somewhat confusingly, in NAV 2015 the Navigate function is implemented using the ListPlus page type, not the NavigatePage page type which was used in the earlier NAV releases.
The Navigate page (Page 344) allows the user (who may be a developer operating in user mode) to view a summary of the number and type of posted entries having the same document number and posting date as a related entry or as a user-entered value. The user can drill down to examine the individual entries. Navigate is a terrific tool for tracking down related posted entries. It can be productively used by a user, an auditor, or even by a developer. A sample Navigate page is shown in the following screenshot:
There are two special purpose page types. One is a component of other objects, and the second is automatically generated.
A Request page is a simple page that allows the user to enter information to control the execution of a Report or XMLport object. Request pages can have multiple FastTabs, but can only be created as part of a Report or XMLPort object. All Request page designs will be similar to the following image for the Item Price List (Report 715) Request page:
The Departments page is a one-of-a-kind, system-generated page. We don't directly create a Departments page because it is automatically generated from the entries in the MenuSuite object. When we create new objects and add appropriate entries to the MenuSuite, we provide the material needed to update the Departments menu/page. The look and feel of the Departments page cannot be changed (though individual entries can be added, changed, moved, or deleted).
The Departments page acts as a site map to the NAV system for the user. When we add new objects to the MenuSuite (thus to the Departments menu), NAV UX design guidelines encourage the entry of duplicate links within whichever sections the user might consider looking for that page (we will later discuss the Search function which makes this task even easier). An example of a Departments page is shown in the following screenshot:
Several of the page types we have reviewed thus far contain multiple panes with each pane including special purpose parts. Let's look at some of the component page parts available to the developer.
The FactBox Area can be defined on the right side of certain page types including Card, List, List Plus, Document, and Worksheet. A FactBox Area can contain Page parts (CardPart or ListPart), Chart parts, and System parts (Outlook, Notes, MyNotes, or Record Links). A variety of standard CardParts, ListParts, and Charts are available which can be used in FactBoxes. System parts cannot be modified. All the others can be enhanced from the standard instances, or new ones may be created from scratch.
CardParts are used for FactBoxes that don't require a list. They display fields or perhaps a picture control. (NAV 2015 Help contains an example of including a DotNet add-in within a FactBox to display a chart) An example of the Customer Statistics FactBox (Page 9082 – Customer Statistics Factbox) is shown in the following screenshot:
ListParts are used for FactBoxes that require a list. A list is defined as columns of repeated data. No more than two or three columns should appear in a FactBox list. A screenshot of the three‑column My Items FactBox ListPart - Page 9152 follows:
In NAV 2015, there are two standard ways of including charts in our pages. The first one, Chart parts, is a carry-over from NAV 2009. The second one, the Chart Control Add-in, was new in NAV 2013.
A Chart part displays list data in graphic form. It is a default optional component of all FactBox Areas; it is not a Page Type. If a FactBox exists, it has a Chart part option available. Chart parts are populated by choosing one of the available charts stored in the Chart table (Table 2000000078). Some charts require range parameters while others do not (they default to a defined data range). Most of the supplied charts are two-dimensional, but a sampling of three-dimensional, dynamic charts is included. A MSDN NAV Team blog provides an extensive description of chart construction and a utility for creating new charts (http://blogs.msdn.com/b/nav/archive/2011/06/03/chart-generator-tool-for-rtc-cgtrtc.aspx). There is also a YouTube video on the topic, available at https://www.youtube.com/watch?v=RwOv3dLdXAw&x-yt-cl=85114404&x-yt-ts=1422579428. Though both of these were created for the previous releases of NAV, they are useful for NAV 2015 as well. A sample standard chart is shown in the following screenshot:
The NAV 2015 distribution includes a charting capability that is based on a Control Add-in (created with .NET code written outside of C/SIDE and integrated into NAV). An example is the Trailing Sales Orders chart in a Factbox Page part (Page 760) that appears in the Order Processor Role Center (Page 9006). Following is a screenshot of that chart:
The Cash Flow Chart Example in the NAV 2015 Developer and IT Pro Help describes how to create charts using the Chart Control Add-in.
Card pages are named similarly as the table with which they are associated, plus the word Card. Examples include Customer table and Customer Card, Item table and Item Card, and Vendor table and Vendor Card.
List pages are named similarly as the table with which they are associated. List pages which are simple noneditable lists have the word list associated with the table name. Examples are Customer List, Item List, and Vendor List. For each of these, the table also has an associated card page. Where the table has no associated card page, the list pages are named after the tables, but in the plural format. Examples include Customer Ledger Entry table and Customer Ledger Entries page, Check Ledger Entry table and Check Ledger Entries page, Country/Region table and Countries/Regions page, and Production Forecast Name table and Production Forecast Names page.
The single-record Setup tables that are used for application control information throughout NAV are named after their functional area, plus the word Setup. The associated Card page should also be (and generally is) named similarly to the table. For example, General Ledger Setup table and General Ledger Setup page, Manufacturing Setup table and Manufacturing Setup page, and so on.
Journal entry (worksheet) pages are given names tied to their purpose, plus the word Journal. In the standard product, several Journal pages for different purposes are associated with the same table. For example, the Sales Journal, Cash Receipts Journal, Purchases Journal, and Payments Journal, all use the General Journal Line table as their SourceTable (they are different pages all tied to the same table).
If there is a Header and Line table associated with a data category such as Sales Orders, the related page and subpage ideally should be named to describe the relationship between the tables and the pages. However, in some cases, it's better to tie the page names directly to the function they perform rather than the underlying tables. An example is the two pages making up the display called by the Sales Order menu entry—the Sales Order page is tied to the Sales Header table, and the Sales Order Subform page is tied to the Sales Line table. The same tables are involved for the Sales Invoice page and Sales Invoice Subform page.
Sometimes, while naming pages, we will have a conflict between naming pages based on the associated tables and naming them based on the use of the data. For example, the menu entry Contacts invokes a main page/subpage named Contact Card and Contact Card Subform. The respective tables are the Contact table and the Contact Profile Answer table. The context usage should take precedence in the page naming as was done here.