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; } } }

regenerate in CC STD in TS 6

gzevin

it could be an FAQ, but I could not find anything similar - could somebody tell me how one could regenerate a templated file in CC STD (apart from going through edit->generate)?

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

Find more posts tagged with

Comments

Migrateduser

Hi Greg,

We did not see a need for a business user need to do a regenerate outside of the context of editing a DCR? They would not be editing TPLs and therefore, there is no valid use case where a business user would want to do a regenerate from the directory listings.

Thanks,
David Yun

Sr. Product Manager, TeamSIte
dyun@interwoven.com

gzevin

David

after I replied you in mail, I've thought a bit more. Actually, a user might still decide not to generate file after edit.

So - what they are supposed to do? As far as they are concerned, DCR is already changed. all they need to do - is to regenerate. How would you do it? go and edit again? cumbersome, IMO.

another thing - I''ve noticed a serious bug in the wizard behaviour. after I regenerated in the wizard, I clicked on Back button, went back into Form and entered some more info. when I clicked on Next, the wizard did not detect neither my edit or save event and happily did proceed to the next step.....

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

nipper

>We did not see a need for a business user need to do a regenerate outside of the context of editing a DCR? They would not be editing TPLs and >therefore, there is no valid use case where a business user would want to do a regenerate from the directory listings.

That is a bad assumption. We do some automated modifications here. (owner is in the DCR, if joe leaves I have a script that
replaces jane with joe). Business users run that script.

Since our DCRs do a lot of inline callouts to an app server, it takes 30-35 seconds to open. Since we do an DD on save (cause DAS
is buggy) it takes a minute to save. So now we have to do all of that to have a business user regenerate ? I do not think so.

gzevin

yep, and I believe there would 1000 and 1 use cases...

what wonders me - who decided to remove that functionality in CC STD? was it the users from focuns groups that discsussed TeamLeo????

I hope it's still possible to include it in 6.1

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

Migrateduser

Nipper and Greg,

You are able to add this in as a custom menu item via the UITK. That's why we made the UITK, because we knew we couldn't make the perfect UI, so we made it easy for you to customize it and meet your end users' needs. I'm forwarding this off to one of our FormsPub developers to provide the steps for doing this.

Thanks,
David Yun

Sr. Product Manager, TeamSIte
dyun@interwoven.com

gzevin

David,

why a standard feature (that existed in pre-6 TeamSite and that most of users got used to) has been removed? it's not something out of ordinary, it's something the users will want to use OOTB.

please file it as a FR for us.

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

Migrateduser

Hi Greg,

As I mentioned before, this functionality is available in CC-Pro. Why did we remove it from CC-Std may you ask? Well the same could be said of New Branch or Submit Logs. These concepts are simply too difficult for business users to comprehend.

The case with Regenerate is less clear cut, but we also believe that this is a concept that business users will not understand out of the context of filling in a form. If your users are that savvy when why aren't they using CC-Pro? And what is wrong with the UITK approach?

Thanks,
David Yun

Sr. Product Manager, TeamSIte
dyun@interwoven.com

sheet layout error.jpg

gzevin

Hi David,

look, as far as using 2 interfaces is concerned, my organisation has decided to recommend CC STD as a preferred interface for the majority of users. Training guides will be developed for this interface only (as you would apreciate the fact that for the large organisation it is hard to justify prodicing of 2 sets of guide, where we used to have 1 set for some time. and not only guides - we cannot afford to conduct 2 training streams, etc).

As you could see, it's easy to produce a use case where a business user comes around the need to regenerate. And this is a concept they need to understand anyway - generation (and regeneration) is an intrinsic part of the whole process.

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

Migrateduser

What "Interwoven believes" should be based on information commonly available on devnet, the yahoo group and other forums, plus what comes in through support, focus groups, user groups, gearup, etc. I don't see how the requirement for business users to regenerat could be missed with all of the posts on this subject on the forums. I don't undertstand why Interwoven works so hard to make the product backwards-incompatible. Again I think it's the architecture that requires regeneration without providing any regeneration logic or rules that is the problem.

nipper

>What "Interwoven believes" should be based on information commonly available on devnet,

