The User Experience
Last updated on: 5/1/2013 12:20 PM
Created on: 3/21/2014 2:18 PM
The Security Console Platform is a client side (workstation) component and therefore needs to provide a robust, yet easy to understand interface. The UI is built using Qt (once owned by Nokia and Trolltech). This toolkit allows an interface developed in C++ to be built on multiple platforms and maintain that platforms native look and feel all while using only one code base. The primary platform targets are the three major desktop platforms of Windows, Solaris (linux) and OSX. The platform is also projected to target the Android platform for use on tablets. This creates some challenges in considering a common UI layout that still keeps aspects of the UI that are native (and expected) of the target platform.
The platform provides the following interface components:
- A system tray component to indicate if user interaction is required
- A tray window that can be opened by the system tray to view notifications, access applet tasks and main window interfaces and access control panel dialogs
- A main windowing system that provides full access to the applets capabilities
- A fixed set of commands that an applet can enable on the menus and toolbars to access the main features of the applet in a consistent manner.
- Applets are provided access to an Icon navigation system, Tree views for organized object management and an HTML view to provide any textual information. All user interaction is first processed by the platform and then the appropriate triggers are activated in the applet.
- Access to a configuration panel to add dialogs to allow the user to modify settings.
The Microsoft Windows platform will make use of the system tray. In the past, due to integration with third party tools, multiple instances of the products would be launched. Not only is launching a new process of the platform expensive in CPU cycle costs, but it also allows settings and log-in states to become out of sync. The SC-7 framework forces a single master instance of the framework to run and sets up an inter-process communication system. To indicate that a master instance is running, the framework icon appears in the system tray. When a second instance is run, the reason for that instance including any command line parameters, is sent to the master instance, which in turn performs the command. This routine is hidden from the user while the framework uses this single instance to make sure data integrity and the execution of multiple commands are kept in sync.
The Main UI window, as well as the system tray context menu, will provide actions to open up any applet that is intended to run as an application. However, it also presents tasks, or shortcuts to application action items, so the user can perform simple tasks without the need to open its corresponding applet. This tasks appear in two forms: a list of new items that can be quickly created and a list of task shortcuts to other common functionality. It is important to point out that while these tasks appear in both the main window and system tray context menu, all tasks are context based therefore allowing tasks to appear on context specific menus throughout the framework. This becomes important in platforms like Android in which all menus are context menus and relate only to the actions available on the screen.
Having items appear properly in the UI is all handled by the framework. To properly have items appear in either the main window or system tray context menu, an applet developer simply just needs to develop the applet conforming to the documentation of the ISCAppletWindowExtension, ISCConfigPanelExtension and ISCTaskListExtension interfaces. Any applet that implements the ISCAppletWindowExtension is treated as an applet that can run as an application and will have a button to open the application as well as command processing to accept commands from the platform shell to open the application (The Start Menu in Windows, for example.) By implementing this functionality through the Interfaces, applet developers can expose all their applet specific tasks while the UI handles presenting the information in the way that is most natural for the target platform. This allows the same functionality to be provided while the framework handles the creation of an experience that is natural for the user's workstation or device.
While the framework also handles the feedback required when an action takes a considerable amount of time and when a problem arises. The framework provides a standard progress meter that is obtained by any applet action request a handle to a progress meter. Each progress meter is composed of a number of components. The most visible are the two UI progress meters, one for the entire job and one for the specific task being executed within the job. Text labels are provided and can be updated to state the title of the job, the task and the step in the process that is currently underway. In some instances a progress meter with a cancel button can be obtained if the task always the user to abort during the operation. Each task is displayed in a standard window that is not under the user control. While the window may be pushed to the background of the desktop OS, it can not be closed. Each running task is displayed in this window and a warning to not turn of the system or device at this time is provided. When all tasks are finished, this window will automatically close. Tasks can also generate a notification as to the result of the task upon its conclusion.
If an error needs to be reported during an operation the progress meter has a function that adds a post code. More than one post code can be assigned to a progress meter. When the progress meter is released, if there are post codes the error reporting system of the framework activates. For each post code the framework queries all applets who implement the ISCErrorReporterExtension for the proper text to display to the end user. In addition, if error logging merits it, the error is reported to the system event logs. To provide a common experience when displaying error dialogs as well as prompts for questions, the progress meter implements its own methods to display dialog boxes. Under the Windows 7 shell, the progress meter handles the overhead of generating alerts such as turning task bar icons to yellow or red.
TopicsDeveloper's Historical Persepctive Why A Platform Standards The User Experience
InterfacesISCApplet ISCTaskListExtension ISCConfigPanelExtension ISCErrorReporterExtension ISCLogConnector/ISCLogEntry ISCCertificateStoreExtension ISCSystemTrayExtension ISCAppletWindowExtension ISCSecureObjectExtension
Applet Building StepsStep 1: Create The Applet Step 2: Adding Action Items Step 3: Adding Configuration Panels Step 4: Adding Custom Error Text Step 5: Startup/Shutdown Step 6: Adding Main Window Support Step 7: Adding Obejct Window Support