Skip to main content

Small Changes, Big Impact: App Mode 2.0's New Customization Features, Part 2

· 8 min read
Justin Emilio

Small Changes, Big Impact

In the first part of this blog series, we introduced Frame's new Application Mode, "App Mode 2.0," highlighting its dynamic nature and the possibility of customizing user interfaces for individual remote applications. We walked through Launchpads, defined their purpose, and elaborated on the key differences between them and Application Mode. We also provided an overview of some of the main features of App Mode 2.0 including customization of the Frame taskbar and Start menu.

In this follow-up post, we will delve deeper into the customization process, demonstrating how you can override the default layout and applications list for the Frame taskbar and how you can utilize this feature to significantly enhance end-user experiences.

Overriding the Default Layout and Application List

App Mode 2.0 enables administrators to make real-time adjustments to the default layout and application list inside the Frame Taskbar. By modifying a pre-session Frame Guest Agent (FGA) script, you can seamlessly override the default configuration to match individual user or group requirements.

You can completely transform the appearance and functionality of the Start menu by adding, removing, and modifying applications and folders. For instance, you may add a new application that an end-user requested during their session or remove an application that's no longer needed. The ability to modify applications and folders in real time empowers administrators with the ability to promptly cater to changing user needs.

Additionally, applications can be layered or virtualized during an active session based on user policy, thus enhancing the versatility of App Mode 2.0.

Let's look at a real-world example:

Scenario: Subject Switcher for a School’s Computer Lab

Let's imagine there is a high school computer lab that has a laptop/computer for any student who is present for any given period in a day. The teacher of this classroom has multiple periods per day that range in educational subjects including Math, Physics, History, Political Science, and more.

However, each subject has its own set of applications and folder structures which are tailored to the experience required for studying that particular subject. Instead of requiring the students to maneuver around in a large/confusing mess of folder structures, we want to be able to give them the option to switch between different contexts/layouts in the Frame Taskbar to match the class they're attending.

The options for how the end user could trigger the context/layout switch are virtually endless. You could have a custom web page built on top of Frame’s Session API, or even just a Windows application UI that is running in the workload VM. Many customers choose to use the pre-session FGA script to dynamically determine the layout of the Frame Taskbar menu, but we want to demonstrate a real-time process in this article.

To keep things simple with the “how”, we are going to script the Frame Taskbar itself to switch between the different layouts. We want to use the Frame Taskbar to act as a toggle or switch mechanism for adjusting the layout of the menu to match the subject context of the current class.

In the screenshot below, you can see what we are aiming to accomplish. We want the initial/default layout of the Frame Taskbar to present the students with a list of subjects to choose from:

Default Menu Layout

To illustrate what happens when you choose a subject, the GIF below shows what the Frame Taskbar will immediately change to as soon as the “Math” subject was chosen in the menu.

Menu Switch Gif

Additionally, we want to make sure that when we choose a subject to switch to, there is an option at the bottom of the start menu that includes the ability to go back to the original menu to switch between all subjects. In the screenshot above, notice the “Back to main menu” option. When someone clicks on that, the initial/default layout menu will be displayed again. This acts as a sort of “Go back”, or “Go home” option.

Let’s lay out the steps for the workflow that we plan to cover. The scenario we will cover will look something like this:

  1. Session starts and the student will be presented with a Frame Taskbar configuration that we have chosen as the initial/default layout (List of all subjects to switch between).

  2. The teacher instructs the students to switch to the “Math” lab layout.

  3. The student clicks on the “Math” button, and the new layout for math-only applications is now automatically updated. (Note that the “Back to main menu” button is now available).

  4. When the student chooses the “Back to main menu” button, the original layout returns.

Here's what is happening behind the scenes:

During the pre-session start to the student session, an FGA Pre-Session pre-session.ps1 script executes and places the server_launchpad_override.json file into the C:\ProgramData\Nutanix\Frame\Config directory. The server_launchpad_override.json file includes the main/default menu layout. Each application on the menu is a Powershell script that replaces the server_launchpad_override.json file with one that is associated with the selected subject.

  1. The session starts for the end user.

  2. The end user chooses Math in the start menu layout.

  3. The override JSON file is replaced with the math.ps1 (Which includes the Back to main menu app)

  4. The Back to main menu button points to default-layout.ps1 which is a script that replaces the override JSON file with the default layout again