Obviously you never worked for Interwoven. If Kevin or Jack agree it is in.

Migrateduser

Scary that someone so removed from the day-to-day reality of working with the product could make any decision at all.

Migrateduser

Nipper,

No offense, but could you give me a little credit (or maybe you don't want to because apparently you all think I'm incompetent) but I am the TeamSite PM, and I am the one making decisions. I want to make the clear to you and everyone else here on DevNet.

I don't claim to be perfect, but I do pride myself on helping meet customer needs. I'm sorry if I did not do that in this instance, but I'm doing the best I can.

David Yun

Sr. Product Manager, TeamSIte
dyun@interwoven.com

Migrateduser

David...I think you folks at Interwoven have dug yourselves into a corner. You all claim that you base many of the decisions on how the UI and other aspects of TeamSite have been made based on "customer" input. Whoever those customers are. But when the loudest of us who post on DevNet, who are customers as well or are working for customers, contradict one of those big decisions, we are met with a brick wall. You basically say "this is how we decided to do it and so be it". It sure makes it seem like there must be a set of customers that are a whole lot more significant than we all are. I'm sure you won't say who the customers are that get to decide how things should work for the rest of us. It does make it hard on the less significant customers. You created the argument - so you have to live and die with it.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Hi Smitty,

I understand your frustration on how things were run in the past, but I disagree with your assessment of the current state of the IWOV team's commitment to customers needs and concerns posted on DevNet.

Many of the issues raised specifically with TS 6.0 here on DevNet have either been addressed in TS 6.1 or are up for consideration in future TeamSite releases. Gripes posted by gzevin, gfaus, yourself, and a whole host of others on DevNet have either received detailed responses on how to get around the issues or solutions to the problem.

Additionally, I spend much of my time entering and managing DevNet related feature requests. We have a mission to meet the needs of both IWOV developers and end users for a wide breadth of customers who are each using us in a unique way.

I know that you probably disagree with my view of the world, but its like I said before, all we can do is to try to most adequately meet the needs of our diverse customer base. What that means is that we can't satisfy everyone all the time, but we can try our hardest to do so and in my opinion, we are doing a pretty good job at that.

Thanks,
David Yun

PS I've filed FR 52437 to capture gzevin and nipper's request for a Regenerate menu item in CC-Std.

Sr. Product Manager, TeamSIte
dyun@interwoven.com

Migrateduser

I certainly don't envy your position. And I wouldn't want your job. I do hope that as more people start using 6.x that it becomes apparent that the 2 UI thing will blow up and become a nuisance for everyone, or at least the majority. I'm seeing it more and more. That's my biggest hope. I know you disagree about that as well, but if it does happen that way, please be open to changing it down the road.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

