We use the following section of our support site to track what features we are planning on doing. We try to have these implemented and tested in the next build. However, some may be more complex, or reminders for a major change down the road.
During the development of v1.5.5, I realized the difference between a Wiki page and a Blog Page is, the visitors ability to post feedback associated with the page. However, to implement blogging in a social community aspect requires that we wrap up the Login database. Which means implementing a new user, a verify user process, forgot password mechanism and a user management feature.
While designing the database structures for the BLOGGING feature, we realized with a few more fields and tables we could actually offer a full-blown FORUM system also. We are currently researching existing products and seeing what features we can put into our initial FORUM implementation.
As a consumer of software products, we receive the product and a long security code. Which we eventually lose track of. So we are looking to implement the ability to store this information in an existing wiki site of ours, however, we want to avoid the information from being viewed by non-authorized visitors.
We are researching techniques which will allow the web master to design a database table(s) via the Wiki engine. Flagging field types, which are search-able, etc. This will allow someone to easily make our wikicatalogue.com and promoteyourwiki.com sites more than simple paragraphs and photos. The part we have not finished wrapping our mind around is how to make an editor screen dynamically based by the structure. We are close to implementing this in the next major build.
Completely Automated Public Turing Test To Tell Computers and Humans Apart. (http://recaptcha.net/whyrecaptcha.html)
Back in the original BBS days, there were door games which focused on advanced user surveys. We are looking to incorporate this to the next major build of 3FWIKI.
Add the ability to enable/disable "numeric values" as part of the search word list used by the search engine. Currently defaults as disabled.
The following are features we are still deciding if we want to incorporate into the product.
Flag the content of a page as READ-ONLY.
Flag the content of a page as PASSWORDED. {most likely doing}
Flag the content of a page as NOT FINDABLE (meaning, do not tag it into the search database)
Flag the content of a page as NO DELETE.
Flag the content of a page as SCHEMA. {Not sure if this is the best place to store the schema}
Flag the content of a page as MENU STRUCTURE.
Flag the content of a page as CONFIG. {For security, the ability to compile the config is being researched}
Flag the content of a page as DONT TAG list. {Part of the security evolution}
Flag the content of a page as PRONOUNS list. {Part of the security evolution}
Flag the content of a page as A FORUM (as a FORUM descriptor record}
Flag the content of a page as a FORUM STICKY POST (meaning it will always show as one of the first threads)
BLOGGING
During the development of v1.5.5, I realized the difference between a Wiki page and a Blog Page is, the visitors ability to post feedback associated with the page. However, to implement blogging in a social community aspect requires that we wrap up the Login database. Which means implementing a new user, a verify user process, forgot password mechanism and a user management feature.
FORUMS
While designing the database structures for the BLOGGING feature, we realized with a few more fields and tables we could actually offer a full-blown FORUM system also. We are currently researching existing products and seeing what features we can put into our initial FORUM implementation.
PROTECTED/RESTRICTED CONTENT
As a consumer of software products, we receive the product and a long security code. Which we eventually lose track of. So we are looking to implement the ability to store this information in an existing wiki site of ours, however, we want to avoid the information from being viewed by non-authorized visitors.
DYNAMIC "STRUCTURED" CONTENT
We are researching techniques which will allow the web master to design a database table(s) via the Wiki engine. Flagging field types, which are search-able, etc. This will allow someone to easily make our wikicatalogue.com and promoteyourwiki.com sites more than simple paragraphs and photos. The part we have not finished wrapping our mind around is how to make an editor screen dynamically based by the structure. We are close to implementing this in the next major build.
CAPTCHA
Completely Automated Public Turing Test To Tell Computers and Humans Apart. (http://recaptcha.net/whyrecaptcha.html)
POLLS/SURVEYS/QUIZS
Back in the original BBS days, there were door games which focused on advanced user surveys. We are looking to incorporate this to the next major build of 3FWIKI.
CONFIG CHANGES
Add the ability to enable/disable "numeric values" as part of the search word list used by the search engine. Currently defaults as disabled.
WAY OUT THERE
The following are features we are still deciding if we want to incorporate into the product.
FLAGS
Flag the content of a page as READ-ONLY.
Flag the content of a page as PASSWORDED. {most likely doing}
Flag the content of a page as NOT FINDABLE (meaning, do not tag it into the search database)
Flag the content of a page as NO DELETE.
Flag the content of a page as SCHEMA. {Not sure if this is the best place to store the schema}
Flag the content of a page as MENU STRUCTURE.
Flag the content of a page as CONFIG. {For security, the ability to compile the config is being researched}
Flag the content of a page as DONT TAG list. {Part of the security evolution}
Flag the content of a page as PRONOUNS list. {Part of the security evolution}
Flag the content of a page as A FORUM (as a FORUM descriptor record}
Flag the content of a page as a FORUM STICKY POST (meaning it will always show as one of the first threads)
Search Engine
Topics Linked to here
Topics this links to
| none |
