Copy to (duplicate to)

The inclusion of a ‘Copy to’ or ‘Duplicate to a location’ functionality within a software application could be highly advantageous for users. At present, the duplicate feature seems to be limited in its capabilities. It only allows users to create replicas of information within the same sub-topic. Additionally, this process automatically appends a numerical suffix to the duplicated content, for example, 1, 2, 3, and so on. While this may be beneficial within the same sub-topic, helping to differentiate duplicates from the original content, it becomes cumbersome when users desire to ‘Copy to’ or move selections to a different location.

The automatic addition of numerical suffixes to duplicates requires users to spend additional time on manual editing, especially when the copied content needs to be transferred to a different location. This could potentially hinder productivity and also increase the possibility of errors.

Implementing a more flexible ‘Copy to’ or ‘Duplicate to a location’ feature would provide a practical solution to this issue. It would empower users to duplicate content and directly place it in the desired location without unnecessary suffixes. This could greatly reduce the amount of manual editing needed, enhancing productivity and ease of use.

In addition, introducing such a feature could significantly streamline workflows, promote better organization of information, and lead to a more efficient and enjoyable user experience. Ultimately, the implementation of this functionality is a forward-thinking strategy that would be a valuable addition to the current system.

Welcome to the forum!

It looks to me as though you may be exploring primarily the contextual menu so far, which only has a subset of the software’s functionality, by necessity. Both of the things you are looking for already exist, and can be found in the menu that handles item manipulation in general: Documents.

Note there are two duplication commands. The second, while it primarily offers a way of duplicating only the container node without its child items, also has the side effect of not serialising the name—and works fine on individual items as well.

Further down in the menu you will find the “Copy To” command you are looking for. (Currently missing in the implementation, but planned for, is a repeat command added to this menu once you use Copy-To, that re-targets the same container you used last time, along with a dedicated keyboard shortcut for doing so.)

There is a bit more as well to take a look into. I’d start with §6.3.4, Moving and Copying Things Around, in the user manual PDF. Mainly for those cases where drag and drop is feasible, you can enable an option that allows for copy-on-drop, which when combined with dragging icons out of editors or search results, can be quite powerful.

Hopefully, this feature will be incorporated into the context menu of the current workspace. Its present location in the Documents menu is rather cumbersome.

As I often have to say, if we put everything into the contextual menus that people have requested over the years, our contextual menu would look like Gimp’s. That’s certainly an approach, but not one we’re keen on.

Personally though, Alt+d, c followed by arrow keys (or even the mouse at that point) seems pretty efficient to me (at least I’ve never been bothered by it!).

It’s not necessarily a given. The developers could introduce functionality that allows users to customize the context menu, adding or removing items as desired, while still maintaining the default context menu items. This approach could speed up navigation for many users. However, if I were using a laptop keyboard without a mouse, then keyboard shortcuts would be the optimal choice.

That’s a lot of infrastructure to build, comparable to the amount required by keyboard customisation. And it should be noted that even 13 years on, the keyboard customisation tool still does not have all of the menu commands in it as each has to be added and maintained by hand. In other words there is no framework for either of these things, and home brew is expensive in time.

This has to be balanced against the time required to finish what is still missing, too. Do we spend months on something new and not part of the design target, or spend those months continue to flesh out the intended design (like the aforementioned Copy To Again command and shortcut)?

1 Like

While I understand the complexity and time investment required to build such infrastructure, it’s crucial to remember that software development, especially for widely-used tools like Scrivener, should prioritize user experience and functionality.

Certainly, adding customizable context menus or expanding keyboard customization might require significant development resources. However, such features can greatly enhance the user’s efficiency and overall satisfaction with the product. It’s about delivering a product that not only meets the user’s needs but also exceeds their expectations by providing a tailored experience.

Yes, there’s a balance to be struck between adding new features and refining the existing design. But in the long term, investment in customizable and user-centric features could prove beneficial. After all, the ultimate goal should be to create a product that serves the users effectively and intuitively, facilitating their work rather than adding to their workload.

So, while the decision indeed depends on project management considerations and the need to allocate resources wisely, the focus should always remain on what will most benefit the end user. This user-centric approach can lead to a more satisfied customer base, which in turn can contribute to the software’s success and reputation.

All right, thanks for your feedback. Mainly I just wanted to let you know the features you requested already exist.

I am very clear on the fact that you are unhappy with where they are, perhaps to a level that is of even greater impact than finding out you can do a thing you wanted to do!