Switching module should not open an new windows

[PaulPoulain]

I find counter-intuitive & not good from ergonomics usual behavior to have the "change module" link opening in a new windows.
We had a discussion on coral mailing lists, see comments added in a few seconds

[PaulPoulain]

Steve wrote:

• There are in fact things that I routinely do in one module that require me to open a separate module, make a change there, and go back to the original module in its own tab/window to finish inputting information. If we defaulted to always open in same browser window, this would result in loss of work. That is the main reason I am opposed to this proposal. This is particularly true when creating a resource record, realizing that an organization record doesn’t exist, creating that organization record (currently, in a separate window/tab), or modifying something in that record, then going back to fill out the rest of the details in the resource record. But there are other examples I could think of where there is potential loss of work. Perhaps I’m alone in approaching the work in this way; who knows, but I don’t think I am.
• As Eric pointed out, it is also helpful to have two copies of the same module open at times so as to be able to compare or copy/paste information.
• Just because a feature change is easy to implement is not persuasive, in my view. I’m particularly leery of changing default CORAL behavior.
• I am aware of usability standards and best practices and concur with what Jeff Mudge wrote about the normal reasons why a new window/tab is needed vs. open in same browser window.
• A seemingly simple change like what has been proposed needs more careful thought and consideration of ramifications, in my view. We’ve not been great at thinking through that carefully at times in the past, which is why I tend to be cautious now.
• Once we have fully implemented CORAL 2.0 (a release candidate version will hopefully be ready soon, followed by a production release), I’d like to engage the broader community in discussing what should be on a development roadmap, and establish priorities for future enhancements.
• If BibLibre or anyone else feels the need to change the default behavior for moving between modules, you can always do so in your local code, but I’m reluctant to rush to a conclusion for the primary codebase at this time.

[PaulPoulain]

My answer to Steve comment:

• There are in fact things that I routinely do in one module that require me to open a separate module, make a change there, and go back to the original module in its own tab/window to finish inputting information. If we defaulted to always open in same browser window, this would result in loss of work. That is the main reason I am opposed to this proposal. This is particularly true when creating a resource record, realizing that an organization record doesn’t exist, creating that organization record (currently, in a separate window/tab), or modifying something in that record, then going back to fill out the rest of the details in the resource record. But there are other examples I could think of where there is potential loss of work. Perhaps I’m alone in approaching the work in this way; who knows, but I don’t think I am.

I really disagree, and have given some pointers explaining why this is a mistake: if we remove the open-module-in-a-new window/tab feature, it does not mean it will not be possible to do it anymore : just use CTRL-clic instead of clic on the module link. But the user has the choice. Currently, the user has no choice, the module is opened in a new window, no choice.
It's a usability mistake !

• As Eric pointed out, it is also helpful to have two copies of the same module open at times so as to be able to compare or copy/paste information.

yes. And removing the mandatory "open in another window" does not change that. Just ctrl-clic instead of clic ! I'm sure you're using it on many websites !

• Just because a feature change is easy to implement is not persuasive, in my view. I’m particularly leery of changing default CORAL behavior.

If the behavior is wrong, I think we must change it.

• I am aware of usability standards and best practices and concur with what Jeff Mudge wrote about the normal reasons why a new window/tab is needed vs. open in same browser window.
• A seemingly simple change like what has been proposed needs more careful thought and consideration of ramifications, in my view. We’ve not been great at thinking through that carefully at times in the past, which is why I tend to be cautious now.

I'd like to continue the discussion, because I'm still not convinced by your arguments, and think mine are more relevant (again : with my proposal you can still achieve what you want, with your proposal, I can't achieve what I want. So my proposal is more flexible)

• Once we have fully implemented CORAL 2.0 (a release candidate version will hopefully be ready soon, followed by a production release), I’d like to engage the broader community in discussing what should be on a development roadmap, and establish priorities for future enhancements.

+1

[PaulPoulain]

Steve last comment:
However, I think there is a broader issue at play here that relates to the role of the governance structure for the CORAL project that was put in place about 1 1/2 years ago. You are on the Steering Committee (SC) and participated in defining that governance structure. (If anyone else is interested in reviewing this governance model as it currently exists, go to https://github.com/Coral-erm/Coral/wiki/Steering-Committee.) A key aspect of what was put in place is that one of the most important tasks for the SC is to review proposed changes to the master code.

In no way do I think community discussion of this or any other functional change should be limited, but I think it would be appropriate to bring this issue for discussion and review to the SC, especially given that this is not a simple issue; it has broader ramifications for those who use the system day-to-day. I’ll start that discussion within the SC and let’s see where that goes, and report back to the community.