I will attempt to make this as brief as possible, but it may run too long for some folks.
In short, the Bridge 13/14 era has been a large waste of time and resources from the perspective of many Adobe customers who have been using Br as an integral part of our commercial business practices ever since it was first introduced back in 2005. I was invited to join the Bridge Prerelease Team by Chris Cox shortly thereafter. I have run my professional workflows through many dozens of prerelease (PR) builds since that time.
My studio currently employs Br 220.127.116.116 Release as the only version of Bridge organizing our productivity. I refused to migrate to Br 13 and continue to reject the idea of migrating to Br 14. Let me be clear. Nothing about what I say here should be understood as advocating that those who have already drunk the Br 13 or 14 Kool-Aid should revert to Br 12. I will, however, encourage those who have wisely remained with Br 12 in light of the Br 13/14 train wreck, to remain patiently persistent and inform Adobe about your dissatisfaction.
Nearly 18 months ago, (May 2022) Adobe introduced the first internal PR build of Br 13. Never in all my years of PR testing have I witnessed a more poorly thought out and destructive build to our studio’s long-established professional workflows. From the destruction wrought by trashed and demoted custom workspaces to the elimination of the multiple window feature, plus a huge laundry list of performance bugs, I found the first PR build as something that would take a very large investment in time just to re-configure our workspaces on a single machine so that it could be tested in our studio workflows. With the additional removal of the multiple window feature, I could not justify that sort of investment in time to do anything more than rudimentary poking around. I told the prerelease Adobe engineers exactly that.
I also informed them that the potential destruction of professional workflows that these changes would demand of Adobe customers would be unacceptable to many whose productivity relies on this application being at the center of those workflows. I was informed that my concerns were “a top priority”.
Six months and several rounds of PR builds later produced no significant changes to the destruction despite repeated warnings that little had changed. It was announced to the PR team that Adobe planned to release the PR version to the newly established public Bridge beta crowd. Adobe was told that this was a mistake and that the build wasn’t nearly ready, but they plowed ahead anyway. More howls from the new Bridge beta crowd, and a few months later, Br 13 was released to Adobe customers in a state that just a few years ago wouldn’t have made it out of prerelease.
Fast forward to July of this year. The first internal PR version of Br 14 was dropped. While the introduction of the shortcut feature was greatly welcomed, as was the re-introduction of the multi-window feature, the rest of the software remained just as damaged and unresponsive as it had ever been. Again, Adobe was informed that this was not ready for prime time. The workspace migration destruction remains the exact same mess that it was in the first Br 13 PR drop 18 months ago, leaving workspaces that have migrated flawlessly for more than 15 years mangled, useless and pushed to the back of the workspace line. This is to say nothing of the hideous lag in performance that makes scrolling through thumbnails, moving files, and other forms of filtration and navigation through an asset base as unwelcome as root-canal, and an unnecessarily large drain on studio time and manpower.
I for one do not consider this as either professional or acceptable. Our studio remains in the Br 12 universe. Unfortunately, now it no longer completely interfaces with the current release versions of other Adobe point products. There exist some simple workarounds for this, but these will degrade over time. Perhaps that is what Adobe is counting on to shut people like me up.
I am not afraid of change if it is productive. I try not to sweat the small stuff. The addition of the keyboard shortcut feature is a shining example. Otherwise, this 18-month process has been heavily destructive to those who are experts in the use of Bridge in professional studio environments, and who have said so privately to Adobe many times during the numerous PR/public beta drop cycles.
I understand the inclination for Adobe to listen to the needs of hobbyists and semi-pros and try to respond to those needs with design mods and additions. However, I am firmly against the idea that those needs, and the resulting changes must severely damage or completely destroy the years-old professional workflows of experienced power-users as a consequence.
Very well put, sir. I totally agree. While the slow performance of scrolling and moving stuff around seems to have been solved (they told me after working on my machine and to be released) I higly doubt that will be the end of it.
This debacle with Bridge 13-14 is unprecedented to me in the industry. I have never seen an app be so horribly beaten up and released in such a bad state that intensive care would be more appropriate. To me it is so serious that I suspect that something very abd has happened at Adobe. I wouldnt be surprised if the entire team has beenreplaced by some summer interns or what not. Or fantastic coders that had to take over by a working code, hold together with scotch tape nad impossible to build on.
Is the state of Bridge known higher up in the chain? Was it even rushed out by order of some new boss eager to "show his qualities". There must be a reason behind all this?
So. If any one at Adobe reads this, and wants to talk to me, anonymously, please contact me and tell me about what happened with the state of the Bridge Team.
This IS serious and affecting a lot of studios that yet has to convert to other apps.
Maz said: "While the slow performance of scrolling and moving stuff around seems to have been solved (they told me after working on my machine and to be released) I higly doubt that will be the end of it."
Can you give an idea of how it was solved? I see lag across the entire platform increasing with file size. I see no such lag in Br 12 once the cache is built.
No idea. They didnt tell me. Just that they've been able tp reproduce it and was going to implement it in the enxt version.
May I ask what platform you are on? Some reports suggest that this is isolated to Windows machines. Are there Mac users experiencing this?
I feel your pain. I am basically an optomist and so when a new relelase of Br comes out I try it. But honestly, I can't use 2024 for any productive purpose. For me 2022 is still the most stable. Maybe 50% of the time when I launch 2024 it goes "Not responding" and after a while I have to kill it. Bummer.
May I ask what platform you are on? Our studio works on Windows machines.
Thank you for sharing your detailed feedback and concerns with Adobe Bridge 2024.
We understand that performance issues and workflow disruptions can be frustrating, We are aware of the scrolling and drag/drop of files for reordering performance issues and working on fixing the same.
Please share if you are facing any other performance issues which is interrupting your regular workflows.
Also could you please share more details about the issues you are facing with respect to workspace migration.
We want to assure you that we are actively aware of the performance problems that users like you have been experiencing. Our team is dedicated to addressing these issues and working on improvements to make Adobe Bridge a more efficient and reliable.
Could you please share a few more details about the “Not responding” experience on launch.. Like if launching bridge with any particular folder/files leads to that state.. Please share a screen recording of the issue and send it to firstname.lastname@example.org.
As requested, I have sent a video clip of a Bridge 2024 session.
I did send it yesterday. It was 13 MB in size. I will resend today.
As an FYI, I never did get a response or confirmation that Adobe received the requested video clip. Went into a black hole.
If they didn't get the first 13MB E-Mail with that clip, it is very unlikely that it went through when sending a second time. Enterprise E-Mail software is often very quite strict and feature-limited. I would recommend using a file-sharing service Like WeTransfer, Dropbox Transfer etc. That way they'll get your clip without bloating the E-Mail. And you can also track if your input was downloaded.
Another option was opening an account at https://adobebridge.uservoice.com/ They allow you to upload attachments. Yet another option was uploading the video to this forum – but you had to put it to YouTube first.
Somehow we have not yet recieved the video.. could you please share this using a file-sharing service.
Also we have released a beta build 14.0.1 which has few bug fixes along with some performance optimizations:
Please try that build and share your experience with the build.
I have dropped the video clip on a Google Dribe and I sent you a message with the link.
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 share a lot of your frustration with Bridge 14. Just one comment on the windows-behaviour change. With version 13 Adobe has indeed dropped a trusted Adobe Standard found in Photoshop, Illustrator, InDesign and several other apps: Hide all panels with Tab. Instead, they now let you maximize any sub-panels, which rather resembles the implementation found in Blender.
The new concept may need some getting used to, but done right, could offer a more flexible experience. Adobe could offer a maximized keywords panel to administer huge keyword lists in several columns – or even Kanban Boards, with drag and drop. No nothing like this is exposed, and I have no idea if the Bridge team even thinks in this direction – but the new implementation would enable such.
I have not fully understood your workflow requirements – but you could test double-clicking any tab title. This should hide everything else and give you the content tab only experience shown in your first screenshot. Another double-click brings back the other panels. There are also customizable hotkeys for maximizing the active panel. I hope this helps a little.
That's a decent idea Poly, and would work in some situations. In my example it's not quite that easy. I demonstrated how the workspace looks with both side panels unfurled, but that almost never happens. The left side is used for navigation, and then collapsed again. IF filtration or metadata is needed, then the right panel gets unfurled. It's either-or in this small of a windowed instance. Both panels unfurled makes the content thumbs and their corrisponding information too compacted to be of much use. Fully maximized spaces can take advantage of this. Not so much with one this small. The only alternative it seems is to replace this workspace with two other new ones, each containing only one or the other side panel.
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.
I understand that this may seem like a simple chore for individuals. Unfortunately, there is nothing at all simple about this in larger studios with multiple users. In enterprise situations It leads one to ask: Other than the addition of the KBSC feature, what new and beneficial features does this bring to Bridge, that make them worth the destruction left in their wake?
Please let’s not forget the fact that even if one were willing to accept the damage/destruction of workflows that have served Adobe customers for decades, the sluggish performance alone is justification enough to avoid this “new and improved” product as long as possible.
Well, it's evident that Adobe is not shy about making drastic changes to their software. I did not follow along, but several massive UI changes in Acrobat will likely have caused an uproar in the print industry as well.
Sometimes I admire that Adobe's development teams dare breaking changes – sometimes I suffer a lot. Regarding Bridge, I have the suspicion that Adobe fatally misjudges the target group for this app. They believe, they have all the data – but quite obviously they don't see the user-group that cannot use Lightroom and isn't well served with a DAM (we're a team too, by the way.).
With the interface remake, one gets the impression that beginner friendliness was the central criterion (see blue focus indicator and huge white space). I doubt that Bridge is considered a serious professional tool internally and that developer resources are released accordingly. If that were different, there would be no need to continue talking for years and years about catastrophic performance.
The bottom line is that both of our sensitivities will not have too much of an impact. I just wanted to offer pragmatic help.
Thank you for the detailed response, we are investigating the issues you have shared.
Also we have released a beta build 14.0.1 which has few bug fixes along with some performance optimizations:
Please try that build and share your experience with the build.
I'm in the same boat and plan on staying with 2022 for now. Br 14 won't show file names in the Content panel anymore, just the first letter of the name, so its completely unusable just from that seemingly intentional and baffling change.
Hi, @Larry29731486lwom, can you please share a screenshot of your Content Panel?
Depending on the size of my thumbnails, I can get at least 5 continuous letters before a space before they are so small that no characters are available. Then, as I expand the size of my thumbnails, I can get more and more before I finally see the full name.