-=bitweaver Design Goals=-
This page is in the proposal stage, so things are still very much open to comment. Please drop by IRC or post to bitweaver-development@lists.sourceforge.com.

__Disclaimer:__ I make some generalizations about application types, specific applications and other things here. Don't take every word as law, there is no way I can cover the fine-grained details of this entire subject in one document.
This page will be the discussion for us all to put in our 0.02 to say exactly::

#What do you think Tiki is now? Pros? Cons? Why?
#What do you want Tiki to be?
#What native features we would like to see in the answer to #2. Why (if you feel like it)

These questions are not as easily answered as one might think. First let us define a few things.

__Native features__ - This means NO addons. using my favorite nemesis, Plone, I will provide an example. Plone is a wholly integrated CMS/DMS with it, you can create, edit and manage douments and media of various types. It natively supports (X)HTML and DTML for added content, and can accept and identify almost all uploaded document types (though it cannot display them without addons). That and more make up Plone's main features:
*Content Management - write/edit/store documents
*Workflow
*Full-text Search
*Portable user storage and authentication (this comes from zope)
*Document discussions
*Template-based content presentation (somewhat xhtml compliant)
*Filesystem-style hierarchical content layout (modifiable)
*Full revision control of every document or file added
*Treats uploaded files the same as created documents (therein is the combination of CMS/DMS, it treats content as documents)

__CMS__ - I know we all think we know what this means, but lets define it explicitly. A Content Management System is some kind of application that allows the content of a website to be managed, edited and changed easily; most often geared for use by non-technical staff. A pure CMS does not necessarily have forums, discussions, or any other addon features (see http://www.callistocms.com for example) Callisto is an absolutely pure CMS, you create a site and manage all it's content with the app, it does not do forums, polls, etc.. Public corporate sites are the most likely canitdates for using a CMS.

__DMS__ - Document Management System - In essense, a glorified web file manager. In practice, a DMS can accept existing documents of a variety of formats, and standardize their presentation and/or their accessibility. A pure DMS may not really do anything to the documents it stores, it may only organize, index and display them. Corporate intranets often use a combo of a CMS/DMS (not including applications like webmail or other groupware).

__Engine__ - I'm just using the word "engine", you could call it whatever. A site engine is usually some kind of combination of CMS possibly a DMS and usually quite a few addon featurres. Perfect examples of this are PHPNuke, PostNuke, Drupal, and of course TikiWIki. Plone also considers itself an engine, but I don't listen to them. Engine-style sites are often driven on a newsbyte style content format that is updated frequently, instead of the long, less fluid document style used by a DMS or CMS.

__Enterprise__ - This does not mean "busy" or just "big". When I plan an enterprise scale framework for something, I look for Scalability, Redundancy, Failure Resiliency (this is not the same thing as being redundant), Performance and Security. An Enterprise will expect 99.99% uptime or better and stable upgrade paths. No PHP-based CMS I have ever seen covers all of these.

__Why do I not call *nuke or Tiki CMS's?__ Because although a site engine application offers numerous ways to control the content of the site it runs on, it is NOT geared towards raw content management. The strength of a site engine generally lies in the bundled or add-on applications (modules, mods, block, it's all semantics) that it can use. Stripped of all addons, most site engines don't do very much, and at that point may not even be able to control content very well.

__Why aren't I calling forums and such "content"?__ Forums and other such features are generally extensions or addons. The core of a web app may or may not support a feature like this, but the base content implies the "core" of a site, i.e. if I have a site about monkeys my 10 pages about monkeys are my content, whereas the forum for discussion of monkeys is an addon application or extension of the core functionality.

__CMSs DMSs and Engines are NOT mutually exclusive!__ We can all see this with every app like Tiki. Some engines really are CMSs, some DMSs are CMSs, come CMSs have engine features. You don't have to pick just one, you just need to be specific in the features you want to see in the core.

^
-=mikelcu aka Mike Culbertson aka troublemaker=-

I think ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and TikiWiki)) is an Engine, with some really powerful CMS-like features and apps. I think it was developed organically without a solid plan, or at least not one that was followed.

__Pros:__ The wiki, the userbase, adodb, smarty, lots of clever and fast code
__Cons:__ Poor security design, cluttered presentation, often obtuse menus options (create a new Wiki page how??), a inherent lack of flexibility coded into the core...there are hardcoded paths, filenames, etc. all over the place. The file organization and naming standard are sophmoric.

I would like to see the /idea/ of Tiki become what products that Plone, Interwoven and similar are NOT. A real CMS that can be used in an enterprise /with/ the features that make it attractive for use on smaller sites. ''__There is a medium between corporate stoicism and opensource hacker fun and I think that something derived from tiki has the potential to be that.__''

