Skip to main content
Adobe Photoshop Family

26 Messages

 • 

390 Points

Fri, Dec 2, 2011 11:37 AM

Not planned

4

Lightroom: How to make Library mode much more helpful and attract many people who have been put off

I tried to like Lightroom but like many people found that Library mode didn't work the way I wanted. When I criticised it some time ago I was told very clearly that the problem was me and not Lightroom. I just needed re-educating to understand why I was wrong.

Well I do understand Lightroom and the design reasoning, and after much thought I still think my views are valid, and I decided to try to help by setting out how Library mode could have an option added that would make its use far more intuitive, in particular for new users. I really think that there are tens of thousands of people who could flock to buy it if it had this implemented.

Please note that this change would be an OPTION, so existing users would not be affected in any way. People who like the way it works now would be unaffected. So here it is...

How to change Lightroom so it works intuitively for everyone, in three easy steps (which would be turned on as an option, and all fit together)...

1. When the user navigates the Folders, and clicks on a folder, automatically update the catalog with the photos that are in the folder. (The feature could be called Auto-Sync). If they have been deleted, remove them from the catalog. If there are new ones, add them to the catalog.
Benefits: Very often no need to Import or to Sync - it just works.

2. When the user is looking at Folders, allow F5 (Or View/Refresh) to refresh the folder view. For example there may be new folders.

3. Make Folders work with the key missing Explorer features added, so it can be used like Explorer. Make Cut, Copy and Paste work, so you can select folders or photos, Copy, then select another folder and Paste. It isn't hard! Naturally they would be added to the Catalog automatically. If you do Cut and Paste, the Catalog would be updated with the new location. There seems to be no down-side to this idea at all!

On a deeper level, the issue is that Lightroom (sensibly) goes half-way to being a total photographic database. Everything is in the catalog/database except the photos themselves, they live in the filesystem. My suggestion makes the relationship between the database and the filesystem much more intuitive and automatic.

Please accept this as a helpful suggestion and not an attack on an excellent product.

Responses

1.3K Messages

 • 

22.5K Points

9 years ago

You do need to go back and refresh your understanding of the concept - Lightroom tells you where stuff should be, not merely what happens to be there. Imagine someone is using your computer and deletes or copies a few pictures in Explorer/Finder, or let's say the drive starts failing and wipes them out. How does your point 1 alert you that something is wrong?

Remember that "options" do impact on others who don't use them - development time is wasted and cannot be devoted to features you value.

704 Messages

 • 

8.5K Points

9 years ago

Honestly, we are way past the era of depending on a file system view, and the limitations thereof, for managing large datasets.

Lightroom gives you the tools to go beyond folders and slice across your dataset using a variety of powerful techniques.

Few people need to store their photos in anything more than a simple dated folder structure, and run the library with the Folder section completely disabled.

946 Messages

 • 

13.8K Points

I run my system with the collections and keywords sections disabled. That's with about 200,000 images.

4.5K Messages

 • 

76.3K Points

9 years ago

Richard,

I hear you - importing and folder synchronization... - can be a bit of a hurdle, especially at first...

I have no big problems with present design in this regard, however I do like your idea of a folder view that includes what's *not* in the catalog - with a more expedient way to add that stuff...

I also think automatically adding / deleting stuff would be a disaster for Lightroom, and that you need to make peace with the fact that Lightroom's library is a catalog database view, and that importing, deleting, and folder synchronization is how things get in and out...

Rob

10 Messages

 • 

712 Points

9 years ago

Richard, Adobe Bridge (which comes with Photoshop/Creative Suite) may be the solution you are looking for.

26 Messages

 • 

390 Points

9 years ago

Peter, thank you for your suggestion.

I am well aware of Bridge, and its capabilities. I was hoping that Lightroom could be brought up to the the same level of file handling.

