CMS Criteria
Chris Ilias
sumo, and here's what I've got so far:
- multi-lingual
- image hosting for members
- spam prevention/tracking (https ?)
- easy to upgrade the CMS (how secure is it?)
- easy for maintainers to figure out
- universal sign-in (KB/forums)
- real-time support option
- sandbox (For KB articles, and anything else we can think of)
- article feedback
- member feedback (rating system)
- video hosting
- kb analytics (popular pages)
- universal search (one search for KB and forums)
- tags?
- WYSIWYG editing
- integration between KB, forums, search, IRC, etc.
Jason Barnabe (np)
keep track of which users still need help and what content should be
documented?
Chris Ilias
> How about the ability to mark support requests with statuses so we can
> keep track of which users still need help and what content should be
> documented?
Good call. I've seen that on wordpress forums.
By the way, it's common practise to quote the text you are replying to. :-)
Chris Ilias
> I was trying to collect a list of criteria for choosing the CMS for
> sumo, and here's what I've got so far:
>
> - spam prevention/tracking (https ?)
> - easy to upgrade the CMS (how secure is it?)
It occurs to me, that with these items, it might be wise to get the
eventual server administrator in on the selection process. Does anyone
have a good idea of who that will be?
Chris Hofmann
We will be able to leverage existing server support from the Mozilla Corp. IT team to some degree. Right now devmo uses MediaWiki for knowledge base like tasks, and Spreadfirefox and Labs has been/will be using Drupal for collaboration/forums.
>From a cost and maintenence perspective using these two pieces at the start of the support site have some advantages, but that shouldn't be the only evaluation criteria.
>From the CMS requirements that Chris proposed and the others that have been documented in the recent discussions how would those two matach up for meeting the requirements. Certainly some existing plugins and extensions would have to be leveraged, and some may have to be built to meet the full set of requirements. Does anyone have ideas on how a MediaWiki and Drupal solution might fall short? Certainly the whole area of real-time chat support wouldn't be addressed by these two so building in that part would require looking at more alturatives.
Chris Hofmann
_______________________________________________ support-planning mailing list support-...@lists.mozilla.org https://lists.mozilla.org/listinfo/support-planning
Majken Connor
-Majken "Lucy" Connor
Jason Barnabe (np)
> I was talking to someone at Seneca's reception that does wiki management.
> He mentioned that Tikiwiki is one of the wikis he works with and that it has
> the ability to have a "sandbox" as it were, letting articles be worked on
> and then approved before going user facing.
I believe I read a story a while back about the German Wikipedia
trying out such a system. I don't know if it's something built into
MediaWiki itself or a plug-in.
Chris Ilias
This may not be needed, if bug 367596 [Create a support info
page/lister] is implemented; but I'd also like the forums to provide
some UA info. If not display the posters UA, include fields for browser
version, OS, add-ons, and URI (if applicable).
Marc Laporte
> On 6/6/07 4:23 AM, _Chris Ilias_ spoke thusly:
>> I was trying to collect a list of criteria for choosing the CMS for
>> sumo, and here's what I've got so far:
>>
Hi!
This is my last post for today :-)
>> - multi-lingual
yes, si, oui :-)
Please see my previous post with all the details. You can see in action
here:
http://docs.limesurvey.org/tiki-index.php?page=English+Instructions+for+LimeSurvey
>> - image hosting for members
Not sure what you want this for but Tiki offers a standard image gallery
feature :-)
http://steelgryphon.com/tikiwiki/tiki-browse_gallery.php?galleryId=1
Please note, site is ugly right now, I know. But it's easy to make it
look good once the CSS/design is decided upon. :-)
>> - spam prevention/tracking (https ?)
When users create an account, they need to click to confirm. This keeps
most spammers away. This will work until system is changed to use LDAP
(in which case LDAP db needs to validate these users)
Tiki supports several external authentication systems, including LDAP.
If anonymous editing of wiki pages or adding comments is permitted,
there is a CAPTCHA protection. (annoying typing in of numbers)
>> - easy to upgrade the CMS (how secure is it?)
TikiWiki is very easy to upgrade. Just unzip the new files over the old
files and run the .sql upgrade script (if it's a major upgrade)
Tiki is an all-in-one package like SeaMonkey. There is no need to
upgrade the core & the module-features separately like other CMSs. No
risk of having a module-feature which is not yet released for the latest
version of the core.
Also, Tiki is well designed where custom language files and custom theme
(look & feel) files are kept in their own directory so no need to
re-merge at each upgrade.
For bugfixes and feature enhancements: this is where Mozilla is
encouraged to participate to TikiWiki development by committing fixes
directly via CVS access. Bugfixes in BRANCH-1-9 New features to 1.10
(HEAD).
JT wrote:
> What makes this difficult: we are a unique case. We have a group of awesome volunteers who provide support to our users for a free product that 100 million people use in 40+ languages. We need an incredibly leveraged system that supports a broad range of users (technical and novices). That means no call center, no big bank, no multimillion dollar custom solution, no large bank of customer service reps where you can monitor efficiency and staff appropriately to meet demands by month, day and hour.
Yes, volume is outstanding. However, in terms of feature-set, so far, I
am not aware of anything that support.mozilla.org would want/need that
should not be part of main Tiki distribution. If you reduce the numbers
(volume), the sentence above can apply to many many open source projects.
>> - easy for maintainers to figure out
It's relatively easy for editors but admins need support to get started
because of the sheer number of features. I have been a project admin for
Tiki for over 4 years and have implemented over 70 Tikis. I am here to
help and I am certain that many other Tiki community members will be
willing to help, since most are Mozilla users.
>> - universal sign-in (KB/forums)
yes, yes, yes.
wiki/forum/bug tracker/blog/etc etc all in single sign on (SSO),
consistent look & feel and site-wide search engine.
>> - real-time support option
Tiki has a basic web group chat but it's no good.
There is a live support system (one on one chat customer/vendor type). I
have never used it in production. I have the impression that it may not
scale very well. (It would be fun to try though!)
A dedicated Chat system like IRC, Jabber or Skype would seem more
appropriate. Tiki has more or less some Glueware to these systems...
>> - sandbox (For KB articles, and anything else we can think of)
Done:
http://steelgryphon.com/tikiwiki/tiki-view_blog_post.php?blogId=1&postId=1
>> - article feedback
I turned on comments for articles & wiki pages.
>> - member feedback (rating system)
There are several possibilities here
http://doc.tikiwiki.org/E-Democracy+system
We use it for wiki pages (was this page helpful?) and for bug reports
(do you also have this bug?).
>> - video hosting
There is a file gallery, which supports any type of file:
http://steelgryphon.com/tikiwiki/tiki-list_file_gallery.php?galleryId=1
You can include any Flash, including YouTube video:
http://steelgryphon.com/tikiwiki/tiki-index.php?page=Flash
>> - kb analytics (popular pages)
yes.
http://steelgryphon.com/tikiwiki/tiki-cms_rankings.php
Tiki 1.9 offers basic stats.
http://steelgryphon.com/tikiwiki/tiki-stats.php
Tiki 1.10 goes even further:
http://doc.tikiwiki.org/Action+Log
And it's easy to plug into an external package or service like Google
Analytics
>> - universal search (one search for KB and forums)
yes, and still an option to filter by just the wiki or just the forums, etc
>> - tags?
Tiki offers a category system. Admins decide of a hierarchical tree of
categories. Items (wiki pages, articles, tracker items, etc) can be
assigned to one or several categories. Very useful to add a contextual
navigation menu (aka "Also in the same category")
Free tagging (where end users can add any tags) is coming to Tiki 1.10
http://tikiwiki.org/FuturePartner
I prefer categories to tags because tags tend to generate some useless
data (synonyms, singular/plural), which makes it difficult to make
something out of it. For example, user A will tag as "Blog" and user B
will tag as "Blogs"
With categories, site admins can control the ontology.
>> - WYSIWYG editing
Tiki 1.9 (stable) offers wiki syntax with quicktags to make it
quick/fast/easy to add the syntax (no need to learn). 1.10 (in dev) will
offer WYSIWYG while maintaining the wiki syntax (that's the tricky part)
I know some people are annoyed at the fact that there are many wiki
syntaxes out there. A few years ago, a Tiki community member tried to
get an RFC adopted for a wiki syntax.
http://tikiwiki.org/RFCWiki
There wasn't sufficient interested at that time.
There is an ongoing effort here:
http://wikicreole.org/
This syntax is actually pretty close to Tiki's and integrates some of
the ideas of the RFC.
I dream of a common wiki syntax but not just for wikis. It should be for
any text editing. Webmails, cell phones, lynx, etc
>> - integration between KB, forums, search, IRC, etc.
The only part which is not seamlessly integrated in Tiki is IRC. The
TikiWiki community uses IRC as well so there is interest for
improving this aspect. For example, having IRC logs which take into
account Wiki Syntax.
>
> This may not be needed, if bug 367596 [Create a support info
> page/lister] is implemented; but I'd also like the forums to provide
> some UA info. If not display the posters UA, include fields for browser
> version, OS, add-ons, and URI (if applicable).
Here it is:
http://steelgryphon.com/tikiwiki/tiki-view_tracker.php?trackerId=1
All fields are configurable. Trackers are multilingual. Multi-choice is
also supported (even if I didn't add in the example)
And there are still plenty of features which you may (will!) want/need
in the future. For example:
Polls/Quizzes/Surveys
Calendar of events (to plan IRC chats for example)
FAQs
Blogs (http://steelgryphon.com/tikiwiki/tiki-view_blog.php?blogId=1)
RSS feeds (wiki pages, blogs, articles, forums, etc)
Watch items (to receive an email when item is edited or posted)
Banner ad system
Score system (to motivate participation)
a Workflow Engine
etc
Rated list of features:
http://doc.tikiwiki.org/features
It will be my please to answer any questions.
Best regards,
M ;-)
Chris Ilias
> Please note, site is ugly right now, I know. But it's easy to make it
> look good once the CSS/design is decided upon. :-)
Marc, thanks for taking the time to read this newsgroup, and address
these issues. The UI is currently my biggest problem with tikiwiki [1].
There's a homepage mock up at <http://wiki.mozilla.org/Support:PRD>.
<https://addons.mozilla.org/> is a good idea of what we want, as well.
[1]<http://ilias.ca/blog/2007/06/in-the-end-its-about-the-ui/>
Marc Laporte
My pleasure.
Tiki is very flexible for design. It has a complete template layer which
makes it not only easy to customize the look & feel but also keeps
future upgrades easy. Wiki syntax is used in pages but when the layout
of a specific page is too complex for wiki syntax, we can use html.
Just give me html/css and I can make tiki templates and teach whomever
how to maintain them. It's easy for anyone with html/css experience. And
with the Smarty Template Engine (http://smarty.php.net/), it's easy to
add some basic programming logic, if needed.
I slapped up something real quick:
http://steelgryphon.com/tikiwiki/tiki-index.php?page=HomePage
And I put a copy here too:
http://themes.tikiwiki.org/tiki-index.php?page=MozillaSupportTest
Please note that not everything works yet. (Ex.: you can't change the
menu items via the menu builder). It's just a proof of concept that
there is no limitation on the customization of the UI/look & feel
We have a site dedicated to themes:
http://themes.tikiwiki.org/
Best regards,
M ;-)
JT Batson
Axel Hecht
friendly URLs?
There was a second one, but it slipped my mind.
Axel
Marc Laporte
> There would be two questions on my mind, firstly, is there a way to have
> friendly URLs?
>
Hi Axel,
Yes, there is a way. It is not turned on by default because it is
dependent on Apache (standard Tiki needs to run on Apache and IIS). I do
not know how to do it with IIS.
> There was a second one, but it slipped my mind.
>
hehe
> Axel
>
Majken Connor
menus are the addons menus, not the tiki menus. Stand by for that to
get fixed (help!?).
-Majken
Marc Laporte
The look is better now.
http://steelgryphon.com/tikiwiki/
However, the current setup is not optimal for template work. I can do
template & CSS editing via the Tiki web interface but it takes me double
or triple the time compared to FTP.
Also, since I can't add files to your server, I am calling images & CSS
files from addons.mozilla.org, so if that site is unavailable, the demo
site is missing some files and is ugly.
Perhaps we could move this test demo site to somewhere where I could
have FTP access? Even better, somewhere with CVS so I and other
developers can commit bugfixes directly to the main Tiki code base. I
already saw one minor bug when working on this. There is nothing like
eating your own dogfood to improve software :-)
http://en.wikipedia.org/wiki/Eat_one's_own_dog_food
Done:
The search box is now integrated.
To be done better:
1- The language switching works on the bottom left but needs to be
fixed/moved to the bottom right.
2- The left hand menu is now editable via the web interface. Now need a
way to take into account second level and identify current page.
http://steelgryphon.com/tikiwiki/tiki-editpage.php?page=LeftMenu
Outer shell now has Firefox look & feel. Similar work needs to be done
for the inner page. Again, this will be a lot fasted if I have FTP
access :-)
Warning: All this was not done cleanly. I just slapped together some CSS
files and some templates to show what can be done. If Tiki is chosen, I
will collaborate with Mozilla UI & Theme people to make something clean :-)
Best regards,
M ;-)
Jason Barnabe (np)
I don't know if you're started this (if not, I can), but I think it
would be useful to write up a spreadsheet with the criteria as rows, the
prototypes we have as columns, and then see how each one rates:
-In prototype as we want it
-In prototype, but needs tweaking
-Not in prototype, but we believe adding it would be minimal work
(installing a plug-in, configuration, etc.)
-Not in prototype, adding it would be a fair bit of work (developing a
plug-in)
-Not possible
JT Batson
JT
JT Batson
Mozilla Corporation
650-903-0800 ext 280
j...@mozilla.com
----- Original Message -----
From: "Jason Barnabe (np)" <jason_...@fastmail.fm>
To: support-...@lists.mozilla.org
Sent: Wednesday, June 27, 2007 8:24:19 PM (GMT-0800) America/Los_Angeles
Subject: Re: CMS Criteria