This Content Component encountered an error
This Content Component encountered an error
This Content Component encountered an error

EDITOR’S NOTE: This is the first of a two-part column on Oracle User Productivity Kit (UPK). This first part covers...

defining standards and securing content. The second part focuses on the use of the library and online editor.

The Oracle User Productivity Kit (UPK) provides a platform for collaboration and content development in a multi-user environment. Alticor Inc., a global company offering products, business opportunities and manufacturing and logistics services in more than 80 countries and territories worldwide, has identified some best practices for using UPK. They include defining standards, securing content, using the library and publishing.

Define standards
Defining standards to outline what you do and don’t want to see in your simulations is an important first step to take before creating a UPK development strategy. The UPK default settings, configured out of the box, are great. But users may want to customize settings.

Color. An organization may wish to customize the UPK color scheme based on the organization’s standards. In that case, prepare authors to select the desired colors by providing them the RGB code so that everyone is using the right shades. There are other considerations as well. For instance, if printed in black and white, can outputs be viewed properly? Or can color-blind members of the team differentiate between color combinations?

Font Style. It is also important to define the use of font style and size, line thickness, acronyms and screen resolution. It may sound like over-engineering, but when each author uses his or her own preferences to build content, a lack of consistency can be distracting. You don’t want people to be distracted by differently colored or sized fonts. You want your audience to focus on the key messages, and consistency will help.

Content. It is important to define how and what information will be put into bubble text. Do you want to include process information? If so, to what level of detail? If not, what information should be included? Do you only include the recorded text? Will you use concept frames or webpages? If so, what type of information should be contained in each of them? What common verbiage should or should not be used? Where and what requires bold or italics text? These are all questions with no right or wrong answer. It is up to each user to determine what is best for its audience and define the parameters so that authors are consistent.

Naming Convention. Naming conventions are important for good organization and consistency. Naming conventions simply lay out how authors will create names for items to avoid confusion and make it easier to know how to search. The following are three criteria for naming files:

  • Entering Timecards
  • Timecard Entry
  • Enter Timecards

Which is correct? That depends on your naming convention. If you want to begin your file names with a noun, then Timecard Entry is correct. If you determine you want your files to begin with a verb, then Enter Timecards is correct. Think about how your audience may search for the information if they don’t know the exact name or title they need. You know your audience, so take the path of least resistance.

Rules. Determine how authors will check in and check out topics (topic by topic or section by section, a single topic or blocks of topics)? Is it OK to reorganize the library or outline, or should the team be consulted first? How will you work together as a team? What is your review cycle? Once you have the rules and standards defined, assign an owner to put all of the decisions in writing. It is important to define standards before beginning development work.

I recommend holding a working session with your team to discuss and define standards and document results in a style guide. Your standards could be one element of your development strategy for your project. This can save a lot of rework, time and frustration by nailing down details up front. You will have a happier team in the end.

Securing content
By default, all authors within UPK have the ability to modify documents in the library. Folders can be restricted by author or by user group. Take time to consider which authors will have access to which folders in the library. One approach is to start with fewer restrictions and then tighten them up as needed over time. Alternatively, start more restrictive and loosen the restrictions as needed over time. Again, know your audience and your organization and make the appropriate choice for your project. 

The UPK administrator can set the following permissions for any folder in the library:

List Folder Contents. Authors cannot save to folders with this permission. An author can view the names of documents in a library folder but cannot open a document in any editor and perform actions that would change the document content or its location in the library. An author also cannot make a copy of the document in any way.

Read. An author can open a document in an editor, but cannot perform any actions that would change the document content or its location in the Library. An author can make a copy (including Save as) of the document and store it in a folder location for which she has appropriate permissions.

Modify. An author has complete access to the folder and its documents and can perform any action (create, modify, copy, delete, publish, export and so on).

Checking in, checking out
Before beginning any work, make sure that alldocuments are checked in so that you are beginning with a clean slate. Use the Check In All command to get started. 

When authors are ready to begin working on a document, they should then use the Check Out command, which blocks others from being able to make modifications at the same time. When checking out documents, the author can choose to check out an individual document, the selected document and all related documents or all documents. I have found it best to only check out one document at a time, unless there are known changes that need to be made to more than one document.

When the author is finished modifying the document(s), she should use the Check In command, which allows other authors to make their changes without interfering with the first author’s work. Add a note on what changed when you check your document back in so people will know what has changed.

If you want to work offline, use the Get command to download read-only copies of documents before going offline. If you don’t know the specific document you need in order to work offline, use the Get All command to download all documents in the library.

Finally, put a formal process in place for checking in and out to ensure your team does it consistently. This helps eliminate frustration among the team and will ensure efficient and effective teamwork.

ABOUT THE AUTHOR
Lissa English is the global instructional design manager at Alticor, parent company of Amway Corp. She is a member of the Oracle Applications Users Group (OAUG) board of directors and serves on a number of the organization's functional committees and special interest groups (SIGs).

This was last published in June 2012
This Content Component encountered an error
This Content Component encountered an error
This Content Component encountered an error

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close