The following document will assist with creating form templates. Form templates are service items in Kinetic Request that have elements that will get used over and over again in your other forms. These are useful for analysts to clone to create their own forms. They will often have empty sections where content would be included, but have many of the more technical areas already in place. Because of this, it is often useful for a more technical person to create the templates up front, allowing analysts to build the actual forms later, based on the templates created.
Creating a Form Template
To build a good template:
- Look at the various forms your company would like to build. Look for consistencies in those forms. These often are:
- Page Header Text
- Section Headers/Titles
- Requester Section
- Requested For Section (for ordering on behalf of someone else)
- Submitter Section
- Footer Section
- Create a section or sections where it is obvious to form builder where to add form specific content. This section could be called “Your Content Here”.
- Create Pages or Functionality that will be common, such as "Save as Draft" functionality.
- Create the tasks that will be common to all forms: An approval and then a record creation is the most common.
- Use a customized JSP to handle HTML header, page header and footer and other visual branding (See JSP section later in this document).
Note that an approval template has a very different structure:
- Approval Questions
- Review pane/frame that displays the original request
In a typical installation, the templates created could be similar to these:
- Simple Form Template-No Approvals
- Simple Form Template-One Approval
- Standard Form Template-One Approval & Create Incident
- Standard Form Template-Two Approvals & Create Incident
- Approval Template
These templates would then include a description about where/when to use them. It’s also a good idea to add an attribute to the template stating who the author is and the current revision. As a best practice, we usually set the “Type” of the form to be “Template”, so they are easily recognized when looking at list of forms.
Using a form JSP
You could also choose to start with a bundle. Bundles are web-based add ons to Kinetic Request which allow you to quickly create a web interface to your request catalog. Bundles include all of the files that you need to get started and come in different themes for styling and branding. A typical bundle includes a category listing page which allows the user to browse through the catalog, a display page for your service items, a submissions page which lists all the submitted, closed and pending requests for the user and a submission details page which shows all of the details and tasks for each request.
Create Your Own JSP
For most situations, it is best to create a copyof this default JSP file so that it can be customized to your own needs, without affecting the samples or simpler forms that use the default. Call this something similar to myITForm.jsp and keep it in the root of the /kinetic/ directory, unless a Bundle is being used, so the references to other files are still intact. Typically, only one customized JSP for all of the forms within a catalog, as they often share the same headers, style sheets, etc.
Then, on the “Advanced” tab of the Kinetic Request – Service Catalog Console, change the DisplayPage (JSP) value from the default JSP to the name of your copied JSP. Now, when the page is rendered, it will use your JSP instead of the default.
The illustration shows the use of JSP in a real-world situation. Everything outside the red boxes are all HTML in the JSP file. The center box is created using Kinetic Request. In this way, the form has a consistent, professional look and feel, while a non-technical person can easily create forms that fit in with the rest of the portal.
In addition to the static HTML in the JSP, it is possible for the developer to insert more dynamic content. In the example the “Example” is the name of the form. Different forms would automatically have different titles across the top. Many form text elements can be included in the static JSP content this way:
- Form Name
- Form Description
- Catalog/Portal Name
- User’s Login Name
Inserting this content in the JSP is done using the JSP “getProperty” tag <jsp:getProperty>. The Kinetic Request server bundles up the template information and user information into beans and attaches them to the JSP page for display (via the response object). All of the properties in these beans can be accessed and included this way.
Of course, these elements and many others can also be embedded into the form itself (content inside the orange box) via dynamic text elements in Kinetic Request. Making the determination of which strategy to use where is up to the developer, but knowing your options is half the battle.
The additional benefit of using a single JSP for the look/feel of the form is form maintenance. If the company changes their logo or color scheme, a JSP developer can update the form in a single place and all of the forms that use the JSP get updated, as well. This makes managing your service portfolio in the long-term less complex.
As you go forward building the JSP, be sure to reference the branding standards defined in the Delivery Model – Branding document. Often HTML can be cut directory from the pages referenced in that document and placed in your JSP.
Having your forms published on the web allows other standard technologies do much of the heavy lifting for you. With a little planning, many of your forms can “draw themselves” letting CSS handle the padding, margins, font, sizing and positioning.
Defining Your Styles
With CSS, it is best to take a top-down approach. The developer should style elements as much as possible at the highest possible level and handle unique situations at the element. All of the elements in Kinetic Request have their own CSS classes to make it easier to style in bulk. You can also create your own classes and apply them to the elements in the form.
A typical CSS setup could include:
- A style sheet (myCatalog.css) which includes html tag and CSS classes defined.
- This would be attached to the portal and reference by all of the forms in the portal. They would automatically inherit these properties.
- This file would define:
- Font family, font-size
- Background color
- Question padding & margins (questionLayer class)
- Question Label font-weight (often bold) (questionLabel class)
- Text padding & margins (dynamicText class)
- Section padding & margins
- Section headers (most sections have a title)
- To do this: Define your own class called sectionHeader and add this to the appropriate Dynamic Text elements in Kinetic Request
- TwoUp and ThreeUp styles
- This can be defined for sections where you want questions to show up in two or three columns rather than in a row.
- Add this class to questions you want to behave in this way
- TwoUp: float:left; width 47%;
- ThreeUp: float:left; width:31%;
- Then on the form itself, define items that may be specific to the form via the Kinetic Request styling capabilities:
- Again, use classes wherever possible for styling elements rather than doing them individually.
- Items that may be defined on the form include:
- Special fonts, font decoration, bolds, etc.
- Special indenting, margins
Many of the forms that Kinetic Data creates have no element-specific styling, letting styles set at the HTML tag or class declarations do all of the styling. This also leads to more cross-browser compatibility for your forms.