Overview and Scope of Personalization and Set Up Functions Per User Type
There are two main user types for set up and personalization functions: an administrator (application admin, system admin, content admin), and an end-user. An administrator sets up applications, systems or content for end-users to use. An end-user personalizes his or her own content, layout, or detailed data display of the applications he/she may use.
For each user type, the personalization or set up functions that can be performed may be scoped across many applications (or suite) or be for only one application. Based on the user type and the scope of functionality, there are several design considerations that can be made to make the user experience (administrator or end-user) consistent and most effective based on the task at hand.
For instance, administrative functions for setting up content per domain may be several flows combined into one stand alone application or module. The administrator works in an "abstracted mode" to configure all the necessary functions that will affect content options and possibilities that pertain to many applications. Once the set up tasks are completed, he/she may open up an affected application and see that the set up functions indeeed are configured as expected.
On the other hand, an end-user may want to personalize the display of a table on a specific page within an application. He she may have some direct manipulation techniques for changing the display while the object is still in view (sorting a column of data in a table, say) or depending on the complexity of the display options, he/she may navigate to another page to update the display. When the changes are made, he/she navigates back to the page with the table to see that the changes are correct.
Like mentioned above, these different design considerations may be made given the specific task, and/or user needs, but overall this guideline should provide a consistent experience within and across these types of personalization and set up functions.
Administrator: Application Administrator, System Administrator, or Content Administrator
There are several different types of administrative users. Each administrator may have a slightly different
role, but in general perform a similar type of task: setting up features, functions, or UI's for other
end application users to use. Depending on the size of the company, these functions may be performed
by the same individual.
For instance, an application administrator may set up the entire application suite for a company. He/she may install several applications and configure each to fit the business needs and rules of the company. He/she may also set up a companies system such that legacy data (from other applications or database systems) are connected with the current applications he/she is configuring.
A system administrator may perform detailed application system functionality tasks such as setting up users, security rights, and priveledges for an application suite.
Lastly, a content administrator may set up content for an application or suite of applications based on larger business process flows and/or domain specific needs. These set up functions may affect what UI and content and end-user can see and/or use. For instance, he/she may set up "templates" or common content that can be used by other end-users.
Application End-User
An application end-user performs personalization functions that are specific to only him/herself. These
personalization settings do not affect any other users. These types of
personalization functions may range from setting a date preference to be seen one way throughout all his/her
applications or changing a page layout to fit his/her specific needs. See below for detailed examples.
The image below outlines all the different set up or personalization functions based on user type (administrator or
end-user) and the scope of the function (across applications or for a single application only.) There are some
parallel functions where an administrator may set up certain features for end users that then the end users
can personalize for themselves. When designing these UI's it important to consider the relationship and consistency
between the two different user types.
Overview and Scope of Personalization and Set Up Functions Per User Type
Definition and Examples
An administrator must be able to set up or install the entire suite of Oracle Applications at a
customer site. He/She may also need to hook up legacy systems to this new suite of applications to maintain
data at a company. The set up or installation may be relatively simple or quite complex depending on the
number of applications being installed, the integration between each of the applications and the databse,
and potential integration with other
non-Oracle applications or legacy systems.
Once the suite is set up, additional contextual information may need to be provided per application domain before the applications can be used (see "Content Set Up per Domain" below for more details.) Also, the administrator needs to set up users, security and priveledges of the entire application suite. This is typically done in a separate application than the installation set up.
User Profile Details
These administrator users may be system administrators or application administrators depending on the nature of the
task. The users are familiar with setting up systems, and installing software. They are technically saavy and
computer literate.
Depending on the size of the company, the function of setting up a system may happen very infrequently, or more frequently of the user falls under a consultant category. Setting up users, security and priveledges may be more of a routine task as new employees come to the company and/or job changes occur.
Current Design Status
Oracle provides an application called iSetup to install the Oracle Application Suite. This UI architecture of this
application is essentially a large "wizard" that guides the administrator through many steps to setting up the
suite. It handles the common installation cases, but does not necessarily provide detailed set up needs for
each specific application. These detailed configurations are either handled through existing Forms applications
or in possible new HTML/BLAF set up modules per content domain (see more information below under Content Set Up
per Domain).
Setting up users, groups, security and priveledges for the application suite is currently handled through Forms. These functions potentially will migrate to an HTML/BLAF application. Other similar UI's exist outside of the application domain to set up users, security and priveledges (Modules within the in the collaboration suite, and Oracle Warehouse Browser, in the BI domain, have some similar features that may be applicable.) These UI's may be evaluated to see if their designs match the requirements needed in applications as well.
Technical Notes
None.
Definition and Examples
An administrator needs the ability to set up and modify the structure and potentially content of many applications
or an application based on several different critieria: function level, verticalization level, localization level,
site level, organizational level, responsibility level, seeded user level. Based on these settings, certain
tabs may appear in one application and not in another, certain types of actions may not be accessible
to certain users, etc.
For example, based on a verticalization setting, a suite of HR applications may be tailored for a government setting versus the private sector. Another example may be a responsibility setting may allow a user to view an object (that potentially appears in different applications, but not update the object.
User Details
The administrator of this type of set up may be specialized (based on the set up type), and/or specialized
based on the domain of the application(s). For instance, the administrator who is setting up the localization settings
for specific applications should be well versed in the countries laws, policies and business practices to make the
correct configurations. Likewise, the administrator who sets up responsibility settings should understand the different
user types to ensure the proper content and functions are exposed given the users role.
Current Design Status
The OA framework provides levels of administrative tasks through their "personalization" framework. It has not
yet been reviewed in detail, but from first glance takes the approach of page specific set up. It is unclear how
the more global settings (localization, verticalization, responsibility, etc) are handled since these set up
tasks need to be able to be applicable to not only a single page, but possibly multiple pages of an application, a full
application and/or across many applications.
For more information (internal Oracle use only) regarding what currently exists in OA, see: Introduction to OA Personalization Framework. For further details, see OA Framework (select "Developer's Guide", then "OA Personalization Framework (formerly known as OA Customization/Configuration Framework)" from center contents of page.
Technical Notes
Changing the current method being deployed in OA may have large technical impact. This is not known yet.
Definition and Examples
An application administrator needs to be able to set up a general preferences UI that allows an end user
to change generic formatting configurations, and/or common display options based on his/her personal preference.
The administrator needs to ensure that these settings are applicable across applications and hook up properly
to the specific data or display in the UI which is affected.
For example, there should be a UI that allows an administrator to set up proper date formats (per locale). These date format options should then be displayed in the end-users general preferences page such that each user may modify to his/her liking. Another example would be the ability to an administrator to set up a generic preference allowing end-users to set the default number of rows he/she would like to view in every table (across applications.) In this scenario, the administrator would have to set up all the valid row number options and ensure that when the end-user selects his/her preference, that all tables across applications are affected for that user alone.
User Details
The administrator of these functions needs to be aware of common content that may be displayed across applications,
and this content may have varied format options or display options.
Current Design Status
Unclear where this functionality is set up, and/or what the end customers capabilities are of adding on to it.
Technical Notes
Not known.
Definition and Examples
A content administrator may need to perform set up functions that span a family of applications within a domain.
For instance, it may be necessary to set up financial information that will be used by all financial applications or,
say, assign human resources organizational information that will affect many HR applications.
User Details
The administrator of this type of functionality is typically a "content" administrator and is an expert in the
domain of the functions that are being set up. He/She needs to be well aware of business
processes and specific contexts that surround this domain.
Current Design Status
Since these types of functions span multiple applications, it would be best if it was contained within an application
of it's own, or a more generalized "set up" application. There may be several "modules" of these types of functions,
or if possible, all the functions could be grouped into one set up application such that the user can perform
multiple set up functions (per application domain) at once. It is important, though, to analyze whether the
same content administrator is performing all the functions or just some of the functions, and another administrator
is responsible for others. This may determine the scope of the applications functionality. Another design consideration
is the frequency in which the set up functions are performed. Grouping high frequency tasks (which are similar) will
prevent the user from having to "hunt and peck" to find where to perform the tasks.
Technical Notes
Unclear where this functionality is currently administered.
Definition and Examples
NEED EDITS HERE
An application administrator needs to be able to set up a preferences UI that allows an end user
to change application specific formatting configurations, and/or common display options based on
his/her personal preference.
The administrator needs to understand the specific applications functionality, and what features
need to be personalized by the end user as a preference. He/she also needs to ensure that these
settings are hook up properly to the specific data or display in the UI which is affected.
For example, there may be a UI that allows an administrator to set up preferences that only apply to the Projects application such as providing the ability for the end-user to personalize the way in which status information of a project is displayed.
User Details
The administrator of these functions needs to be aware of the application specific content that
should be able to be personalized by the end-user.
Current Design Status
Unclear where this functionality is set up, and/or what the end customers capabilities are of adding on to it.
Technical Notes
Not known.
Definition and Examples
A content administrator needs the ability to set up specific content for an application that then
becomes available for the end-user to view, manipulate, manage, etc. This content does not
span applications, but is typically specific to one application.
Application specific content setup may include making settings and in some cases creating objects/data that are necessary for the application to function properly. Updating setup items may happen quarterly (e.g. for consolidation), annually (e.g. for tax code), or even less often.
User Details
These functions are typically performed by a content administrator, but may also be performed by an
end-user with greater security power than other end-users. This user typically has greater functional
and technical knowledge of the application. For instance, the user may be a consultant
of a company that performs the tasks when the application is installed. He/She sets up the necessary
application specific data and content then releases the product to the rest of the company.
On the other hand, this user may be an end-user of the application, but given his/her role in the company may also perform these administrative tasks. For instance, depending on the company, there may be a project manager function that not only manages the day to day progress and status of ongoing projects within his/her company, but also performs set up tasks for all projects managed throughout the company. He/she may set up budget templates that all projects can use, and then when he/she is managing his or her own project, he/she selects on of the specific templates as a budget to use for the specific case.
Current Design Status
Some different UI models are used to organize and display this type of functionality based on the
user types, the scope of the functions and the frequency of use. For instance, the functions may live
within the application itself as a primary tab or horizontal navigation section depending on the
scope of the functions. If the scope is applicable to the entire application, it may be more appropriate
to have the function at a tab level. Using a tab has drawbacks, though. It's important to consider the
primary activities/objects of the application and if the setup functionality is something that is done once,
initially, and then rarely, therafter. If so, then possibly the tab is not the appropriate location for the
fucnationality. Also, with a limited amount of horizontal space in the tab bar, it
may be important to reserve the tabs for the primary activities of the application.
If the scope is specific to the content within a tab, and performed more frequently, it may be best to have the functions within a horizontal navigation section closely associated to the object(s) that are affected.
It may also be possible to isolate all the Setup functionality and put it into a separate application/module, particularly if the users who deal with the setup tasks are different than those who normally use the rest of the application. Putting the Setup functionality into its own application/module keeps the activities cleanly separated and helps the administrator focus on the task at hand rather than cluttering up the main UI with interactions that are not part of the normal course of events of using the application.
Technical Notes
Today, this type of set up functionality is seen as:
Definition and Examples
An application administrator needs the ability to customize the menu structure or tab/navigation structure
of an application. Typically this type of set up is based on an end-users responsibility priveledges.
User Details
The administrator needs the ability to turn on and off tab/navigation elements per different levels of
end-user responsibility settings.
Current Design Status
Unclear if this functionality for ERP and CRM applications is part of the OA "Personalization" framework. See
above under Cross Application - Set Up Structure and Content of Applications based on Org, Site, Locale, Responsibility, etc..
Unclear whether or not other divisions (ST, etc.) expose this functionality to administrators.
Technical Notes
Not known.
Definition and Examples
An administrator needs the ability to define specific page layouts and content for end-users.
User Details
The administrator most likely performs this task rarely, or at application set up time.
Current Design Status
Unclear if this functionality for ERP and CRM applications is part of the OA "Personalization" framework. See
above under Cross Application - Set Up Structure and Content of Applications based on Org, Site, Locale, Responsibility, etc..
Unclear whether or not other divisions (ST, etc.) expose this functionality to administrators.
Technical Notes
Not known.
Definition and Examples
Administrators need the ability to set up objects within an application to display a certain way, and with
specific type of content. For instance, an application may have a table of Purchase Orders. The developer
at Oracle may seed common views for that table. The administrator at a customers site, though, may want to seed
other views for end-users that are specific to his/her company.
User Details
The administrator typically performs this functionality at set up time of the application.
Current Design Status
Unclear if this functionality for ERP and CRM applications is part of the OA "Personalization" framework. See
above under Cross Application - Set Up Structure and Content of Applications based on Org, Site, Locale, Responsibility, etc..
Unclear whether or not other divisions (ST, etc.) expose this functionality to administrators.
Technical Notes
Not known.
Definition and Examples
Preferences are personal settings that the end-user can make/change at any time. There are core preferences that
should be available in every BLAF app and apply across the entire application suite. There are also application
specific preferences (see below under "Application Specific - Preferences Personalization").
End-user preferences can be defined as functions that allow the end user to: turn on or off application features (i.e., turn on/off instruction text [not available today] or changing accessibility settings); change display settings (i.e., the branding size that would be displayed [not available today]); change formatting settings (i.e., date format or number format); change personal settings (i.e., personal password.) Again each of these types of perferences may be applicable to the entire application suite, or applicable per a single application only. Depending on the scope of the preference, the location of where that preference is in the application slightly varies.
User Details
Every end-user should have the ability to change his/her preferences as desired.
Current Design Status
Access to preferences is through a global page button on every single page of the application suite. When selected,
the user navigates to the preferences section. Within the section, the default page is the cross application
preferences. Subsequent preferences pages are application specific.
The preferences designs are fully documented at:
Technical Notes
It is unclear as of October 2002 if the OA framework supports the global
preferences page (with side navigation) as designed. OA does provide
a global button on every single application page that accesses a single
preferences page (with only cross application preferences.) For a list
of which settings are currently supported in OA, see Cross
Application Preference Settings List.
Server Technologies (ST) provides a global preferences button. This does access a page similar to what is specified in the BLAF
guidelines. Not all the same global settings as ERP and CRM have been implemented.
Definition and Examples
Application specific preferences is accessed through the same global page button (preferences button) as cross application
preferences. The different scope of preferences is represented in the side navigation, cross application preference being the default
section called "General." Application specific preferences would be another section or sections within the side navigation
depending on how many exist for the specific application and if they fall under logical groupings. Application specific
preferences are optional based on whether or not they are needed by the application.
Application specific preference settings should fall under the same categories as cross application preferences (turn on/off features, change display settings, change formatting settings, change personal settings), but these settings would be applicable to only the application that is in use.
User Details
Every end-user should have the ability to change his/her preferences as desired.
Current Design Status
Application specific preferences are specified per product. The access point and page layout should follow the details mentioned above under
"Cross Application - Preferences Personalization".
Technical Notes
See technical notes above under "Cross Application - Preferences Personalization".
Definition and Examples
Depending on the application, the end-user may want the ability to personalize the order in which his/her tab/navigation elements
(tab, horizontal navigation, side navigation, and/or subtab components) appear in his/her application. He may also want the
ability to turn on or off a tab/navigation element if it is not applicable to his daily work, and/or
interests.
This functionality may be quite useful in certain contexts, but can be detrimental in others. For instance, in a portal context, turning off a tab named "Weather", say may be appropriate, since the end-user may or may not care to see weather information on his or her portal. For many business applications, though, turning off a tab such as "Purchase Orders" in a purchasing application may prohibit the user from using core functionality of that application, thus not being able to complete core tasks.
Providing the ability to rearrange the order of the tab/navigation elements is a "nice to have" personalization feature. The end-user may be able to tailor the content or functions he/she most frequently uses in a specific location for ease in learning the application.
User Details
End-users in specific contexts may have the ability to personalize tab/navigation display or order.
Current Design Status
Sever Technologies (ST) currently provides a "set up" global button that allows the end user to turn on or off a horizontal navigation
section (only). ST may also provide the ability to change the horizontal navigation order. The functionality is represented in the UI
as a schematic picture of the tab/horizontal navigation component. The user selects and unselects checkboxes (associated with the schematic
graphic, but not within the graphic) to turn the features on or off. (This information is being checked to ensure
accuracy with what is currently available in ST. It may change. If the functionality is for end-users of ST products, the global button
should not be named "Set Up.")
The Portal product provides the ability for an end-user to turn on and off tabs in a portal. This is accessed through a global "Customize" button (terminology should be changed to "Personalize"). Once there, the functionality is exposed in the UI within the acutal component itself. So, to turn on or off a tab, there is a check box within the tab. It is unclear if portal provides reorder capabilities of tabs, and/or any personalization features for turning on or off (and/or reordering) horizontal navigation, side navigation or subtabs.
The Applications division (CRM/ERP) does not provide this functionality.
This area of personalization should be consolidated to provide a consistent design solution, since there are different metaphors and UI's that are being deployed. Some design considerations:
Technical Notes
Portal provides the most robust functionality for this type of personalization. For more notes, see above under "Current Design Status."
Definition and Examples
Page personalization provides the end-user with the capability to change the layout (how the page looks or what goes where)
and the content (what is on the page) of a given page within an application.
Providing the capability for an end-user to personalize a page makes sense for certain contexts in certain applications. For instance, central (centrally located within an application or across applications) or summary-type view only pages are good candidates for personalization since an end user may refer to these page types often and want to see content and layout of that page in a specific manner. Below lists examples of summary-type or centrally located pages that are used throughout applications and domains:
Most other types of pages within an application are transactional pages or pages where data can be changed, deleted, created, etc. Transactional pages may or may not be appropriate for an end-user to personalize since eliminating (or turning off) certain functions may prohibit the end-user from performing functions necessary to complete the process correctly. For example, if the end-user has the ability to personalize the sections of a transactional page that need to be filled out for a Quality report, say, if that content or portion of the page is turned off, he/she will not gather the data. This can be risky given it may be part of his/her role to provide the data, yet he/she has taken the liberty to personalize the page such that the data will not be captured.
User Details
End-users in specific contexts and on specific pages may have the ability to personalize the layout and contents of a page in
an application.
Current Design Status
The Portal provides the ability for an end-user to personalize the layout and content of a portal page. The functionality is accessed
through a global "Customize" button (terminology should be changed to "Personalize".) Once at the page, the user can remove portlets,
rearrange the layout of porlets on the page, and add new portlets to the page. The end-user is in an "edit mode" of changing the portal page
(i.e., he/she is not on the actual portal page itself), but is viewing the page as it would be seen on the updated page (insitu model.)
All other applications (CRM/ERP/BI/ST/Tools) do not have page personalization features.
Technical Notes
Portal provides page level personalization capabilities. No other division has these features.
Definition and Examples
Many different types of objects used throughout Oracle Applications may need to be personalized by an end-user. The end-user not only
wants to change the display of these objects (how they look), but also change the content that is being displayed. Heuristics per application
and per page need to be applied on when personalization capabilities should be exposed. Even if the object does have the
capability (or UI) to personalize does not necessarily mean it is a desired task (or would be used frequently enough) to warrant
the functionality to be displayed.
For instance, in certain professional CRM applications an end-user may spend his or her full day managing certain customer's sales orders. Given the frequency of use and high understanding of context and data regarding his domain, there is a high likelihood that he would like to personalize the data and display such that it best tailors his daily needs. In this scenario, exposing personalization is appropriate. In contrast, in an application that may be used frequently, but on a specific task that is used in frequently, or not core to performing daily tasks, personalization features may just add clutter to the UI rather than helping the user. The likelihood of the end-user taking the time to personalize every table, and/or possible object in an application to his/her special needs may be unrealistic.
Below lists the objects that can (or could) be personalized and briefly describes the details for each:
User Details
End-users in specific contexts and on specific pages may have the ability to personalize the
layout and contents of an object on a page within an application.
Current Design Status
Below lists the design status for each object that can (or could) be personalized:
Technical Notes
Below list the technical status of each object-level personalization functions:
Based on the user type that is accessing the functionality, the frequency in which the functionality is used and the breadth or scope of the functionality, a different design choice may be made. Below lists the common access points for all different personalization and set up functions:
For instance, when an end-user personalizes a table, he/she navigates to a "decentralized" location (drilldown) page from the actual content that is being personalized. In contrast, some other objects are personalized in a "centralized" location or insitu with the object itself.
For instance, sorting of a column header of a table is a form a direct manipulation where the content that is being altered is in view when the personalization is happening. An alternative form of sorting may be to drilldown to a different page and select sorting options from a table (say which columns to sort and what order should each column be sorted.) This latter example would be an example of "abstracted" manipulation since the content that is being altered is not in view at the same time as the personalization functions are being performed.
For instance, in Table personalization, the use can not only change the layout (display) of the table (i.e. the appropriate order of the columns) but can also determine what data (content) should be shown as well (i.e., saving search criteria. On the other hand, some personalization or set up functions may only require that display is changed, and not data. For instance, an administrator may determine the default order of the tabs to be displayed in an application but can not change the content within those tabs.