- keycontent.org & ricks99
- Mike Pilling
- Jason Diceman (coop tools /Web binder)
- Gary (Chibaguy) theme work
- support.mozilla.com team
- Marc Laporte
- Editing a wiki page (and other edit zones in Tiki) is not as intuitive as it could be.
- Tiki is not as sexy as many other systems
- Most users are accustomed to WikiPedia UI & Syntax
Check what everybody else is doing and enhance our own Tiki interface.
Please check out opensourcecms.com and report here on nice things you have seen.
Since this causes surprises/adjustments for end users, we should not do this often. All the changes below are somewhat inter-related so we should do it once, and well. And this should play nice with the WYSIWYG editor which was added to Tiki 2.0
I want to hear from end users, UI experts and people who do a lot of Tiki training (and see how new users use, and what they have trouble with, etc)
Work in progress: Tiki 3.0 edit wiki page example
moved to: Lost Edit Protection
Moved to Toolbar
- Direct link to plugins (why a second step?) idea from slj done in 3.0
- Add links to doc.tiki.org for all plugins done in 3.0
- Re-organize to have 5 tabs
- Quicktags explanation (visual)
- All wiki syntax for activated features
- All wiki syntax for de-activated features (we still want to see what we could turn on)
- All wiki plugins for activated features
- All wiki plugins for de-activated features (we still want to see what we could turn on)
Very nice: http://keycontent.org/tiki-editpage.php?page=Sample%20Collaboration (Very nice that it shows the relevant Quicktag)
Cooptools had some nice stuff as well
- Done in 1.10 (and backported to 1.9.8.x, too). Wiki help now shows:
- Wiki syntax
New users often suffer from "feature shock" when first using TikiWiki. There are so many features and things to click on that they often become overwhelmed and afraid to use any features (from fear of doing something wrong). It would be very helpful to new users to have some sort of a dynamic help system, whereby there is a prominent help button (like the "fullscreen" button, always visible) that the user can click, and then receive pop-up descriptions of various page objects as they "mouse-over" them. They would have to then click the help button again to escape the dynamic help mode and return to normal page functionality. This feature is similar to that found in some Windows applications where a user can click a question mark icon, which then changes the mouse cursor, and then click on various application objects to receive help on those objects. This is in essence a site feature in itself (may want to be turned off) and not trivial, but getting beginning users to get comfortable with using Tiki is not trivial either.
Tiki 1.10 has editable sections when using the split plugin but it's not enough.
The work has started! Please test latest 1.10 from SVN.
phase 2: wish1800
Can be seen here too:
Need fallback for non JS
If a category is picked, the checkbox "Categorize this object" should be done at the same time.
moved to Spellcheck
Gary has been using different layouts/icons
Should pick only 2-3 nice layouts to include with the base Tiki install. This is ongoing. See Gary
Wiki editing: Preview with diff, like Mediawiki
Page history could be better: See WikiPedia for ideas like a button to increment the diffed versions
Have a useful diff. MediaWiki is currently much better at understanding the changes than Tiki. It goes word by word, not letter by letter.
When viewing a diff, I should be able to see
preferred diff engine: admin setting, which could be optionnally overriden by user. If I override once, next time, it should use the same one (and not default always to html diff like in 2.0)
The diff procedure is not intuitive: when page is large, it's difficult to find action button
- These security features cause support requests. Maybe we could enhance UI to facilitate use of dynamic content so users can add html
- Allow for a template for new articles (containing a TOC, sample syntax, or whatever the admin wants). This already exists content template
- Don't mess with the browser's default looks and behaviour for buttons and text fields. Users are used to how these things look and act by default.
- Capitalize button labels!
- better labels & system messages