Scope

Before we delve into building the functionality of the system, we will first spend this chapter outlining the scope of the application. This will put you in a good position to begin setting up a JET application for the first time (in Chapter 4). Up until this point, you have been working with JSFiddle examples. Going forward you will be expected to scaffold your own JET application locally on your PC. Chapter-by-chapter versions of the code will be available on GitHub, if you get stuck.

The JSON data payloads for Chapter 3 will be made available on GitHub. Throughout the book, they will also be given at the start of the chapter in which they are used.

Page Skeleton

The layout of the application will follow a standard three-column application layout. The left-hand column will be used for viewing and filtering open tickets, and the main content area will show the selected ticket and all its information. The box in the main section on the right will contain metadata about the selected ticket, such as information on the person assigned to the ticket, any ticket history, and rating information.

There will be a total of two menu bars. The main menu bar will hold the application logo, main menu navigation, and user information. The second menu bar will hold ticket-related actions, such as adding a new ticket and the tabs of the open tickets.

Note that the logged-in user text at the top right is in a more natural language format. This has been added to keep with the theme of improving the user experience. A simple change such as using natural language, can make the application feel a little friendlier, which, in turn, will make the user feel happier. Natural language additions such as this work great if an application is looking to adopt some sort of AI interface too, such as integrating the Oracle Digital Assistant Service into the UI.

We will be using a tab component for the main content area. This is so that users can have multiple tickets open at the same time. Having this kind of multitasking will be beneficial to bigger companies that have a lot of different support tickets open, or even for a support representative who will be dealing with multiple tickets and may have to keep several tickets open concurrently. The page skeleton is illustrated in Figure 3-1.

Ticket List

The leftmost pane of the application will contain a list of tickets, as shown in Figure 3-2. This list will be searchable using quick inline searching, which will give the user a “search as you type” experience. The search functionality will be built as a Web Component, giving it the full benefits of the Web Component architecture, which we will explore more later in the book.

Viewing a Ticket

Selecting a ticket from the list will open the ticket in a new tab in the main content section. Each ticket will be assigned to a new tab, and the currently visible ticket will be highlighted in the list on the right-hand side.

The ticket view itself will show information about the current status of the ticket and options to escalate the priority of the ticket and close the ticket. Escalating the priority will move the ticket up one level, and users will be informed of this when they click the button. Before closing a ticket, users will be shown a pop-up asking them to confirm their action.

The first message displayed for a ticket will be the original support message raised by the customer; this will include the avatar of the user, the user’s full name, attachment (if available), and their message. Following the original message will be all the replies by both support representatives and the user, all in the same format. Any notes from the user will be displayed on the left-hand side, whereas the support representatives’ replies will be on the right. The amount of time since each note was posted is also shown.

To the right of the notes, users will be able to see information about their support representative, including a small bio and their average rating. The aim of this to reassure customers that they are in safe hands. Figure 3-3 shows selected ticket 10006 in focus.

Replying to Tickets

At the bottom of each open ticket (see Figure 3-4), there will be a box in which users can reply, using a WYSIWYG editor. The editor will be implemented using a third-party plug-in. The idea here is not to have a rich editor that permits images, HTML, etc., just a simple editor that can handle line spaces and some basic formatting.

Users will be able to upload an attachment with their comment, such as an image to aid with the support incident.

Clicking the Reply button at the top of a ticket will move the focus down to the reply box, so that it is easy for a user to get to the reply box on really long tickets.

Closing and Rating Tickets

Once users have received a satisfactory outcome to their support ticket, they will be able to self-close the ticket. To do this, they must click the Close Ticket button at the top of the screen, as shown in Figure 3-5.

Clicking the Close Ticket button will show a dialog window asking users to confirm that they want to close the ticket. Figure 3-6 illustrates the ticket closure dialog, with a drop-down list to specify a closure reason.

Once they confirm, the ticket will then be closed, and the status of the ticket updated. The buttons at the top of the ticket will disappear and are switched instead to a rating component, with which users can rate their experience with the support assistant, as shown in Figure 3-7.

Creating a New Ticket

Figure 3-8 illustrates how the create ticket section will look. The section will slide down and push the rest of the content farther down the page, making the ticket creation the primary focus to the user.

Notifications

Notifications generated by the application will be shown in a box at the bottom right-hand corner of the screen. (See Figure 3-9). For example, if there is an error with the action a user is trying to perform, an error message will be shown. Success messages will also be displayed here, and the component we will use provides the means to easily set the type of notification.

Notifications will be global, and they can be dismissed by the user, by clicking the cross next to them.

Searching for Tickets

As briefly mentioned, users will have the ability to quickly search for tickets using a “search as you type” search box at the top of the ticket list. Search as you type gives users a better experience. It is similar to autocomplete on Google, in that it will start returning results to the user almost instantly, meaning their item may appear before they even finish typing a word. Combine that with not having a search button to press, and the time and effort for a user to find what they are looking for is greatly reduced.

Note in Figure 3-10 that the full search term has not been typed, yet the user can already see the item he or she is trying to search for.

Summary

This chapter has provided an overview of the screens we will be building using the mock-ups provided, and it has also explored their functionality. Make sure that you have a good understanding of the expected functionality before moving on.