Ok, I've seen a few posts that mention a few other posts about not using SP wikis because they suck.
Since we are looking at doing our wiki in SP, I need to know why we shouldn't do it for a group of 6 automation-developers to document the steps in various automated processes and the changes that have to be made from time to time.
Here are some caveats I came across that will vanish if you use a wiki other than Sharepoint.
Sharepoint lets you create tons of separate wikis, but I'd recommend having one big wiki for everything. My company made a bunch of little wikis for each project/feature, but only admins can create the individual wikis, so if I want to write about something that isn't doesn't match one of the predefined categories, I have to find a manager to create the wiki first.
Secondly, if you use Sharepoint make sure everyone on your staff only uses IE, since Firefox doesn't support the WYSIWIG editor. This is a good thing for most wikis, but makes collaborating difficult in Sharepoint. Imagine editing auto-generated HTML in a tiny little box all day.
Third, try to write up your project documentation in the wiki and resist the temptation to upload Word docs to the Sharepoint library. No point in writing up all your docs twice and watching things get more and more out of sync.
Finally, image support in Sharepoint wikis is terrible. You have to add a file to a document library somewhere and type in the URL. My images were forever getting deleted because they don't seem to make much sense out of context.
I have a much more positive view of Microsoft's Sharepoint Wiki. In many ways it reminds me of FrontPage 98 -- and that was an unfairly maligned product.
The comment about using a list is misguided. Sharepoint Wikis ARE Sharepoint lists, in which each page is a list item with an HTML attachment.
It's true that you can't link into a page, but if the pages are short I don't see that as a problem. SP Wiki makes it very easy to have short pages.
You can manipulate the Wiki attributes from access 2008 if you wish, and you can add attributes to the wiki list items as desired. For example -- do you want categories? Just add them by editing the list. Want specific views? of list items. Create them too.
There's real genius in the way Microsoft built their Wiki framework atop Sharepoint lists -- which are undeniablly well done.
The TRUE drawback of Sharepoint Wiki was mentioned by famerchris. The approach to image management is surprisingly awful. It's such a serious problem that you should consider other Wikis for this reason alone.
There is a convoluted workaround that I use. It takes advantage of the superb Sharepoint support and image editing integrated with Windows Live Writer.
Create a SP blog that will hold the images that will be referenced in the wiki.
Use Windows Live Writer to post to the wiki-image-blog. Drop your image into WLW, resize it as needed, etc. If you like, use WLW to write your image associated wiki text first draft as well.
After you post to the Wiki, copy and paste image and text into the Wiki editor rich text field.
This takes suprisingly little time, far less than any other option I've read of. I admit, it is convoluted.
Other than the image problems I'm pleased and impressed with the product. If only Microsoft had thought harder about images ... if only ...
The default wiki included with Sharepoint doesn't support common wiki features well at all. There is no way to edit a single section of a page, and no way to link directly to a particular section on another page. The backend is in HTML so you lose the ability to edit in plaintext using simple syntax. The diff feature can't span multiple versions. Poor cross browser support of WYSIWYG editing. No way to auto-insert a table of contents...
There are, however, other wiki add-ins for Sharepoint which I can't categorically dismiss, for instance Confluence makes an add-in for Sharepoint. I haven't evaluated this software myself, and Confluence is somewhat expensive ($1,200 for 25 user license) although if you are already on Sharepoint I sense large corporate coffers :P. There also appear to be some free add-ins like CKS Enhanced Wiki but that appears to have a lot of the same problems mentioned above.
We run into this topic all the time, and the first question I have taken to asking people is "Why do you need a wiki"? Almost always the answers are things "ease of editing", "multiple contributors", and "Word is to heavyweight". Very rarely have we seen anyone ask for what I consider to be uniquely wiki-like features (special "magic" markup, fine grained version history showing changes, etc). Also, they usually want some kind of categorization of things, not just completely free-form pages.
In the SharePoint world these things should scream "list" at you if you've been working with the tool for a while. There is basically no particular reason to use a wiki for these knowledge base-style applications, especially since "ease of editing" usually directly conflicts with the idea of learning a special markup language for most user. Through a couple of rich-text columns in there, and you're all set. If you really don't like the built-in rich-text editor (yes the image uploading process is clunky and it doesn't work in Firefox), have someone in your organization go drop the 8 Benjamins and go get the RadEditor for SharePoint. It should pretty much handle those concerns.
Generally once we've gotten over the "but it needs to be a wiki" dogma, we've had pretty good customer reception to just using lists. In some cases, where a little more of a page templating facility was required we turned to using the WCM features of MOSS, which requires a little more up-front thought about templates, but also has a better out of the box experience for things like content snippets and image handling.
Because the default implementation is not a wiki, it is an HTML editor.
If you've used a wiki before you'll know the difference. Just look at "Your answer" at the bottom of this page to see the difference. You use markup in a wiki, which is relatively easy to read and edit. Formatted HTML completely obscures what is written.
My two cents worth as a wiki content creator and super-user, rather than an administrator or developer:
I am currently editing a document in Sharepoint Wiki as I type this, and it is by far the worst editor I have ever come across. To be precise, I'm using Sharepoint Foundation 2010 (previously known as WSS), editing pages using IE 9.
To sum up the problems I've faced: When creating wiki content you want to concentrate on the content and the wiki engine should be so easy to use as to be almost invisible. With Sharepoint that is not the case. I really struggle with the pseudo-WYSIWYG editor, having to fix frequent formatting problems.
I estimate that I'm about 15% less productive writing wiki content with Sharepoint than I am with ScrewTurn or Wikimedia because I have to deal with the formatting issues. If I spend a day writing wiki pages I would lose about an hour trying to fix formatting issues.
For background: I've created four internal wikis at our company - the first in Wikimedia, the wiki engine behind Wikipedia, the next two in ScrewTurn, and a final one in Sharepoint. In each wiki I've written about 50-100 pages.
In both ScrewTurn and Wikimedia the editor looks fairly primitive - a plain text editor that uses simple wiki mark-up codes for formatting. Each has a row of buttons that can apply mark-up codes for simple things like bold and italic formatting, and to create links, so beginners do not need to learn the mark-up codes by heart. While the editors look plain they turn out to be really simple to use, especially for fixing formatting problems.
Sharepoint Wiki, on the other hand, looks slick but is terrible for editing. Instead of using a plain text editor with wiki mark-up it has a WYSIWYG editor that looks much more sophisticated than other wiki editors. However it has personality, an evil one. It frequently adds blank lines or changes the colour of text. When I select text to format then go to the Markup Styles dropdown to format it, sometimes the act of selecting an item from the dropdown list deselects the selected text so the formatting applies to text at a random location. Inserting text copied from Word sometimes causes the editor to double or triple up on blank lines between paragraphs at other places on the page. There appears to be no easy way of creating a table, apart from writing HTML.
The biggest problem about the editor, however, is that you can't easily see what is going on behind the scenes so it's difficult to fix it. Yes, it's possible to edit the page's HTML but that really defeats the purpose of a wiki.
The overall impression I get as a user, is that this is alpha-level code that has been knocked up by a summer intern. I know Foundation is the free version so perhaps I get what we've paid for but I cannot believe a professional software company put out this product.
For a group of 6 people that will be making "every now and then" edits, the built-in wiki will be fine.
The Sharepoint Wiki is essentially a list of Static HTML Pages, with the only Wiki-feature being [[article]] links. No Templates, No Categories, nothing.
We ended up having a separate MediaWiki and only use the Sharepoint wiki for text-based content that does not need much layout.
Don't forget the Community Kit for Sharepoint - Enhanced Wiki Edition. This adds some features to the out of the box version.
Before the rant, here is my overall experience with SharePoint as a wiki.
It is a poorly implemented feature that failed becouse there was a fundemental lack of investigation into what current wiki environments provide. That is why it failed in it's editor and why it misses on points like: tagging, history comparison, and poorly generated html code.
You need to skip it and get something else that does the job better and link to it from SharePoint.
Having production experience with both products, I'd recommend ScrewTurn over SharePoint.
see edit history for rant
My company rolled out sharepoint recently, and I have to say my user experience was Very Bad. And I'm not just saying I was apprehensive to using it: I went in with an open mind and tried it, and many things just felt like they didn't really work right.
The reasons Luke mentioned more or less cover it.
Why wouldn't you consider using something else like Screwturn Wiki which Jeff donated to a short while ago? I haven't used Screwturn myself, but it is free and open source, and may be a faster lightweight solution for what you need.
We looked at Sharepoint for a department wiki a few months ago. Even though we're primarily an MS shop, we went with DokuWiki. Open-source, so easy to keep up to date, great plugins, and a file-based back end.
I would also temper the ratings of the OOB wiki and its lack of functionality with the technical level of the authors here.
I agree that the SP wiki might qualify in name only - certainly when compared to some more robust offerings - but remember as an admin - your primary success is determined by end user adoption. In short - for every feature that a wiki like Confluence adds, it also adds user education, syntax, etc.
While I would love SP wiki to have more "wiki-like" - there is a certain, undescribable satisfaction you can take when your CIO adds an entry in the company wiki - or you are recognized by a group of administrative assistants who find the new wiki "revolutionary".
In short - the built in functionality may be lacking to the jaded eyes of us tech professionals, but to the technologically naive, its pretty easy to train on, and can expose them to a technology they may have heard of but could never (before this) understand or imagine using.
I've played very briefly with SharePoint Wiki Plus. It's a third-party extension that adds features to the SharePoint Wiki. For serious wiki users then you probably need something more than the SharePoint provided Wiki - either via an extension or a dedicated Wiki product.
Maybe try http://wordtosharepoint.codeplex.com/ for migrating your Word content to SharePoint? It takes care of linking images and most other things.
Screwturn is wicked awesome - and it is C# / .Net.
Sharepoint 2010 is supposed to have better wiki features, and there is always the community kit of sharepoint.
If you are able to leave the Sharepoint Wiki behind - you could always head over to the http://www.wikimatrix.org to find the wiki that works for you.
I fully concur with the above (Keng). Whatever that thing is within SharePoint (currently using 2010), it is NOT a Wiki by a long shot.
I am implementing an automated documenting solution, where I extract config and other info (like perldoc markup) from source code and XML config files. It inserts the info in a set of DokuWIKI pages, complete with formatting markup (including tables). It comes out perfectly formatted and works with a couple of tens of lines of perl, includes internal links to manually edited static doc pages, and support for namespaces so I can have my information logically organised. There is no way I could do that in SharePoint (sigh - company direction)...
The best I can do is try to make DokuWIKI template resemble sort of the SharePoint site (to keep the look and feel similar) and link out of SharePoint. :-(
Related
I've always used TextWrangler/ Notepad++ to develop websites from scratch. I'm now coding what I'd say are very advanced websites this way.
I want to know if it's efficient to do things this way and whether I should learn DreamWeaver and use that
I use Dreamweaver, basically because I'm a designer not a coder. I find it useful to use Dreamweaver, because it has all the tools you need to create a website. Dreamweaver has the ability to be a WYSIWYG in the "Design" mode, but you can easily switch to the raw code and mess about with the code. Which is what I tend to do anyway.
Dreamweaver isn't a cheat way of web design, it is a tool. Much like a pencil and paper would be to an artist, or a hammer to a joiner. It's not what is used to create a website that should be ridiculed or the designer who uses Dreamweaver should be abused. But in fact the website itself, and the application of web design skills/knowledge.
Dreamweaver has it's own project file system, so you know exactly what is in your project and what isn't. You can also see all the external files that are linked in one HTML file, such as a JavaScript file. You can swap between the source code of the HTML file and the external file source code, with one click and with no other open "windows".
Dreamweaver is quite easy to learn (in my opinion), and should at least have a fair trial run.
If I were you, I would download a trial version of Dreamweaver, and try it out.
I hope I've helped in some way.
There are code editors with assists that are far better than DreamWeaver, like Espresso, Brackets or the upcoming TweakStyle.
Each software have a different added value depending on what you're searching for.
Why isn't possible (or feasible) to have latex code written on internet pages: latex being the page's source, like html.
This idea came when I was writing on wikipedia some math article and I realize that the current implementation is quite weak, either in presentation as some things that cannot be written inline.
So, a definitely prettier and simpler approach would be to introduce latex code within the page: the browser would interpret it and, using texlive or equivalent, compile the page with latex generated fonts. This could be inside a HTML, but the generation was using "pure" latex and not some javatex or else.
The latex interpreter could be a plugin of the browser, like Java once was.
This could have profound consequences, like scientific articles be shown on the internet without the need of .pdf or latex based documents be putted on internet in a one click away. The article was code with appropriate packages for internet viewing. The user could at anytime download generate the pdf equivalent of that page.
Any ideas why isn't this feasible /possible?
In general, using LaTeX for web pages is not a good idea - (La)TeX is designed for exact print output, not for a web view of some web page, where the exact display depends on window/screen sizes, user settings, etc.
Also, at least on my computer, TeX combined with a DVI viewer (or PDFTeX with a PDF viewer) is still quite slower than HTML with a web browser to render a similar sized page ... and there is no easy way to have DOM-like scripting for a LaTeX-page, other than regenerating it on each change. You don't want this.
For these parts where this makes sense (mathematic formulas), this actually already works: There are JavaScript interpreters for subsets of LaTeX (i.e. most of math mode), embedded in a normal HTML document. One example is MathJax, which is used on the more math-heavy (i.e. scientific) sites in the Stack Exchange network, like Cryptography Stack Exchange.
After much online research and getting close to what I am looking for by hacking it together (ie. modifying templates and other files, exactly what every expert out there appears to advise against in terms of SharePoint customization) I have decided to go ahead and post my issue here to see if anybody has ever had any experience with this.
In essence, I start off with a plain My Sites host. I would like to keep the My Profile and My Content pages, and add a bunch of new content of top on that. For us, simplicity is of utmost importance and so when I created a new Web Part Page and noticed that it added an additional ribbon under the navigation menu, I decided that it had to go. This is what it looks like out of the box:
With ribbon
Notice that at this point I have already made a few modifications, such as removing the My Site link that by default appears all the way to the left of the other options. This sadly was accomplished in a very brute-force way.
Now, here is the ribbon-free navigation bar, which is just what I want to be able to design without making system changes that I will regret in the future (and that may be easily overwritten by a CU or hotfix)
Without ribbon
So I guess I should make this clear, I don't want the navigation gone, just customized (ie. no My Site string to the left of my options, no Site Actions drop-down for read-only users) and the Browse/Page ribbon that gets added by default everytime you create a new page, well that one just needs to be gone completely, as shown in the second screenshot.
I have read all about hiding ribbons (which just hides the whole thing, including navigation), customizing ribbons (no success in accomplishing this type of basic navigation after trying them out) and simply don't know what to do anymore.
Maybe I am just taking the wrong approach by modifying something instead of just creating it from scratch, at the end of the day it is nothing but a static navigation bar common to all the pages with the special current user drop-down all the way to the right, then if a user has write permissions, she would also get the Site Actions drop-down under Home, that's it.
Hopefully an answer to this question will help others as well who are looking to simplify their SharePoint My Sites host a bit, as out of the box the number of web components that users are presented with might be just a little too overwhelming for your everyday employee, at least in the industry that we operate in.
Anyway, thank you kindly in advance, I look forward to your replies. Do let me know if there is something that is not entirely clear from my explanation :)
If you take away user's Create Personal Site permission (http://technet.microsoft.com/en-us/library/cc262500.aspx) in your User Profile, the "My Site" link will go away.
I'm in a bit of a pickle at work. My department designs a number of internal systems for the company, mostly data-reporting related. We have less than 10 true content pages that actually need to be maintained by a human. These pages were written in PHP and maintained through Dreamweaver by a non-technical staff members - they used the design editor, and avoided the code as much as possible. There were issues, but overall it worked well.
Recently this project was updated and converted to a ASP.NET Web Application. This resulted in some architecture changes, making the content harder to edit with a WYSIWIG editor (it's now revision controlled, it's compiled and thus must be re-deployed after modifications are made, etc.). We sort of assumed that the staff member who had been maintaining it would just continue to do so, now using Visual Studio's "Design" mode instead of Dreamweaver's. We were mistaken, and it isn't an option for technical and non-technical reasons.
The staff member will not be touching any HTML - we need a WYSIWIG editor (this is a requirement we were handed...no arguing with them over that). I started looking at CMS', mainly Drupal, but after a bit of playing around I see that content 'Blocks' don't really have a WYSIWIG editor, instead expecting HTML. Is this true for all CMS'? Is there some easy-to-setup CMS out there that comes with a WYSIWIG editor? Does anyone have any other ideas? Don't care what language it's in, I'll make something work.
This really isn't my area of expertise - I do application development primarily, with an occasional web front-end. Not sure I'm even asking the right question, but hoping someone can help.
WordPress makes use of TinyMCE, and it works pretty well for some NON techie clients of mine. You can write (PHP) scripts that will call the WP functions and pull the page content.
Back to the point, I have found the backend of WordPress to be usable and friendly to a good mix of people. We often use it for a backend and build something completely custom for the frontend, and have had good results.
http://www.cushycms.com/
They let you add easy WYSIWYG capability to any website, regardless of the technology used.
You just add a tag once in your source file, and let your users go to CushyCMS.com to add text content.
I am by no means a CMS expert, but I believe SiteCore might suit your needs. It is a .NET system, built on top of ASP.NET, and from my limited experience with it, the UI for business users is very usable.
Take a look on Joomla. It includes WYSIWYG editor. It is much simpler than Drupal
As Frank points out, TinyMCE is a great option, in fact you use it here :D. Have a look at some examples: http://tinymce.moxiecode.com/examples/full.php
The good point is that TinyMCE is just javascript, so in theory you can add it to any CMS, or in fact to any HTML form.
Also, I think is the default input method for Joomla if you are interested.
I would recommend CKEditor (the successor to the FCKEditor), I haven't used FCKEditor in ASP .NET code, but have used it in PHP with a lot of success. I haven't gotten around to converting old code to CKEditor, but plan to in the future.
If this is something where you can load HTML files from your server that has FTP access...a quick and dirty solution I have used is CushyCMS.com, you supply ftp credentials and hook up the files and they are good to go. Non-technical customers of mine have liked the editor a lot. It allows you to specifically say what you want edited and what you don't.
In PHP the way I usually architect using CushyCMS is to have the main page do a require_once on the content page and the content page has the HTML block that I want them to be able to edit.
so the code looks like this:
<?php
//...other code
require_once("page_content.php");
//...other code
?>
where page_content.php looks something like this:
<div id="whatever" class="cushycms">
editable text here
</div>
Hope this helps.
I used to think that for user friendly editing, you need a WYSIWYG editor, such as the TinyMCE that has already mentioned. Not any more.
Editing content in such a rich text editor is not very handy. Very often you end up messing up the content, and either does a technically savvy person have to come to help, or you have to switch to CODE view (= HTML) to clean up the mess.
Now I'd be far more inclined to use something Markdown, like this site (and Reddit) uses. For most purposes, you don't need rich text, and it is just as handy a WYSIWYG tool. If you need a few rich text touches, like making some text bold or italic, this works quite easily too. Lists, either numbered or bulletted, are a snap. And making links... Those WYSIWYG tools always seem to be able to mess it up in ways you can't even imagine.
Plus, this way, the resulting HTML is always clean and minimal, and it's extremely hard for the user to mess up.
What about Expression Web? It is made to edit ASP.NET web pages, and can integrate with TFS
A friend of mine wants to have an application where people can upload documents in Word (or text) format, and then allow people to make edits to those documents within a browser.
Is there any mechanism that would support adding text "bubbles" for adding comments? Either floating, or off to the side.
Being able to save back to Word format is a must too. Or at least, some format supported by Word, that would still be editable. Saving it as an image is not acceptable.
I was thinking about opening the Word Document in an FCK Editor window, but FCK only seems to have "normal" inline text editing capabilities (although it is great).
Is this feasible?
Yes it is feasible. Google has done that (and it does have comments). So has Adobe. I'm sure there is more.
Xopus provides a programmable platform that allows you to define editable XML within a WYSIWYG environment. You could use it to define what you want to edit (XML), against which rules you want to edit it (an XSD) and how you want it to look while you edit it (XSL). Then you tie that all together with the Javascript API.
In other words, you could pretty easily define a document that contains multiple paragraphs with optional comments and then have them displayed as bubbles exactly the way you want them; when saved, a script on the server could be executed that converts the XML to a Word document.
Take a look at the demos.
If they are Word 2007 documents, you can use Silverlight. Here's an example application that uses Silverlight to open a Word 2007 document and display it in the browser.
Since StackOverflow is a programmer site, I'll assume you're a programmer. You can use Silverlight to add the bubbles and annotations to a Word 2007 document, but you'll need to know VB.NET or C#.
Take a look at docx2web.appspot.com which is (currently) a very bare bones editor with the distinguishing feature that the browser is directly manipulating (more or less) the "flat OPC" version of the docx.
This means that there is no lossy conversion on either the way in or the way out. So for example, when you save after editing, anything which was in the original docx is round tripped back to Word.
As far as support for older .doc is concerned, POI can be used to convert them to .docx (although your mileage may vary).
Why are you trying to compete with google docs?
I know that TinyMCE provides some rich controls for in browser editing. Last time i looked at it, it had 100% of the stuff i would normally use in word, and then some. On the other hand, i probably has 1% of the features that MS word provides. It would be VERY difficult to implement it all.
As far as saving to MS word compatible format. i am sure its possible. it would probably be easier to save to a non-doc format.
As far as popups etc, those can be easy built using jquery UI or any other javascript framework.
Bottom line: yes, its possible, but why?!
It is possible. For example eyeOS has a text processing application able to open and process Microsoft Office and OpenOffice.org text documents.