-
Always design the WorkView process before configuring the solution. Design the application including classes, attributes, view layouts, etc on paper/whiteboard to get an overview of what the solution will look like and how it best solves the business problem.
-
Test all changes. Creating and maintaining a test environment is important to fully test changes before implementing them in a production system. Once changes are created in a production system, another test should be performed in the production system.
-
Use good naming conventions for Filters. It is best to create a naming convention for filters in your application. Filter names should be prefixed with the class name to allow for easy identification.
-
Add description to all items when possible. Adding description to configuration items allows for easy troubleshooting and maintenance. These items include actions, notifications, filter bars, filters, and views.
-
Configure intuitive Attribute Display Names. When creating attributes, the attribute's name is also copied to the “Display name” field. The value in the “Display name” field should be configured to make sense to users. For example, if attribute name is “TotalAmountDue” the Display name will also reflect this value when you tab out of the attribute name field. A more user friendly text should be entered in to the display name field. For example, “Total Amount Due” or “Total Due”. In addition, please note that the attribute's display name is also added as Filter Column Heading text.
-
Configure default values when configuring Attributes. Whenever possible, default values should be configured for attributes. This makes data entry easier for users as they do not have to enter those values. For example, you may want to create default values for items like “Date Created” using the current date or date & time.
-
Configure data sets when possible for set values. Depending on your business needs, it may be necessary to configure data sets for attributes where possible. Data sets can ensure that users enter the correct values in fields and allows for consistency.
-
Create multiple views when there are many items to be added to a View. If there are many items to be added to a view, it is sometimes best to create multiple views. This will prevent users from having to scroll down a long view with several attributes, embedded filters, folders, etc.
-
Use the Copy View functionality when configuring several Views for the same Class. Some WorkView solutions require that you create multiple Views for users based on roles. For example, “Employee Info” View created for all Employees with limited View items and “Employee Info - Mgr” View created for Managers that contain salary information, disciplinary comments and dates, etc. Using the copy functionality not only allows for consistency across Views but also makes it easier and faster to create them.
-
Configure View names with Keyboard shortcuts. When creating views, add keyboard shortcuts to the view names to allow for easy navigation.
-
Assign Screen Actions to relevant Views. If there are several views created for a screen and several screen actions are available, it may be necessary to assign actions to specific views. For example, you may want to assign the “Display Task Report” action to the “Tasks” view instead of the default view.
-
Add elements in a table when possible. When creating a view, add items such as labels, attribute fields, etc in tables to ensure that they are aligned properly.
-
Add Help Text to field properties. When creating a view, add help text to items on the view. This allows users to know what a particular field is for and any other information you may wish to display.
-
Disable lookup buttons for items you do not want users to change. If you do not want users to change values in certain fields such as Date, DateTime, Data set or relationship with lookup, disable the lookup buttons in addition to making the field read-only. Note that users can change values for fields marked as read-only if the fields have lookup buttons.
-
Set fields that users should never change to read-only. This ensures that users will not able to change those fields or values that are set automatically by WorkView or by the Administrator.
-
Configure CSS blocks with descriptive names. When configuring CSS blocks in WorkView, make sure the name of the field is descriptive.
-
Ensure users have rights to view images added using CSS. When you add company logo, background images, etc to a view using CSS ensure that all users have access to the file through UNC or URL.
-
Denote required fields with red asterisk. Depending on your environment and business case, you may need to add a label next to fields that are marked as required. This allows users to see which fields must be entered at a glance, otherwise they will be prompted to supply values for the fields when they attempt to save the object or navigate to a different view. The red asterisk can be achieved by creating a block in CSS editor.
-
Do not change Attribute name value in the Designer. You may change display name of attributes on a view but do not change the actual name of the attribute. It is considered best practice if this value is the same as the attribute's name found in the attribute configuration window. This also allows administrators to easily identify attributes when troubleshooting or performing view maintenance, etc.
-
Use Line Break and Separator to arrange and group like items together. When configuring a view, it may be necessary to group items together using line breaks and separators. For example, you may wish to add all customer information fields at the top of a view, then a separator between that and issue information fields.
-
Group Filter Bar Items by Filter Bar. Similar items should be grouped together in one filter bar rather than grouping all items or unrelated items in one filter bar.
-
Configure Subfilters when possible or when users will need to see dependent Objects. When users need to see dependent items attached to a parent object, it is recommended that subfilters be configured for the parent filter. This allows users to see any related/child items without necessarily having to open the parent object to look for items in an embedded filter. For example, if users will need to view “Notes” objects associated with a particular “Issue”, they may first open the “Issue” object then look at the items in the embedded “Notes” filter. By configuring a subfilter for “Notes”, the users do not have to open the parent “Issue” object – they can just execute the subfilter for “Notes” from the filter result window and see a list of items attached to the current “Issue” object.
-
Use the Copy Filter functionality when configuring several Filters for the same Class. Some WorkView solutions require that you create multiple filters for the same class. Sometimes these filters have the same view attributes. By creating a “template” filter and copying that for new filters, you will save time configuring filters and also have a consistent view attributes setting.
-
Use Attributes that are unlikely to change when configuring a Filter Document Type Association. When configuring a filter Document Type Association that displays WorkView objects that have an OnBase document attached, it is a best practice to use an attribute that is unlikely to change when configuring the keytype map. For example, if configuring Keytype map for an Employee Filter Document Type Association, it's best to use “EmployeeID” or “SSN” attribute as a map attribute instead of “Department” or “LastName” which are likely to change.
-
Use Data sets when configuring User Entry Constraint Filter if available. For a better user experience enable Data sets when configuring User Entry Constraint Filter for attributes that have Data sets.
-
Configure Default Filter for Applications. If a filter will need to be accessed frequently by all users within an application, the filter can be configured as the Default Filter. This will be displayed by default when users access the application.
-
Use the “Add existing class” feature if a class already exists in another application. If you have several applications in your WorkView database that will have a common class in them, use the “Add existing class” feature to share the class across the applications. You may also need to create a “Shared Application” that will house all shared classes. For example, you have several applications that will have the “Employee”, “Customers” classes. You can share these classes across multiple applications allowing you to only maintain information in one place.
-
Configure class Display Name with singular noun. When a class is created, the class name is copied into the Display Name field by default. If the class name is “Employees”, the display name will also be displayed as “Employees”. This should be changed to a singular noun “Employee”.
-
Configure Class Titles for all Classes. Class titles are displayed in Internet Explorer's title bar and on the computer's task bar. Class titles should be configured preferably with an attribute value from the object. This allows users to easily locate items when multiple windows are open. For example, if 5 employee objects from the “Employees” class are open, a user will have to look at possibly all 5 windows to locate the correct employee. By configuring the class title with a value of “EmployeeName”, it will be much easier to find item for “John Smith” among 5 open windows. In addition, class titles are used as object names which are displayed in WorkView calendars, favorites, recently viewed items, Collaboration Workspace, etc.
-
Backup the database before using the “Purge” feature. Before purging history data and inactive/deleted objects, it is highly recommended that you backup your WorkView database. Please note that once items are purged they cannot be recovered.
-
Backup database/Class data before deleting Class data. Before using the Delete Class Data feature in WorkView Configuration, be sure to backup the database and class data for the class you are performing the action on. Please note that this operation cannot be undone.
-
Use UNC paths for WorkView System Paths. It is highly recommended that system paths (Style Sheet, Resource, and Backup) for WorkView be configured using UNC paths.
-
Do not point WorkView system paths to a path that has existing files. When configuring WorkView system paths, do not point the paths to a location that already has existing files for example, style sheets, templates, etc. Doing so can cause undesired results.
-
Copy and reconfigure WorkView system path when database snapshot is taken. In some environments, it is a common practice to copy the production database and make it a clone/test/development database. The WorkView system path should also be copied. After this is done, the WorkView system path in the clone database should be changed to point to the clone/test path. Note that you must not point system path from multiple WorkView databases to the same path. Doing so may lead to undesired results.
-
Share Actions and other items when possible. Depending on your business needs and number of applications available in your database, you may need to share items such as actions, data sets, etc so they can be used by several applications.
-
Use descriptive names for shared items. When creating shared items like data sets, actions, notifications, timers, keytype maps, sequences and calendars, use descriptive names whenever possible. For example a calendar configured for the “Help Desk” application could be called “Help Desk Calendar” instead of just “Calendar”. Note that when importing an application and you choose to use existing shared items, if an existing item for example, calendar, has the same name as another item being imported, the new application will use the existing item. Using a descriptive name for shared items will minimize the chances of this occurring.
-
Edit Template resources in Notepad. When editing resources for templates, the edit should be done in Notepad or any text editor that will not add additional formatting. Microsoft Word ®, for example, adds additional text/formatting that can cause the template to not be displayed correctly.
-
Configure Default Document Type for Classes. When users will need to attach documents to a class, it is highly recommended that you configure Default Document Types for the class. This adds a “WorkView Defaults” Document Type Group and lists the Default Document Types for users when doing an import. If this is not configured, (depending on rights) users may have to scroll through a long list of Document Types.
-
Enable the “Display Static document count on Documents tab” option. In situations where users need to act on objects based on whether or not a document is attached, it is recommended that the Display Static document count on Documents tab is selected. This reduces the number of mouse clicks it takes for users to see if a document is attached to an object. Also, if Dynamic Folders are configured for the class, a query is done when the user clicks the Documents tab. By enabling the Static Document count display, unnecessary queries will not be made to the database when users only need to see the static documents.
-
Enable the “Use objectname instead of objected for relationship attributes” option. This option controls how items are displayed in the History tab for relationship attributes. If the option is not enabled, ObjectID will be displayed in the History tab when a relationship attribute value is changed to a different object.
-
Verify user rights to configured items. When finished with configuring a WorkView solution, verify rights using the Master Security feature. Also, login as a test user belonging to different User Groups to ensure it functions as expected for that user or user group.
-
Add the WorkView server URL as a Trusted Site. Client machines that will access WorkView should add the server URL as a Trusted Site.
-
Import a few items to ensure items are imported correctly. When importing several objects using the Import Class Data feature it is best practice to import a handful of objects and verify that values are imported and mapped correctly.
-
Test all items after performing an Import/Clone/Copy. It is recommended that administrators test their solution after importing, cloning, or copying a WorkView application to ensure it functions as expected.
-
When formatting height and width settings for views, it is a best practice to use pixels. It is a best practice to use pixels to specify width and height settings in views instead of percentage. Using a specific pixel setting ensures the view will always display as designed and is not dependant on scaling of the view's size.
-
When formatting views, use multiple tables when configuring embedded filters, folders, and viewers. To ensure that all information on a view will print without incident, do not use one table on a view with all elements in that table. Create separate tables. When using embedded filters, folders, and viewers, it is best not to add them to a table. If tables are necessary for formatting purposes, these elements should be placed in tables with single rows and two columns.
-
Tabbed browsing should not be used. As a best practice, Internet Explorer's Tabbed Browsing Settings should be configured to use either of the following pop-up settings: Always open pop-ups in a new window or Let Internet Explorer decide how pop-ups should open.