• admin : site creation - including initial settings/structure/content
• user : content viewing - including search & detail correction
• user : content creation - new pages
• user : content refactoring - on single or multiple pages
• admin : site evolution

(here is only considered a simple wiki site, no forum, no blog…)

below some large themes you may find 'improvable':

registration

• direct wiki site registration (no wikidot registration first prerequisite)
• automatic or (user) choice registration to wikidot within wiki site registration form
• site default choice (setting) for wikidot registration

contribution controls (how do you call these 'edit','history','save'… buttons down there)

• choice of their place (up/down the page)
• choice of their list
• choice of their name/picture/style

all of this through settings (site manager) or in a special system: page (like for nav bars)
In fact, I personly would like to place these controls on a separate and very thin top/bottom bar.

editor

• raw mode on choice (no button toolset at all)
• wysiwyg mode on choice (see comments below)
• choice by the user !
• with site default (setting)

Wysiwyg on choice doesn't prevent anybody to edit in insertion or even raw mode. But a wiki is usually not intended only for technicians. I want my users to have the choice; they will massively choose wysiwyg (but not me ;-)).
Wisiwyg may be a hard work to implement! But in fact, not all the editor's features need to be wysiwyged: you may limit it to the rendering of the toolbox buttons… No ?
The choice of the toolbox buttons, and the choice of what features aren't in the toolbox, is really fine. It should not be extended, except maybe for

• a 'create anchor' / 'anchor link' pair of buttons.
• a very basic replace function

(simple search and undo usually beeing available from the )

languages

• wikidot internationalisation to allow:
• first : site language choice (on creation / setting)
• and then : multilanguage site with language choice by the user
• all user interface translated (*)
• optional : admin interface translated

(*) contribution controls, default nav bars, default modules, default pages, info docs…
You may launch a multilanguage/internationalisation project into the communauty by delivering all these texts to be translated (in addition to the present multilanguage handbook).

doc

• to be refactored from all present sources (doc, help, communauty, howtos, FAQs… too many sources in too many places)
• multilanguage from the start (no default language)

points of view to be clearly distinguished in the doc/info/help system :

• user doc / admin doc
• learning guide / reference manual
• low level (standard user) / higher level (technical user) / no level (factual info)
• information / examples

I'll post later on more specific points as I meet them.

Heartful thanks & congratulations for your work !/
denis

That said, I'd also like the default code of a plain [[gallery]] tag to include a relative path to each image, so that when you used [[include]] to include a gallery page on another page (a blog post in my case), it didn't try to just include images from the blog post. Now I have to manually add the relative path for each image so it show up correctly for includes.

I'm working on a project that won't have anything for a while, but when I'm ready to upload it, I'll have almost 300 images to be uploaded into it.

It could be useful have in the history the changes relative to tag (if tags is added / changed / removed).

Ent

the first status is a category "submitted:" ( before the page name) , and perhaps this category is closed for all except the admins and the authors.

second stage is the rename ( or Copy) - the status change - to "beproofed:" , only allowed for some moderators to be edited,

and the third is "proofed" - only alllowed to — admins? - have a look in the site manager - permissions of the categories…

There are some different groups of members and allowances now - could be these is enough..

or you need for a different group of members a different , parallel ( and private?) wiki with specific memberships only for such editing group-members closed for all others.

What you want is the group's of members to build free and to give the permissions for such groups.

This will come .. but no idea when.

Could be that I missed out on some functionality. I just started my search, and ended up reading all the suggestions…

I want to have parent-child page can be available in address path such as http://sample-site.wikidot.com/parent-start-page/child-page/another-child-page, it would be nice… (can you make it happen)

This conflicts with categories.

Add the little HTML, Java, or VB scripting. If the security problem is compromised, limit the syntax using in each scripting language to the most secure level…

