BLAF Guidelines - Personalization and Set Up Functions in BLAF: Overview
Personalization and Set Up Functions in BLAF: Overview
Last Updated 03.06.03
General Description
Personalization and set up functions are seen througout Oracle Applications. The user types who perform these
functions vary, as well as the scope and content that is being altered varies. This guideline
groups and summarizes the wide variey of personalization and set up functions across Oracle products into
categories, and provides a design brief of what is available today, and what will be designed in the future.
Note: This guideline is a design brief that outlines some existing BLAF designs for personalization and
set up functions as well as identifies areas where there are missing designs. This guideline has not yet
been updated since November 2002 to reflect ongoing work in page personalization and administration setup.
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.
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.
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.
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:
a horizontal navigation section (like in Projects). Once the section is selected, typically there is a
task menu listing the different set up functions available.
it's own module or application. Much financial set up functions are preformed in their own applications or
modules. The functions are launched from the Forms Navigator menu.
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.
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.
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.
A detailed list of cross application preferences is also listed off of the Global
Page Templates guideline. Some of these have been implemented in ERP and
CRM applications (OA Framework), some have not. For full list see: Cross
Application Preference Settings List.
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:
Access needs to be centralized, esp. if ability to turn on or off since when turned off need place to go to turn on.
Should the overall UI model provide the end-user the ability to see what is being turned on or off (i.e., portal), or have a more abstracted
representation, and traditional web form widgets to personalize (i.e., ST)?
reordering: Should the ability to reorder be designed "insitu" with drag and drop or again as an abstracted model using a
standard web component such as the shuttle? Technically, the insitu model with drag and drop would be a future enhancement in the
technology stack.
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:
Portal Pages
Home Pages
General Home Pages (aggregate view of all content and functions within an application.)
Contextual Home Pages (aggregate view of an object and functions available to perform on that object.)
Summary Object Pages (Object Template Pages)
This may be a "lower level" page within an application that displays an overview of an object, and it's
properties (detailed attributes.)
Object Status Pages
This type of page does not show object properties but shows status information regarding an object, such as in
a CRM scenario, there may be a customer page that shows current status information regarding that customer, the last order he/she
placed, what products he/she likes or dislikes, are there outstanding issues with the customer (unpaid invoices, etc.)
Report Pages
This type of page shows business intelligence data.
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:
Table Personalization - Provides the capability for the end-user to personalize the content (via search query) and display of a table (column
order, column names, sorting, totalling). It also provides overall settings (view name, number of rows, etc.). Table personalization is closely tied to searching, and
iterative searches.
HGrid Personalization - Provides the capability for the end-user to personalize the content (via explicit
selection of certain nodes in
a hierarchy) and display of a hierarchy (column order, column names, sorting, etc). It also provides overall settings (view name, etc.).
HGrid personalization is closely tied to table personalization and searching.
Tree Personalization - Provides the capability for the end-user to personalize the content (via explicit selection of
certain nodes in a hierarchy). At this time, there are no requirements for display options to be set as well.
Graph Personalization - Provides the capability for the end-user to personalize the display (what type of graph,
what colors used, detailed visual features of the graph) and content (what data should be shown in the graph).
Pivot Table Personalization - Provides the capability for the end-user to personalize the
content of the pivot table. Unclear of all the display personalization options available for the pivot table.
Portlet Personalization - Provides the capability for the end-user to personalize the
content (i.e., in a favorites portlet, the user can add or delete bookmarked links, etc.) within a portlet.
Content Container Personalization - Provides the capability for the end-user to personalize the
content (i.e., add or delete shortcut links, etc.) within a content container in an application. (This
functionliaty currently does not exist.)
List (bulleted list) Personalization - Provides the ability for a user to customize a bulleted list
of objects/items/tasks. For instance, on an application page, there may be a section of related links. The user
may need to add or delete links from this section. (This functionality currently doesn't exist except in a portlet.)
Choice List Contents Personalization - Provides the ability for a user to customize the items within
a choice list. For instance, it may be appropriate to have an LOV choice list that the user can personalize with
his/her most frequently used values.
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:
Table Personalization - Full table personalization standards exist allowing the user to personalize the
query (search criteria) and display of a table. Access to this functionality is through "local" buttons, or buttons
associated with specific content: a personalize button associated to the "View" choice list (containing personalized
views of the table) and/or a "Save Search" page level button (where applicable on Object List pages with search and
results. Once the user has accessed the personalization screens (decentralized location from the actual
final table), the user changes settings in an "abstracted" mode (with common web widgets, not direct manipulation
of the table that is being personalized.) Once complete, he/she returns to the instantiating page with the new personalization settings
for that table set. For full guidelines, see:
HGrid Personalization - HGrid personalization standards exist allowing the user to personalize the
contents within a hierarchy (by selecting individual nodes) and display of the HGrid. The design model for HGrid
personalization follows the table personalization model. See above for details. For full guidelines, see:
Tree Personalization - There is not a specific guideline for tree personalization at this time (Nov. 2002). For
consistency with other hierarhcy personalization, this guideline should follow a similar model as HGrid personalization.
Graph Personalization - The ability for end user to personalize the content and look of a graph is
done through a wizard flow. The functionality is accessed via a button associated with the graph. Each step in the
wizard represents a different type of personalization setting for the graph. For example flows (for
internal Oracle employees only), see:
Graph Wizard Prototypes - In Progress
(Note: Some of the content within the URL above may or may not be BLAF compliant approved. The content is work in progress.)
Pivot Table Personalization - Personalization of a pivot table is handled differently than the table and
HGrid method above. Access to personalization features for a pivot table is provided above the pivot table in
a BI specific "toolbar" element. This "centralized" approach (since it is shown with the pivot table itself) has
options within it to allow the user to change some display options as well as change the content of the pivot table in
an "abstracted" mode (not direct manipulation of the pivot table itself, but with surrounding standard web widgets.)
Not all functions are available within this "toolbar" and more options are provided on "decentralized" drilldown
pages off of the pivot table page. Pivot table personalization does not allow (at this time) for saving these particular
"views" like the table or HGrid.
Portlet Personalization - Access to portlet personalization is local to each portlet via a link (this link needs
to be renamed to "Personalize". The user navigates to another page ("decentralized" from the portlet itself) to
personalize the contents and display of that portlet. When finished, he/she returns to the portal page with his/her
portlet personalized as desired. Currently there is not functionality available to save personalized portlet
views like the table and HGrid.
Content Container Personalization - Specific designs for content container personalization do not yet exist.
Requirements being gathered to assess best approach.
List (bulleted list) Personalization - Specific designs for bulleted list personalization do not yet exist, but
initial designs were created for the Oracle Applications Portal (2000-2001.) The design model used was a "decentralized"
approach, where the user accessed the functionality local to the bulleted list, then drilled to a "decentralized" page
where he/she selected items from a shuttle component ("abstracted" method with list not in view.) Once complete,
the user would return to the list to see his/her personalized results.
Choice List Contents Personalization - Access to choice list personalization is local to the choice list
itself (i.e., a button next to the choice list labeled "Personalize." Once selected, the user drills down to a
"decentralized" page where he/she can select the items to be displayed in the list and/or optionally add new
items. This list of items is typically represented as a table. Once complete, the user returns to the instantiating
page with the choice lists contents personalized. The LOV choice list follows this model. For detailed examples, see:
Below outlines design considerations that must be made when personalization and set up
functions are exposed. For consistency across applications and across similar personalization and
set up functions, the same design model should be used.
Based on the personalization and/or set up function that is going to be performed, the first design
consideration that should be made is how does the user (administrator or end-user) access the functions? Are
the functions in an application of it's own (stand alone), a tab within an application (global to the application), or a button located next to the specific
object (local) that is being personalized?
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:
Access Point Options:
Stand Alone: as a Family of applications or modules
Stand Alone: as a Single application
Global to Application: within an Application - as a Global Button
Global to Application: within an Application - as a Tab
Global to Tab: within a Tab of an Application - as a Horizontal Navigation Section
Local to Page: within an Page - as a Page Level Button
Local to Widget: with a Specific Object - as an Object Level Button
Once the access point is chosen for the personalization and/or set up functions, it must be
determined whether or not the functions are "centralized" or insitu with the object/page/application that is being
personalized/changed in view or whether or not the user should navigate to a "decentralized" location
to perform the personalization or set up tasks.
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.
Whether or not the administrative user or end-user is in a "centralized" or "decentralized" location to
edit the functions, another design consideration must be thought through. Should the user be able to directly
manipulate the content he/she is personalizing (or setting up) or should he/she be presented with a more "abstracted"
form of personalization or set up?
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.
Lastly, another design consideration that comes into play when creating the user interface for
personalization and/or set up functions is what exactly is being updated? Is just the layout (where
items are positioned or where items within a component are positioned) being altered, or is also
content being determined as well?
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.
Bookmark
