P: Integrate Library & Develop Modules

I could easily see this idea extrapolated to encompass all of Lightroom.

Note: Its really only a problem worth solving in the case of lib+dev, but just for grins (and consistency), how about:

Instead of modules which define both main (center) panel content and side panels, simply separate those. One keystroke or click dictates center pane content, and independent keystrokes or clicks dictate side panels.

This way, one could make a last minute dev adjustment before printing..., or enter a forgotten keyword before uploading to the web...

I mean, there is plenty of room on the menu bar for the slideshow, print, and web menus even in library/develop mode... and, the slideshow, print, and web modules really don't need to consume a lot of context-dependent keystrokes (do they?).

PS - I don't use slideshow, print, nor web module - so this is all a don't care for me personally - just an idea...

PPS - I'm not saying the side panels couldn't also default to a more appropriate set when switching main/center-pane content, but the gist of this is that any side panels could be made accessible regardless of center-pane content.

Repost of my latest thinking from one of the other threads:

"Develop is slowly acquiring Library's features (the last one added was collections) and it's had quite a few of them from the beginning (i.e. filmstrip). Now some of the shortcuts are starting to merge (Survey was the last one changed). So, they just need to keep moving in this direction - add relative adjustments and folders to Develop, add a multi-view mode (with zoom) and make filmstrip multi-row and you pretty much don't need library anymore except for metadata. Then make Library much more dedicated to metadata with things like a full-screen keyword view and other such things to help heavy metadata users and everyone will be happy."

I would add that Develop should make better use of the Library previews as well.

I think having to pay mind to which module one is in invalidates the efficiency of keystrokes. It's a huge hindrance to productivity. Breaking down the barrier between the Library and Dev module should be of the utmost priority. New features are less important than streamlined workflow of existing features.

I wish this were done along side of the updated 2010 rendering as improved quality and efficiency go hand in hand. New gizmos are of secondary importance to quality/efficiency, for my needs.

One of my least popular sayings is:

"The UI doesn't matter (except when you're learning)".

In other words, after a while it becomes second nature to know whether '\' will get you a library filter or a before-after comparison.

Put another way: once you learn what to do, you just do it...

So, for me, the single biggest factor is the switching lags. I know for others, the context issues are more critical (especially newbies).

Anyway, without a doubt, I'd prefer the ACR Cache / Preview business to get straightened out so one could cull / review in either mode without penalty, and switch just for a quick look at the other modules panels.

I dont think we are doomed forever that dev mode will always be slow. I think there just needs to be a change to refine the image displayed over time. In other words, a jpeg preview would be fine in dev mode too, for a few seconds. At present it goes up for a moment, then gets prematurely replaced with something worse - oops.

Also, intelligent look-ahead (e.g. one should be rewarded for sequencing orderly in the same direction), background processing, and ram usage would help. For example, if you have a bunch of photos selected, Lr should not rest until an instant preview/cache entry is available for all - in ram if possible, else on disk, and a reasonable attempt should be made to predict which image you may want to view next (the look-ahead/reward thing I was mentioning).

CPU & Ram work for free once paid for - I say "use 'em!" And those of us who resist the creation of 300MB tifs (or have plenty of disk space even so) have plenty of room for ACR cache entries to go beyond the most rudimentary "not quite rendered even" state - whatever that means...

R

Rob, you make some good points. I agree that mode-dependent keyboard shortcuts should be avoided in general.

However, I don't think there is a big GUI problem at the moment. The biggest issue for me are module switching lags. Module switches should be as much a "workspace swap" as possible, i.e., there shouldn't be any lags caused by re-renderings, for example.

Once such lags are eliminated, your requirement of "be able to view photo-info/metadata in mid-develop" would be addressed, wouldn't it? I don't see a problem in quickly using "E", then make the metadata changes, and then use "D" again, as long as the transition doesn't take longer than swapping out the panels.

One thing that bugs me about the Develop module is that I cannot flick through images as quickly as I can in the Library mode. I don't like to switch to the Library mode for quicker navigation. However, I somewhat see the rationale for why image switching doesn't work as quickly in the Develop module. When you develop an image you need the best possible view of it and producing that takes a bit of time. Entering the Develop module implies the commitment to invest that time.

I would appreciate anything that could be done to avoid unnecessary re-renderings (e.g., a switch from Develop to Library and back need not involve a rendering at all) but the whole matter isn't as easy as simply asking for two modules to be combined into one. Currently each modules focuses on a particular task and is optimised for that. That counts for something too. I think all we should be asking for is to make transitions between modules/workspaces as quick/painless as possible.

BTW, it should not be necessary to switch to the Library module to enforce the rendering of previews so that they are instantly available in the Develop module (I sometimes develop several images in sequence and when I step through them in the Develop module, I first see the unedited version for a moment until the final rendering kicks in; a visit to the Library module fixes this preview-cache-update problem).

This is not top priority for me either, but if Adobe has Lr ripped apart already, I think this would be a more favorable way to put it back together...

This is not top priority for me either, but if Adobe has Lr ripped apart already, I think this would be a more favorable way to put it back together...

Let Adobe do it if they've got time on their hands! Otherwise, the problem is completely overstated.