nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Wizards/Editing/Tagging in CC Standard/TS 6.0

gzevin

I did not really know which forum I had to post this ...

Since TS6 Beta, I have made a few comments/suggestions about editing templated file and its subsequent tagging/generatioin in CC Standard.

I've done some testing and here my impressions - well, this seems to be the best integration (so far) of templating and core TeamSite. You click on 'Edit' of an HTML file, the wizard brings you FormsPublisher, you save, it asks you about regeneration, if you click yes, it regenerates the file, no questions asked, then, if you choose to submit, the wizard takes 2 files (yes, both DCR and HTML!) .. but, it brings the Tagging step, and, attempts to tag BOTH files, for some reason, Tagging of DCRs, I believe, is wrong, as only web assets need to be tagged as such..

This step is unnecessary, and I hope that engineering could eliminate unnecessary tagging step for DCRs in wizards. If this is done, I can safely say that the users will be really happy about this functionality.

on the side note, I believe that tagging of multiple files is ugly and this functionality needs to be redone ASAP as well.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Find more posts tagged with

Comments

Migrateduser

Greg,

Both issues are filed as bugs and being looked at for 6.1. Most likely the tagging of DCRs will be addressed first. In the mean time you can turn off tagging completely.

Thanks,
Todd

Dev. Mgr., CCS and UITK

Migrateduser

Yes, we know this is one of the biggest usability issues with 6.0 and we plan to address it moving forward. The current recommendation is to do generation in WF, so that only one file needs to be submitted by the author.

Going forward, it was unclear if the best practice was to tag the dcr or the output file (or tag the dcr and clone the tags to the html). What would you like?

The "tag multiple files" screen that comes up for 2 files was never designed for this scenario. It was originally designed for power users who wanted to normalize the metadata on a field across a large number of files.

Going forward, there are several design options for tagging multiple files in CCStd:

1) Present the individual screens in series
2) Append all the forms into one really long form
3) Have another/more advanced user input the metadata.

Any other options? Which do you prefer?

gzevin

no, the current functionality is great - I mean to have 2 files (I mean dcr/html pair) to be dragged along together (and yes, currently I implement this in workflows - if DCR is submitted, generate HTML, if HTML is submitted, attach its respective DCR).

However, I believe you could make the wizard to pick up non-DCRs only and pass them to the tagger.

Now - let's talk on theoretical level now. I always pointing out to my clients, that the DCR is not the target of tagging - it's HTML who is ultimately the web asset and only HTML which is identifiable in the information architecture. (Actually, I AM moving one of my client from entering metadata in DCR to Extended Attributes!) Also, you could have one-to-many relationship for DCR->HTML, and it's not clear how would you handle this. So, I think that only web assets should be sent for tagging, regadrless of what they are.

About tagging interface. Just recently I have been presenting my TS 6.0 experience at the user group meeting here, in Sydney. And, I was asked about whether IWOV has fixed the tagging interface (as we know, it comes from MetaTagger), as tagging of multiple files is extremely un-dfriendly.

I believe, the interface should be able to mimic what is currently in setmatadata CGI in 5.5 - with the ability to switch between individual/mutliple file tagging. Having this one could fill common tags in one place, and then switch to individual files. It;'s also important to retain the tabs - I think this is a great feature that I am already heavily using - you could visually separate mandatory, non-madatory and project-related metadata, and I hope the same functionality is retained when one moves to tag individual files.

Finally - do not underestimate the need to tag - I feel that it will be the job of an ordinary user to do initial tagging now (since tagging was fully integrated into the system), and they do deserve a better interface.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

As a counter-argument to the dont-tag-dcrs issue. The project I'm involved in (5.5.2-based) explicitly wants the DCR to be tagged *before* page generation, and then behind the scenes (in the workflow) it takes care of transfering all the EAs from the DCR to the generated pages, which then get deployed (while the DCRs do not).

The metadata design here does *not* call for (or support) the concept of distinct metadata for distinct pages generated from a single DCR [well, not entirely, some of the EAs are modified slightly when being copied to multiple-page outputs].

Clearly there's a difference of approach / need here - so in the spirit of customization that would appear to be the mainstay of the 6.0 release - I think something like this needs to be configurable. Something like:

wf_tag_files = (dcrs|non-dcrs|both)

(other???)

However, I do agree that the idea of being able to switch from "common" metadata to "file-specific" metadata fields is something that appeared lost in the translation from the ancient 4.x Set Metadata CGI to the MetaTagger CGI. I'm not sure how well the concept would fit within the new model, but I'd think it would be worth exploring how feasible it might be to re-introduce that concept.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gzevin

Adam,

It could well be that in a particular project one could choose to depart from the traditional view that it's web asset that gets tagged and that is considered as a primary entity. I am not going to argue about it.

However, I think that this is the default behaviour that needs to be shipped OOTB and, naturally, there should be some configuration allowed to tweak this. What worries me is that the wizards do not seem to be configurable (ie their interface is not open to the public) in 6, only 6.5 promises that. I hope that this feature of configurability that you have just mentioned could be given to us in 6.1.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU