Need Some Advice for HelpSpot
If you're in the market for a powerful and user friendly Help Desk solution, please take a look at my company's flagship product HelpSpot.OK I'm opening this one up to the public. I'm having a hard time with this decision so I thought getting a few comments might be helpful.
First, I need everyone to put on their User hats. No technologists here, just users! Here we go:
Part of HelpSpot is a help desk portal and part of that portal is a knowledge base like system. It's actually a little different, but that's not important for now.
The problem is that the help desk is going to have the ability to create articles/pages in the KB and I'm not sure what the best approach is in terms of HTML support. The way I see it there are 3 options, all with significant downsides.
- Open text box that just accepts HTML or plain text. - The obvious big downside here is that you have to know HTML to be able to do any formatting. While help desk staff are more technical than your average user many still won't know HTML, but perhaps this is an OK v1 option.
- WYSIWYG field that does the formatting. - Here I see a few issues. First is that there aren't many good cross-platform options. The one I like best is tinyMCE. It's LGPL and also has some nice commercial components which could be useful. Still, WYSIWYG components are often buggy. I've also found that users tend to go crazy with them and what you get is wild inconsistency between pages.
- Enable Markdown support. - Markdown is a text based system for formatting text to HTML. So to make a word bold you do this: **this is bold**. Now that's pretty neat and fairly easy to learn, but is it too geeky? (all formatting details)
Thanks in advance for taking a few minutes to help me think this over. It's great to have a group of people to bounce ideas off of. Another wonderful side benefit of blogging!
If you have other suggestions I haven't considered please feel free to post those as well.
Discussion
Well opt.1 (plain HTML) should be out of the question. It has no advantages over opt.3 plus you have to make sure html tags used are safe (even though internal stuff would use this, it could still be a problem: imagine typing <b and forgetting to close the tag - I believe systems like markdown don't have such problems)
Opt.3 would be no problem for most users to learn, but you lose the WYSIWYG aspect. If these KB articles are long it will be hard. If they are short it will be OK.
Opt.2 will be OK, if you cut down most features of tinyMCE (or whatever else you use). Leave only B, U, I, links and maybe images. Generated HTML will again be awful but you can't have everything...
Personally I would go with opt.3 But also keep in mind that opt.2 may look cool in the features list. Maybe make it a system wide preference?
Finally take a look at textile (http://www.textism.com) for another opt.3 approach. 37signals use it for basecamp/backpack. Textile has a BSD style license...
Created by Dimitris Giannitsaros on 05.21.2005 1:05 pm
Ahem... I was trying to give an example of broken HTML tags and this affected Wordpress! PLease correct it if you can!
Created by Dimitris Giannitsaros on 05.21.2005 1:05 pm
Ian,
most of the users will like option 2, is hype and will give you better comments over your product. I agree with Dimitris about cut down tinyMCE.
You have to have in mind your objetive public, to try to understand there need. Most of the people that use Help Desk system need for a unique tool, because if they need to use two they don't use. And many don't have time to expend on, they want something symple.
Try HTMLArea, you can edit the document in WORD and cut/paste into HTMLArea, and remove WORD tags with a symple action. I Prefere HTMLArea over tinyMCE, in HTMLArea you have moe control over it, in development way.
Created by Roberto Cruz on 05.21.2005 1:05 pm
I've used HTMLArea and tinyMCE in conjunction with Mambo pretty easily. tinyMCE seems to load a little more quickly. I would agree with stripping it down to basic functionality.
Created by Joseph LeBlanc on 05.21.2005 1:05 pm
Hmm. Good points. I tend to agree that wysiwyg is an advantage in terms of marketing even if it may not in fact produce superior results. If I go with a wysiwyg I would have a use/don't use option but I don't think I'd want to have a use/ don't use/ use markdown/textile option. Seems to be too much and it would create even more code to manage for limited gain.
I guess right now I'm leaning towards a wysiwyg with limited functions as you mention. Though I'll surely get requests for whatever functions I do leave out. Perhaps I'll default to very limited functionality and have a setting which allows the more advanced components to be included on a per user basis.
HTMLarea seems to be going through a transitional phase. Check this out:
" Update, March 8 2005. Some time ago, InteractiveTools expressed the will to take over the project. We provided some fixes that we made and were not in the CVS version and a RC2 was released at htmlarea.com; however, soon thereafter InteractiveTools announced the project closed and forums discontinued. Bang!
Our position on this is that the editor will keep going; we are actually making quite some progress in its development, but only in house at this time. We are still planning to release version 3.0, quite possibly under a different name (so it might actually be a 1.0) but still free, at least for the core editor--some plugins might be released under a commercial license. We can't provide explicit deadlines, so please bear with us. "
http://www.dynarch.com/projects/htmlarea/
There are no files on the sourceforge page:
http://sourceforge.net/projects/itools-htmlarea
All this is another reason why wysiwyg systems scare me a bit.
Created by Ian on 05.21.2005 1:05 pm
Another note on the good/bad side of WYSIWYG solutions (e.g. tinyMCE):
Even if you hide most features, you can still paste from Word. People will notice this, use it and think it's a great feature. This seems good but:
a) copying and pasting from word produces *awful* and very bloated html. I just copying and pasted some text from Word to tinyMCE and to notepad. The notepad file was 10kb (text without formatting) and the tinyMCE's produced HTML was 35kb...
b) tinyMCE and most WYSIWYG editors stop working so great after you paste from Word... which is frustrating if someone tries to re-format text originally pasted from Word.
Created by Dimitris Giannitsaros on 05.21.2005 1:05 pm
Yeah, but it's hard to work around the paste from word issues. I'm not super worried about word, because during my research I found most help desk members who managed the knowledge base did it right in the tool and not in Word first though I'm sure they'll be exceptions.
I played with Textile a bit, wow very cool. I think it is superior to markdown though I'd need to do a little more research. Building a table was insanely easy and the other markup seemed a bit more logical than markdown.
http://textism.com/tools/textile/index.html
Created by Ian on 05.21.2005 1:05 pm
do it like blogger does it .... they give you both views . You type in WYSIWYG and at any time you have the option to switch to HTML mode and edit the HTMl , so this way you cater for every type of users.
just an idea 
Created by Muhammad Raza Saeed on 05.21.2005 1:05 pm
Personally I'm okay with the markdown stuff but I'm not sure how non techie users get on with it. Have you been able to do any trials? I'm not sure how difficult WYSIWYG editing is to implement but I would personnally worry that focussing on this would end up a worse business decision.
Warning: Brain dump ahead
Another idea: (Not sure of the practicality in web apps however)
Have a "palette" of different types which you can click and drag into the edit box (or just press the button and it inserts it at the caret position in the edit box). These types could be "Internet link", "Image link", "Bold" or similar.
Is it possible to use the "update part of the page" to keep a preview on?
Created by MattB on 05.21.2005 1:05 pm
It seems like writing documents is best suited to a word processor like Word. Doing serious editing in something akin to this comments box sucks, even if I can make text bold, etc. as the WYSIWYG controls allow. Have you considered writing an add-in to Word that would allow users to publish a document directly to the KB server? Or what about uploading a document? I guess the other question is how often does this task occur? If the user has to spend a lot of time doing this activity, I'd want to make it as easy as possible. I'd much rather write documents in my word processor where I have grammar checking, spell checking, formatting, etc. You add-in could easily export and publish it, and possibly massage the content (stripping WordML bloat out, etc.) along the way.
Just an option to consider.
Created by AnonymousCoward on 05.21.2005 1:05 pm
It's very hard and buggy to do drag and drop on the web so the palette idea is hard to implement. Also in systems I"ve seen like that it tends to then show the HTML code which I pretty much want to avoid because it's very robust and creates confusion in the text box. I might do something with previews, but I have to think about that a bit.
Writing is certainly best suited to word processors, the browser makers have done a pretty poor job of adding good and consistently accessible writing tools to their products.
Writing an add in is an option, but I can't have that be the primary means of creating articles because I don't want to create a dependency on having Word to use the product. Also I have some reservations about forcing the use of a desktop app for an otherwise entirely online application. However, most of the system is or will be open via web services so after the initial release I have some ideas for creating hooks into desktop apps which work with HelpSpot. Something like a knowledge base hook in Word is definitely possible.
The knowledge base isn't something people will be writing in every day. It's usually added to when new problems crop up and the solutions need to be documented or when a company releases something new and they need to create some documentation for it so it's not like this is a part of the system where the users are in it 8 hours a day.
Of course writing in Word and copying and pasting into the text area is possible. As mentioned above some of the WYSIWYG apps do some filtering, but it isn't very effective because Word puts alot of junk into the code. I like the idea of uploading a Word doc and having it transformed into an article. That will be something I'm going to look at as a v1.5->v2 feature. It's a little bit trickier to pull off on Linux but it can be done.
Created by Ian on 05.21.2005 1:05 pm
Ian, for my experience in HelpDesk, First implementation of SIEBEL for more than 10.000 users, First Implementation of Siebel in Spain, Epeience with DirectTV help desk, and many others. The user of any help desk application have to be able to do all the things within the application and switch at less as possible.
I recomend to you to include any WYSIWYG application or solution, but integrated. Don't do your application depandand on 3rd parties, simple do not work.
The key in a Help Desk system is that the user have all the needed information available in every moment, just the needed not more or less.
My Best regards
Created by Roberto Cruz on 05.21.2005 1:05 pm
Well opt.1 (plain HTML) should be out of the question. It has no advantages over opt.3 plus you have to make sure html tags used are safe (even though internal stuff would use this, it could still be a problem: imagine typing <b and forgetting to close the tag - I believe systems like markdown don't have such problems)
Opt.3 would be no problem for most users to learn, but you lose the WYSIWYG aspect. If these KB articles are long it will be hard. If they are short it will be OK.
Opt.2 will be OK, if you cut down most features of tinyMCE (or whatever else you use). Leave only B, U, I, links and maybe images. Generated HTML will again be awful but you can't have everything...
Personally I would go with opt.3 But also keep in mind that opt.2 may look cool in the features list. Maybe make it a system wide preference?
Finally take a look at textile (http://www.textism.com) for another opt.3 approach. 37signals use it for basecamp/backpack. Textile has a BSD style license...
Created by Dimitris Giannitsaros on 05.21.2005 1:05 pm
Great point Roberto, keeping the users in the help desk application is extremely important. I think I probably will do the WYSIWYG. Most, including Tiny give the user the ability to edit the raw HTML or use the WYSIWYG so it is probably the best 2 out of 3 world 
That's some amazing experience you have! I'll be doing some more posts like this as we go along and really look forward to your feedback.
Created by Ian on 05.21.2005 1:05 pm
Ahem... I was trying to give an example of broken HTML tags and this affected Wordpress! PLease correct it if you can!
Created by Dimitris Giannitsaros on 05.21.2005 1:05 pm
Ian,
most of the users will like option 2, is hype and will give you better comments over your product. I agree with Dimitris about cut down tinyMCE.
You have to have in mind your objetive public, to try to understand there need. Most of the people that use Help Desk system need for a unique tool, because if they need to use two they don't use. And many don't have time to expend on, they want something symple.
Try HTMLArea, you can edit the document in WORD and cut/paste into HTMLArea, and remove WORD tags with a symple action. I Prefere HTMLArea over tinyMCE, in HTMLArea you have moe control over it, in development way.
Created by Roberto Cruz on 05.21.2005 1:05 pm
I've used HTMLArea and tinyMCE in conjunction with Mambo pretty easily. tinyMCE seems to load a little more quickly. I would agree with stripping it down to basic functionality.
Created by Joseph LeBlanc on 05.21.2005 1:05 pm
Hmm. Good points. I tend to agree that wysiwyg is an advantage in terms of marketing even if it may not in fact produce superior results. If I go with a wysiwyg I would have a use/don't use option but I don't think I'd want to have a use/ don't use/ use markdown/textile option. Seems to be too much and it would create even more code to manage for limited gain.
I guess right now I'm leaning towards a wysiwyg with limited functions as you mention. Though I'll surely get requests for whatever functions I do leave out. Perhaps I'll default to very limited functionality and have a setting which allows the more advanced components to be included on a per user basis.
HTMLarea seems to be going through a transitional phase. Check this out:
" Update, March 8 2005. Some time ago, InteractiveTools expressed the will to take over the project. We provided some fixes that we made and were not in the CVS version and a RC2 was released at htmlarea.com; however, soon thereafter InteractiveTools announced the project closed and forums discontinued. Bang!
Our position on this is that the editor will keep going; we are actually making quite some progress in its development, but only in house at this time. We are still planning to release version 3.0, quite possibly under a different name (so it might actually be a 1.0) but still free, at least for the core editor--some plugins might be released under a commercial license. We can't provide explicit deadlines, so please bear with us. "
http://www.dynarch.com/projects/htmlarea/
There are no files on the sourceforge page:
http://sourceforge.net/projects/itools-htmlarea
All this is another reason why wysiwyg systems scare me a bit.
Created by Ian on 05.21.2005 1:05 pm
Another note on the good/bad side of WYSIWYG solutions (e.g. tinyMCE):
Even if you hide most features, you can still paste from Word. People will notice this, use it and think it's a great feature. This seems good but:
a) copying and pasting from word produces *awful* and very bloated html. I just copying and pasted some text from Word to tinyMCE and to notepad. The notepad file was 10kb (text without formatting) and the tinyMCE's produced HTML was 35kb...
b) tinyMCE and most WYSIWYG editors stop working so great after you paste from Word... which is frustrating if someone tries to re-format text originally pasted from Word.
Created by Dimitris Giannitsaros on 05.21.2005 1:05 pm
Yeah, but it's hard to work around the paste from word issues. I'm not super worried about word, because during my research I found most help desk members who managed the knowledge base did it right in the tool and not in Word first though I'm sure they'll be exceptions.
I played with Textile a bit, wow very cool. I think it is superior to markdown though I'd need to do a little more research. Building a table was insanely easy and the other markup seemed a bit more logical than markdown.
http://textism.com/tools/textile/index.html
Created by Ian on 05.21.2005 1:05 pm
do it like blogger does it .... they give you both views . You type in WYSIWYG and at any time you have the option to switch to HTML mode and edit the HTMl , so this way you cater for every type of users.
just an idea
Created by Muhammad Raza Saeed on 05.21.2005 1:05 pm
Personally I'm okay with the markdown stuff but I'm not sure how non techie users get on with it. Have you been able to do any trials? I'm not sure how difficult WYSIWYG editing is to implement but I would personnally worry that focussing on this would end up a worse business decision.
Warning: Brain dump ahead
Another idea: (Not sure of the practicality in web apps however)
Have a "palette" of different types which you can click and drag into the edit box (or just press the button and it inserts it at the caret position in the edit box). These types could be "Internet link", "Image link", "Bold" or similar.
Is it possible to use the "update part of the page" to keep a preview on?
Created by MattB on 05.21.2005 1:05 pm
It seems like writing documents is best suited to a word processor like Word. Doing serious editing in something akin to this comments box sucks, even if I can make text bold, etc. as the WYSIWYG controls allow. Have you considered writing an add-in to Word that would allow users to publish a document directly to the KB server? Or what about uploading a document? I guess the other question is how often does this task occur? If the user has to spend a lot of time doing this activity, I'd want to make it as easy as possible. I'd much rather write documents in my word processor where I have grammar checking, spell checking, formatting, etc. You add-in could easily export and publish it, and possibly massage the content (stripping WordML bloat out, etc.) along the way.
Just an option to consider.
Created by AnonymousCoward on 05.21.2005 1:05 pm
It's very hard and buggy to do drag and drop on the web so the palette idea is hard to implement. Also in systems I"ve seen like that it tends to then show the HTML code which I pretty much want to avoid because it's very robust and creates confusion in the text box. I might do something with previews, but I have to think about that a bit.
Writing is certainly best suited to word processors, the browser makers have done a pretty poor job of adding good and consistently accessible writing tools to their products.
Writing an add in is an option, but I can't have that be the primary means of creating articles because I don't want to create a dependency on having Word to use the product. Also I have some reservations about forcing the use of a desktop app for an otherwise entirely online application. However, most of the system is or will be open via web services so after the initial release I have some ideas for creating hooks into desktop apps which work with HelpSpot. Something like a knowledge base hook in Word is definitely possible.
The knowledge base isn't something people will be writing in every day. It's usually added to when new problems crop up and the solutions need to be documented or when a company releases something new and they need to create some documentation for it so it's not like this is a part of the system where the users are in it 8 hours a day.
Of course writing in Word and copying and pasting into the text area is possible. As mentioned above some of the WYSIWYG apps do some filtering, but it isn't very effective because Word puts alot of junk into the code. I like the idea of uploading a Word doc and having it transformed into an article. That will be something I'm going to look at as a v1.5->v2 feature. It's a little bit trickier to pull off on Linux but it can be done.
Created by Ian on 05.21.2005 1:05 pm
Ian, for my experience in HelpDesk, First implementation of SIEBEL for more than 10.000 users, First Implementation of Siebel in Spain, Epeience with DirectTV help desk, and many others. The user of any help desk application have to be able to do all the things within the application and switch at less as possible.
I recomend to you to include any WYSIWYG application or solution, but integrated. Don't do your application depandand on 3rd parties, simple do not work.
The key in a Help Desk system is that the user have all the needed information available in every moment, just the needed not more or less.
My Best regards
Created by Roberto Cruz on 05.21.2005 1:05 pm
Great point Roberto, keeping the users in the help desk application is extremely important. I think I probably will do the WYSIWYG. Most, including Tiny give the user the ability to edit the raw HTML or use the WYSIWYG so it is probably the best 2 out of 3 world
That's some amazing experience you have! I'll be doing some more posts like this as we go along and really look forward to your feedback.
-----
Created by Ian on 05.21.2005 1:05 pm