This section contains an overview and describes these steps:
» Step 1: Create the Fluid Component
» Step 2: Create the Fluid Page
» Step 3: Add Fluid Pages to the Fluid Component
» Step 4: Update PeopleCode References
» Step 5: Update, Remove, or Redesign Unsupported Control
» Step 6: Enable Search Pages
» Step 7: Adjust and Finalize Layout
» Step 8: Implement Responsive and Adaptive Behaviors
Understanding Classic PIA to Fluid Conversion
Before attempting to port a classic page for fluid deployment, the designer must carefully rethink the user experience of the classic page you are porting. Many user experience decisions that worked well in classic mode do not fit into fluid patterns for navigation and design. While there may be some straightforward cases when a classic component can be converted using the exact steps mentioned below, you are likely to encounter several cases where redesign is preferable to a direct port.
Redesigning may be the most suitable option because the fluid user experience differs from the classic user experience in significant ways.
TABLE 1. DIFFERENCES BETWEEN CLASSIC AND FLUID
Difference Description
Layout |
The layout of a component
developed for the fluid deployment needs to display correctly when viewed
from any supported device. Since fluid is supported on mobile phones and
tablets, this works out to a very large set of devices (see Appendix). To
make best use of the available space, a fluid layout must automatically
reposition page controls depending on the available space. |
User interaction patterns |
The pattern for user
interaction on a mobile device is different from the pattern for interaction
with a keyboard and a mouse. Additional factors have to be taken into
consideration such as touch screens in addition to mouse clicks, and slide in
addition to drag. An obvious example is that buttons need to be larger in
order to provide a suitable touch target. In addition, the location of the
back button, menus and actions in the UI need to be consistent with patterns
followed by mobile operating systems to provide the expected user experience. |
User expectation |
The user expectation from
mobile devices is different. The changed style of usage must be taken into
consideration when designing for a mobile device. For example, a mobile
application may be used while on the go, and therefore must be designed for a
shorter attention span. |
Step 1: Create the Fluid Component
To create a fluid component:
1. Open the classic component you want to port to fluid, select
File > Save As,
and enter a new name
Though not mandatory, it is recommended to adopt a naming convention for fluid components (and pages). In this
case, because it is the HR_BUSINESS_UNIT component being ported to fluid, and FL is added to the name to indicate “fluid.” For example, HR_BUSINESS_UNI_FL.
2.
Select Yes on the dialog
box when prompted
to save a copy of component PeopleCode from the classic component.
Since fluid is mainly
a UI update, existing PeopleCode logic, records, and application packages
ported from a classic component will continue to work
with the fluid component.
3. Open the Component Properties dialog box, and on the Fluid tab, select
Fluid Mode.
4. You will also want to enable
the Fluid header toolbar options
as per your requirements.
Refer to PeopleSoft Online Help for further details.
See PeopleTools 8.54:
PeopleSoft Fluid User Interface Developer’s Guide, “Defining Components for Fluid Applications.”
http://docs.oracle.com/cd/E17566_01/epm91pbr0/eng/psbooks/psft_homepage.htm
Step 2: Create the Fluid Page
To create a fluid page:
1.
Select File > New, and select Page (Fluid) from the New Definition dialog box, and click OK.
.
2. Select a layout page from the
Choose Layout Page dialog box.
To minimize your effort, pick a layout page that is the best match for the page that you are porting. In our example, the page being created is a simple, one-column layout, so using the layout: PSL_APPS_CONTENT is appropriate.
For more information on layout pages, see Appendix 3: Layout Pages.
3.
Save the fluid page.
You will be prompted
to save the fluid page. It's recommended to adopt a naming convention that will indicate
from which classic page this fluid page is being ported. In this case, the page
is named BUS_UNIT_TBL_HR_FL since the
classic page is BUS_UNIT_TBL_HR.
Some layout pages provide PeopleCode in the page Activate event. When prompted, you should choose to save a copy of PeopleCode with the newly created page.
4. Clone the classic page you are porting,
setting the page properties so that the page is now a subpage.
Select File > Save As. Select a page name indicating which page classic has been ported. In this case, the subpage is named BUS_UNIT_TBL_H_SBP.
When prompted,
do not copy the PeopleCode to a subpage.
You can copy the PeopleCode manually at a later point into the main page. Page Activate
PeopleCode on subpages is not executed.
Open Page Properties, and set the
Page Type for the newly created page as Subpage.
It
may be required to create multiple
subpages from a single source page. Some layouts may have multiple areas into which fields can be added. If, for example,
you use a two-panel layout,
you would have two separate
areas on which to place content - one to populate the folding left panel and a second area for the actual content of the page. This will force you to split the
source page into two subpages and distribute
the page controls as desired. In this case you can either clone the page several times and delete the non-required
fields, or move the fields into newly created
subpages manually as needed.
5. Insert the subpage(s), into
the main layout page.
The layout page will have one or more areas into which fields can be added. Insert the subpages into the appropriate areas.
Copy the page Activate PeopleCode from the original page into the fluid page.
Now that all the fields of the original page have been moved into the fluid page, move the PeopleCode from the original page to the fluid page Activate event. This step must be repeated for every page that is in the component. If there are subpages on the page it may be required to clone the subpages as well so that the fluid component has no dependency on any classic component. It’s not recommended to share a subpage between a fluid and a classic page since some page field level properties are not cross- compatible between fluid and classic mode.
If your component used the PeopleTools toolbar action buttons for save, correct history, and so on, these do not automatically appear on the fluid converted component. You will have to add buttons to the bottom of your pages for each of these actions and assign toolbar actions to them as shown in the screenshot below.
Creating a footer page is an easy way to add the required buttons to every page in the component. A footer page is a new page type with PeopleTools 8.54 that, if used, is automatically shown at the bottom of all pages in a fluid component. For example, adding the footer page PT_FOOTER_SAVEONLY to your component will add the Save button on the bottom of every page in the component when it is rendered.
Step 3: Add Fluid Pages to the Fluid Component
In this step you add the new fluid pages to your cloned component, and remove the old ones.
|
|
If the previous step was performed correctly, the component buffer
structure will remain unchanged for all your existing PeopleCode, apart from page names and component name references. For example:
Step 4: Update PeopleCode References
If there is PeopleCode in which the classic page names or the classic component name is referenced, update the references to point to the new fluid names to avoid PeopleCode errors.
Step 5: Update, Remove, or Redesign Unsupported Controls
Several controls and constructs that are valid in classic PIA are not intended for use in a fluid experience. You will need to remove or redesign these controls. This section discusses common considerations with such controls.
Help Text
Currently, the popup help text does not display in fluid mode.
However, a similar appearance can be generated using the popup group box type. Set on the Fluid tab for a group box, selecting Popup for Group Box Type.
Scroll Area
Currently, scroll buttons for next and previous are not yet supported in fluid
scroll areas.
However the component buffer has the data and developers can implement their own mechanism to navigate the data.
Classic Grid
Putting a classic grid in a fluid mode component will result in a JavaScript error. Replace classic
Grid Layouts with the fluid Original Flex Grid Layout.
PeopleTools 8.54 introduces several new grid styles,
but the Original Flex Grid Layout option
is closest to the classic grid appearance.
Update classic grids to flex grids by changing the Grid Layout on the Use tab of Grid Properties dialog box.
Field Style Property
The classic page field Style property on the Type tab should be moved to the Default Style Name page field property on the Fluid tab.
Style (Type tab)
Default Style Name (Fluid tab):
HR Core Navstack
(Enterprise or Shared Component controls)
The HR Core navstack is used in several self-service pages to return to the referring page.
Navstack is not supported in fluid mode.
Remove the control and all PeopleCode referring to it. The Back button on the fluid banner provides the functionality of HR Core NavStack.
HGrid
The HGrid is used in manager self-service pages to represent the reporting
structure of employees.
The HGrid is not supported in fluid mode. Remove the widget or redesign it.
Toolbar
The toolbar is used in products such as Recruiting and ELM to present page level actions to self-service users. Pages using the toolbar may require you to write CSS to realign the content depending on the icons used.
Step 6: Enable Search Pages
By default, fluid mode allows pivot grids and PeopleSoft Search Framework to be used to provide search features for a component.
See the product documentation for PeopleTools
8.54: Fluid User Interface Developer’s Guide, “Defining
Components for Fluid Applications,” Working with Search Pages
http://docs.oracle.com/cd/E17566_01/epm91pbr0/eng/psbooks/psft_homepage.htm
Alternatively you can create your own custom fluid page to provide the search functionality.
Step 7: Adjust and Finalize Layout
At this point, the component is usable in fluid mode. The next step is to optimize the look and behavior.
You first want to identify and correct any layout inconsistency. Fine adjustments to the layout can be made by using CSS.
The PeopleSoft delivered stylesheet, PSSTYLEDEF_FMODE, provides numerous commonly used styles so that most of the time developers can adjust the layout without
having to create
their own stylesheet. An extract of some
of the commonly used styles
in the fluid stylesheet is provided in the appendices of this document.
For example, to align the "OR" in the screenshot above to a more desired place above the second input box, you can apply the provided style psc_label_filler to the control using page-field properties.
It is also possible to attach your own stylesheet to the component using the PeopleCode construct:
AddStylesheet(Stylesheet.<STYLESHEETNAME>);
More information on the AddStylesheet function is provided in the PeopleCode Language Reference:
See the
product documentation for PeopleTools
8.54: PeopleCode Language Reference, "PeopleCode Built-in Functions and Language Constructs," PeopleCode Built-in Functions and Language Constructs: A, AddStyleSheet
Step 8: Implement Responsive and Adaptive Behaviors
The final step in the process is to make the page adapt to the available display area. There are a couple of ways to accomplish this.
The first method is applying responsive design principles using media queries. PeopleTools provides a few media queries in the default fluid style-sheet, however it’s also possible to write your own media queries and to attach them to the component using the AddStylesheet function.
The second method is by using adaptive
design features provided by the PeopleTools system. PeopleTools categorizes devices
under small, medium,
large and extra large form factors based
on the detected device w dth
(measured in pixels). Fluid pages and page controls have an additional set of properties which allows styles to be added conditionally based on device type.
You can use these options to override the styles applied at the page field level, according to the width of the device as detected by the server. If needed, you can have different styles applied to a control depending on what device accesses a component.
In addition, controls or groups of controls can be suppressed entirely for a particular a form factor by selecting the appropriate checkbox in the Suppress On Form Factor group box, allowing different sections on a page to be served depending on device type.
For more information, see the production documentation for PeopleTools 8.54: Fluid User Interface Developer’s Guide, "Creating Pages for PeopleSoft Fluid Applications," Setting
Properties for Fluid Pages
Appendices
These appendices contain additional information that may be helpful for certain steps in this document. This document contains these appendices:
» Appendix 1: Fluid Target Devices
» Appendix 2: External Resources
» Appendix 3: Layout Pages
» Appendix 4: Delivered PeopleSoft Style Classes
» Appendix 5: Common Terms Related to PeopleSoft Fluid User Interface
Appendix 1: Fluid Target Devices
When building a Fluid page, it's important to understand that there is a wide range of target devices accessing a page.
Mobile devices running Android and iOS are supported targets for fluid components in addition to the desktop operating systems that were supported by the previous versions of PeopleTools.
The primary target device for classic pages is desktop PC's. In the past, a majority of PC’s had a resolution of 1024 x 768 or 800 x 600, a physical keyboard, and pointing device (mouse).
See the following website for screen resolution statistics for metrics regarding the percentages of website visitors using a screen resolution of at least 1024 x 768.
http://www.w3schools.com/browsers/browsers_display.asp
Note that the Apple iPad does follow this trend with a device independent resolution of 1024x968, though its default viewport is standardized differently.
This makes development considerations relatively simple. A single layout that looks and behaves in an acceptable way on devices with these common resolutions for PC was sufficient to cater to all supported devices for PeopleSoft. There would be some scrolling and whitespace inconvenience on the minimal set of devices having other resolutions.
Pointing devices such as a mouse and track pad which are common to PC devices are accurate in comparison with touch screens, so the UI for the PC can use small icons and links which take up less screen real estate. This allows designers to fit more information on the screen.
Over the years, higher resolution displays, both small and large have started to become more common and as technology evolves, productivity tablets running PC OS's but with a smaller screen and touch interface are becoming increasingly available. In addition, personal devices such as phones and tablets running iOS and Android an Windows Phone are increasingly being used to access company applications.
iOS
Apple manufactured mobile devices (iPhone, iPad, iPod touch) run iOS.
As such, there are a fixed number of devices, which means a fixed number of resolutions to support. The following are some screen dimensions (in DIPs):
» iPhone and iPod touch: 320 x 480
» iPad: 768 x 1024
Android
Android is a mobile OS which is maintained and developed by Google. Unlike Apple, Google doesn’t control the hardware on which Android is installed. As such, the device types, screen size, and hardware on which Android can be installed varies greatly.
The following links provide details on common screen sizes and resolutions for Android devices:
http://developer.android.com/about/dashboards/index.html#Screens http://opensignal.com/reports/fragmentation.php
Appendix 2: External Resources
A good understanding of HTML, CSS and JavaScript is recommended in order to make the best use of fluid functionality. PeopleSoft Fluid User Interface is built on these languages and it fully exposes these underlying technologies to the developer.
A lot has been written on how to design high quality mobile friendly user interfaces. HTML and CSS are commonly used technologies for delivering native-like apps on mobile devices.
This section lists a selection of articles relating to the topic of designing for mobile devices and designing pages that look and behave like native apps across multiple devices sizes.
Information on HTML5, Responsive Web Design, and Adaptive Design
http://en.wikipedia.org/wiki/Responsive_web_design http://en.wikipedia.org/wiki/Adaptive_web_design
http://www.techrepublic.com/blog/web-designer/what-is-the-difference-between-responsive-vs-adaptive-web-design/ http://en.wikipedia.org/wiki/Display_resolution
http://alistapart.com/article/dao
http://www.webdirections.org/resources/john-allsopp-the-dao-of-web-design-revisited/ http://www.creativebloq.com/responsive-web-design/get-started-5132987 http://www.alistapart.com/articles/responsive-web-design
http://www.html5rocks.com/en/ http://www.w3schools.com/css/css3_intro.asp
iOS User Experience Guidelines
http://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/WindowsandVi ews/WindowsandViews.html#//apple_ref/doc/uid/TP40009503-CH2-SW15
Android User Experience Guidelines
http://developer.android.com/guide/practices/screens_support.html http://opensignal.com/reports/fragmentation.php
http://developer.android.com/about/dashboards/index.html#Screens
Windows User Experience Guidelines
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj206974(v=vs.105).aspx http://blogs.msdn.com/b/b8/archive/2012/03/21/scaling-to-different-screens.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx http://msdn.microsoft.com/en-us/library/windows/apps/hh465349.aspx
Appendix 3: Layout Pages
Layout pages are a concept
introduced with fluid user interface development. The use of layout
pages is comparable to that provided
by the “New Slide template” functionality of Microsoft PowerPoint.
By cloning a PeopleSoft delivered layout page, you are given a tested starting point so that you do not have to design every new page from scratch.
PeopleSoft will periodically provide new layout pages to satisfy other use cases, and customers can add to this library by creating new pages of type Layout Page in Application Designer.
This section describes some examples of delivered PeopleSoft layout pages.
For more information on layout pages, see PeopleSoft Online Help > PeopleTools
8.54 Fluid User Interface
Developer’s Guide, “Creating Pages for PeopleSoft Fluid Applications,” Creating
the Primary Fluid Page
PSL_APPS_CONTENT
PSL_APPS_CONTENT is a one column layout template.
HCSC_2PNL_LO_LFL
HCSC_2PNL_LO_LFL is a two panel layout with a left panel that can be hidden/shown by the user.
(Delivered by HCM applications)
HR_ESS_LAYOUT_LFL
HR_ESS_LAYOUT_LFL is a layout with employee photo header for self service
components in HCM. (Delivered by HCM
applications)
Appendix 4: Delivered PeopleSoft Style Classes
This table describes some commonly used style classes delivered in the fluid style sheet (PS_STYLEDEF_FMODE).
TABLE 2. COMMONLY USED DELIVERED STYLE CLASSES
Style Class Name Category Construct Description
ps_hidden psc_hidden
ps_inline
Display
Any Set display attribute to none so element is not displayed.
Sets display
attribute to INLINE on
psc_inline psc_display-inline
Display
Any
element (preferred to use psc_display-inline).
psc_display-inlineblock Display
psc_display-block Display
Any Set display attribute to INLINE- BLOCK on element.
Any Set display attribute to BLOCK on element.
psc_float-left psc_float-right psc_float-none
Layout
Any Floats the element left, right or none (respectively).
psc_label_filler Layout
Group Box
(Layout)
Used turn surround field(s) which do not have labels
on the left side of the control. Reserves space on the left to provide
alignment of fields with labeled fields (default 33%).
psc_width-<num><unit> Layout
psc_nolabel
Label
psc_label-none
psc_label-invisible Label
Any
Field Grid
Field Grid
Sets the
width of the element to num units,
where num is a number between 1 and 100 and units is either px, em or pct.
Forces all
ps_box-label elements to be hidden from rendering (no space reserved).
Sets all
children ps_box-label to INVISIBLE (space is still reserved).
psc_label-width<num>pct Label
Fields or group
box set to
.psc_label_filler
Sets the width of ps_box-label to num pct, where num is a number between 1 and 100.
psc_label-width<num>em Label
Fields or group box set to
.psc_label_filler
Sets the width of ps_box-label to num em, where num is a number between 1 and 50.
psc_control-width<num><unit> Control
Fields
Sets the
width of the inpu control similar to psc_label-width. Num is a number between 1
and 100, unit is em, px or pct.
psc_control-height<num><unit> Control
Fields
Sets the height of the input control. Num is a number
between 1 and 100, unit is em, px or pct.
psc_column-2 Layout
Group box containing Fields
Prepares container to include columnar items. Overflow
is hidden so that container contains the “floated” items.
psc_column-3 Layout
Group box
containing fields
Prepares
container to include columnar items. Overflow is hidden so that container
contains the “floated” items.
psc_columnitem-1of2
psc_columnitem-2of2 Layout
Any within psc_column-2
Specifies the width within a psc_column-2 of either
50%, 100%
of 100% respectively.
If the width
of the viewport is less than 767px, both styles use 100%.
psc_columnitem-1of3 psc_columnitem-2of3 psc_columnitem-3of3
Layout
Any within
psc_column-3
Specifies the width within a psc_column-3 of either
33%, 66%
or 100% respectively.
If the width
of the viewport is less than 767px, all three styles use 100%.
psc_columnitem-auto Layout
Any within
psc_column-2 or psc_column3
Does not specify an explicit width of a column items
but is floated.
psc_primary Color
psc_selected Color
Button
Button Link
Radio Button
Used to distinguish a button as the primary action on
a page (there should only be one with this color at any time on the page).
Used to
distinguish the selected or ACTIVE button/hyperlink/radio button in a
collection of button bar collection (see later).
Appendix 5: Common Terms Related to PeopleSoft Fluid User Interface
The following table provides definitions for some of the common terms that are used in this paper as well as throughout the industry when discussing responsive design and adaptive design.
TABLE 3. COMMON TERMS
Term Definition
Adaptive Design |
A page design that uses properties published by the device's
browser to the web server to serve a layout as appropriate for the device
properties. Note that
because of the way that CSS pixels, zooming, and viewport properties work on
mobile devices, multiple fixed width layouts can be as effective as fluid
layouts for building native-like websites for devices. |
CSS Pixel |
A
relative unit that is used when writing CSS. For example, the HTML below generates a div
element of width 1 CSS Pixel: <div style='background-color: red; height: 1px;
width: 1px; '></div> As a result of how density independent pixels behave, when
a page containing the code above is opened on an original iPhone and on an
iPhone 4, the size of the element is rendered visually exactly the same on
both devices though the iPhone 4 has double the resolution. 1 CSS pixel = 1 DIP when zoom is 100%. |
Term Definition
|
However,
this relationship changes when the zoom level changes. The only unit we can
access from CSS is CSS pixels. |
Device Height/Width |
The height/width of the device in density
independent pixels. Because
content in PeopleSoft scrolls vertically, device width usually is the
deciding factor fo layout of responsive pages. |
Density Independent Pixel (DIP) (sometimes
referred to as Device Independent Pixel) |
A reference unit introduced and supported by mobile OS’s to
reduce the complexity of coding for multiple device sizes. For
example, the original iPhone has a physical resolution of 320 x 480 at 163
PPI. On the original iPhone, 1 DIP = 1 physical device pixel. The iPhone 4s
has a physical resolution of 640 x 960 at 326 PPI. On the iPhone 4S, 1DIP = 4
physical device pixels. The result
is that though the iPhone 4s has four times the number of hardware pixels in
comparison with the original iPhone, both phones have the same number of
density independent pixels. |
Device Pixel (or Hardware Pixel) |
The smallest physical element of the display
hardware. |
Device Pixel Density |
The
number of hardware pixels represented by a density independent pixel on one
axis. The first
generation iPhone has a device pixel density of 1 (1 pixel = 1 DIP
horizontally). The iPhone 4 has a device pixel density of 2 (1 pixel = 1
DIP). So while
the iPhone 4 has twice the number of physical pixels in comparison with the
first generation iPhone, both devices have the same number of density
independent pixels. |
Fixed Width Layout |
The layout of the page doesn't adjust itself when
the browser is resized. For
example, the visible content of the page wrapped within a container element
that has its width set to a constant. |
Fluid Layout |
The page content flows to occupy the available
space when the browser is resized. |
Media Query |
A CSS feature that enables developers to selectively enable
and disable styles based on viewport, device, and browser properties. |
Pixels Per Inch (PPI) |
The number
of physical pixels under one inch of the device on one axis. The same measure
is referred to as dots per inch or DPI for printer devices. With CSS media queries, DPI may be used to
refer to PPI on pixel screens as well. |
Resolution |
The
resolution of a display is the number of pixels on each dimension. It is
usually quoted as Width x Height. For example, a display with a maximum resolution of 1920 x
1080 is composed of 2073600 device pixels. Resolution may be quoted in
physical pixels or density independent pixels. |
Responsive Design |
A page design that uses CSS media queries to alter its
layout on the fly based on the properties of the viewport. |
Viewport |
The
area of the device display that is available to the web page to show
information. On mobile
devices running a modern browser, developers can configure the default zoom
and window size (including the size in CSS pixels) of the web browser’s
viewable area by using the viewport meta tag. If a
viewport is not specified, default properties are assigned to the viewport
based on which OS is being used. Default
viewport details for iOS and Android: http://developer.android.com/guide/webapps/targeting.html http://developer.apple.com/library/ios/#documentation/AppleApplications/Reference/SafariWebConten t/UsingtheViewport/UsingtheViewport.html#//apple_ref/doc/uid/TP40006509-SW27 |
Validation and Feedback
This section documents the real-world validation that this red paper has received.
The approach described in this document was tested on several delivered PeopleSoft components.
Customer Validation
Oracle is working with PeopleSoft customers to get feedback and validation on this document. Lessons that are learned from these customer experiences will be posted here.
Field Validation
Oracle Consulting Services has provided feedback and validation on this document. Additional lessons that are learned from field experience will be posted here.
No comments:
Post a Comment