We just released a new version of our Visual Scheduling Widget, to offer you even more functionality to create powerful HTML5/JavaScript Gantt charts. With version 7.0 you will get a new view type that allows structuring resources depending on their skills.
At the beginning a word about the only breaking change of the new version: Please note that there is now no fallback of allocation property values to activity property values by default. For example, if an allocation did not have its own color, it was previously colored with the color of the activity to which the allocation referred. We decided to change the behavior since this improves the performance when updating activities. Also, many customers did not use these fallbacks at all. If the old behavior is needed for your application, you can re-enable it by setting the option decouplingOfAllocationPropertiesFromActivities to false.
A new view type – The Skilled Resources View
This is by far the most important enhancement of this VSW release. Production planning requires a wide range of skills from resources – regardless of whether they are machines or resources. Therefore, it is obvious that VSW also provides a view focused on this aspect of resources.
The new view of type SkilledResources is a special kind of resources view and shows resources grouped by skills. These skills can be defined by objects of type Skill. Analogous to all other VSW object types, you can handle these objects with the methods addSkills, updateSkills, and removeSkills.
Skill objects are displayed as rows – similar to resources. And the resources that belong to a skill are positioned below its row.
To define skills for a resource, the resource property SkillIDs can set an array of strings listing the corresponding skill IDs. Since a resource can have more than one reference to a skill object, it is possible that a resource is displayed multiple times, once for each skill.
Similar to how resources can have skills, allocations can have them as well. However, each allocation can have only one of them (see allocation property SkillID). This allows you to determine which skill of a resource is required or claimed for processing an activity.
In the new view, each resource row shows all allocations associated with the corresponding resource. That is, those allocations that have no skill assigned to them are also displayed. To make them visually distinguishable from the allocations with skill, their design can be altered by the option allocationBarDesignOfOtherSkill, for example, to tone down their colors (see option tonedDownOverlayColor) or to reduce their heights (see option reducedBarTopOffsetAndHeightScaleFactor) so that they are less noticeable.
Please note that the following limitations apply:
- Only the resources of the first level of the resource hierarchy are considered, i.e., the resources with no ParentID set; resources that have the ParentID property set are generally not displayed.
- Resources that have no skills assigned to them are ignored and not displayed in the SkilledResourcesView.
- An unknown skill ID set to a resource is also ignored.
The following figure gives you an impression of what such a view looks like:
Here we see on the left side a Resources View with five resources and four allocations assigned to them. In the Skilled Resources View on the right side of the figure above, we see three skills (welders, electricians, and plumbers) with the associated resources. Lisa is not shown in this view, because she has no skills. Peter is referenced by Allocation 1, which requires the skill of a welder (see the green bar). Since he is also an electrician, a second bar is displayed for Allocation 1 below the electrician skill (see the small pale bar). In a similar manner, Dave and Allocation 2 are treated. For Mary, the bar representing Allocation 4 is drawn pale for each skill because no skills are required for that allocation. Tina is listed in this view because she has a skill, regardless of the fact that she has not been assigned any allocation.
Streamlining and simplification of the API
For an application developer, not having to deal with APIs that are too complex or difficult to use makes their daily work easier. With this in mind, the following changes have been made.
- The prefix "PM_" has been removed from object property names and analogously "pm_" from option names. However, there is no need to change the existing code immediately as the former notation will continue to be supported for compatibility reasons. You can delete the prefixes in your application with a global replacement.
Note: Avoid using both notations for the same object property at the same time. For instance, if you have an activity object with the property Color set to "red", then the subsequent setting of the PM_Color property will have no effect – the activity bar will remain red – since the new notation takes precedence.
Please also make sure not to use property names for your own properties on the data objects that might conflict with ours. Our property names always start with a capital letter. Please use a prefix like a special character or "App_" or start with a lowercase letter. - The word "nonworking" is now consistently used in exactly this spelling in the documentation and can thus also be used in the application source code. In the code, it is still allowed to use "nonWorking" everywhere.
- The callback onLogWarning has now the new argument code. It is used to pass a warning code to help developers to understand why the warning has occurred. Possible codes are listed in the new enumeration WarningCode. As part of this enhancement, new warnings have also been included. In the future, the warnings will be added gradually.
- For reasons of symmetry, the allocation objects now also provide the BarPatternType and BarPatternColor properties in the same way as the activities.
- The callback canDrag now can handle a promise. This replaces the now deprecated options forced(Activity|Allocation|Resource|Entity)Allowed(Bar|Row)DragModes.
- To make life easier for developers, a brief description of the important option method has been included in the interface definition document, despite the fact that this method is actually implemented by the widget base class within jQueryUI.
Reducible complexity of bars to gain performance
Performance improvement is an ongoing topic for us. This time we have created a possibility to reduce the complexity of bars by a switch in such a way that an increase in performance can be achieved.
For this, the new property BarDesign has been created for activities and allocations. Here you can specify in great detail which elements of a bar should be displayed. The values of the BarDesigns enumeration can be combined by using bitwise OR operators for this purpose:
netronic.nVSW.BarDesigns = {
Simple: 0,
Default: 65535,
DefaultReduced: 16711680,
Entries: 1,
ComplexShape: 2,
// actually only Regular is changed to Rectangle when unset
Symbols: 4, Status: 8,
Constraints: 16,
ReleaseAndDueDateSymbols: 32, // ignored on allocations
Baseline: 64, // ignored on allocations
ProgressAndPredictedEnd: 128,
Text: 256,
TonedDownColoring: 65536, // see option tonedDownOverlayColor
ReducedHeight: 131072 // see option reducedBarTopOffsetAndHeightScaleFactor
};
Instead of specifying the design individually for each activity or allocation, you can also use the options defaultActivityBarDesign and defaultAllocationBarDesign for setting a default design.
If your code still contains the allocation property PM_BarDesign, please delete it. For the value 4 this is without after-effect, for other values which were marked as deprecated for a long time, changes to the application are necessary. If this is the case, please contact us in case of difficulties.
More flexibility in showing texts
There is a wide range of new options and properties for versatile design possibilities of texts in terms of content and formatting:
- New option applicationVariablesMap is for flexible replacements in formatted texts. The keys of this map serve as variable names that can be used everywhere where text can be formatted (see below).
- New text formatting properties BarTextFormat of Activity and Allocation objects, and TextFormat of TableCellDefinition objects.
For activity and allocation bars, the new options defaultActivtyBarTextFormat and defaultAllocationBarTextFormat allow to set default values for the text formats. In this context, it should be mentioned that the property InnerHTML of the TooltipTemplate object has been renamed to HTMLFormat for symmetry reasons. - Inside the new text formats, the new accessor […] for property accessor strings allows you to get access to array or map content with dynamic value inside the brackets.
- The formatting of dates and numbers can now be customized by the options intlDateTimeFormatOptionsMap and intlNumberFormatOptionsMap, respectively. See also the description of the built-in JavaScript object classes Intl.DateTimeFormat and Intl.NumberFormat.
Extended possibilities for the graphical representation
The following enhancements to options and object properties are related to the graphical representation:
- So far, when using the grouping feature of VSW, it was possible to color table rows depending on their grouping level. To improve usability, the new property TableColorVisibleInTimeArea for the GroupingLevelDefinition object allows coloring also the row in the time area with the same color as used in the respective table row.
The following figure compares the previous representation with the new one:
- When working with hierarchical structures of activities, resources, or entities, and the levels are all colored in the same color, it used to be very difficult to visually distinguish the different hierarchy levels within the table part. The new option separationLinesInColoredIndentation remedies this shortcoming. As you can see in the illustrations below, additional vertical lines help the eye to grasp the layers more quickly:
- The height and width of symbols in table cells are now definable by the new properties SymbolHeight and SymbolWidth for the TableCellDefinition objects.
- The new option applicationStyleDefinition expects a string to be injected into the HTML page containing the VSW object as content of an HTML style element. This can be used, for instance, for defining CSS custom properties.
Assuming this option is set to "#ganttWidget {--my-color: magenta}", the following is generated in the page:
<style>
#vsWidget
{--my-color: magenta}
} <style>
Now we can refer to this CSS custom property when defining the color of an activity bar, for example:activity.color = "var(--my-color)";
The smart thing about this approach is that you can easily change the styling via CSS without having to change or replace a CSS file. For more information about using CSS custom properties in VSW, please see also this blog post.
Of course, applications can also insert CSS styles themselves into the DOM tree. The advantage here, however, is that the variables from the applicationVariablesMap option can also be used via the notation ! - The color of the three dots in the table symbol column was always black. To improve the readability, the dots now are automatically colored white if the background color of the symbol column cell is a darker one. The next figure shows a comparison between the old and the new representation:
- The height of the curve panes can now be globally altered by the new option defaultLoadCurvePaneHeight or for a specific resource by the resource property LoadCurvePaneHeight.
Features in previous releases
