Client Server or Browser

Whats your thoughts...

If you were the CEO of Interwoven and you had a choice when TeamSite was first developed whould you choose to make it a Client Server application or Browser based as it is now? Why?

Thanks in advance!
WIN2K TS/TST 5.5.2 sp5; OD 5.6.0.1; DD 5.5.2
The Professor-

Find more posts tagged with

Comments

Migrateduser

Browser-based, as it is now.

It's more portable, more marketable, more easily supported, and thus more widely-accepted than a Client/Server app. Vignette follows the Client/Server path for the technical users and developers, at least. To Interwoven's credit, you can't imagine how many people I've heard that were **** off at Vignette's products and especially their "professional services". From what I've seen (as a third-party, by the way), Interwoven does a much better job of training their consultants.

Alas, I went off on a tangent.

Good topic!

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

Adam Stoller

I think it's a tough call.

The browser-based interface makes it much easier to implement within any size organization and to be able to grow in usage with little-to-no effort (client-side installations of LaunchPad and VFE kind of detract from this)

An application interface makes it much easier to implement aspects of the UI and provide things like keyboard shortcuts, control redrawing issues etc.

I'm not sure, but I also think that having it be central (browser-based) makes customizations far easier than would be the case if it was distributes (application-based) - unless a real neat (and robust) mechanism were used to update the application from the central server [this can be done, I'm just not sure on the ease of impelementation, aspects of testing, etc.]

The other "big win" for browser-based is that you only need to have a beefed-up server, you use virtually no diskspace and relatively little CPU and memory on the client machines - whereas an application-based system would require more disk, memory, and CPU utilization on every client machine upon which it gets installed. (not sure of the $-tradeoff here, but somehow I think the 1-big-server tends to be less expensive than the N-beefy-clients)

Mind you, in most cases I'd prefer to have a client app - because I don't really like web-based apps very much -- but I can appreciate the various pros and cons.

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

Migrateduser

Little CPU? I know you're way up there in 6.5-land, but you remember 5.5.2 and older, don't you? Remember how less-than-diligently designed DCT's caused a user's CPU to plateau at 100% for a minute or more? Go back 2 years and Teamsite was a dog... although, I still prefer the browser-based apps.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

Adam Stoller

Okay - point taken with respect to DCTs with FormAPI code and VFE issues (those are the client-side pieces that exist even with the centralized server browser-based approach) -- but aside from that, if you're interacting with workflow or generating files or interacting with DCTs that do *not* use FormAPI or VFE, do you really see much CPU utilization on the client side?

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

Migrateduser

Absolutely not -- and you're right in that you only need one beefy machine and basically don't have to worry about client machines (especially with 6.1 and later versions). I'm wondering what experiences others have had with competing product lines to Teamsite, both from a technical as well as a CRM perspective.

Dave

Current Environment(s):
(1) TS 6.1 SP2 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 6.1 SP2 on Win2K

Bowker

Browser based.

Many organizations are locking down employee desktops due to licensing/support/... issues. Even the Visual Formatter object is giving us trouble. Our users don't have the ability to install software on their desktops. This is, from what I can tell by other posts on DevNet, a growing trend.

P.S. From someone who used to travel around (a lot!) to update the client side of a C/S app - client side software is a nightmare to support/maintain/upgrade....

Dan Bowker
Northern Trust
Web Publishing Technology

DavidMusser

I think I would have done both :-) Think of how nice it would be for someone to have TeamSite on the desktop, and have it auto sync to a master teamsite server when they log in. TFO to the next level if you will.

-D

chuckles

One model that seems to be growing in popularity is to have an entire application run as a single Java applet or ActiveX component. That gives you some flexibility in deployment and keeping users on an up-to-date version while mostly avoiding desktop support issues.

shanon

Browser-based - no question.

Many of the pros and cons have already been addressed, however I'd like to reply to the slow-loading DCTs comments.

I've been with TS since v4.2.1 so I've seen the bad and ugly... Finally with the 6.x release we're moving to DOCUMENTED support for a Java Web Application container and hence, "the good."

The main reason that the system performed so badly is that pre-6.0 we were still in the CGI/Perl world. FormsPublisher has introduced JSPs and caching which makes everything run so much better and faster. Not to mention that we can finally use sessions ( FINALLY! ) instead of passing params through hidden fields and coding zillion-line perl callouts and menu items.

After you've got 6.x running, there's really no comparison between browser-based and a fat client.

- Everyone's got a web browser already and, thus, the system required to use one.

- Browsers provide a great presentation engine that is internationally compatible. The advancements in HTML and CSS have cemented a strong foundation for most any display requirements.

- Fat clients require time and money to make them as best as they can be. This time and money can be spent making the core product better instead of it's presentation.

- Web services APIs in 6.X ( CSSDK ) provide developers with the ability to write their own fat clients using Java or a .NET flavor, so if you're not satisfied with the interface, you can write your own fat client interface, or even a more suitable browser-based one if you desire.

Browser-based interfaces really are the lowest common denominator for software presentation and while they may not be as elegant as some of the sleek fat clients, they provide great ROI and speed time to market.

Shanon

Shanon Levenherz
Mercer eBusiness Team
shanon.levenherz@mercer.com
http://www.mercerhr.com