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

workarea link from Task detals in CC PRO?

gzevin

I believe this is a generic issue, not WF-related, so I am posting in this forum.

Ok - in Task Details in CC PRO there is a link to workarea. if one clicks on it, a window with workarea 'index' pops up, and if one did not configure index page for visual preview for a workarea, this window will take you to a top level directory of the workarea, and it will show red crosses for images... If you remove VisualPreview Toolbar, then the images for folders, etc, will reappear.

This issue is in fact well known and in CC STD it's solved by enabling directory browsing instead of visual Preview (page 53 of the UI customisation guide, v. 1.1.0)

However, I could not find something similar for CC PRO.

any ideas?

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

Find more posts tagged with

Comments

gzevin

Some update on the issue. This is considered by interwoven a s 'feature' and the support is offering to raise a FR for me.

I am not satisfied though...As this issue has been pretty serious with CC STD , so in 6.0 IWOV has offered a workaround and in 6.1 introduced a new attribute for UITK...

however, they obviously overlooked the same issue for CC PRO...

more to follow....

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

nipper

>Some update on the issue. This is considered by interwoven a s 'feature' and the support is offering to raise a FR for me.
>

Hmm, it is a "feature request" to have 2 different GUIs act the same?

iwovGraduate

Do you have a FR # yet ?
I have the same issue with my current client.

gzevin

Hmm, it is a "feature request" to have 2 different GUIs act the same?

this is why I insist this is a bug, and am not closing the case. IWOV has simply overlooked (again and again, as usual) this fact - they were concerned with CC STD probably (and yet they have that horrible perforamnce issue with it).

this is the price you pay for making 2 interfaces. My client was against this even during Focus groups meeting on TeamLeo....

I don't have FR# as yet, as I have not done with this case. Apart from pushing this into the bug list, I am asking for a way to at least disable this link. I'll play around with it myself... Not sure that I'm going to succeed...

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

gzevin

well, we'll see... but I think this will be not only our customers, but many more, as people are trying to move to this 6.1...

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

gzevin

This is a reply from IWOV:

In reply to:

I've verified with our Engineering folks with regards to this query. The Engineering team confirms it's not possible to:

1. Enable workarea browsing similarly to CCSTD or
2. Options to disable the workarea link from the workflow task screen

According to UI Toolkit manual, this link can only be customizable in CCstd. The only way to acheive option 1 is to hack through the Teamsite codes and use CSSDK to compose the view workarea command. However, this option will cause a lots of issues when the CLIENT attempts for future upgrade and it's highly not recommended at all. Alternatively, in CCpro, the workarea link is coded in a jsp file and it is not public to customer to change/modify the jsp as it change will may cause significant impact to Teamsite's usability/stability.

My apologies that the above information are not good news to your query. Please do let me know if you're agreeable for me to file the feature request on behalf of CLIENT

I have requested a FR, and will let the # when I get it.

I hope that quite a slew of customers will stand behind me....

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

iwovGraduate

Thanks Greg,

I still think this should be considered a bug as stated in earlier posts. Bug or FR, we get a number either ways. Smiley Happy

gzevin

we are trying to push IWOV to file this as a bug, as this is not satisfactory!

FR # is 54550, however I hope to get some support from other clients, as probably not everybody realises, how serious this issue is.

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

iwovGraduate

I have a couple of customers to add to this. Will let you know if I (or the customers I am working with) can change this to bug.

... if I can avoid typos in FR#s. Smiley Happy

Migrateduser

What a wonderful feature. Two separate and distinct UIs. Brilliant idea. Thank **** my management is agreeable to creating our own custom UI.

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

gzevin

I just got off the phone with one of former clients of mine. Now, with the wizard's behavior in CC STD, they'll have to customise their existing workflows... ... as if you generate a file from a DCR, they both will be attached by the wizard, regardless of your wish. And if your workflow was relying only on DCR - tough luck.....

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

gzevin

Samir,

here is the reply for IWOV support.. I was rolling and laughing.....

Unfortunately, I'm not able to file this request as a bug for the follow reasons:

a. The availability of similar feature for CCPro is not documented in the Teamsite guides. As such, it does not fall under the classification of a feature failure to be filed as a bug.
b. Checks with Engineering confirms that the request should be filed as a feature request as disabling the link to the workarea is not configurable. Also, changing the workarea view via CSSDK will cause a lots of issues when the DET attempts for future upgrade and it's highly not recommended at all.

that is, if this functionality is not documented, it's not a bug.. and who cares if it brings a screen that will confuse even many professional users....

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

Migrateduser