You can upload scripts and iframe them (I think they got it setup to work for correctly and risk free now, but I haven't checked. You can upload the scripts on another site then use them for sure), or embed limited scripts. Thats goes for both java and html. (Any client side scripts)

Or at least if point 2 is can't be happen in Wikidot, expand the Wikidot library syntax and also the complete implementation…

Complete? There is no such thing, but it is constantly getting better!

Expand the 300 MB storage limit to the site that host for downloading… (I hope this could be happen…)

I personally would prefer an increase in the max file size rather than an increase in the total capacity, but both would be nice (thanks for the increase that we got a while ago!). I personally have lots of other locations I can host downloads from, so it is not a big issue for me.

• I want to have parent-child page can be available in address path such as http://sample-site.wikidot.com/parent-start-page/child-page/another-child-page, it would be nice… (can you make it happen)
• Add the little HTML, Java, or VB scripting. If the security problem is compromised, limit the syntax using in each scripting language to the most secure level…
• Or at least if point 2 is can't be happen in Wikidot, expand the Wikidot library syntax and also the complete implementation…
• Expand the 300 MB storage limit to the site that host for downloading… (I hope this could be happen…)

I think that what I want for now… Keep your good work!

 [[ul style="background-color:#000;color:#FFF;"]] [[li]] Something [[/li]] [[li]] Something [[/li]] [[/ul]] 

Currently to do that, I have to add a class or id selector in the theme and select the html tag through the selector.

 #styled-list ul { background-color:#000; color:a; } 

Then i have to wrap the unordered list in a div with the selector

 [[div id="styled-list"]] * Something * Something [[/div]] 

I'm aware there's easier ways of doing this. This is just an example of having to put CSS in the theme when it belongs inline on the page. Imagine if you only used this list once.

— Shawn

The forums need to be able to have password-protected boards, or boards that limit visitors based on membership (I.E. a staff board).

And the ability to add HTML to the pages would be really nice instead of just using the Wiki language.

One handy feature for novice content creators would be a checklist of items that the user might want to edit on a page: tags, orphan links, etc, that can pop up when you make changes to a page. As they get experienced, they may well want to stop seeing that list, so you'd also want to be able to set personal edit preferences.

Another useful feature would be the converse of per-user permissions: for example, if I operate three separate areas on my wiki, it'd be nice if users of one area have different editing permission from users of another area. (Possible workaround: create three separate wikis and link them, but that can get pretty cumbersome).

Backups including a dump of the forums and page histories

Yes, I know that Wikidot has all this information backed-up server-side and can restore them if needed from server-side backups. Yes, I know that if a user is running the future Wikidot 2.0 on their own servers they have the same option to just restore the server files for everything.

But here's where that logic breaks down: what if the user has current Wikdot 1.x site and wants to migrate all that existing content to their own Wikidot 2.0 server? You really need to plan for this scenario before you release Wikidot 2.0 to the public.

Per-user or per-role menu assignments each user or role can see

It would be especially useful to be able to have different versions of a top menu for your admins and mods. Right now you have to go to some major contortions to make your documentation and links and lists for your admins/mods somewhat hidden from everyone else.

Per-user or per-role ability to hide namespace pages or even specific pages

Similar to the way that you can globally block editing specific pages or entire namespaces, it would be great to have the same functionality to prevent specific pages or entire namespaces from being viewed at all by either specific users or entire roles. For example, you might want some pages that are visible only by your admins and mods, even if a smart member figures out the exact name of the page or sees the page title in the list of all pages on the site rendered by the [[pages]] module.

best regards
bruno

BTW, as the first step, could wikidot make a simple interface to make a dummy html which name must be assigned by user to pass the verify of google webmaster? If possible, an interface to edit robot.txt is necessary.

But for your own you can decide the "Theme" ( and the "standard" Font size of course) for your OWN Site - what ever you want!

Or create a user-customized CSS.theme qwit bigger font's..)..

I write this not to forget such possibility..

Please keep the wiki site using your voice. The sense that you are there is important. It seems as though some of the new material is being written in the corporate voice of god.

No one will be wondering about ways of donating money.

And maybe be more open about the importance to you of the whole collaborative writing effort. It moves wikidot above other sites.

Your request for suggestions is a real morale booster — and loyalty builder.

If this request for suggestion would have been signed "The Wiki team " it would not be the same.

Maybe let the names and personalities of other members of the team become part of the wikidot experience.

• As I'm posting here, there are way to many buttons available. Do I really need bibliography, footnotes, page link wizards, headings, footnotes, toc, to post? Stick some in a dropdown or a tab, combine some "wizards", whatever.

Good points on the tool bars. There are a lot of buttons.

The buttons you use in the wysiwyg editor are very bland. You might also note that there is a lot of support in there for people who do math work and media. Not everyone is going to use this and it's limiting to bury the stuff people do use in the stuff they don't.

If I could change anything about that I would make two changes.

First, I would use an icon standard (and there are several open source ones out there) with COLOR on the icons.

Second, I would allow people to configure the 'page editor' window by disabling the toolbars, or enabling them on a per-user basis, with a default for each wiki. If someone wants to edit with a toolbar that is not available, they should be able to choose more from dropdowns.

- mailing options in the forum: like google groups, it would be determinant in terms of usability to give users the possibility to choose whether to check new posts on the forum or receive them in the emais (with digest option). EXACTLY like google, no need to brainstorm. I know there are feeds, but we are nerds guys, common people is different, and common people participation is wikis' target.

- MULTI-category search. I can build up a category search system through backlinks, but I cannot search using more than one filter (category) at a time. Therefore also backlinks become useless.
For example: what do I care of having backlinks for finding in my database all the people who live in NY, all the baby-sitters, all the female members, if in the end I'm not able to find out what I really need, that is a female baby-sitter to take care of my son while I'm away from NY?

- Optional, since I imagine that this is already possible by installing the software on my own server (thanks guys!), I would like to be able to manage all those features related to the profile pages, but internally in my private wiki. That is internally visible profiles of all the members with lists of contributions and private messages between users.

What do you think?

Thanks and good job!

Davide

It would be extra nice to optionally turn off the shortcut buttons, making the editor completely clean.

If youre not using firefox , then get it!
then get the web developers plug in.]

