30
Replies
I did send it yesterday. It was 13 MB in size. I will resend today.
First, my platform. I test all new builds on a 3-year-old custom built i7 machine that was state of the art when built. It runs the most current version of Windows 10. All hardware drivers are the most current available. All file locations and associated caches are local to that machine and not accessed over a network.
Although several builds have been previously tested, I chose not to upgrade our studio to Br 13 due to the extremely damaged state in which it was introduced, and still remains. Before each new build is tested, I meticulously remove all traces of previously tested builds including a significant number of orphaned files that are typically left behind by an incomplete Bridge un-install process. These orphaned files and folders are left behind at the hidden Windows path destination C:>Users>User>AppData>Roaming>Adobe>Bridge 2023 or Bridge 2024 after Bridge is uninstalled.
Eliminating these orphan files and folders establishes a clean slate for any new install of Br and assures proper migration of data and preferences from the currently installed release version of Br, (currently Br 12). When a new build is installed, a new cache location is created for that build to avoid possible cross-contamination of the stable Bridge cache currently in use.
Beyond the lethargic scrolling issues that you have acknowledged, there are at least two equally maddening performance issues. Combined with the scrolling problems, the newly offered Br 14 is vastly inferior to Br 12 in existing production workflows.
Filter panel delays. When creating a filtered collection of assets from a large group of files in a single folder, (roughly 1600 files half of which are text files 2K<, half are graphic files averaging 2-4 megs. each), there is typically a .5 second delay between clicking on the first filter selection and any observable effect. This lag decreases a bit with each additionally selected filter. This lag increases to as much as 1.5 seconds for the first selected filter when attempting to filter a larger collection of assets in a folder hierarchy when all subfolders are included. (roughly 4500 files, same file type mix) Again, the lag reduces with each new filter that is added. Oddly, de-selecting a filter is almost immediately evident.
No such delay exists with Br 12. Filter selections are echoed instantaneously, regardless of whether the files reside in a single folder, or if many more files in multiple subfolders are included. This newly introduced variable lag is unacceptable in high volume workflows that have never been affected by it in the past.
Folder panel lag. Ever since the introduction of Br 13, furling and unfurling folder hierarchies in the folder panel has become an adventure in wasted time and effort. Sometimes it takes as many as 3 clicks to activate the furling and unfurling of folders. Sometimes it works fine. Sometimes the arrow shivers as if it is trying to unfurl, but nothing happens. Why has this erratic behavior remained present in the public releases of both 13 and 14 but has never been evident in 12?
Workspace corruption. Our studio makes use of more than a dozen windowed workspaces in Br 12, each designed to manage and serve assets to numerous other applications each with their own unique footprint. Most of these workspaces are not displayed maximized on a single monitor, but rather as windowed instances in various positions and configurations on a monitor array adjacent to the applications they serve. Since they are compact versions of Bridge, they have been designed to make the most efficient use of monitor real-estate possible, according to the needs of the application being served, whether it be an Adobe point product or some other company’s software tool.
When upgrading, there is significant corruption and distortion of custom workspaces, some of which have migrated flawlessly for more than 10 years. Ever since Br 13’s first appearance, all custom workspaces are demoted to the back of the workspace line in the toolbar requiring administrative time to untangle, re-sort, and in many cases completely re-design them. All migrated custom workspaces refuse to accept the gridlock feature which is part of the workspace definition.
Due to architecture changes starting with Br 13, vanishing side panels no longer exist. Instead, the two side panels left and right don’t retract completely and waste valuable UI real estate with unusable information. They appear as if somebody left their dresser drawers ajar with socks and underwear hanging out. Nothing displayed is useful until the drawer is manually dragged out far enough to get hold of whatever is contained there. This is a slow and sloppy process, but serviceable in a fully maximized workspace. It creates needlessly wasted time and space when attempting to use a tightly designed windowed workspace that requires efficient use of UI real estate in a compact form factor. Opening and vanishing these side “drawers” in the past was a function of a simple double click on the boundary causing the panels snap open to their designed width, and then back closed again out of sight without any waste of space.
I don’t pretend to understand the code that this behavior depends on. What I do know is that the new behavior presents a loss-of-space issue that has never been a problem in the past. The only work-around seems to be a complete re-design of most custom windowed workspaces. It also forces the creation of several new workspaces to eliminate the resulting clutter and recapture the wasted space. All this is forced by a new design “feature” that brings nothing valuable to the Bridge experience while destroying some current advantages that have existed since the product was first introduced back in 2005. I’m wondering where at Adobe I direct the invoice for all the wasted time, effort, and staff re-training necessary to adapt to this ill-considered design choice.
Here is one example of a Br 12 windowed workspace designed with both side panels fully retracted by default.
Each side panel can be unfurled to its exact designed width when needed with a double click of the mouse. Yes, it’s a very tiny hot spot to click on. However, no manual dragging around is necessary, nor is necessary to guess how far out to drag them out. The correct furled and unfurled configuration is already baked into the workspace and as effortless to access as a double mouse click. That’s important since furling and unfurling either of the two side panels in a compact workspace happens numerous times during an editing session.
Here is what happens when the same workspace is imported into Br 14.
The two side panels are not migrated in the retracted state as designed, but rather fully deployed in widths that are not the same as designed in the original workspace definition. This goes for any migrated workspace that is designed to have one or both side panels fully retracted by default. When the side panels are pushed aside, the thumbnail grid is not the same size as the original workspace, and the gridlock feature is not engaged.
Ironically, the edges of the new side panels that won’t close completely are useless for the newly required dragging since the hot spot for dragging them out and pushing them aside remains the same tiny 2-3 pixel wide line at the edge. Why does this wasteful and destructive new “feature” still exist? Return the behavior to the original intent, would you please?
Sometimes the old ways are still the best ways. It’s wise to listen to expert, highly experienced professionals that employ Adobe’s tools every day.
I believe you can replicate most of your old behaviours – just with slightly different methods. One option was storing Layout unfurled and Layout maximized as separate workspaces. Instead of hitting Tab, you now had to press hotkeys to switch between display variants. I realize that this is no Toggle, but it might work for you.
This maximize subwindow thing can be really cool with the right devs working on them. Blender has complex node-editors or code-editing subwindows that you may quicky toggle maximized. Just hiding left and right dockers would give a far inferior experience. 
AdChoices