Ideally there would be a single program combining Bridge and Lightroom. This would make perfect sense. The basic version wouldn't have the DAM features or the database and various other things would be missing. That basic version would be included in Photoshop. Buying Lightroom would get one the full version, which would do everything Lightroom does, but upgraded as I described.

Unfortunately it won't happen because I understand the two teams regard each other as competitors and are therefore unlikely to work together. A recent public statement by the head of Lightroom said this quite openly.

I've been amazed by the blinkered responses to the suggestion, and the way it was quickly marked to be discarded. My core argument is that since Lightoom's database does not contain the photos themselves, which are in the file system, the two should be as tightly connected as possible. Seems obvious to me. And for anyone who says it is impossible, take a look at ACDSee Pro, which already does exactly what I am describing.

1.3K Messages

 • 

22.5K Points

9 years ago

Blinkered? Are you having a laugh? Your "tightly connected" is a "browsing" app which is distinct from the concept of a database which catalogues where images should be. This "should be" versus your real time is an important difference in DAM and allows LR to safeguard your picture collection, showing you when stuff has gone missing and allowing you to reconstruct your folder system after a catastrophe. Browser-based workflows like you propose merely reflect what's there now, not much use when things go wrong, but if that's what you want there is Bridge with its different (rather than competing) character and development teams.

As for your proposed changes being "upgrades", well, I'm just off to polish up my Newspeak....

26 Messages

 • 

390 Points

9 years ago

No, I wasn't joking, and I continue to be surprised by your attitude. I understand exactly how LR works. A browsing app need not be distinct from the concept of a DAM. Only in the current LR implementation. Please open your mind to the possibilities I open up.