then have a read of : http://community.wikidot.com/howto:design-your-own-css-theme

and http://community.wikidot.com/howto:themes-an-idiots-guide (my pref.. but then, i wrote it!)

On the 5th issue, I must concede that I hadn't see that.

Thanks,
lgbtsource

I'd be eternally grateful if I can get someone to help with the 1st and 3rd issues on my post. With the second issue, I was thinking in terms of a person editing one section of a page and another person editing another section of the same page.

Thanks,
lgbtsource

There are a few changes I would make:

• I would like to use a Level 1 Heading for the titles of pages, but can't because it automatically rendered in italics and can't be undone.
• The 'Exclusive Lock' could be an option. Unless, I'm doing a major edit on a page, I don't really have a need for it.
• Along with many others, I would like there to be more themes. I have Gila with a sidebar and would like it to wrap around the top of my wiki.
• I think that there should be an option on whether to show how many page revisions there have been at the bottom. I'd like it to show the date and time that a page was updated in a similar fashion: Last Updated 03 February 2008 18:00. Because of time zones, the ability to see exactly how many hours ago it was updated by hovering the cursor over it would be be nice.
• Lastly, the ability to edit small sections of a page would be great. If it is a long page, I might want to only make one sentence more coherent and won't want to go through the whole article to find it. For instance, I might want to change the spelling of Mt. St. Helen to Mount Saint Helen in the section about the effects of its 1980 eruption. The page would be better managed if there was the ability to edit small sections of it.

lgbtsource

Well, I've talked it over with the union…we were hoping for a new water cooler and for the company fridge to be cleaned out.

I've eaten from the same cereal bowl every day - I think the food is so old, it's multiplying.

