Allow copy/paste of views (or some other method of duplicating a view)

[ClayHelberg]

Some applications end up with multiple views, 95% of which are identical, for example the customer wants a choice between a spatial target and a model target, but otherwise wants the experience the same.

Currently, this requires either tedious recreation of a lot of content in Vuforia Studio, or else hacking the project files to duplicate the *.js and *.json files with new names.

It would be really nice to have an easy, reliable way to duplicate a view for cases like this.

[dsgnrClarK]

YES, this would be a GREAT feature!

(Even the Project has to be reopened)

Thinking about this every time I duplicate *.JSON and *.JS. 😅

[mwodarz_INNEO]

In cases like this, I would delete the resources from the model container and clear the not necessary items from the uploaded resources - and save the project.

Then I would copy or move the project from the project folder to the ProjectTemplates. After restart the VS service, you can use this templates for all the "95 % similar projects".

Maybe you know this way or maybe this would help (a bit)

CheerEO

Marco

[ClayHelberg]

Thanks, Marco. I'm afraid you haven't quite understood my use case, though. I'm not trying to develop multiple projects that are all similar--which would be the perfect scenario for your recommendation. Rather, I'm developing a single experience (project) with multiple views, where the views differ only in a few details (primarily the type of target used, thingmark/spatial target/model target).

The idea is this: suppose you don't know for sure whether your user will be standing in front of your product or not when viewing the experience. For the case where they have the physical device in front of them, you want to use a model target. But you also want an option for someone who isn't there with the actual device, so you provide an alternative view with a spatial target and a fully virtual device. Other than the difference in target, the two options should work very much the same--same menus, same UI controls, same sequences, same code and CSS, same IoT data, etc.

That's the use case I'm asking about. It would be nice to be able to develop the "virtual" (spatial target) version of the experience, and then copy that View and paste it as a new View. Then it's a simple matter of swapping out the spatial target for a model target in the new View, and I'd be done.

I can approximate this by fiddling in the guts of the project directory and duplicating the JS and JSON view files, but it would be less of a headache if it were baked into the UI.

[RolandRaytchev · Accepted solution]

Hi @ClayHelberg ,

to clearify this issue I reported to R&D PTC and will provide a feedback so far Info is received. Thx (ptc reference VTS-331)

[ClayHelberg]

Thanks very much!

[RolandRaytchev]

Hello @ClayHelberg ,

as mentioned in the pervious post I reported this issue to R&D (internal VTS-331)

Now received feedback from dev team and want to provide it to you:

there is a copy functional (save as) which can be used to create a copy of an experience. If you have to change the view e.g. from spatial to model target, you could create a new experience. Has the customer tried this?
copy view, whilst technically not that difficult to implement, actually introduces as many problems as it potentially fixes. Now you have two views which, for a very short time, are in sync, but quickly would get out of sync. If you now move a model in view1, view2 is out of step. if you delete the pvz from view2, view2 still references it, your experience stops working. 
copying the view isn't necessarily the right way forwards, and as mentioned above, if you want a simple solution, copy the experience.
The recommended approach here would be to have a single view, and have it adapted to the type of tracking that is needed. An advanced experience that can adapt to different targets will need an advanced approach to implementation, but there are ways in the Studio/View platform to have all content be dynamic, and this includes the targets themselves. 
Studio allows the targets to be selected on-the-fly, this is not a valid reason to introduce this capability. It is an advanced case, which requires the user to use the TML (Widget) in order to create the targets dynamically rather than using the Target Widgets within Studio.
The tml could be used in some case but this widget is not documented yet, and the challenge and (I believe) the correct solution here is education, to show by example how to build more advanced experiences for example one that can switch it’s target at launch time. I know the enablement team are not programmers so this is an advanced topic even for them, but this is something the product team can document by example.

[ClayHelberg]

Thanks, @RolandRaytchev . To some degree, I understand their logic, however, they are claiming I should "just do it this other way (which requires some advanced programming that is undocumented and not accessible even to our own internal support staff)". As you can imagine, this response is not as satisfying as I would have hoped for.

I would be very interested to see an example of how this could work. The ability to choose type of target dynamically would be very useful for some of the projects I've been working on, and if it were available, would probably be a better alternative to what I've been doing, i.e. copying views and replacing the target widget in the copy. Can the developers recommending this provide a sample project to illustrate how this kind of dynamic content generation would work?

FWIW, I do see value in having the two variations packaged as a single experience vs. splitting into two separate experiences. I can handle the "diverging content" problem by waiting until the very end of development to copy the view. If further changes are required, I can either a) make parallel changes, if there are only a few simple changes, or b) modify the first view as needed, and then replace the previous copied view with a fresh copy after the changes are made. I haven't had any trouble making this work with the hack-the-json method, but it would sure be nice to be able to use the standard copy/paste buttons to do it.

[RolandRaytchev]

Hi @ClayHelberg ,

thanks for the detailed feedback!

I will reopen the dev ticket where I reported this issue  and will provide your feedback to our development team. I will inform you , when we receive a feedback from R&D

Thanks

[ClayHelberg]

Thanks, @RolandRaytchev , I appreciate you and the dev team for taking the time to dig into this.

[RolandRaytchev]

Hello @ClayHelberg ,

just received an answer  from R&D regarding  your last feedback :

good feedback.
================
of course my goal here was only to point out there are alternatives - potentially better depending on how they plan to develop longer term. examples have been shared with the field/enablement teams for many years, and if these aren't made available to customers, this is a problem that we need to fix. We are addressing that right now by documenting things :)

a feature such as ‘copy view’ isn't a bad idea - I merely wanted to point out some of the challenges.

i’m sure the PM can put it on the backlog - no promises as to when it will get done, as there are alternatives

[ClayHelberg]

That's great, thanks @RolandRaytchev . I agree, alternatives are always welcome, and if this can be documented and/or implemented as a standard feature, I'll be glad to take advantage of it when it's available.