Agent Desktop

Get Involved. Join the Conversation.

Topic

    Jens Lundell
    Soup up Workspace load! - Optimize your Workspace Layout
    Topic posted January 22, 2019 by Jens LundellBronze Crown: 15,000+ Points, tagged Browser UI, Service Console 
    150 Views
    Title:
    Soup up Workspace load! - Optimize your Workspace Layout
    Content:

    This is Part Two of the Soup up Workspace load! series. For the Introduction go here.

    Summary

    In this article we examine some of the elements you can add to a workspace and discuss how they affect the load time of workspaces. The recommendations apply to scripts as well, except the relationship item specific ones, since scripts can’t have relationship items.

    As mentioned in the previous post, it is often very helpful to compare the performance of your custom workspace with the standard workspace. If there’s a significant difference, you know there’s something that slows down your workspace, and you can successively remove and change items to figure out the culprit. There can of course be multiple factors that contribute to a performance degradation, so be prepared to spend some time on doing this testing. Use the tips in the previous post to make sure you get accurate timings.

    Minimize fields

    Having too many fields on a workspace can cause usability problems for agents, and will also make workspaces load slower. Fields on tabs that are not shown upon load are less of a concern, but visible fields all need to have their UI controls created when the workspace loads, which takes time. Periodically audit these fields and make sure they are used and that agents need to see them. The easiest way to do this is to create reports that count recent records where the field value is blank (null). For example, if an incident field is blank for all incidents that have been updated in the last month, then you can probably remove it, or at least move it to a tab that isn’t shown upon load. If you’re not sure, you can try to move it and then wait for feedback. If somebody complains, you can refer them to the new location and use that as an opportunity to learn more about how agents use the field.

    If you have many read-only fields, consider adding them to the Info ribbon button (not available in the Agent Browser User Interface) instead of having them as fields on the workspace. Alternatively, add them all as merge fields on a Text Control. Those approaches reduce the number of UI controls created upon load, thus reducing load time.

    An alternative to placing less frequently used fields on tabs that are not shown initially is to use a script with several pages that agents can page through if required. There’s not a big performance difference between the different approaches, but the script design can be more usable, depending on your business use case and your agents. Of course some agents may think it is less usable, so make sure to gather user feedback before finalizing the design.

    Reduce your control hierarchy

    Having multiple levels of nested Table and Panel controls forces the rendering engine to do a lot of sizing calculations, which slows down load, and may even cause visible flickering. This is especially true of the older style editors in the Service Console: the Answer, Opportunity, Quote, and Quote Product editors. In the Agent Browser User Interface the Internet Explorer, Edge, Safari, and Firefox browsers also struggle with a lot of nested content. As such, we recommend you inspect the control hierarchy using the Selected Object dropdown in the Design ribbon tab and reduce the number of Tables as much as possible.

    Note that whenever you add content to a Panel control, the system will automatically create a Table control inside the Panel to hold your content. As a consequence, Tables are almost always better to use than Panels, because adding a Panel may simply result in a redundant control.

    Take a look at the Creating a workspace with fields to the left Dynamic Agent Desktop recipe for more information on how to reduce your control hierarchy.

    Use Browser controls judiciously

    Browser controls can be very handy in allowing you to embed external tools into the workspace, reducing the need for agents to switch applications and manually launch webpages. The browser control is unfortunately expensive to create, and it has a big memory footprint, so make sure to only use it when needed. If you simply need to give agents a convenient way to launch a certain webpage, consider using the Hyperlink control instead, or add the URL to the Links ribbon button (not available in the Agent Browser User Interface). If you do decide to use a Browser control, make sure to set its Delay Load property if the control is on a tab that is not visible upon load, which prevents the workspace from unnecessarily loading the web page every time. Also, instead of having multiple Browser controls next to each other, combine them using these techniques:

    1. Combine several pages into one page using frames. Here’s some example HTML code for putting two web pages on top of each other: 

    <html>
    <head>
    <title>Page with frames</title>
    </head>
    <frameset rows="*,*">
    <frame src="https://en.wikipedia.org">
    <frame src="https://w3.org">
    </frameset>
    </html>
    

    The method above may not work for all sites since some are not allowed to be in frames.

    2. If you don’t need to have all of the pages open at the same time, you can replace several pages with your own launch page – i.e. a page that contains links to the other pages. Here’s some example HTML code for a launch page that shows two links to other pages:

    <html>
    <head>
    <title>Page with links</title>
    </head>
    <body>
    <a href=" https://en.wikipedia.org">Go to Wikipedia</a>
    <a href="https://w3.org">Go to W3C</a>
    </body>
    </html>
    

    3. Use one browser control and dynamically point it to the appropriate web page using the “Set the URL of a web browser control” workspace rule action.

    Optimize your Reports (and report based relationship items)

    Having reports run and display data when you open a workspace can be very expensive since additional processing is needed, more data needs to be sent to the desktop application, and a separate server request is often required to get the data. If you absolutely need a report, limit the data requested by reducing the columns and the rows returned. Also make sure to set the Delay Report Execution property for all your report controls. That will ensure that reports run only when they become visible, which reduces workspace load time and improves memory usage.

    Be aware of the Thread control’s performance impact

    The incident thread control is the most complex workspace control available. It renders existing threads but also has logic for composing new rich text threads. Because of all the logic and the need to show potentially long threads, it is expensive to create and render. For most workspaces this is, unfortunately, a price you have to pay since the most important information of an incident is in the threads, and hence agents need to see them for every incident. However, if that is not the case for certain agents or for certain incidents, consider removing the thread control, or add it to a tab that isn’t shown upon load. Also consider disabling the option to create a new thread by default, as that adds additional processing.

    OK, that’s it for the second article in the Soup up Workspace load! series. In the next article we’ll look at how to speed up your workspaces by optimizing your workspace rules.

    Please share feedback, questions, and ideas in the comment section below.

    Jens Lundell
    Oracle Service Cloud