I'm having a hard time seeing the logic in saying that 2 UI's can't work. In almost every project I've worked on, I've been asked to develop a 3rd UI to supplement the other 2 UI's. This 3rd UI is email notifications (now with Command URLs aka CCI's). I know that Nike has mostly savvy developers and they could probably handle any UI that's thrown at them, but not all corporations are that way. Some have very non-technical marketting people that want to be able to post on the web but don't want to spend a lot of time to learn a complicated UI. I think that's why CC-Standard was created. Although I think it's still got a bit of a learning curve to it, I don't think the curve is as high as it was with WebDesk or WebDesk Pro. I think that different types of users require different types of UI's and different hand-holding. I'd be surprised if most companies agree with your assessment that one UI is the end all for all users.

- Jason

Migrateduser

I don't have a clue what you're trying to say about email. The argument is based on training and ease of use. In this day and age, who should need to go from one UI to another by logging out of the system and logging back in? That's a bit archaic. There should be one UI - meaning one login. The customer should be able to configure what the user gets to see based on who the user is. If the user is defined as a business user, show them the CCS looking stuff. If the user is defined as a developer, show them the CCP looking stuff. The argument revolves around 2 separate logins and 2 distinct development teams for those separate UI's. That will end up creating scenarios where like functionality works differently in the 2 UI's: bad, bad, bad. We already see that with cgitask scripts. If you have 2 distinct development teams, you are in for trouble.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

issue.PNG

Migrateduser

Out-of-the-box, CCStd does not allow the user to regenerate a page in file view. In 6.0, the regenerate link is not exposed publicly and, thus, there is no easy way to add your own custom regenerate link to the CCStd UI.

However, in 6.1.0, the regenerate link is publicly exposed for use by the custom toolkit. To do this, follow the steps for adding custom links via the customer toolkit. The steps are outlined briefly here; for the official word, refer to the customization guide:

1. Identify in the UI hierachy where you are adding the link.
2. In a ui config file within the customer toolkit, mimic this hiearchy down to the parent where you are adding the link (ie, the menu, or the actionlist.)
3. Use an <iwov> tag to add this link.
4. Compile and deploy the customer toolkit.

For example, if you wanted to add the regenerate link to the action list menu rendered by each file, your ui config file would look something like this:

<?xml version="1.0" encoding="utf-8"?>


<iwov-ui>
<action-list id="iw.ccstd.list_directory.file_list.actionlist">
<menu id="iw.ccstd.list_directory.file_actions.menu"/>

<iwov-insert-after id="iw.ccstd.list_directory.file_actions_undo_changes.link">

<link id="com.corp.custom.regenerate"
refid="_iw.formspub.regenerate.link"/>
</iwov-insert-after>
</menu>
</action-list>
</iwov-ui>

nipper

>No offense, but could you give me a little credit (or maybe you don't want to because apparently you all think I'm incompetent) but I am the TeamSite PM, >and I am the one making decisions. I want to make the clear to you and everyone else here on DevNet.

David

I am certain you are the TeamSite PM. You should know that there are a number of ex IWOVers in this list, many who have seen
PM evolve through the ages. One thing stayed true & that was the influence if Jack and Kevin on the product.

The main point is that your current customer base (of who actually use the software) have had product ehancement requests
out for a long time. Many sit there. With the cancellation of GearUp and the elimination of the focus groups, the day to day users
never get heard. Yea, a VP in my company goes to "meetings" with Interwoven every six months or so. Does he know what
the users & implementers like & don't like ? No, he is worried and bends Martin's ear about strategic stuff. Is that important ? Yes,
but is the tactical day to day stuff we see (& feel ignored) important too ? Certainly.

#SOAPBOX off

Andy

Migrateduser

>No, he is worried and bends Martin's ear about strategic stuff. Is that important ? Yes,
but is the tactical day to day stuff we see (& feel ignored) important too ? Certainly.

AMEN!!!

- Jason

Migrateduser

Dave,

I was trying to say that I think more UI options is the answer rather than less. Or at least more flexible/customizable UI options. I definately agree that functionality of like-functions should be the same (or very similar) across all UI's, but I also think that there are a lot of advanced functions that most users will never need; so hide those functions. I also think that Interwoven created the 2 UI's so that we wouldn't have to build them from scratch. They gave us a starting point from which we can add/remove our customizations.

That was my point.

- Jason

Migrateduser

Don't you think that a single UI should be smart enough to display what the user needs to see? I'm not saying we should display everything to every user. But the UI should be intelligent enough to display what you want people to see, based on their profile. I think it's laziness to have 2 distinct UI's that you have to login to separately where you should have a single login and then decide what to display. Support is going to blow for me if I have to support 2 distinct UIs. It's just a weak implementation.

All this customizability is supposed to allow us to display whatever we need our users to see. Having to log out of the system and log back in to get from one UI to the other is absurd.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

I agree, a strong architecture behind a single consolidated UI should allow flexibility to meet user needs instead of the redundant development, training and support. It's a no-brainer.

JonathonG

Smitty,

I think I finally understand what you've been getting at. Its not that you don't want 2 UIs, its that you want the "which UI" decision to be made deductively by the system, and not something the user has to choose. I believe you'd like some kind of configuration like:

businessuser: CCStd
poweruser: CCPro
hybriduser: both

Where the first field is the userid and the second field indicates the UI they are to have. Do I understand you correctly?

(Obviously, I can't make anything like this happen. But, perhaps restating in different terms will help someone in IWOV proj. mgmt. understand what you're looking for. And, it sounds like something that I'd like to see at some point, as well)

Jonathon
Independent Interwoven Contractor