Features in progress or already implemented

  • TikiIntegrator — lets make other pages be integrated and look natively in Tiki! :-)
  • TikiWikifier — feature to import remote HTML pages with autoconvert to wiki
  • Refactored Tiki modules layout. Theme makers now be able to redefine modules look-n-feel by redesign module.tpl and optional module-error.tpl (which is used if {tikimodule} Smarty block can't render module... but it is really unusual case... so it is optional :-)

Future ideas to be implemented in Tiki

Here is just small notes about smth what I want or have plans to change/implement in Tiki in some undefined future...

  • Tiki core
    • TikiCoreWishlist — core as I c it
    • TikiCorePrototype — start to code prototype... just demo
  • Smart (intellectual) environment :-)
    • just some ideas:
      • ... there is no need to show login box when user already logged in
      • ... modules can be up/down automaticaly depending on user 'hits' (i.e. most usable on top)
      • ... there is not needed to show changes_from_last_login more than N times after login (resonable default 3-5) — usualy this info interested just after login
      • ... messages count (module) interested only if new/unread messages waiting in inbox
      • ... appilcation menu can dynamicaly reorder items in to popup 'most usable items on top'
    • ... looks like 'modules' can be shown using banner engine technologies with wide range of targeting :-)
  • Wiki subsystem
    • Wiki parser should be rewritten: there is two ways possible here
      • Using FSM (need to build FSM before and then update it if neccessary) — classic way for grammar parser
      • Another approach: a set of rules a la TikiIntegrator applied to a text (interface can be reused ;)

      both versions may (should?) have a dynamicaly generated php file with wiki parser, so after reconfigure (change rules/automata) wiki parser will be regenerated to apply changes in Wiki syntax
      both versions may have an admin interface to configure (tune) Wiki syntax, so it is possible to make a few syntaxes and exchange syntaxes among sites... for example: Tiki may emulate phpWiki (or any other) syntax to allow easy migrate from other wiki systems :-) Another feature: wiki grammar become selfcontained item — so it can be tuned better and better and then distributed among users. Even more features: imagine that a wiki page may contain directive which grammar to use... :-)
      {wikisyntax name=TikiWiki version=1.8}
      This is __native__ ''TikiWiki'' syntax :)
      now switch to phpWiki...
      {wikisyntax name=phpWiki version=1.0}
      ... actualy I don't know how it look like :)
      ... of couse admin can set some syntax as system default. Another mega feature: wiki grammar can be downloadable/upgradable :-) — i.e. tikiwiki.org maybe central point of distribution of official Tikiwiki grammar, so site admin may download/update syntaxes installed. (btw downloadable rules idea can be applied to TikiIntegrator :-)
    • Special wiki like syntax for quizz definitions... of couse it will be inherited form standart wiki parser... :-)
    • yet another page view mode using <del>/-+<ins>+- HTML tags to highight changes after previous version
    • search-n-replace for wikipage (with history... per page?, per user?)
    • auto glossary generation/referencing. What is this? :-) — example: look at HPC (High Performance Computing) or NLM (Netware Loadable Module) — this are examples of abbreviation with inlined explanation. Imagine what if Wiki can learn such definitions automaticaly... :-) — I.e. after 1st mention all others (placed in other pages) may look like this: <ABBR TITLE="Netware Loadable Module">NLM</ABBR> (-+<ABBR>+- with tool tip I mean :-)
      • page/category/site wide — i.e. the same abbreviation in different knowledge areas may mean different things (of couse)
      • collect terms automaticaly

      Questions currently w/o answers:
      • what to do if page with definitions removed? — should abbreviation be removed too? If not immediatly when how long it will be in DB till removed?
      • what to do if abbreviation changed? algorithm should remember all abbreviations defined on given page before editing session and remove all definitions which is absent after edit action... then add (actualy update) new terms introduced on new version of given page... (even if smth was already defined it should be removed — new term should always redefine previous one)
    • auto quote — insert <QUOTE> HTML tag
    • auto align/indent
    • — i.e. superscript number in text and explanation on page bottom (like in a books :-)
    • predefined wiki variables (like user or theme, even maybe some user preferences, features currently enabled, smth else?) — this allows to make wiki texts like
      # wiki source
        Dear %user%, when u will read this page...
        # will expand to...
        Dear zaufi, when u will read this page...
    • conditional wiki text...
      # wiki source
        {if %user% != %page_owner%}
        Dear %user%, when u will read this page...
         Welcomeback master! :)
    • Allow to user (with tiki_p_admin of couse) edit top/bottom as wiki pages...
    • Page update marker (new icon after link to page :-) actualy can be a simple text like <span style="color:black; background-color: yellow; font-size: 6px">updated</span> or <span style="color:black; background-color: yellow; font-size: 6px">new</span> — depends on creation_date == modification_date
  • Smarty
    • it will be cool to write some useful blocks for smarty:
      # to generate a set of tabs...
        {tab} ... {/tab}
        {tab} ... {/tab}
      # and to generate trees... (a la categories tree or menus)
      {tree name=node loop=$tree_struct}
      {flipper} <flipper code here> {/flipper}
      {node} node code here can use {$node.data} {/node}
      {child_start_code} ... {/child_start_code}
      {child_end_code} ... {/child_end_code}
      also check the lib/tree/tree.php for some aux comments
  • Themes — I think themes should be more configurable. For example 'Matrix' theme can have an option 'full/light' to switch on/off some transparency effects. Another my theme 'Notheme' may have an option to switch variants I/II/III to use. I think every theme may have a configurable size for left/right column... and so on. So ...
    • look like theme should have a properties panel so user may (if admin allow :-) to change some aspects of theme like sizes, colors, variants (somethimes when I found a cool solution for smth and forced to define another theme which is 99% the same as original — this suxx — the better will be to add an option to theme properties :-)
    • another thought: actualy it can be good to split theme into layout and style (CSS file) — currently tiki have 2 basic layouts (which is look the same): table based (with leftcol bug) and tableless (divs based)... but with ohertel and gmuslera on IRC we found another one I want to give it a try :-) — but it is just tiki.tpl file needs to be changed... no need to define yet another theme...
  • Still unclean :-( ideas about widgets (i.e. reusable thing containing code + visible design) — yea smth like QT one ;) Examples:
    • 'find' form (which is present near almost all tables in Tiki) it can be a widget
    • page counter with navigation (i.e. page m/n with prev/next links)
    • categorize (sub)form
    • emoticons bar

    I think such examples realy many may be counted in Tiki... i.e. I mean some reused design elements with some code (which is usualy copy-n-pasted form file to file) to handle events from ...
    Need to think more anout it :-)
    • How to define it: code and tpl representation
    • How to use (insert in to tpl file and get/pass parameters from/to widget)
    • Of couse it should be a class :-)
  • Consider to use <LINK REL="" HREF=""> tag with types like defined by W3C...
    • it can be useful for pagination (instead or with addon to exist pagination links)
    • in wiki structures and TOCs
    • maybe instead of some menus
      • like wiki page bottons
      • links to admin page of corresponding feature — i.e. suppose we r on tiki-list_trackers.php, link to tiki-admin_tracker.php maybe one of the following:
        Two example links here:<LINK REL="Appendix" HREF="tiki-admin_tracker.php" TITLE="Admin Trackers">
        <LINK REL="Bookmark" HREF="tiki-admin_tracker.php" TITLE="Admin Trackers">
        <LINK REL="Author" HREF="tiki-index.php?page=UserPagezaufi" TITLE="About Author">
        Cool feature (or bug?): mozilla interpret links placed in body too... plz drop a comment below about your browser: do u c the links in navigation toolbar? :-) Two links placed above in this code fragment... But actualy it is strange: Links visible in 'preview' mode and interpreted in normal view... maybe smbd broke (again) CODE plugin???
    • In addition for wiki Copyrights feature <LINK REL="Copyright"> maybe given
    • Link to author of wiki page, article or smth else... can be <LINK REL="Author">
    • <LINK REL="Help"> — can be used in addition (or instead) of existed Tiki Help (links in dialogs)
  • FANCYTABLE plugin may have sort links on columns...
  • smth else... don't remember all my ideas :-(

Page last modified on Wednesday 09 March 2005 03:38:47 GMT-0000

Upcoming Events

No records to display