Get read of the modules

Question

or at least combine library/develop
I also did not find a user that uses quick-edit - so why keep it?

Answer 1

[email protected] wrote:
> I don't see the issue with the time it takes to switch.
I agree that LR has done well in making changing modules a one-keypress
action. But there's more to it than that - switching modules switches the
behavior of the applicaation. The eyes and brain have become used to a
specific screen layout, and so there's a map in your head of what's where,
and suddenly that changes, so you have to adjust. Your hands may have
become used to how far to move the mouse (and in what direction) to perform
a specific action, so you have to adjust to *that*. Your fingers have
become used to a set of keypresses to perform actions, and now they need to
swap in a different set. All of that takes brainpower and has an effect on
your ability to work smoothly.
There's a term in software engineering called a "context switch" (sorry if
you already know this - I don't know your background). When a computer is
running some task, and it's time let another task have the processor, the
computer saves the state of the current task, loads the other task's state
into the current processing space, and then lets the other task do its
thing. That's the context switch, and it can be intensive. The actual
trigger to swap tasks might be a single instruction (the equivalent of a
single keypress in LR), but it causes a cascade of processing that causes an
overall degradation of performance.
Even though we aren't computers, people have the same basic experience.
When you're deep into some task, and somone interrupts you to ask a simple
question, it can take a few seconds for your mental context switch before
you can understand the question and answer it. Then it can take you
*minutes* to get back into your original task as deeply as you were in it
before the interruption. That's why people perform better when given large
chunks of uninterrupted time.
The module switch in LR introduces a context switch (admittedly to a lesser
degree than I just described), and that's where part of my objection comes
from.
The second part comes from my experience in user interface design (I've been
writing software for all of my adult life, and focusing on user interface
for about the last 9 years). Every conversation I've ever had with a user
has contained (among other things) one basic request: I'd like to be able to
do anything from anywhere. For example, the last app I worked on had
something like LR modules - you were looking at either a "Manage Computers"
area or a "Reports" area. Both areas had a typical 3-panel layout -
navigation tree on the left, list of things on the top right, and details of
the selected thing on the bottom right.
In the case of "Manage Computers", the navigation tree showed groupings of
computers, the list showed computers in the current group, and the detail
area showed the selected computer. In "Reports", it was groups of reports,
reports in the current group, and the selected report.
One request from users was to be able to run reports on the currently
selected computer when in the "Manage Computers" area. And here is where
the app differed from LR: you didn't get switched to the "Reports" area to
do it - the report ran, and its details showed up in the "Manage Computers"
detail area. If we'd taken the LR module approach, we'd have switched you
to the Reports area to run the report. You'd have lost the whole context of
which computer you were looking at, and so on. That was considered jarring
to our users, and I agreed with them.
By analogy, if I'm looking at an image in the Library module Loupe and I
want to crop it, the crop rectangle could be made to show up right there in
the Library module Loupe, instead of switching me to Develop to put it
onscreen. That's much less jarring, even though it's the same number of
keystrokes.
Rob Freundlich
"Males are biologically driven to hunt giraffes" - Newt Gingrich
"Some folks you don't have to satirize - you just quote 'em" - Tom Paxton