- J.M Shiells

I'll second (or third) the request for better table editing. Even with the advanced table tags, it gets cumbersome with a largish table. However, I have a suggestion for this: Use the existing syntax, but have a Table Edit Wizard or mode, in which the table is presented as bunch of tiny edit boxes, plus there is a "delete row" button on each row and a "add row" button at the bottom. This would be a sort of wysiwyg just for the table aspect.

By the way, I would argue against trying to do a wysiwyg editor. The problem with this is that it is never good enough, and you will sink all your development effort into it, letting all other features go by the wayside. Some very selected places, like the table editor (and maybe a tabview editor that works in a similar way) makes sense, but only for these sorts of gross layout features, and then just allow the guts of them be simple edit boxes where an editor just uses the existing syntax.

I don't have any major changes to suggest since I really like the site as it is now. But I do have a few minor requests for things that I would personally like to see. Some of these may be slotted for premium services and I can certainly understand that, but I have nothing to lose for asking so here goes.

• More permission options for categories. Specifically a "read" permission. This will let users create categories that cannot be read by default users … for example: A private staff area.
• Dynamic content in the TOC. So instead of displaying headings only, we could enter an image for example. So if a plus sign will pop text in there, perhaps some other sign would pop anything that follows in there at the top or bottom of the TOC area, but within the box.
• A Meta tag editor.
  • Meta tags are a very standard feature and while I do retain suggestions for how to improve the site, I can still live without those improvments, but the lack of a way to edit my tags is a complaint that I have. Please provide us with a way to better promote our sites through this very common standard. Many google features cannot be used unless google is able to verify you as the site owner. For example, we cannot use many of the features of Google webmaster tools: https://www.google.com/webmasters/tools/siteoverview. Tools like these are essential for getting more visitors to our sites - that also promotes Wikidot. Meta tags do actually help for ranking too as they are a part of the entire ranking model and help with keyword saturation. I should point at that any measure given us to improve our visibility will improve our traffic. Likewise, any traffic improvement for us will also mean more exposure for wikidot. You could quickly turn those 15,500 major backlinks into 150,500 backlinks.

Thanks for reading.

I would like to have more control over the way the modules work:
eg. I don't like the fact that the a.hover text for the footnotes includes the text "footnotes" and "click to scoll to footnotes"
I would love it if we could actually see and alter how the modules behave.

Another MINOR thing in regards to that is that I would like to be able to put square brackets around my footnotes (the way that wikipedia do it) eg ^[3]
This is a nicer, cleaner look than having just a number and is not that hard to code.
But at the moment there is no way to add custom text to an already defined module.

The other thing that I would like to see is user-definable modules.
So that we could create an entirely new module eg. [[customwhatever]]

Appreciate any considerations,

BradLee

I haven't been using wikidot for long, but it sure looks good so far. The only disappointment I have had so far is a lack of flexibility in site structure. I would really like to be able to do things like nest tags and nest categories. Also tagging categories or categorizing tags would be nice. I'm managing my organization mostly with the backlinks module right now because it is the only way to get the flexibility that I want, but it seems that there could be an easier way.

but without any Forum content!

That is a neccessarity for a business to save the comments of their customers!

Best regards
Helmut

Backlinks for each page. This can be implemented as a module: A short list of pages that point to the current page.

Module Backlinks already exists : http://www.wikidot.com/doc:backlinks-module.
To have it on each page, just insert [[module Backlinks]] in the default template !