This has been such a difficult thing to deal with over the years - what Interwoven classifies as a bug versus what they consider to be a feature. At the last Focus Group I went to, someone asked specifically about this and Interwoven's answer was, in effect, anything that doesn't work the way it was intended to work is a bug. Everything else is a feature.

No one knows what the ratio of fixed bugs to open bugs is, or the same for feature requests because the open bug and feature request lists are not exposed. But we all know how many of our features requests have been added to the product. I won't be holding my breath for this feature.

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

Migrateduser

Alright I got off my lazy **** and actually tried this, and for IW to say that because it wasn't in the documentation that it wasn't supposed to act this way, then it can't be a bug is even more ludicrous that the usual excuses they make. This behavior is terrible, it's broken (notice the red X for all the icons) and it's absolutely not desirable. This can't be a feature - it is not even remotely like any other UI in 6.1. I will jump in and stand behind any push to get this filed as a high priority bug.

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

gzevin

Dave,

the red X'es will go away if you close the 'Smart Context' Tab (the bugs in that Tab - is another story that I will tell soon). But still this functionality is confusing.

After IWOV has discovered (with a tip from me) that setting up an 'index' page in CC STD was posing a huge problem, they introduced the new 'browse' feature for it (I mean, duplicating the Browse feature). And this is in the UITK documentation. But - the same feature in CC PRO was not either thought of or taken off . This what I call good design and good regression testing at IWOV.

I hope to get a good slew of customers to stand behind us and push IWOV to fix this ASAP.

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

Migrateduser

I hope so, too, Greg. It's just nothing remotely close to what I'd expect to see when clicking on a workarea link. I'd expect to see a TeamSite UI looking view of the workarea. I just can't believe they think this is a feature to make it right. Especially since they fixed it in CCStd.

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

gzevin

yes, this is my exact point. IMO, they simply overlooked this issue and now they try to save face saying this is an intended design. I also asked how to disable this link, and even this apparently cannot be done easily....

I hope somebody from IWOV is reading this, so something could be done.

I already asked my manager to escalate this issue further, as I am not prepared to be fed such rubbish and swallow it.

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

smenon

Greg..

The workarea preview functionality was designed with the idea that non-technical users would like to browse a virtualized website rather than a folder structure. If you configure the web server to use the index page so that the content is virtualized, it should work for both CC Std and CC Pro. In the event that the web server has not been configured to point to an index page to virtualize the site, the default option for the web server is to display the contents in that folder. That view including the icons, are completely controlled by the webserver. When this issue was raised in the past, it was always in the context of preventing business users from seeing the directory structure. Based on that it is appropriate to provide the ability to configure the link for the CC Std UI because the users of that UI are probably more affected by the lack of virtualization when compared to the CC Pro users. Hence the decision to include this only in the CC Std UI. The fact that this option was "added" to the base product, where you could not configure this link, is what made this a feature as opposed to a bug.

Without getting into the religious argument about whether it is a bug or a feature request, let me try to understand the expected behavior so that we can look at providing you the best solution. Given that the UIs behave very differently, in your opinion what is the expected behavior when a user clicks on the workarea link in the task details in CC Pro? Should it display the tree view of the workarea including all the menu options and the content and workflow tabs or should it be an isolated view with only the contents of the frame that displays the folder listing?

We are looking at exposing the configID for this link which will enable you to override the URL for this link with a custom URL. You could choose to redirect your users to a custom page if you don't want them to see the directory structure. Would you want the link to be configurable because you want to disable, override or remove it? The solution might be different based on the desired action. I am trying to get this included in the TS 6.1 SP2 and TS 6.5 releases, although it hasn’t been committed yet. I will update you with the actual release vehicle for this when I have it committed.

The other issue that has been raised about the folder view showing up with red crosses instead of the icons seems to be an IE 6 browser caching issue. We haven't seen this behavior with IE 5.5 or Mozilla. On IE 6 also, it is very intermittent and if right click and choose “show pictures”, the icons get repainted correctly.

thanks

--Sunil Menon
Product Manager
Interwoven, Inc.

gzevin

In reply to:

Without getting into the religious argument about whether it is a bug or a feature request, let me try to understand the expected behavior so that we can look at providing you the best solution. Given that the UIs behave very differently, in your opinion what is the expected behavior when a user clicks on the workarea link in the task details in CC Pro? Should it display the tree view of the workarea including all the menu options and the content and workflow tabs or should it be an isolated view with only the contents of the frame that displays the folder listing?

