SharePoint: Create an HTML Generator for Quick Wiki Creation
Author: Kerri Abraham
January 8, 2008 2:00 PM: The version 1.0 edit date on my first ever wiki. I read the introductory information on the page and just had at it. To be honest I made no connection whatsoever with a Sharepoint wiki and Wikipedia, nor had I ever used or heard of a wiki before. Ah, ignorance is bliss! Also, I happen to be the type of person who views something like a recipe simply as a suggestion, so when I read the description of web parts or site templates, I figure that is just a generalization of how it might be used. I never associate rules with it, (like wikis are meant only for collaboration between many members – controversial as that might be.)
In my eyes, the wiki was perfect for building a procedure manual. Using the home page as an index, I started creating wiki pages and entries that hyperlinked to other lists, tying the whole works into a one-stop shop for everything work related. I was able to name the information multiple ways so that no matter how you thought of it, you could still find it under that name.
Staff loved it. It was about a year later that I started to read about all the complaints and supposed inadequacies of the Sharepoint wiki. I thought the critics were crazy; this was the perfect way to pull lists together.
For the most part I had been using Word to create nicer looking entries than what was possible using the wiki tool bar. I created the text and graphs in Word and copied them into the wiki. It was efficient with good results.
Then my role changed and I found myself creating wiki content for positions I knew nothing about. One of these new requirements in particular proved to be more of a challenge because it was for an entry level position and the very nature of the job made it a jumping off point to other opportunities, creating a high turnover rate and a real need for solid training material. That meant extensive screen shots, something I had mostly avoided because of the added time it took to format in the wiki text editor. Previously I had used links to other Office formats like PowerPoint or Word documents if the picture needs were extensive, it just saved me the most time in trying to get the build put together. The problem was the waiting on load time, wikis page are instant; I needed a better method.
Then Jim Parker posted How to Solve Your SharePoint Rich Text Editor Blues outlining how to use Windows Live Writer (WLW) and I knew I was close to an answer. I couldn’t download the LiveWriter on my work computer, it was blocked by security policy, but I had often seen the new option in Word 07 of creating a ‘New blog post.’
I hadn’t made the connection until reading Jim’s article, because I had only been thinking in terms of wiki content, but now I was seeing it! Repurpose the Blog to be a HTML code generator, this was brilliant! As Jim outlined, the first step is to create a Sharepoint Blog. Then there are a couple of options, use the Launch blog program to post right from the blog site, or create a ‘New blog post’ in Word from your desktop. If you don’t have Word 07, read Jim’s article and go that route. When you have the blog entry created, just hit Publish. It takes care of finding the newly created blog for you.
It is almost like magic the way all the images upload in seconds to the Blog’s ‘Photos’ Picture Library. Publishing to blog converts the Word document into HTML. Now if you edit the blog entry it is easy to paste (Ctrl-A to select all + Ctrl-C to copy +Ctrl V to paste) the entire HTML code into any other Text Entry-Webpage Dialog Source editor box in Sharepoint, like those used for Wiki pages or Content Editor Web Parts. Now it is super easy to convert new or existing document with pictures to a wiki format.
A few things I can share about this process:
- The blog post itself can be deleted once the code is copied; the value lies strictly in the picture library, since it is now the picture source generator. Choose to keep or delete the Word .docx according to your own preference.
- When the blog .docx is saved, either to a Sharepoint library or personal file, if the pictures are edited at a later date and then republished, it will upload the new pictures using the same name as the original so there is no need to copy the edited picture to the wiki, since the picture is generated from the Photos Library. Don’t delete or change the order of the pictures in the original document if you do edit and republish. The pictures are named according to date and order in the original blog post, if you’ve pasted the HTML somewhere else, you’ll have a real mess if the pictures get out of order. Make sure you clearly understand this concept before extensively using this process.
- The PNG picture files tend to be relatively small upon upload. They range in size anywhere from 2 KB up to just over 100 KB for the largest. Comparing that to my old method of uploading mostly GIF files, I find the same wide range in file size, but some of the GIF files top out well over 400 (or even 1000) KB+. I fully admit I am at fault for not optimizing those large pictures upon upload, but can you be sure all your end users will remember to do that extra step too? With blog publishing, it no longer is an issue.
- I have created this blog directly below the top level parent site. Since I am repurposing this Blog for code generation and using the blog’s Photos Picture Library as the source for nearly all my site pictures, I create special permissions for the blog, locking it from visitors, but I open the library up to view by all. To avoid confusing people I keep them from seeing it. I also adjust the page and views of the posts to optimize the page width and make it easier to get to the HTML source by adding the Edit icon to the view.
- Tables can take a bit of testing to get to publish correctly. Watch that the original table is set with Table Properties to the dimensions you desire. If it doesn’t publish correctly to the blog on the first try, reset the properties and publish it again, and again, and again until you find the setting that makes it work. Once you have a table that works, save it for reuse. Test out the color pallets and table options available in Word to inject a little personality to the information.
- Take advantage of the blog’s categories and naming conventions as they carry over to the picture titles. Note that the creation date on the wiki entry will correspond with the published blog date, and if the blog title is the same as the wiki content, all the pictures end up instantly organized according to date and subject!
- Hyperlinks can be hit or miss. In general, if a hyperlink is added to a picture (or text) within the blog post it will publish as such as long as the entire HTML is copied and pasted into the wiki. This is a huge advantage since the wiki’s editor doesn’t allow for image hyperlinks. In my experience however, that is not always a perfect process. If the link is lost, it is possible to use a Content Editor Web Part to create the hyperlink and then paste it into the wiki.
- The [[brackets]] can be included in the blog entry, and will work as hyperlinks to other wiki pages once pasted into the wiki editor.
- Test out Print Preview, wiki pages print very nicely and include the dates last modified, date printed, and a breadcrumb so staff are never wondering how old a document is or where it came from.
- Not all Word elements will publish into the wiki the same. Avoid Text boxes, use one column/one row tables instead. Testing is the best way to learn what elements transfer well.
- Some fonts shrink or balloon when published. Using the default Sharepoint font of Verdana gives the most consistent results with fonts staying true to size.
The example I used here is a riveting document detailing how to change the high speed scanner rollers. Only one staff member held this knowledge. Capturing this kind of process may seem trivial, but if the rollers need to be changed over the weekend, explaining this over the phone would be nearly impossible, not to mention the productivity that would be lost should it cause extended downtime in the medical record scanning process. With this knowledge capture we have eliminated a productivity risk and ensured that this knowledge can be passed on.
Is this a best practice? You can be the judge. All my pictures are now consistently grouped together with the same name and date as the wiki content they were created for, and my effort toward that end has been cut by at least 80%. As Jim Parker so clearly points out in his article, this is great for the new end-user in both ease and consistency of process. In terms of end-user adoption, this one is at the top of my list for coolest Sharepoint tricks ever! My most sincere thanks to Jim for sharing the knowledge!
Author: Kerri Abraham
Kerri Abraham is the Revenue Cycle Sharepoint Coordinator at Mercy Medical Center in Cedar Rapids, Iowa. Converting Sharepoint enthusiasts one information worker at a time, she is leading the charge to win end-user adoption through the creation of extensive training materials and knowledge capture. Introduced to Sharepoint in 2006, but holding a dedicated Sharepoint support role since 2008, and brand new to tools like Sharepoint Designer, she focuses entirely on out-of-the-box solutions.
on
Thank you for sharing this this is great. Is it possible to know more about how you created your wiki sites.
Thanks Rebecca, this is the foundation of how I build all my wiki content, and I used to build lots of it! I like wiki sites versus libraries for their navigation ease. All information pertaining to the job at hand I store on the wiki site. Using the home page as an index, you can link all your information into one place with wiki pages and hyperlinks (hint: create the hyperlink in Word and paste it into the Wiki to keep it from being underlined and add a more consistent look to the page.) I also ‘bucket’ my information across the top. Start by creating a table, color the cells in Word to make them look more like buttons, and create [[links]] to pages that pertain to a specific topic. You can then use the same link listed from A-Z as you do under that bucketed topic page, always linking back to the original information, never recreating it. I will do follow up articles outlining this process in the future though, I’ve been working with Larry Pfaff on a great bookmark/anchor solution and I’m anxious to share it!
Kerri, I am one of those who complain about the SharePoint wiki.
I would argue that those techniques – although very useful – are not adapted to co-authoring, which is often what a wiki is about (think knowledge base for example).
I think you have to consider your audience and the participants in the process. I have wikis where the information workers who participate in its use are all professionals, with years of experience and knowledge to share. Those workers have the ability to create their own wiki content for a knowledge base. And generally, they don’t need pictures, it is mostly notes. I have a number of other departments that are entry-level positions, i.e. right off the street These staff are working to build a fund of knowledge and move on from there. They are not at a position yet to contribute regularly, and giving them access to do so jeopardizes the validity of what we have built as a resource for the rest. Our needs are to get staff information they can depend on, to do a job that could potentially mean life or death….this is healthcare after all. Honestly, there isn’t anyone complaining or even asking “hey, can I help with that?!” It’s hard enough to find just one person willing to jump in and take over the responsibilities.
A wiki ultimately is a library with really cool HTML features. Supervisors love the ease of editing. Staff love the organization of it and how quick it is to respond. I love that I can link one resource to another in an instant. An additional benefit over Word is that not all of our machines have Word installed, so they can’t always open Word docs, so often times people have been publishing Word to PDF – talk about a headache to edit later!
Some may think it is limiting to not allow all to contribute. I think it is limiting to think that they must.
Well, the ease of editing, that’s what I question. Isn’t the point of this post precisely to provide workarounds, because working directly in the wiki is not that easy?
Christophe, Text is a breeze to change in the wiki.. Click Edit, start editing.
Need a new picture? Create a new blog entry, paste in your picture (which is a breeze to size properly within Word) and publish it to the blog, copy the picture to the wiki. You don’t even need to mess with URLs at all with this method. Copy the picture with the boxes around the edge, paste it into the wiki or CEWP just like that.
I agree with Christophe. The wiki is not user friendly and there are much easier solutions available to achieve the same results. Does creating this workaround really solve the issue?
You appear now to be creating your content in an external editor. You’re using the wiki as a final resting place for your content. If this is the case, why force the wiki to work? I know with a big enough hammer we can make a square peg fit the round hole, but in the end do we really want to?
jaxkookie, What easier solutions provide the same results? Hyperlinks within Word docs? Hardly as fast and easy as wiki links. Power Point Presentations? Not reasonable for someone on the phone with a customer, download time kills that as a viable quick resource. List items? Still the same issue with pictures.
I say there are limitation with every solution, but the wiki is fast. No download waiting, that is the seller for me and my staff. They race the clock to do their jobs. Fast isn’t just perferred, it is required, and with this method we can create the documentation fast too!
Straight HTML pages, not converted from word. The are many wysiwygs available to edit or create web page content. I have been developing On-line Reference guides (OLR), which are an on-line help or reference site specifically designed for phone reps. These guides contains upwards of 1000 pages. Never has there been a load time issue. Another valuable point to keep in mind is the organization of data. All our content is chunked or mapped.
Mapping is a communication tool that provides end users with a simplistic way to getting the message across that meets their needs. This also provides users with ways of scanning, skipping and retrieving the information they need quickly and easily. This is not a format; it is a way of thinking.
When chunking data it should not exceed any more then 7 +/- 2. The chunking limit is a guideline, based on George A. Miller’s 1956 research, for creating information that people have to memorize. These web pages (or even wiki’s, Yuck!) do not have to be “memorized,” but maintaining these chunking limits aids in a reader’s ability to process information. Maintaining strict guidelines and closely following this helps us create smaller pages that will load faster, yet invisible to the end user.
Our content or pages for our legacy OLRs were all HTML with some scripting. Eventually we migrated to InfoPath. InfoPath is a great solution for sharing and single sourcing content. Once the template was, users enter data into the form, save it to SP. The files are saved as XML and linked to an XSL file for viewing in a browser. There are other more efficient means of achieving this, but then there is cost.
The navigation for this content uses a frameset left nav like SP Quick Launch, quite similar to you top navigation. Docs or forms are stored in a forms library. They are mapped to a taxonomy that is assigned during creation for reporting and/or reuse. Reuse is the key in saving time during future development.
I understand that different strokes for different folks. I am always willing to try new things, but I am still not sold that the SP wiki is the way to go when chunking content. I look forward to seeing more of your work.
jaxkookie, that sounds very interesting… the parts I could understand … I openly admit I’m an end-user from an end-user’s perspective. From my perspective, that seems complicated. Now my end user can do [[this]] and create a new page of content. My method is an easy sell for the beginner, in less than an hour of training they can be off creating wiki content, text, pictures, and they know how to organize it in a manner that makes sense to their team. This fosters a great deal of pride in ownership (and allows for some creativitiy too) – which in turns leads to more interest in Sharepoint — because I make it easy enough that anyone can do it!
jaxkookie, I too would be interested in reading more about your method. And I agree with Kerri, this is certainly not for any end user.
Ease of editing and ease of access are two different debates. What makes the content easy to access is the fact that it is in HTML format, not the fact that it is hosted in a SharePoint wiki.
And one more comment about wiki. “easy” and “fast” are relative. To judge if the SharePoint wiki is good, you need to compare it with other wiki solutions.
I don’t mean to start yet another discussion, but the pride in ownership is an essential piece of this SharePoint puzzle. Oh well, you started it Kerri!
Christophe, I’m curious why we must compare the Sharepoint wiki to other wikis? It is a Platonic comparison my mind, if we only have Sharepoint, we only know Sharepoint.
Kerri, let me quote you: “I started to read about all the complaints and supposed inadequacies of the Sharepoint wiki. I thought the critics were crazy”.
With a broader view than just the SharePoint wiki, you would have a more informed opinion, and maybe more respect for these critics. Poor guys!
Christophe, Again, I quote the same: “Ignorance is bliss.”
As for the critics?! If only I had know the critics as I know them now, I would never have judged so harshly – but I still hold out that I might win you over in the end!
Kerri you have a winning personality, but I still struggle with the wiki. I like the feed back on the my last response and I think I write something up in more details.
Thanks agani
Kerri,
Thanks for the post! I also use the wiki feature in a somewhat unconventional way and this definitely gives me additional options.
I LOVE it when people stick to their guns. Keep at it, Kerri. Keep at it. — Mark
Of course we love it! That’s why we consultants get paid to manage change ;-)