• Some scripting language: This could be only allowed to few members, as it could do great harm! Just imagine:

 foreach[sandy, mindy, paul, july] {newpage(friends,$); //adding a new blank page with that name in the "friends" category append(friends, $, "+++ ".$." Page:"); append(friends, $, "This is my friend, ".$.); attach(friends, $.".jpg"); append(friends, $, "[[image ".$.".jpg size="small"]]"); } 

Or creating parametrized templates:

 foreach[sandy, mindy, paul, july] {newpagewith(friends,$); //adding a new blank page with that name in the "friends" category usetemplate(friends,$,template,$); //deploying the template which has a reserved value for the wanted name. } 

• If possible, Object-Oriented pages?: This may be unrealistic, but now, each page posess some files. Other objects can be added, like boolean flags indicating the status of a page (0 if in construction, or 1 if developed ), list of strings (name, address, phone number…) so constructing pages could be as easy as:

 +++ $thispage.name() web page. $thispage.name() is $thispage.age() old, and these are his friends ([[script]] for (i=1; i<=thispage.number-of-friends) return thispage.friend(i) [[/script]] this page is [[script]] if (thispage.construction==true) return "this page is **under construction.**; else return "completed." [[/script]] 

• Backlinks for each page. This can be implemented as a module: A short list of pages that point to the current page.

• Autocompletion. How many times you remember that page you have created last week, but you do not remember its name? It would be nice if as I type, the possible existing categories or pages appear, so you do not have to check if that link existed or not.

Wow, imagination flies about the possibilities of wikidot!

Greetings

Make it more easy to make a new page and find it afterwoods - new pages made can be hard to find if they are not "parented"

Furthermore I second these ideas from the thread:

• TABLES - made easier to make and maintain
• Drag and drop of pages on the sitemap function, which changes the parent page
• New ways to redesign site structure
• Make it easy to integrate with other applications
• Easy-to-make user groups (along with the permissions). Like, Super Admin, Admins, Moderators, Privileged Users, Users and Guests as default.
• Make it more more mobile phone friendly. I tried it with my Nokia 6280
• Multilingual
• In the meantime, let me just say that this is a wonderful tool you have created and I am grateful for whatever you do!

best regards Flemming

Now you are asking, I have some ideas, that are related to other already commented

1- Multilingual… There are still much people that are limited by their use of English
2- WYSIWYG? Its good, attractive, but maybe less effective that WYSIWYM (what you see is what you Mean) concept. Plain text editing should be kept
3- Permissions. Allowing the creation of working groups for certain specific tasks. I mean: Any ordinary user may ask permission to join a group where was created by a moderator. The moderator is responsable for carrying out the task, and he should be allowed to enrole or dismiss a collaborator of lower rank, and also to give credit (or discredit) to those that have performed the tasks

And, thinking on bigger colaborative networks, it should be great if users could be promoted after getting some points, gained with effort. This way, administrators could know which user can be promoted to be a moderator. Bigger rank moderators may propose tasks with bigger reward, while young moderators may have less confidence and moderate only small groups. Recent users can have tasks with lower degree of responsability, while experienced users may review other's work and express their opinion, raising the valoration of other contributions, getting also points for these reviewing tasks.

This is a great incentive for everybody to collaborate, and the administration of the community could be easier.

so that reader do not need copy-paste the code, they can just download it with a click.
this will be very much usefull.

tia

I just got here yesterday and really like what I see. The one feature I'd like to see added is the ability to use some basic html in addition to the wiki formatting.

It doesn't have to be all html code, or even actual html code. I'm on another website where we have pseudo-html - for example we can use <b> for bold and <i> for italics (and I think we can use [b] and [i] as well to simulate ubb), but it's not really html at all, it's something the site admin coded in manually to allow it (while still retaining the quality control to keep out malicious html code).

Also, I've seen some blog sites that do an autosave every minute or so on their compose screens. If that's not here already, I'd like to request that feature as well.

Thanks for making such a great wiki site! :)

But on thing is especially important for me - interface should be relatively similar to one from wikidot no.1, because people are conservative. You know…

Thanks once again for great application, which makes my life lot juicier! (sorry, I really don't know, if it is english, hope you understand :-)

—hartnell

Also, I posted this elsewhere, but Safari is now available for Windows; I read that wikidot doesn't have any Macs available for development. It'd be really nice to have Safari support. :)