caution

For security reasons, the ability to override default configurations should be carefully managed. Administrators should implement appropriate measures to prevent unauthorized changes.

To be clear, this workflow is one of many ways to handle this scenario. For this blog post, we wanted to provide a clear and concise demonstration of the feature that can be implemented with very minimal effort and documentation.

For this workflow to operate as expected, let's review the prerequisites:

Prerequisites

  1. Make sure the folder/directory C:\ProgramData\Nutanix\Frame\FGA\Scripts\User exists and the definition.yml file is setup to execute pre-session.ps1 (See here for more details on how to do this)

  2. Inside the C:\ProgramData\Nutanix\Frame\FGA\Scripts\User directory, make sure math.ps1, physics.ps1, and back_to_main.ps1 files exist in here (based on the code below)

  3. In the C:\ProgramData\Nutanix\Frame\Config directory, make sure the main.json, math.json, and physics.json files exist (Based on the code below)

Code Examples

Back to Main

back_to_main.ps1
#Toggle the files
$filePath1 = "C:\ProgramData\Nutanix\Frame\Config\main.json"
$filePath2 = "C:\ProgramData\Nutanix\Frame\Config\server_launchpad_override.json"

#Force an overwrite of the override JSON
Copy-Item -Path $filePath1 -Destination $filePath2 -Force

Math and Physics PowerShell Code

note

Since this is only for demonstration with dummy apps, you can create your physics PS1 file based loosely on this math.ps1 file

math.ps1
#Toggle the files
$filePath1 = "C:\ProgramData\Nutanix\Frame\Config\math.json"
$filePath2 = "C:\ProgramData\Nutanix\Frame\Config\server_launchpad_override.json"

#Overwrite the file
Copy-Item -Path $filePath1 -Destination $filePath2 -Force

Server launchpad override -- main.json (Used in Pre-Session script, or placed by Sandbox as server_launchpad_override.json)

{
"name": "root",
"order": 0,
"applications": [
{
"name": "Math Class",
"path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"arguments": "C:/ProgramData/Nutanix/Frame/FGA/Scripts/User/math.ps1",
"order": 1
},
{
"name": "Physics Class",
"path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"arguments": "C:/ProgramData/Nutanix/Frame/FGA/Scripts/User/physics.ps1",
"order": 1
}
],
"folders": []
}

math.json Contents

note

Since this is only for demonstration with dummy apps, you can create your physics JSON file based loosely on this math.json file

{
"name": "root",
"order": 0,
"applications": [
{
"name": "Math Application 1",
"path": "Z:\\Autoruns64.exe",
"icon_url": "",
"order": 0
},
{
"name": "Another Math App",
"path": "C:\\Windows\\System32\\taskmgr.exe",
"icon_url": "https://images.freeimages.com/fic/images/icons/2794/metro_ui/512/command_prompt.png",
"order": 1
},
{
"name": "Back to Main",
"path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
"arguments": "C:/ProgramData/Nutanix/Frame/FGA/Scripts/User/back_to_main.ps1",
"order": 2
}
],
"folders": []
}

Once these files are in place on the Sandbox, you can publish into production and test the results in an App Mode 2.0 enabled Launchpad.

Conclusion

With the implementation of App Mode 2.0, Frame has taken another giant step towards improving and personalizing end-user experiences. By enabling administrators to customize user interfaces, including the ability to dynamically modify the Start menu and application list, App Mode 2.0 provides the flexibility necessary for today's diverse and rapidly-changing work environments.

As we continue to develop and refine Frame, we'll focus on introducing more dynamic customization options to further enhance end-user experiences and meet our customers' evolving needs.

Stay tuned for future updates, as we explore more features and provide more in-depth tutorials on how to get the most out of Frame. Remember, small changes can indeed have a big impact!

Interested in other Admin API blog posts? Click here!

Contact Us

Need help with your Frame deployment, have an idea for a new use case, or just want to learn more about Frame?

Email us at frame-sales@dizzion.com and one of our experts will reach out!

Follow Us

LinkedInTwitter
#workfromframe
Justin Emilio
More content created by Justin Emilio
Justin Emilio is a Senior Solutions Architect with Frame.