I note that the ONLY benefit you can come up with for the present system is that when you lose files the system goes wrong (in the sense that you can't see files that don't exist, and doesn't display files that do exist!) and you can see that you have blundered. That IS a valid point that you make, but that issue could be tackled separately.

In contrast the changes I propose would make the system hugely more helpful and would I believe increase sales. Many people have rejected LR because of its file handling limitations and its failure to automatically keep the database in line with reality.

There is no point in pointing me at Bridge. It is not a DAM.

Why are you so fixed in your belief that you can't have a DAM which is automatically tied to the file system? As I pointed out, have a look at ACDSee Pro. It is a DAM, with a database with many features similar to LR. When you go to a folder, it automatically updates. No need to sync. And it works like Explorer. You can copy and paste.

And don't forget that I suggested that what I proposed could be an OPTION. So you could continue to work in your way, and many new customers could work the easy way. So why oppose it?

1.3K Messages

 • 

22.5K Points

9 years ago

An option still means an unnecessary feature that runs counter to the very concept of Lightroom, and equally seriously to developers' time not being available for genuine upgrading. And of course, the database is for far more than safeguarding your pictures - though your "valid point" is what the rest of us would call "critical" - but I rather think my listing other advantages for someone who throws round the words "blinkered" and "blundered" might be wasted!

26 Messages

 • 

390 Points

9 years ago

I don't do insults, so I shall ignore your last sentence.

If you really have other reasons why the database should be disassociated from reality, please give them.

Please remember that I think the database itself is excellent and I'm not criticising it at all. It doesn't need to be changed in any way to provide the features needed.

It is the concept of Lightroom that needs a slight tweak. The software changes needed would actually be quite small.

946 Messages

 • 

13.8K Points

"If you really have other reasons why the database should be disassociated from reality, please give them. "

A lot of people use external drives to store their images, and disconnect them when they go to the field. In the current implementation, they can still browser their previews. In your approach, the entire drive full would be deleted from the database when the drive is disconnected.

26 Messages

 • 

390 Points

No, it wouldn't. It is impossible to cover every little detail in my description, but all that would happen would be... nothing. With my suggestion the catalog for a folder gets updated automatically when you select that folder. When you did this for an offline folder, it simply would not update. It wouldn't know what changes might have been made, so it would do nothing. No catalog data would be lost.

1.3K Messages

 • 

22.5K Points

9 years ago

Oh, I see, using your words back at you means it's you that is being insulted. Right.

Where I think there's room for some change is in auto import where we have a watched folder concept, previously mostly useful for tethering. That might be extended so you can mark other folders as auto import, and you'd need safeguards for the numpties that would use Explorer/Finder to move files that are already in LR into the watched folders, and more. Even that limited change is a lot more than the developers can do over a pizza, and your "reality" upgrade is a few quite small changes?

26 Messages

 • 

390 Points

9 years ago

I would ask you to go back and read the descriptions of the three changes suggested in the original message. These are not difficult changes, nothing like as complicated as the change you describe. There are no database implications. It is just a little extra code in one module. It is not a lot of work. I estimate 4 pizzas worth, by your measuring system.

But the benefits would be huge, it would invite into the Lightroom fold many users who have previously rejected it. The problem I have putting this over is that existing Lightroom users are, by definition, happy with the way it is, so they see no reason to change it. I'm asking on behalf of the many who have looked at it and rejected it.

I also think that if Lightroom 5 had this upgrade, it could be used as a significant marketing feature of the product.

My later suggestion of a single integrated Lightroom+Bridge would take a lot of work and I can't see it happening, however logical.

Champion

 • 

5.1K Messages

 • 

93K Points

9 years ago

Richard,

You raise a good point that I've also thought about -- is it possible to have a digital-asset-management system that provides the capabilities we associate with "database" programs, but that also reflects the current file system like a "file browser"? Users could apply, filter, and sort by metadata very quickly and aggregate into sets (collections and stacks) independent of the folder structure, but they could also manipulate images and folders using Finder/Explorer or any other file-system tool as well as the application. While I'm very comfortable with database programs like LR, like you I recognize that there are many users who are not or who have long-standing existing workflows intimately tied to traditional file manipulation, and such users will indeed resist database DAMs.

In addition to ACDSee, Windows Live Photo Gallery takes this approach. They wanted a consumer app with the ease of use of iPhoto but that didn't copy photos into a "library" ghetto separate from the user's normal files (which confuses users similar to the way that database DAMs do). You can search by date, tags, and other metadata very quickly (it uses database technology under the covers), but to the user, it's essentially just an extension of Windows Explorer. I think they succeeded -- I've tutored a number of non-sophisticated casual users in the use of both programs, and I find that WLPG is easier for them to learn and use.

WLPG is targeted to a much different audience, of course, and it doesn't provide collections and stacks, but that's not a fundamental limitation of the approach. (Bridge, a "file browser", provides collections and stacks too.)

However, I do think that moving LR very far in that direction is probably a very large undertaking. I'd think that as soon as they started trying to make the current underlying database reflect file-system changes in real time, Adobe would have to make fundamental, large-scale changes in both the user-interface design and in the underlying implementation. This is just my educated guess, and not being intimately familiar with the LR implementation, it would be hard to turn this from a modestly informed opinion into an authoritative pronouncement. Perhaps the features you suggest in your original post would be a useful step in this direction and more easily implemented.

26 Messages

 • 

390 Points

9 years ago

John

Thank you for your comments. I agree your examples demonstrate how it is possible to take this approach and how intuitive it is for users.

I wasn't requesting large-scale changes, or any changes to the visible interface. If you work through my list of changes in the first message they are very modest. I have a great deal of experience designing and building computer systems, and although not of course familiar with the internals of LR, these do not seem a lot of work. I'm not asking for any more changes beyond these, I think they would have a dramatic effect on take-up by new users.

4.5K Messages

 • 

76.3K Points

Richard,

Would you use a plugin that could do it, or would you only consider a native solution? Or are you now beyond all this and only thinking altruistically about new users?

Rob

26 Messages

 • 

390 Points

I don't see how this could be a plug-in.

4.5K Messages

 • 

76.3K Points

A plugin could keep track of everything on the filesystem - under your root photo directories, and auto-import new files. If files have disappeared, there could be some options for how to handle it - e.g. prompt first before auto-removal from catalog, and if you answer "don't remove - they're just offline", remember that answer.

It actually would work quite well, although it would bother me knowing that it's busy keeping track of stuff that 99% of the time is of no consequence.

Begging the question of why not just issue a folder-sync instead of going through the import dialog box, it does the same thing, albeit two steps instead of zero. - confusing for new-comers, but you're not a newcomer anymore, right?

26 Messages

 • 

390 Points

OK I can see that a plug-in could address suggestion 1. But what you propose is a feature that would go around looking at all the folders. What I proposed was much simpler - it only looks at a folder when you select that folder. When you do that, it syncs automatically.

4.5K Messages

 • 

76.3K Points

So like the folder-sync, except without having to click through the dialog box. eh? Are you familiar with the folder synchronization feature?

26 Messages

 • 

390 Points

Yes I am, and yes, that is the basic idea. It would need to be optional to allow it to work as it does now, and one would be able to choose what it would do when it finds changes. For example...
New photo appeares in folder? Add to catalog/Tell me/Do nothing
Photo vanished from folder? Delete catalog entry/Ask me/Do nothing
Photo changed? Ask me/Do nothing

4.5K Messages

 • 

76.3K Points

So two advantages over the present folder synchronization:

- No need to issue folder-sync manually/explicitly.
- Each answer is individually rememberable - so one could have new photos always imported, but changed photos and vanished photos require approval, etc.

Am I getting it yet?

26 Messages

 • 

390 Points

Correct. These would be preferences. Once set they would stay in operation. You would never need to sync again, everything would work quickly and automatically.

4.5K Messages

 • 

76.3K Points

As it stands (Lr3), plugins can easily add new photos, but they can't remove them, and auto-syncing changed photos via plugin may be a little iffy...

I wonder if a simple plugin to check for new photos when folder source changes and automatically import them would be of interest, since Adobe is unlikely to budge on this anytime soon, given their quick "Not Planned" response.

Just out of curiosity, where are these photos coming from that you would want to be auto-imported. I think most people import from a camera card, or copy to a new location on hard disk, then import from there. Are you pre-processing with another app that is doing the distribution into the final folders that you want Lightroom to see?

26 Messages

 • 

390 Points

If a simple plugin could do that, that would be good news.

To answer your question the photos could have been manually copied from a card. They could have been moved around in Explorer. Or perhaps the user wants a folder structure and has moved all the photos into new folders. Or then changed their mind and moved some between folders. Or deleted some that are not required. In fact any change of photo location for any reason.

I personally like to keep my photos in a tightly defined complex folder structure which predates Lightroom by many years. So when new photos have been taken, they need to be placed in a new set of folders in that structure. But this is just my preference, everyone has their own.

4.5K Messages

 • 

76.3K Points

If you only use Lightroom for deleting or moving photos and/or photo folders, doesn't that solve a big part of the problem?

When I first started using Lightroom, I constantly rearranged stuff in Explorer, as I was used to doing before Lightroom, then had to resync in Lightroom - I just don't do that anymore.

26 Messages

 • 

390 Points

Yes, that's exactly what I would like to do. And that is why it needs suggestions 2 and 3 above implemented. I need to be able to create, rename and delete folders, and cut, copy and paste groups of photos between folders and so on. At the moment one has to go out to Explorer and do the file manipulations, then to back to LR and resync.

I know some people who use LR simply depend entirely on the LR database. I want to also keep my existing folder structure and file naming conventions.

4.5K Messages

 • 

76.3K Points

So, if Lightroom's "file manager" were as capable as Explorer, you'd be happy enough maintaining your folders/files in Lightroom. But as it stands you feel you need to go outside to do the manipulation, then back to Lr to sync. I can see why this would be a pain.

I think I see the dilemma now, and agree that cut/paste should be supported and drag/drop should be more controllable.

This might be an idea that could be pushed through, and if so, do you still need the other aspects of your request? - i.e. auto-sync??

26 Messages

 • 

390 Points

You have a good point. If one could do all the file operations inside LR, and that includes cut, copy and paste (file copy is currently impossible), then there would be far less need for the automatic sync of the selected folder. One could live with manually syncing.

But the three suggestions do work naturally together. Then one can manipulate the file system (including adding new files from outside LR) with the catalog automatically keeping in step.

4.5K Messages

 • 

76.3K Points

Sounds good Richard.

Recommendations:

- Make a new feature request for better file handling, which *excludes* the stuff about auto-sync. This will fit in well with existing Lightroom perspectives, and may gain traction.

- Add your +1 vote for the functionality necessary to properly support your "niche" druthers via plugin. (When Adobe says "Not Planned", they mean "Isn't Going To Happen Anytime Soon").

Sorry for not rounding up the links, but look for stuff like catalog operations for removing photos, and renaming/moving folders and files.

Rob

26 Messages

 • 

390 Points

Rob: Thank you so much for your support and suggestions. As you have probably guessed this is my first visit to this forum and I'm unfamiliar with its workings and psychology and as a result probably went about it the wrong way. You obviously know what to do and how.

Is there any way I could persuade you to tackle this, and I'd follow behind supporting it. You could just copy and paste and tweak the text from my first post.

4.5K Messages

 • 

76.3K Points

Richard - you're welcome.

If I were to post FR/Idea, it would be:
============================

Title:
-----
Lightroom: Cut & Paste folders / files

Body:
------
Please support Cut & Paste of folders and files.

Drag n' drop is too squirrely, and anyway some folks are more used to doing it that way.

Reminder: SDK support for delete/remove, rename, and move photos & folders also desperately needed.

Thanks,
Rob
=============================

Do you need Copy & Paste too - wouldn't that result in duplicates? Or would you just want it for folders and then just copy the name (empty folder).

?

R

26 Messages

 • 

390 Points

It needs to support both drag and drop and cut/copy/paste, and also the keyboard shortcuts Ctrl X C and V.

I realise that Copy/Paste is a sensitive subject. Purists would argue that you should never be allowed to make a copy since the pure concept of one original and everything derived from that must be enforced. I understand that point of view but should users be forced to worked that way even if they want the freedom to work as they wish? Are there really no cases where you might not need to make a copy of a file? I also have a feeling that when the user has JPGs in their system there might be an argument for it being allowed. So yes, we should have copy/paste.

I didn't know about the SDK issue - that sounds an important point.

I think that is everything covered. Do you think you might submit it now? (My name is probably mud.)

4.5K Messages

 • 

76.3K Points

Richard,

Some of the best people are impure, but it helps to know the purpose for various features. (and if I'm going to submit the request (not sure I will yet), I would certainly want to be able to justify it).

For example, if somebody has "Don't import duplicates" checked in the import dialog box, do you still allow copy/paste? (Do you have that option checked?).
Should it be allowed, but choose unique names for the copies?

Me? Never, ever, ever, do I want to have a duplicate photo in my catalog - how about you?

Rob

1.3K Messages

 • 

22.5K Points

"....should users be forced to worked that way even if they want the freedom to work as they wish?"

Lightroom doesn't enable every conceivable workflow, does it.

"Are there really no cases where you might not need to make a copy of a file?"

Sure there are cases, but you understand LR also aims to steer people away from physically duplicating files and into a metadata-based workflow. That said, your Copy/Paste metaphor is less potentially risky and demanding of developer effort than the "reality" point #1, and Cut/Paste does address other problems (have you ever tried dragging one folder in a long list of folders?).

"My name is probably mud"

You're as good as your next post. Just don't refer to others as ignorant or blinkered. Try ridicule instead!

26 Messages

 • 

390 Points

Rob, to answer your question aboiut duplicates.Since the person wants to duplicate the file/folder, the wishes of the user are what the program should obey. I think it is quite different to the "don't import duplicates," which is mainly to stop wasting time bringing in data that is already there. And leave the name alone. If the user wants to change the name they can. So in my view the user takes precedence over the pure approach, even though I agree the system should encourage the pure approach.

I've designed databases and I can tell you that the moment you (sensibly) make something impossible, a user pops up who finds a reason to want it. Allow for one wife, and then you find someone with two for example. Allow for two and then they get four.

4.5K Messages

 • 

76.3K Points

Richard,

Far be it for me to want to keep users from doing what they want to do.

I'm probably not going to submit this FR/Idea for you, but I don't think you are on any kind of bad list - Adobe mostly takes ideas for their own merit.

I do however think it may help your case to explain how you would use copy/paste. "A user may want to do it" is perhaps not strong enough.

PS - When Lr4 SDK is released, I may revisit options for a plugin-assisted solution.

Good luck,
Rob

26 Messages

 • 

390 Points

Rob, If I'm going to have to do it - are you sure you can't be persuaded, you obviously know an awful lot about this - please can you tel me...

1. When you write "FR/Idea" what does the FR stand for?

2. Do I simply put a new message in the same place where I put my original one?

3. Do you have any other advice about how to write it compared to the way I did it this time? Be blunt.

4. Can you give me a description of the SDK shortcomings that I can include?

4.5K Messages

 • 

76.3K Points

Hi Richard,

FR stands for "Feature Request" - sorry for acronymization...

You'll be fine submitting a new 'Idea' - maybe something like:

Title:
-----
Lightroom: Copy/Cut & Paste folders / files - like Explorer & Finder...

Body:
------
Please support Copy/Cut & Paste of folders and files - via context menu and keyboard.

Drag n' drop is too squirrely, and anyway some folks (like me) are more used to doing it with the keyboard, like they do in their operating system.

=============================
(feel free to change the wording so it sounds more like you and less like me...)

You can leave out the part about the SDK - I've already submitted that stuff as separate 'Idea's.

Rob

26 Messages

 • 

390 Points

OK I've just done it. Please take a look and support it, anyone reading this. Thanks. Here is the link:
http://feedback.photoshop.com/photosh...

4.5K Messages

 • 

76.3K Points

Nicely done.
-R

1.3K Messages

 • 

22.5K Points

9 years ago

I've looked over them again and I don't think you appreciate how grossly you are oversimplifying the implications of what you suggest. For instance, take your point 1 - automatic deletion of [the LR record of] files that are no longer in the folder and importing any that now are. So, these deleted files - what happens to the editing work that was done on them? Is it retained in the catalogue? Or written back to - back to where, as they're gone? So there's going to have to be some kind of automatic writing of XMP as long as LR has the files available. [You're going to need that if the user has deleted the files from one folder and put them in another which subsequently gets imported.] That's the garlic bread eaten. What about all the LR metadata that isn't currently saved to XMP? More development hours and we're into a long lunch hour now. Now what about folders that are offline - either because the drive is shut down or it's dead, or because you've deliberately deleted the folders in Explorer. Whoops, one click and they're no longer in Lightroom. So you'd be into code branching for folders which have changed and those that have gone missing etc. By the time you work through such permutations you're into an in house 24/7 Pizza Hut.

And the app as a whole would still be over these folks' heads!

26 Messages

 • 

390 Points

9 years ago

John

No. You seem to have completely misunderstood what it would need to do. I never said to automatically delete files. If files have already been deleted by the user, then it should remove the catalog entry for that file.

I would happily explain it to a developer, but you seem so utterly opposed to this type of change that it doesn't seem likely I could ever convince you.

If you want to find out what it is like I suggest you download the trial of ACDSee Pro and try it. It is incredibly simple. Please note I'm not recommending that program to anyone, just using it as an example of how this particular way of working can be made to work very easily.