We are looking at exposing the configID for this link which will enable you to override the URL for this link with a custom URL. You could choose to redirect your users to a custom page if you don't want them to see the directory structure. Would you want the link to be configurable because you want to disable, override or remove it? The solution might be different based on the desired action. I am trying to get this included in the TS 6.1 SP2 and TS 6.5 releases, although it hasn’t been committed yet. I will update you with the actual release vehicle for this when I have it committed.

The other issue that has been raised about the folder view showing up with red crosses instead of the icons seems to be an IE 6 browser caching issue. We haven't seen this behavior with IE 5.5 or Mozilla. On IE 6 also, it is very intermittent and if right click and choose “show pictures”, the icons get repainted correctly.

Sunil,

I hope you realise that this functionality with red crosses appearing is not any good, especially when it comes up like that with supported browsers.

What *had* to be done before and needs to be done now ASAp is to realise - WHY did you put that link? In my opinion, I'd certainly expose that link to UITK, so the users could write their own customisation, as they wish (eg, if you are integrating with some obscure app. server, this link could launch appropriate URL, outside TeamSite).
As a standard behaviur I'd simply switch the UI back to the tree view - or, simply give me an ability to disable it.

thanks for your comprehensive reply

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

Migrateduser

I'm using IE 5.5 and am seeing the same behavior. So much for that theory.

Like Greg, I don't even understand what the point of the link is. Personally I would like to see it disabled or removed as a link altogether. Why anyone would feel the need to look at a task and need to go to the workarea - I just don't see any of my users needing that, especially if all it does is give them an archaic directory listing of the workarea. Please don't sit back and blame the web server for behavior you can control. That is bush-league support. I don't care what you do with it as long as you allow me to remove the link. At the very least it should work the same, regardless of which UI the user is in. The more you make these UIs different, the harder it is for us to support them. You've made a huge mistake with customers by creating two vastly different UIs for us to have to support. Not only that, the training issue is equally as difficult when you have the same action behaving differently depending on which UI the user is logged into. This is really a nightmare for us. You ask what we'd like the behavior of any action that exists in both UIs - the answer is THE SAME BEHAVIOR. Always.

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

smenon

Dave..

When a business user is assigned a task to modify a page, they would like to see the website that is going to be modified. Most business users like to navigate the website and get to the page that they are going to modify in a virtualized view of the site as opposed to a directory structure. The link is there to enable them to get to the site from within the task details view. However, for this to work, you have to configure the webserver to specify the index page and have it virtualize the site for you. You will see the directory structure only if you haven't configured the webserver to pick up the index page.

I understand that your users don't work in that model and you would like to disable the link alltogether for them. Point taken and we will look at making that link configurable.

The two UIs are meant for very different target user bases and hence it is never as straightforward as saying that the behavior should be the same. The desired end result of an action in both UIs should be the same, but the path taken to get there might be different depending on the UI. Ideally, a CC Std user should never have to work in CC Pro and vice-versa and so there should be no confusion about the two UIs. The only overlap might be for the folks that support the users who might have to work with both UIs. Again, it seems like your user base profile does not fit into the two UI model and if that is the case, you might want to just pick one of the two UIs for all your users. Even if you pick one the two UIs there will always be some other customer who will pick the other UI and we will have to support both.

thanks
Sunil

--Sunil Menon
Product Manager
Interwoven, Inc.

Migrateduser

> most business users like to navigate the website and get to the page that they are going to modify in a virtualized view of the site as opposed to a directory structure.

I would seriously question this assumption as I have been doing CMS for 4 years and seen very few users work in this mode. My 5.x experience includes many requests to have the SCE toolbar disabled. I feel the user should always be given a choice if they want to view the site or the structure and that the UI should probably support both. I feel that if they are working with the site they should go to the site and the CMS should be integrated with that rather than going to the site, finding the page they want to edit, returning to the CMS, finding the page they want to edit...

Migrateduser

Sunil, I do appreciate your explanations and your willingness to listen to our points of view. This is really refreshing - I wish there was more dialogue like this on DevNet from Interwoven. So thank you for that.

While I do also appreciate that you can't possibly satisfy everyone, and you try to satisfy the majority, I think that a link that says workarea is misleading to represent the index page of a site. Couldn't you maybe come up with a more appropriate reference word than workarea? It just seems to represent something different than what everyone associates the word workarea with. It's a little confusing. I think that might be a better remedy than just allowing us to disable the link. I think it's good to display the workarea associated with a task. But the link to the index page should be called something else, like Site Preview or something like that. What do you think?

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

lhdavis

Call the link "Smitty" and see how many questions Support gets Smiley Happy

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov