SHAREPOINT & MADCAP = what's the deal?

[madcampus1]

HELPPPPPPPPPPPPP - I started at a new company, so we purchased MadCap. Great! But all I keep hearing about is 'HOW' MadCap and SharePoint works together? So, I'm confused. Please help me? Send me links to downloads of white papers, demos, or whatever you have on this marriage of SP & MadCap. I can't find any...so I need soooo much help!

a) Is there a demo or white paper that EXPLAINS why I would want SP and MadCap to work together? I get versioning (I can check my files in and out and use in Flare, etc), but beyond it being a 'CONTROL' tool (using SharePoint), what does this integration of SP and MadCap get it? And why do I want it.

b) We are becoming a SharePoint shop, so there are Development folks walking around saying "Oh, SP & Flare", but why? They can't even give me an answer other than it sounds cool together. So, can anyone help?

I'd like for someone to explain:

a) All the features or benefits I get from this marriage of SP & MadCap
b) I know we want to deliver WebHelp & Context Sensitive help, but why do I need SP to do that, other than to check in and check out files.

Sorry for my frustration, but I toook over from someone who LEFT this position as a tech writer and no one seems to know what she was touting, other than great, get SP AND MADCAP together...


ALSO, can some folks chime in on HOW they are using SP in their current environment. What are the results? Why are you using it and what are you leveraging?
I'm curious about PERMISSIONS - does SharePoint bring that into play. If I post my help to SP, store my files there etc. that I get some "permissioning" on those topics or something?

[RamonS]

I'd want some plausible reasons for using SharePoint in the first place. Without hiring a developer to do all the stuff that doesn't come out of the box SharePoint is, well, useless. The majority of tasks people attempt to do with SharePoint can also be done with a plain simple database and server side scripting enabled web server (read XAMP) for far less up front cost. Then again, SharePoint is nothing else than yet another kludgy conglomerate of non-standard web pages from Microsoft tied to IIS. You can host any Flare WebHelp output on the same server and link from SharePoint to it.

