SharePoint vs. TWiki
I am interested in opinions on Microsoft's Sharepoint
portal software compared to TWiki.
- 10 Nov 2002
My initial reaction is - Sharepoint sucks. Let me explain myself:
First, a little context. My company is located in USA+Denmark+Japan, with cross-continent work teams. Each country has (to keep it simple) team A, B, C
, etc., and all the team A's
work together on team A
projects. You get the picture. Half a year ago, we in the Japan office started a TWiki-based intranet effort for the entire Japan office, across our Japan teams. Two months ago, the USA-based team A
started a Sharepoint-based intranet for all team A's,
across the world. So at the moment we have two partially overlapping intranets, and in the overlapped area are the work materials of team A
Being in this team A
, I get to experience the joy of working with both sorts of intranets. Here are my initial comments. Please note that the experiences here reflect the setup used in our business case; perhaps it's easy to address the problems I mention, but that's not happening here.
I'll try to answer if other TWiki users have questions.
- TWiki is a lot easier to update: click the edit link, then save, and you're done. Can't beat that.
- TWiki is webpage-based; you see the content right away, directly in the browser, and it's all searchable and easily changeable. Sharepoint seems to be a very basic-level web-overlay; content material is stored in documents just like on a file server, and I can't search for the contents in the documents. Is this an attempt from Microsoft to web'ify their Exchange Public Folders?
- In TWiki, I can immediately change the contents of the page I'm looking at. I can even rename/move the page itself! In Sharepoint, I can't easily move stuff around, and there's no simple way to update content that's already been uploaded.
- Sharepoint seems to be a little more upload-and-forget oriented, while TWiki is write-it-online-and-maintain-it-there oriented.
- Sharepoint has a fixed structure, like a file share, that forces me into a single route to each document. Each piece of content is not freely hyperlinkable like in TWiki.
- Sharepoint looks very professional, but also very finished. It has a done-deal look over it, and it does not encourage or even look like it's possible to update content.
In summary, it appears to me that Sharepoint is a web-based replacement for a very static file server. TWiki is just the opposite, a highly volatile neverending work-in-progress, and that is also what it looks like - but it could use a little more newbie friendliness (professional usability?) to better encourage newbies to participate. But still, compared with Sharepoint, TWiki wins this. Sharepoint is impressive-looking but not easy to work with (except as an uneasily navigatable static reference source), while TWiki is geeky (scary?) looking but very flexible and powerful - and easy, once you get into it.
I'll assume right away that the views above will change over time, and that my immediate impression after such a short time aren't very accurate. To complete the picture. let me also point out that I'm familiar with TWiki from earlier intranets too (and I love it, despite it's quirks); and I don't hate MS (I worked for them some time ago). I honestly tried to give an objective evaluation, but then again, even objectiveness is subjective
(See further comments from me below
- 11 Nov 2002
I'd second Torgen's views on Sharepoint. I've currently got TWiki running for IT documentation (Knowledgebase, Install Docs etc). It's battling a sharepoint server which has been suggested as being used for the same task more becuase were are somewhat of an MS Shop.
You could create a Twiki-like area using text areas inside a Sharepoint list, but you don't get the benefit of other TWiki items (Rev Control, easier markup lang etc). It's also a right pain to have to pull a word document over a WAN, only to find that it isn't what you are looking for. And when it takes upto 60 secs to pull one document there is a lot of wasted time.
Probably the only great benfit of sharepoint is the ability to import a spreadsheet into the system and have it appear as a basic updateable database. We use it for IP Address management as it makes an easier system to maintain instead of spreadsheets.
Personally, documentation is better stored in TWiki. Easier to maintain more than anything else.
- 13 Nov 2002
We evaluated Sharepoint for our document management system for a couple of months. It certainly looks slick, particularly compared with the default TWiki appearance, but we ditched it because it was just too tied to MS products. You only get all the features if you used Windows OS and the Explorer browser. Other OSs/browsers did work to limited extents, but most features were not available unless you went the pure-MS route, and there was no guarantee they would continue to work with future versions. Since we are a multi OS/browser company, that was reason enough to reject it. Another major disadvantage were the lack of revision control.
One other datapoint - I spoke to someone at another company that had entered all their documents into Sharepoint and had it crash, corrupting the database and requiring re-indexing of all the documents. This basically shut the company down for a whole day. Although this is just a single anecdote, it reflects another important difference between Sharepoint and TWiki in that TWiki stores data and metadata in plaintext on disk, so it is always easy to get at the raw information. Sharepoint's encoding means data corruption is much more serious if/when it happens.
At the same time we were evaluating Sharepoint we also evaluated TWiki, and we are now standardising on TWiki for almost all documents and shared information in technical groups within the company. It evolved in a more underground way but spread quickly across these groups. However it has not broken out beyond that to nontechnical users because of issues widely discussed at twiki.org such as difficulty of editing content for non-html-savvy users.
- 17 Nov 2002
Greetings, I agree completely with all the above comments of Share Point v Twiki. I�ve had the opportunity to test with and pilot MS Share Point for numerous clients (ASPs and Enterprise) over the past 18 months. The bottom line is that Share Point is a complete nightmare to configure and support. There are numerous issues with supporting Share Point which are show stoppers.
a)The requirements of MS office + the SP extensions on each workstation (very fat client w Office).
b)Users require substantial training to be able to use Share Point.
a)Not scalable (Team Services just makes things worse).
b)No way to provide high availability of the doc store.
a)Forced to use MS Front Page to modify the environment.
b)Documents are difficult to maintain.
4-Expensive on the server and clinet side!
Last Month I had the opportunity at a trade show to ping a bunch of network administrators and business owner about MS Share Point. Everyone has the same gripe, difficult to setup and maintain, users are unable to use it, no high availability and it�s not scalable.
I�ve been testing and tweaking on Twiki for a couple months on a Linux box and I really like it. It does not have a polished look out of the box like Share Point but it�s simple to brand and customize. Unlike Share Point which requires a lot of users training, Twiki seems to be more intuitive and simple to use.
I�ve had the opportunity to work with other document management solutions from Stellent and Documentun as well. Share Point is by far the least desirable of the document management solutions I�ve tested and piloted. Twiki is an excellent alternative to the more polished and proven solutions from Stellent and Documentun.
- 24 Nov 2002
Here are some of my experiences with Share Point Team Services(STS)
Some of the great features of STS
- Out of the box basic team site
- Fundamental building block in STS is a list. Everything is a list of data. You can define your own list(meta-data) For e.g. you can build a weekly status report list with custom columns like (week of report, author, actual report)
- Consequently very easy to create project specific lists.
- Content is stored in MSOffice documents.
- It uses Windows Index Server. Consequently contents of all uploaded office documents are searchable
- Extremely easy to set-up and maintain. However moving your site to another machine is not a very smooth process
- Upload non-textual content (design drawings/discussions etc)
- Web based discussion board support
- High level of integration with MS products
- Polished UI. Good for non-techincal users like the Administration department.
- Need to have MSProducts to collaborate/integrate effectively with STS.
On the whole, our experience with STS has been pleasant. However these are early days and we will need to see how STS scales w.r.t users/content
- 28 Nov 2002
I have not personally installed sharepoint, but my experience with MS products is you can install them quickly -- in an hour or 2.
I have spent days trying to get twiki to work on IIS with ActiveState
Perl. Installing CygWin
alone is confusing.
Backup will be a lot simpler with twiki, and you don't have to boot it all the time (Sharepoint seems to need a boot daily at our install. Too much action at a distance). Sharepoint is hard to read, the discussion boards are about the only collaborative tool thats useful (and not as good as outlook folders), hyperlinks between content are hard and frequently break.
No RSS feed or other useful change history of whats changed in sharepoint. All you get is an email listing the discussion boards you subscribed to that have changed. It would be anologous to manually having to subscribe to every single page in a wiki.
Content is really hard to publish in sharepoint (its somewhat easier if you buy office XP). It all basically has to be in word or excel documents, lists (created by an administrator), or discussion boards. It really provides no value over storing your office documents in a directory tree; you have to create the file, upload it into sharepoint, download load it again to edit it, then upload it again.
You can lose stuff in sharepoint. There are no diffs (no RCS
-like backend). You could lose key intellectual property just by having someone edit or delete a file -- its gone for good (unless you remember the file was there and on what date and do a database restore).
Search doesn't work well.
was apparently written by the FrontPage
team. Draw you own conclusions from that. Web Pages That Suck
has a nasty logo to be applied to web sites that are created with Front Page.
Sigh. I wish I had never come across sharepoint. Its only worth using if your content isn't worth anything.
- 31 Dec 2002
Some time has passed since I wrote the first comment above
. I've come to realize more about both intranet platforms, and I want to share these additions with you. Overall though, TWiki still wins. But some things urgently need attention; TWiki isn't perfect either.
Pro TWiki, Con Sharepoint:
- Sharepoint requires Office installed, and the native format to store data is Office format. That may work well ona local network, but if the server is on another continent, it sucks because files take forever to access. It doesn't seem like an ideal method for browsing for the knowledge that is "probably in there somewhere."
- Also, documents open inside the browser. Ever try to work with a huge Word document from inside IE? It's nearly impossible to do; you've left the browser but you didn't get the power of the application in return. Instead, you're stuck with a poor user interface.
- I can't add any comments or questions to this sort of intranet (at least not with the specific implementation available to me). It's a browse-only experience, no way to add anything.
- I should mention that the "owners" of that intranet also have extremely limited resources for installation and maintenance, so I wouldn't expect any changes or improvements to appear.
Con TWiki, Pro Sharepoint:
- TWiki is not good with spreadsheet data. Small tables are possible easily enough, but large ones are plain impossible. An attached Excel file is better but still not very good (except that it gets revision control on the file level, doesn't it?).
- Why isn't the TablePlugin installed by default? And there are a handful of other plugins that should be mandatory as well.
- TWiki can't handle advanced data, not just spreadsheets. In can handle anything that can be written in an e-mail, including simple formatting markup, but anything smarter than that needs to be attached, and then it gets very cumbersome to maintain. Think about a Word document with graphs or diagrams or images, or even flowcharts! Obvious file types when working with documentation tasks, but impossible in native TWiki format.
- TWikiDrawPlugin seems like a great approach. Alas, we haven't tried it yet...
- TWiki is ugly! It may be very flexible and powerful, but it can still be these things with a much nicer skin.
Must-haves in future TWiki versions:
- Improve usability and default skin (for instance TigerSkin plus IEJS skin).
- Easier maintenance and especially installation to keep the cost down.
- Yeah, the software is free (GPL) but not so the working hours of the IT personnel.
- Setup is very tricky to get right. Not every company has Linux or Unix experts, but many have Windows knowledge only. In the case of my workplace, we could easily find the hardware and the software, but the difficulties in installation and no less the maintenance of it is severely threatening the intranet.
Bottom line, TWiki still wins. But it's not good enough just yet. (The obvious response is to ask me to help programming the next version
but I'm not any good with Perl, though I'd love to contribute with what I know, if I knew how. But that's not the topic of this page.)
I'll still come back and add comments when I learn more, and I'll stay tuned to any reactions. I'd really love to hear some positive hard facts about Sharepoint.
- 09 Jan 2003
My company tried Sharepoint (actually some of the system people were strongly anti-TWiki and tried frantically to impose any commercial system instead of it), but they never really managed to set it up (in summer 2002). If they could have made Sharepoint barely usable, they would have banned TWiki from the site.
- Only works with MS clients
- Slow, especially on a WAN (sending Office documents is orders of magnitude bigger than text)
- Backup is tricky, there is always the risk of loosing all/part of your data.
- It is complex to use, users need training.
- Max load can be easily reached on one machine, requiring to set up multiple sharepoint servers, which could be quite complex to manage.
- Setup seems to be easy for Microsoft specialists (but non-specialists battled with it in vain for weeks)
- Actually, sharepoint do not provide a lot of functionality, relying on Office tools. For instance, showing diffs is done by the Word history of changes mecanism, which is inherently non portable, but very well integrated.
The summer 2003 version may be better. But it is clear that there is a definite
design goal for Sharepoint to prevent its use with non-Microsoft software.
- 03 Jun 2003
Did I Read it correctly that SharePoint
is a free download for MS Server 2003? I am quoting InfoWorld
found via google search in saying "Microsoft Corp. on Wednesday delivered Windows SharePoint
Services, a part of Windows Server 2003 that allows end-users to set up Web sites for collaboration and information sharing."
- 01 Oct 2003
I guess better MsOfficeIntegration
could include invoking Word in the right way for sequential revisions of the same document. Sounds like a plugin and I think there was something in MorePluginHooks
to request plugins take care of revisions.
Might as well make use of what they provide
- 03 Jun 2003
I was looking to use both TWiki and SharePoint
on a new project. Reasons:
- Typical feedback on Wiki: "Wiki is very good as a starting point and also for IT people but as we might involve more and more non IT people you might want to look at a more userfriendly solution"
- TWiki too techy for some
- TWiki didn't have the security I needed - see SecuringAttachments
- Wanted good integration to Windows and office
- Wanted document searching, linked to security
Of course I already have TWiki, so only messy bit was creating a secure Web
. That was only messy because I was careless on the syntax for groups and in WebPreferences
- I had a usable system in 2 hours of asking (this was last week). However, within two hours a Microsoft security patch killed SharePoint
, it is still dead! Also this, somewhat old, version of SharePoint
, only support Office XP integration and many here don't have Office XP!
- 01 Oct 2003
- 02 Oct 2003
Side note: Microsoft C# design team use a wiki internally... See WikiInTheNews
- 28 Oct 2003
Having just set up a sharepoint server, I can say that it has improved considerably since I first looked at it. Its integration with office is formidable.
gives interesting stats.
If you want to play with Sharepoint, I'd recommend taking a look at http://apptix.net
- they offer a free 30 day trial.
- 31 Aug 2004
Thank you for the link Martin (to register at http://www.apptix.net
, cookies should be enabled). There's a showroom at http://solutions.corasworks.net/Default.aspx
- 01 Sep 2004
- 01 Mar 2005
Martin, did you switch over to the dark side
What do you see as low hanging fruit we can do in TWiki to improve the usability compared to Sharepoint?
- 01 Mar 2005
- Must be to get WYSIWYG editing out. i.e. cut down the Kupu for TWiki until it works.
- Play with SharePoint to understand how the custom-views of data table works; sketch out how we can do it in TWiki and mobilise a team to get it done.
- Make a web for TWikiApplications.
Its not just usability though: The competition from e.g. http://www.microsoft.com/office/solutions/accelerators/scorecards/demo.mspx
- 02 Mar 2005
- 02 Mar 2005
Oh god - another scorecard app. Jolly good, if you happen to want to do scorecards "the Micro$oft way". The power of TWikiApplications
- which we do not push enough - is their configurability for the way you
do things. Flexibility is the great power of TWiki, even if the end user doesn't use it (and even if we make it harder with frightful syntaxes!)
- 02 Mar 2005
To do anything sensible with sharepoint seems to require that at least the administrator using Windows office 2003. (nice upsell, huh?)
For an idea of sharepoint's functionality, take a look at http://www.sharepointcustomization.com/resources/tutorials/WSS%20and%20SPS%20Training%20-%20A%20course%20to%20enhance%20your%20personal%20productivity.pdf
- 07 Mar 2005
The biggest reason for me to go along with SharePoint
rather than TWiki (apart from the fact that Intel corporate is bought into SharePoint
) is that SharePoint
makes it easy to control accessibility on an item by item (page by page) basis.
allows deeply nested hierarchy - which MegaTWiki
does, but standard TWiki does not do out of the box (or has that changed already?).
I will admit that I am finding SharePoint
really, really, ugly and awkward to use, compared to the various wikis I have used since 1996.
- 06 Apr 2005
Talks about the feature list of Sharepoint2005.
Most significant for me was the inclusion of tightly coupled WorkFlow
- for process nuts this is where the war will wage.
- 08 Feb 2006
For those using Openoffice, this could be a good alternative to Microsoft Sharepoint http://www.o3spaces.org/index.html
I've not used it, I work in a very MS centered Company. Maybe someone can or would like to test it. Maybe there is some integration potencial with twiki.
- 18 Mar 2006
(0) I am happy to say that my local community at work is beginning to give up on SharePoint
, and is moving to wiki more and more.
(1) Apart from SharePoint
access control, mentioned above
also has the big advantage that one can click on a document such as a Word file attached to a SharePoint
document library, edit it, and save it. No need to upload a new version of the attachment.
supports editing-in-place from the browser.
I believe that this is obtained via WebDAV support in the Microsoft applications. One of my coworkers is looking into wiki/!WebDAV.
Of course, since I use UNIX (or Cygwin) as much as Windows, I would like all of my trusty UNIX apps to be able to be invoked "in-place". IMHO the right way to do this would be to mount a WebDAV server as a filesystem. Probably as a private user namespace.
- 23 Mar 2006
You can manipulate attachments in TWiki directly with the WebDAVPlugin
- 23 Mar 2006
Problematic, since our IT department is reluctant to make changes to their Apache installation.
- 23 Mar 2006
Microsoft has presented a new version recently:
Bill Gate's speach:
Short version / Flash-presentation:
I didn't have time to look at it closely, but integrating blog AND wiki technology with sharepoint's document management services seems to make sense.
- 19 May 2006
is not working for Apache 2.0. I know my IT department (which is sold to Micro$oft) will claim that capability over Twiki. Also, they claim the new sharepoint 2007 has wiki and blog capabilities and thus defeats at first instance the introduction of TWiki in my organization....any suggestion?
- 09 Dec 2006
That sword is also hanging above our twiki. Our new head of IT is in love with Sharepoint.
- 09 Dec 2006
probably because he doesn't actually have to work with it himself...
that said, it does have a half-decent file management module that TWiki lacks...
- 09 Dec 2006
For everybody not that familiar with Sharepoint it would be nice to have a comparison table.
- 10 Dec 2006
Uhmm that doesn't sound good Arthur. So far I could only argue price...but again if they are sold to Micro$oft my countless hours putting this baby together will be for nothing...Any compelling suggestion?
- 11 Dec 2006
Hmm, I hear very consistent feedback: IT managers love SharePoint, most users hate it.
Sorry, I can help on a comparison table, but yes, that would help the TWiki project (and prospective users) a lot.
- 12 Dec 2006
How about I just start a table template that people can edit up...
| Easy setup for authentication on a Windows Domain
| Administration of user rights and priviledges
|| Super easy
|| Doable, but not related to the Windows Domain necessarily
| Tight Integration with Microsoft Office
|| Files can be attached but not edited right off the server--not really integrated
| Searches attachments
|| Requires a plugin
| Availability of functionality to do different things
|| Plugins available
|| Lots of plugins available
| Ability to get your data out of the system
|| Forget it--locked into Microsoft forever
|| Very easy
| Ability to export data for reference without a server
|| Not that I know of
| Ability for users to add content
|| Very easy
|| Very easy
| Ability for users to add content structure
|| Not very easy
|| Very easy--Same as adding content
| Tools required to work effectively with the system
|| Microsoft Windows + Office 2003
|| Any browser
| Tools required for admin work
|| Windows, Office, FrontPage
|| Any browser
| Ease of setting up a server
|| ? (Probably not too difficult)
|| Not too difficult (depends on how you do it)
| Document Versioning
- 12 Dec 2006
Has anyone tried the Sharepoint wiki capability? What about Sharepoint's price? Is it gonna be per seat or per connection?
really needs to be upgraded to Apache 2.0 so that we can argue direct server editing and versioning. A standard pre-installed attachment searcher is also needed (I'm a TWiki newbie and still can't get the plucene to work).
Check out this article. Even people with comercial wiki software are concerned about it:
- 12 Dec 2006
Hm, maybe if our favorite Wiki engine would support document creation (e.g. via a DITA
based backend) that would prolong its lifespan.
- 12 Dec 2006
Our company is more in need of a file repository.
- 13 Dec 2006
Hm, in the meantime the usability of the attachment table should be enhanced. The standard processing of one attachment at a time only is really annoying. Why can't we at least have checkboxes in each row to select the number of attachments that shall be processed (moved, deleted, ...)? Of course I'm against missusing TWiki as document management system, but it really could do much better in handling attachments. At its current state it's too geeky for most users I fear.
- 13 Dec 2006
Franz, why are you against 'misusing' TWiki as a DMS? I think that, if the attachment table could be improved towards a document management widget, that would be really nice. With that I mean:
- version controll
- ability to create (nested) folders
- easy copy/paste of wiki url to the attachment(s)
- easy upload of several documents simultaneously
If the attachment table could do this, then either every Web could have a single central DMS, or every topic could have a very powerful and easy to use attachment table.
- 14 Dec 2006
I'm against it because one can do so much more by directly SEARCHing through the content of (structured) topics (organized in a flat pool) than by falling back to the old hierachical file system thinking. But of course I'm with you that a nicer interface for dealing with attachments (which IS very common and well understood) should be a must for a system like TWiki. If one uses an additional indexing engine like Plucene one could even (re)find the stuff one has attached somewhere.
- 14 Dec 2006
for some related information on how our company tried to solve the problem (and ended up with a bit of a n upgrade mess).
I believe that AutomaticAttachments
has a lot of potential to solve these issues.
- 14 Dec 2006
Pankaj, did you ever upgraded to Dakar? Did you end up building a plugin for it?
- 14 Dec 2006
Nope. Budget constraints are preventing us from spending any further resources, although it's very high on my personal wish-list. Hopefully, sometime next year we will be able to justify the investment.
- 14 Dec 2006
promises to index attachments, but the package has been abandoned. BatchUploadPlugin
has really struggled to move to TWiki-4. Personally I think that webdav is a better route to go than trying to enhance attachment handling, but again no-one is prepared to support an apache 2 version. Together, these make me think no-one is really serious about using TWiki as a DMS.
Jos, you can already create hierarchical subwebs. Why don't these class as nested folders?
- 15 Dec 2006
I have created feature request topic ImproveAttachmentHandling
- 17 Dec 2006
This means Microsoft Sharepoint is joining forces with the Socialtext Wiki.
- 18 Dec 2006
Even worst (or better), WikiCalc
is providing nice spreadsheet functionality to wiki, apparently planned for socialtext.
- 19 Dec 2006
Don't get over-exited about Socialtext. Although I find the new version very good on the usability side, it is a very basic wiki (by design). The Sharpoint integration is quite shallow, basically on the link level. And WikiCalc is a separate product with different wiki syntax.
- 20 Dec 2006
Crawford, as I understand it Subwebs could be used as folders when you store all file attachments in one central topic per web. What I meant was the ability to organise attachments per topic in several (real or virtual) folders.
Perhaps if there was some widget that could show all attachments at the right location in a topic tree (based on parent/child relationships), with some ability to upload/delete/manipulate them from within this widget, then from a users' perspective there are already folders - without subwebs - because every topic is in this view in fact a folder. Something similar can be imagined for topics, where the organisation into folders would be just an interface thing without any actual subdirectories on the server.
Mind you, I am not a programmer, or much of a sysadmin, I am just trying to imagine how this might work.
- 21 Dec 2006
I think this is fundamental to the TWiki data model. TWiki was obviously designed as a wiki, and not as a database or a document repository. It sort of "fell" into these roles later, but they are not the TWiki raison d'etre
. So you can only have one form per topic, and a topic has a flat collection of named attachments. I think it would be a bad idea to try and change this.
On the other hand, nothing is stopping your from writing an extension that creates a new topic for each uploaded attachment, and then organising those topics in whatever way you see fit using TWiki SEARCH etc.
- 22 Dec 2006
I think that if TWiki provides by default, attachment search (integrate it directly with plucene or swish) and provides by default webdav, then it would be in the right place.
- 22 Dec 2006
Following is a conceptual way for creating an attachments linkage/hierarchy:
Current situation: an attachment is referenced in a dedicated "File Attachment Contents Table" and/or in-lined the Topic's text.
Current work-flow, scenario 1: a user write the topic's text, and in some point of time attaches file/s via a separate mechanism
, s/he have to exit the Edit-text mode and enter the Attach-file mode. Then need to return
Edit-text mode in order insert the relevant reference.
Current work-flow, scenario 2: a user write the topic's text, while in-line referencing a file (which would be up-loaded in the future) and hopefully the two references (Table and in-line) are matched.
In any of the above scenarios the user
is responsible for verifying and validating a file-to-reference linkage.
My suggestion: A user may still write a file attachment reference (e.g. %ATTACHURL%/file1.txt) in-line its text.
But, Similarly and consistently the way TWiki refer to CamelCase
(A question mark after a word symbolize a link to a topic that doesn't yet exist), a question mark would symbolize a not yet up-loaded file.
That way the user gets an instant feedback for no-exist file.
That way it does not matter, if one upload and attach a file and then
create a reference in its text, OR s/he refer a not yet uploaded. But TWiki let the user a proper indication.
Moreover, and relating the hierarchy issue: I would suggest that TWiki expand the hierarchy model, and includes the
Headings levels as part of a virtual hierarchy i.e. %ATTACHURL% would be composed from the Site+Web+Topic+Headings
The uploaded file it self would be physically stored in the old way and place while filename.txt,v file may carry also the additional virtual hierarchy info. Virtual path composed of Site-Web-Topic-Heading_Lvl1-Heading_Lvl2-Heading_Lvl2-Heading_Lvl3 etc. (The user is responsible for shorten headings names)
TWiki needs to sense %ATTACHURL%/filename1 and no match in order to display '?'. And eliminate the '?' from link, in case file is properly placed.
Camelcase wiki words and file-attachments are similarly handled (consistency).
A user gets an indication for Not-Uploaded-Yet file (better UI services).
While reading, the user gets an immediate link to the document (better UI services).
A user may create an attachment hierarchy via Site-Web-Topic-Headings usage.
- 31 Dec 2006
I've been trying to decide what to do for a Wiki for my current department. Whilst in keen to use TWiki again, I needed to be objective about it. Thought people might be interested on the how this consideration has gone.
| Consider Wiki
|| We already have several instances of this. The OpenSource project died a long time ago. Main advantages are simplicity, database backend and integration to my companies security model.
|| Used internally for some successful documentation sites. After looking at this I wasn't convinced it makes a good general purpose Wiki
|| Almost too powerful, fairly expenisve in computing resource, not sure if we can get the NTLM to work
| Sharepoint 2007
|| Sharepoint use is rising rapidly in my company and it's broadly liked. If the Wiki functionality in 2007 was good enough this would have been an obvious choice. I've now got to try this and while I can see many people tempted by it there are serious limitations. In particular storage appears to be HTML and documentation very limited. There are many other lacks e.g. no support for headings
So we'll be going for TWiki, but working alongside Sharepoint for list and document management. Hopefully we can get NTLM working and at present would be good to know how widely this is used and if it works better from a Windows host (IIS or Apache) or Solaris.
- 24 Jan 2007
Very interesting read, thanks John. Well, NTLM should be doable, I have read about it somewhere (ApacheInstallModNTLM
). If one of the open indexing engines (e.g. Plucene) would be easier to configure and WebDAV
would work on Apache 2.0 TWiki could even be used as DMS. Just my 2c.
- 24 Jan 2007
I have seen that TWiki performs much better on Linux than Windows using the same hardware. I cannot compare Solaris to Windows, I suspect that you get better performance and better integration support on Solaris. As you know, TWiki is CPU intensive, so get enough GHz and MBs for a high volume site.
- 24 Jan 2007
I certainly feel more comfortable using Linux/Unix. Fortunately looks like there's a 4 CPU Sun box of reasonable spec that's available. If there's time I'll try an NTLM module - as yet another registration and logon always put people off.
- 24 Jan 2007
, would you mind elaborating more on the lacks of sharepoint 2007 wiki functionality? Which other lacks did you find? Thanks,
- 20 Feb 2007
I only did a quick check of Wiki features in Sharepoint 2007. The almost total absense of documentation and help made this fairly difficult. But as I said above the apparent lack of any Wiki Markup language was a real problem. In essense this was really a simple Web based HTML
editor for composing pages and not really a Wiki in the conventional sense.
- 25 Feb 2007
compares the SharePoint
wiki and TWiki. CERN uses both.
- 22 May 2007
Interesting article at LWN about Sharepoint
[subscribers only until 21 Nov 2007], and its role in helping Microsoft Office applications and document formats. By tying the document format closely into the Sharepoint server, it's possible to embed Office into server-based business processes, making it much harder for organizations to go OpenOffice
Maybe we should be collaborating with the OpenOffice
folks to develop some key features that improve integration? The real competition is not just SharePoint
vs TWiki, it's (Office plus Sharepoint) vs. (OpenOffice
plus TWiki)... Although we also need to create better Microsoft Office integration
- 14 Nov 2007
Some comparison of TWiki and SharePoint
including pricing. By the time you add up the license fees for Sharepoint software, client access licenses (CALs), Windows server software, etc, it starts looking like an expensive solution. I'm not counting Microsoft Office costs, but if you were to look at end to end costs of licensing for Linux clients plus OpenOffice
, with TWiki on Linux servers, the OpenSource
solution is a lot cheaper, and as far as I can see far more flexible. I find it quite painful updating our Sharepoint server, as do most others, so I end up just using the wiki as much as possible.
- 26 Nov 2007
You must be very careful when comparing the prices of TWiki and SharePoint: AFAIK the cheapest licence for SharePoint (Microsoft Windows SharePoint Services) is included in the licence for the Windows Server 2003 licence. For many companies (including the one I work for) this means they can user SharePoint for free, because they already have SharePoint! Of course some parts of the functionality are missing (e.g. the access to SharePoint for people outside the company and the portal server stuff). Nevertheless big parts of SharePoint - including the Wiki part - are available.
In our company right now we are at the decision point between TWiki and SharePoint: Money is no argument: As said above, SharePoint is more or less free for us. Politically TWiki is highly under pressure because our IT department always prefers Microsoft whenever possible. Thus I need more arguments for TWiki:
One could be resources: TWiki runs since one year on a little virtual machine with just 150 MB. I am sure SharePoint will need more. Does anybody have some figures?
Another could be the SQL
-Server needed for SharePoint: At the moment we only use Oracle. Are there any experiences with the SQL
-Server for SharePoint (maintainability, backup, reliability, disaster recovery).
Finally the Wiki of SharePoint itself: I am sure that TWiki has much more functionality, but we do not use all of them. Perhaps the functionality of SharePoint is sufficient. Does anybody know real drawbacks compared to TWiki?
- 26 Nov 2007
We moved to Sharepoint 2007 here pushed by IT, but we kept TWiki also. We plan to use TWiki as a front-end for Office documents stored in Sharepoint. What I can say:
- Sharepoint comes in many different versions, with pricings that can grow quite large as you may be forced to use much more expensive versions of Windows and SQL Server, have additionnal layers as MOSS
- Sharepoint works in a degraded mode with non-IE browsers. For instance photos will not have thumbnails in firefox. The wiki and forums will require you to edit by hand in a text area the raw HTML of the contents, WYSIWYG is only for IE
- Sharepoint is actually a toolkit to build applications on. It comes with a default interface that has blatant usability and consistency issues. You will need to budget .NET development on it
- backups are tricky: there is no way to restore a projet, you will have to restore a whole site
- Sharepoint is not complete: you will have to buy commercial addons for something as basic as group management
- Sharepoint takes the opposite architecture as the one recommended by Microsoft: they put all the documents in SQL Server, a database technology not designed to handle a lot of data. So you will quickly have to buy huge machines (16 G ram) to handle the documents of ~500 people after 2 month use.
- There is no possibility to replicate Sharepoint servers: this means bad news if you are a multi-site company
- Sharepoint is extremely slow: there is no miracle, as everything is Office documents, every operation involves moving around big amount of data
Basically, Sharepoint is designed to be used in huge clusters of Windows+IIS+SQL servers machines in a big data center, with people in your company used to .NET programming, and users working with Office 2007. But it really feels like a technology from the last century compared to more modern systems like Groove
of the various new "web2.0" hosted solution, or systems like KT
. It doesn't scale: my advice would be to keep one sharepoint server per team to avoid having to run a sharepoint instance on more than one servers. But sharepoint will definitely improve the productivity of pure Office 2007 teams, this is sure.
- 31 Jan 2008
My company is planning to upgrade its intranet site using SharePoint
2007 and Wiki. The idea is to use Wiki as much as possible and fallback to SharePoint
only for the features, where Wiki fails (if at all).
I am not sure if this is really a good idea, since I am not informed of any typical scenarios or cases where Wiki might not be able to deliver and we need to couple it with SharePoint
. Version controlling could be an issue, but I am not very convinced.
Could you experts kindly share some of your experiences please.
: I am thinking of pushing my company at least to the model adopted by your company. Can you please explain how does your Wiki-SharePoint interface looks like.
- 02 Apr 2008
This is a very interesting and valuable resource, that needs structuring and a complete overhaul. I will see, if I can support this process.
- 03 Aug 2008
I have listed a couple of resources, that could help to establish a new article: http://is.gd/1dgf
MS Sharepoint is not listed in WikiMatrix yet.
- 03 Aug 2008
I use SharePoint
for my client and inside of Deloitte. I have built lots of SharePoint
sites and the wiki is often the least successful component of the site. In my opinion, its a little better than having track changes on in a Word document. It is very difficult to garden because you really can't assess the health of the wiki or assist others (a key component of keeping collaboration vibrant in your knowledge ecosystem). If you would like to know more, feel free to contact me. You may also enjoy this blog post: http://briandrake.wordpress.com/2009/05/06/the-promise-and-pitfalls-of-sharepoint/