-=Mike & Brian's Core Feature List=-
My core feature list comes from a conglomeration of features found in other CMSs.
*__Flexible storage backend__ - Support for multiple DBs should be native from the beginning. SQL queries should be 100% portable /or/ there should be different subsets of queries depending on backend...the app should NOT be married to any one data source.
*__Mobile User Base__ - This /must/ be able to retrieve and store user information from any source. An abstraction layer could provide auth from LDAP, SQL, Radius, Kerberos, anything. A flexible API would allow new auth modules to be added by 3rd parties.
*__Layout__ - An organized application layout is essential. There are innumerable organizational and security implications to the way an application is laid out on the filesystem (I know, I do it for a living).
*__CMS core with modularity__ - My ideal app would be a CMS at heart, with all authentication and data storage handled by the core. Additional functionality such as forums/polls/etc would all be extensions or modules. In it's raw-est form, the app could manage a nice 10-page site with nearly static pages. Also, the core would be written with assimilation in mind. I do NOT want to write another forum, phpBB already did it and theirs is better. THe same thing applies to many apps. PNphpBB is a great idea and the core should be planned with things like that in mind.
*__Dynamic Content__ - Wiki-style collaboration and/or commenting.
*__Full-Text Searching__ - Anything edited/added/uploaded into the app should be at the minimum indexed for a /smart/ search feature. The core must store information with the idea of finding it later well in mind
*__Full Revision Control__ - Any and all documents/files/objects managed or stored by the app would have revision control applied to them (configurable)
*__Standard Output__ - The output format of the application would be XML or XHTML using CSS. Every page without user input screwing it up should validate 100% at w3c.org. Why? /real/ compatibility. There will always be browser bugs, but being 100% standard is the easiest way to keep the field even. (If you think XML or XHTML is not backwards compatible, visit www.callistocms.com with NN4)
*__Modular Output__ - The theming and templating framework must be designed with the idea that sites will NOT follow the standard header/3 colums/footer layout. Making each displayed component truly a modular piece lets users redesign their own site in any way they see fit. (no open-source CMS/Engine I know of supports this without quite a bit of hacking)
*__out-of-the-box usability__ - The default app would have enough usable/compatible templates and GUI-configurable options to let anyone install it and set up a site.
*__Enterprise Attitude__ - The world does not need another nuke. The app would be planned with the intention of use in an enterprise, with support for individuals. As fun as they are, quiz addons are not a bonus when picking a corporate intranet. However, any and all contributions should be strongly encouraged. Brilliance comes from the most unusual places, plus you never know who will want what :)
*__Fully Documented API__ - extensions and modules must have a properly documented API to use for easy development (think smarty)
^


^
-=jomar aka John Riley=-

It seems to me that ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and ((bitweaver and TikiWiki)) is conglomeration of various open source capabilites that outgrew any roadmap that it may have had at one time.

__Pros:__
* A lot of capabilities at an excellent price.
* An exciting approach to loosely managed communication.
__Cons:__
* Documentation is poor and / or lacking and / or outdated (installation, administration, usage)
* User interface is at times eclectic, non-intuitive and cluttered.
* Quality / reliability from release to release is highly variable and unpredictable.
* Impact to users of changes / enhancements are not fully documented
* Architecture not modular enough. More modules and fewer core features. Mods must be easy to install / develop.
* APIs and developer processes not well documented

I guess my perspective is that it's a communication tool. It seems, from the 40,000 foot view that it's a tool that allows people to present, solicit and collaborate. I see no need to limit it's ultimate scope, as long as it's possible to manage it's diversity / complexity.

-=My Core Features List=-
I'd like to see bitweaver have an infrastructure "core" and lots and lots of optional user-contibuted modules:
* Modular Presentation, Database, File, Intra-module communications, Administration and Initialization subsystems with associated APIs
* Wiki, Forums, Articles, Blogs, File Galleries and FAQ's as the "baseline" module set (give or take a few)
* Being a software developer, I'd like to see software development lifecycle support modules
* Need to be able to install and configure quickly (including the ablitiy to encapsulate stored setups for easy site replication)
* Needs to be very readily "themed" (branded)
* Need the ability to readily and quickly add capabilities
* I'm thinking that, due to site entropy, there should be ways to easily reoorganize, sift and categorize content periodically.
* I'd dearly love to see automated testing / validation capabilities. I think that would go a long way toward managing quality and minimizing wasting precious developers' time. It would also go a long way toward developing customer confidence
^
^-=Thoughts from an application developer=-
Remember: Wiki, wiki, wiki.

Why? Principles:

1. As we have learned to our dismay, most of our users are never going to learn HTML.
2. The "Webmaster" syndrome is killing us. Every little change has to go through the Webmaster.
3. We (application developers) are DESPERATE for a package that enables us to DISTRIBUTE page maintenance responsibilities to end users! But no HTML!

''This is why we are trying to use Tiki.''

Tiki isn't EVER going to be used for an enterprise's public Web site, where the Webmaster is still very much in charge (and has to be). It is already used in who-knows-how-many intranets, non-profits, NGOs, semi-public collaborative sites, etc. Because of the Wiki!

So:

Market identification: engine + wikified CMS

Implications for Design:

1. Make sure that the core of bitweaver is the Wiki -- and what is more, that the Wiki is state of the art. Carefully study TWiki.
2. Build automated site generation tools into the Wiki core, including automatic menu generation and option to include a new Wiki page in a specified menu! (See typo3 for an excellent implementation of this concept)
3. Keep the Wiki syntax simple! Tikiwiki's syntax has gotten out of hand, particularly with plugins.
4. Add capability to give individual-level permissions to pages (the current page creator is owner is a start, but doesn't go far enough).
5. Build INCLUDE capability into the Wiki so that text never needs to be repeated.

--bryan ^

Page History
Date/CommentUserIPVersion
01 May 2004 (04:37 UTC)
SEWilco209.98.144.1610
Current • Source
No records found