I used to work on SP deployments as an admin and I am so thankful that I no longer have to deal with this stinking pile of garbage (yes, harsh words, but I won't apologize, because SP is just that: a stinking pile of garbage). Now I sole use it as a consumer and anything our SP sites do could be done nicer and faster with the much better web development tools out there. SharePoint is nothing but a fad that C-level managers drool over because it is from Microsoft and the pro version costs a lot of money. There is the twisted belief that just by installing SP and making everyone endure using it problems like lack of communication and insufficient information sharing are a thing of the past.

Here is my advice: dig deep into Flare to get the best out of it. For anything else either write up specs for a web developer or if needed work on it yourself. It doesn't really matter if you use ASP.NET or PHP or something else. With .NET and PHP you can save yourself some work by using one of the many freely distributed frameworks. Sure, you could use SharePoint as framework, but there are many frameworks out there that do about the same for a fraction of the cost and without the intense hassle that SP comes with. The time spent on web development is the same. For checking in and out files, use a real source control system.

In the end, do your homework and evaluate the needs. Don't blindly follow something that someone said a week before they quit and apparently without documenting the decision process to end up with the 'MadCap + SharePoint = fixes everything' formula.

[madcampus1]

RamonS thanks for the great reply. Here's some clarification:

We already OWN SharePoint and many of our clients who will USE/consume our online help have it. So, we are IN SharePoint, there's no going back, BUT I'm looking for WHAT SHAREPOINT and MadCap do together.

1. Yes, I can store files in SP for versioning.
2. Yes, I can post the help to SP and then provide the clients a hyperlink for them to view it.
3. Yes, I can probably use SP's permissions to restrict WHO gets to view the online help.

BUT WHAT'S NEXT. What else can SP do for me that I'm not seeing as it relates to our webhelp? I wish MadCap had some usecases out there or something about this...I'd like to hear who has deployed MD + SP and what results are they getting? What's being leveraged in SP that's so wonderful that we need to marry it to MD?

BUT I don't see why I'd need SP and MadCap together beyond the 3 above and no one can tell me. I'd like to know who has put their MADCAP content or webhelp into SP and why? What did they GAIN from it? Was it permissons? No one can answer that.

We are already married to SP internally, so that's final. We are using it as a document repository and some team websites. BUT now, many of our clients have SP and our software is integrating with SP, but being NEW I'm trying to figure out how my HELP and SP will marry and what I gain from that.

Hm??? Still lost...

[RamonS]

We are already married to SP internally, so that's final. We are using it as a document repository and some team websites. BUT now, many of our clients have SP and our software is integrating with SP, but being NEW I'm trying to figure out how my HELP and SP will marry and what I gain from that.

Hm??? Still lost...

The question needs to be is what your customers hope to gain from it. As for writing tech documentation I think whatever SP offers or does not offer is irrelevant. Yea, I can see the versioning (which would be internal use to you) and the access rights management (for end-users) benefit as small, but true benefits. Other than that I can only see political benefits as you can claim that your help 'fully integrates' (aka has a simple hyperlink) with SharePoint.
My assessment that SP is mainly useless and just popular because it is hip and from Microsoft doesn't come from afar. If you create web parts then don't make the SP-only ones. SP can handle the standard ASP web parts just fine and you can use outside of SP as well. But web part creation is purely development work. As a TW you don't gain anything from it.

[madcampus1]

RAMONS...

Now, you are on track! You said what I've been feeling! I think someone promised our clients this seamless integration, but can't explain any architecture behind it. Just a HYPERLINK.

I also heard that they want to be able for the CUSTOMER to add HELP locally to the Madcap files...so that's another monster...haha! I believe maybe we can use SP
for that...

We are already married to SP internally, so that's final. We are using it as a document repository and some team websites. BUT now, many of our clients have SP and our software is integrating with SP, but being NEW I'm trying to figure out how my HELP and SP will marry and what I gain from that.

Hm??? Still lost...

The question needs to be is what your customers hope to gain from it. As for writing tech documentation I think whatever SP offers or does not offer is irrelevant. Yea, I can see the versioning (which would be internal use to you) and the access rights management (for end-users) benefit as small, but true benefits. Other than that I can only see political benefits as you can claim that your help 'fully integrates' (aka has a simple hyperlink) with SharePoint.
My assessment that SP is mainly useless and just popular because it is hip and from Microsoft doesn't come from afar. If you create web parts then don't make the SP-only ones. SP can handle the standard ASP web parts just fine and you can use outside of SP as well. But web part creation is purely development work. As a TW you don't gain anything from it.

[RamonS]

Now, you are on track! You said what I've been feeling! I think someone promised our clients this seamless integration, but can't explain any architecture behind it. Just a HYPERLINK.

This is how 99% of companies "integrate" with SharePoint and other apps. There isn't any sharing of common data objects or even the same database or a web service or agent that can send and receive records. It is the same bopkus like 4G phones (being marginally better than 3G, but not by an entire technology generation) or MSSQL Express being "free" (it is not free, neither in code not price as you first need to buy Windows).

[forfear]

There might be compelling reasons to publish targets to Sharepoint. But I do not imagine this to be the solution for everything (so much depends on the business case and challenge you expect to face):
For example:
- Is configuration management/document versioning/change management an issue?
- Is this a information/security risk management issue?
- Do you want a repository to store backups of project source files?
- Do you want to make all the support documents for your products accessible to
- Product support technicians
- Customers
- Product support technicians + customers. (or all internal staff)
- Are you doing this because its a general management directive to centralize storage in existing repositories (to simplify IT backups and risk audits)

You might want to use Sharepoint and Flare to do some of the following. But have you considered the other available alternatives. Flare was among the first authoring tools to offer support for team foundation server source control way back in Version 3. The alternatives, when considered, may sometimes present a far more viable solution? Just because you have a hammer ....

• to create a centralized document or product support repository: a web accessible location where you can download, browse or search for PDFs, CHM and Mobile WebHelp versions of all published versions of online help. Anyone can already do this conveniently.
  • Have you considered alternatives such as FTP servers, file server, existing web servers or the corporate content management server?
• to store Flare/Blaze project and topic source files with light version control, and user control access.
  • Do you know you can manage access to source code versioning, in a much more robust manner, if you are already storing projects on a source code versioning server like Visual Source Safe or Team Foundation Source Control.

[trent the thief]

We are already married to SP internally, so that's final. We are using it as a document repository and some team websites. BUT now, many of our clients have SP and our software is integrating with SP, but being NEW I'm trying to figure out how my HELP and SP will marry and what I gain from that.

Hm??? Still lost...

The question needs to be is what your customers hope to gain from it. As for writing tech documentation I think whatever SP offers or does not offer is irrelevant. Yea, I can see the versioning (which would be internal use to you) and the access rights management (for end-users) benefit as small, but true benefits. Other than that I can only see political benefits as you can claim that your help 'fully integrates' (aka has a simple hyperlink) with SharePoint.
My assessment that SP is mainly useless and just popular because it is hip and from Microsoft doesn't come from afar. If you create web parts then don't make the SP-only ones. SP can handle the standard ASP web parts just fine and you can use outside of SP as well. But web part creation is purely development work. As a TW you don't gain anything from it.

Come on Ramon, you're among friends here. You can tell us how you really feel about SharePain.

My company also bought into the SharePain hype. What we needed was a true WAN Intranet. What we have is a confusing hierarchy of files that are virtually impossible to find unless you already know about them. Thankfully, though, we'll be keeping our source files in normal source control.

[LTinker68]

What we have is a confusing hierarchy of files that are virtually impossible to find unless you already know about them. Thankfully, though, we'll be keeping our source files in normal source control.

To be fair, though, that's not necessarily SharePoint's fault. You need to have an information architecture plan and set up governance and training so others follow it. If you just put it up without forethought and a strategy for its use then you're no better off than you were using free-for-all file shares.

[trent the thief]

What we have is a confusing hierarchy of files that are virtually impossible to find unless you already know about them. Thankfully, though, we'll be keeping our source files in normal source control.

To be fair, though, that's not necessarily SharePoint's fault. You need to have an information architecture plan and set up governance and training so others follow it. If you just put it up without forethought and a strategy for its use then you're no better off than you were using free-for-all file shares.

Oh, yes. I understand. Our site is set up well enough, but there are still too many nooks and crannies where project specs end up, and unless you're intimately associated with the project, you'll never know they exist.

I've been using corporate intranets for 20 years. SharePain is not a new solution. Plumtree tried it, and a couple others. IMHO, the whole corporate CMS idea begins to fall apart when there are more than 5-6 people adding and editing files and sections. It will work okay for small organizations, or for those organizations that are large and have a dedicated group whose only job is to maintain the CMS.

[RamonS]

And the biggest issue is that SP does absolutely nothing out of the box. Other systems of equal kind and lower (no) price offer way more features. With SP you always have to fire a developer for a few weeks before you can do anything with it. Total non-starter, yet the world throws money out the windows for that. I just don't get it!

[trent the thief]

You sure pegged that one. I've always thought hat there is some sort of collusion between M$ and a secret organization of third-party developers who have an inside track. Why else would they create such byzantine creations that require additional outside help to use?

[RamonS]

That is because SP is a product that was developer driven, was designed by developers, and is only liked by developers. That anyone else other than an MS in CS would lay hands on this thing was never considered during the design cycle. Unfortunately, the marketing team did a heckuva job selling this garbage to managements: It fixes all your communication, collaboration, and documentation issues. Just install it and your entire company will be 180% more productive within a few hours.
Luckily, I don't have to deal with it any longer. I even put my SP books on the shelf in the common area so that nobody gets the idea that I could help them with anything SP related. Leaves to discuss what is worse, SharePoint or the ribbon....hmmm, I go with the ribbon, at least I can uninstall SharePoint.

[trent the thief]

That is because SP is a product that was developer driven, was designed by developers, and is only liked by developers. That anyone else other than an MS in CS would lay hands on this thing was never considered during the design cycle. Unfortunately, the marketing team did a heckuva job selling this garbage to managements: It fixes all your communication, collaboration, and documentation issues. Just install it and your entire company will be 180% more productive within a few hours.
Luckily, I don't have to deal with it any longer. I even put my SP books on the shelf in the common area so that nobody gets the idea that I could help them with anything SP related. Leaves to discuss what is worse, SharePoint or the ribbon....hmmm, I go with the ribbon, at least I can uninstall SharePoint.

I'm still using my ribbon killer add-on. MS is full of "productivity exports" who've never needed to work on a deadline for a deliverable.

[RamonS]

Except for Outlook, which I have to use at work, I entirely sidelined MSO. LibreOffice works much better, especially for what I need to do with spreadsheets.