Features / Usability

Posted by erik.green 09 Sep 2004 22:02 GMT-0000 posts: 7

I second the request... right now I'm using an ordinary wiki page for this, with some action items hand copied to trackers. Doesn't work well.

I'd really like to see action items in a hypothetical meeting notes plugin added to a tracker that will repeatedly remind the owners that they have something to do.

As a side note, the new features in 1.9 look nice, but I don' t need most of them. They're targeted at "internet hobbyist" type sites more than anything. The ability to display image galleries (and the last images added), a jukebox, and quizzes and polls are probably very nice for small workgroups or for online groups working on things like writing wikis =) But they're all things I turn off automatically in an office environment.

Some stuff I'd really find useful should it ever find its was into a wiki:

• Better support for access to outside data sources (ability to view/edit database tables, interfaces to other applications like peoplesoft, microsoft AD/LDAP)

• Support for an external WYSIWIG editor - most of the people I have writing docs complain about the tiny TEXTAREA editor included with the wiki. I would love to give them something like Abiword to edit with.

• Import scripts for other wiki types, so I can import content from all the other wikis out in the world

• Much more inter-wiki communication. I want the ability to send items between trackers in a known, pre-defined format between wikis using something like the "external wiki" link syntax. A general way of sending objects (file, image, page, whatever) between wikis would be a really good thing, as would the ability for one instance of tikiwiki to define a "link" to an external tikiwiki page which is updated/cached regularly. So, I could have a single page with, for example, announcements on one wiki that all the other wikis display.

• Namespace support... right now I'm using multi-tiki for supporting multiple departments, and it's a lot of work. Best for me would be the ability to define multiple namespaces with separate permissions and also sub-namespaces that inherit permissions from their parent. IE, Engineering namespace with child electrical with its own document tree starting in Engineering.electrical

• On the subject of names, maybe a way to enforce page naming conventions would be good? We've adopted the use of a page path as a prefix to the name to avoid name collisions... if our users do things right, we end up with a top level page named TOC, with sub pages off of it, like TOC.Linux, TOC.Solaris, and they have child pages named likewise: TOC.Solaris.SVM, TOC.Solaris.Hardware...

• An XMLRPC api for wiki use... there are a lot of programs out there now that support interfaces using XMLRPC. I can work with PHP to do this, but some easy way to do it from within wiki pages would be great.

• Finish the Workflow engine - add more flexibility and make it easier to use. This feature is an incredibly powerful one for corporate use - the ability to automate business processes is a killer application. The problem right now is the large effort required to get a flow working. Maybe including some skeleton programs automatically to the various steps would be good, with modules/subroutines for accessing wiki features like DSNs, editing trackers, editing pages, etc? IE, you create workflow steps, and you can insert into each step a template for code. At the end of the flow creation you could click a button to check syntax of your code, make sure it does something sane, etc. A php code generator?

• More finished/flexible features scaled for enterprise use throughout the wiki - for an example look at the PDF generation feature. You can select wiki pages to include in the PDF one at a time. This sucks for any wiki larger than a certain size. I find limitations like this all over tikiwiki.... features that work fantastically for a small wiki, but are broken in anything large enough to be corporate useable. As a rule of thumb, if a feature wouldn't work with a tiki DB the size of the wikipedia, it's not useable in corporations.

• Get away from the use of an "admin" account for super-user. For many modern corporations, regulatory agencies and the government require per-user tracking for administrative functions, especially with regards to security. Have an admin account for setup of the wiki, but have its only function be to grant super-user privs to other accounts, who can then admin the wiki. That way when an action is taken using admin privs there's a record of it.

• Add better controls for handling user lists and privileges. The current method of searching through the user database and adding privs one at a time works for small sites, but sucks for sites like mine with a potential 3000 users.

• Freeze the database format and/or add a script API. I realize I can write scripts that access the tikiwiki back end database in perl or P HP, but I don't want to write them and then have to re-write them every time a new wiki version comes out. Is it really necessary to translate the database to a new format with every single release? It's not a huge deal to do this for a single wiki, but I need to do it for seven of them quickly enough so the users don't complain about the wiki being down...

• Add in a feature like the "avatar" but for corporate users make it a vCard-format with contact information. Most of my users disable avatars because they're unprofessional looking.

whew - That's a lot of venting. Keep in mind that I love and use Tiki a lot... it's the best out there, and I just want to see it get better.

Keep up the good work wiki-folk,
Erik