This section on the Community is no longer supported, in favour of Wikidot's Official Feedback Site.
It is retained here for archiving purposes.
Wish List
Tags
Posted by 
David Marseilles on 1215417119|%A %d %b %Y|agohover, last edited on 1245528624|%e %b %Y at %H:%M |agohover
| This wish is open |
Description
I would like the New Page module to be expandable via custom form creation, allowing for quick submission of standardized content, or page creation for users with little wiki expertise.
The means would be through markup that is found in the Mail Form module paired with markers in a live template in the category that the New Page Form points to. So for instance;
Example
New Page module:
[[module NewPage category="x" include="video-instructions"]]
# pageTitle
* title: What is the Name of your Video
* rules:
* required: true
* minLength: 2
# videoEmbedCode
* title: What is the Embed Code for your Video?
* type: text
* size: 150
* rules:
* required: true
* minLength: 30
# videoDescription
* title: Describe your video
# videoUploader
* title: What is your wikidot username?
# videoTag1
* title: What type of video is this?
* type: tagSelect
* options
* montage
* tournament
* clan-war
# videoTag2
* title: What map does this video feature (if any)?
* type: tagSelect
* options
* port: Port
* city: City
* : None of the above
[[/module]]
http://(wikisitename).wikidot.com/x:_template
%%content{2}%%
%%content{1}%%
==========
[[table]]
[[row]]
[[cell]]
[[embedvideo]]
%%form videoEmbedCode%%
[[/embedvideo]]
[[/cell]]
[[cell style="padding: 10px;"]]
[[div style="width: 300px; height:320px; overflow:auto;"]]
+++ Description:
%%form videoDescription%%
[[/div]]
[[/cell]]
[[/row]]
[[/table]]
====
+ %%form pageTitle%%
[[size x-small]] uploaded by[[*user {$%%form videoUploader}]][[/size]]
Would present a form with 4 text areas (pageTitle, videoEmbedCode, videoDescription, and videoUploader) and two option drop-down boxes (videoTag1 and videoTag2) that automatically tag the page with predefined tags. I'd like to see automatic tagging available through both a basic text area (type: tagTextArea) and the dropdown tags as shown above (type:tagSelect) An include attribute would allow us to make an instruction page elsewhere with helpful information, and present it at the top of the form.
Custom marker tags would derive from field names. They would be placed in the Default initial content area of the Live Template, and when the page is created, would be replaced by the user input of the respective field names. So %%form videoEmbedCode%% would be replaced by the embed code that a user pasted into that text area.
So at page creation, the module would Send the Page title to a header at the top of the page (because the live template moves %%content{2}%% to the top), create a wiki user signature just underneath that, place the embed code between the embed tags inside a table underneath the title and user signature, and send the video description to the appropriate cell in the same table, while tagging it with predefined tags. Page created, and the user did not need to know wiki-speak.
Applications
This functionality could have endless uses, not just for simplifying content creation for people who don't know how to use wiki, but for automating repetitive entry on database items. It could also serve as the foundation of an editor for a future wikidot blogging platform, one that wouldn't take away our current flexibility, but would provide a nice, standardized (but still alterable and optional) method for creating new posts.
Related Links
WiiHD's Video Upload site
At this site I allow users to submit video game related videos for listing, rating and commenting to the community. I use the current New Page module, and simply provide instructions in [!-- comment --] form as to where to paste what.
The content automatically appears on the main page, thanks to the ListPages module.
Some people are scared by the wiki text area, and others just don't follow instructions. A form like the one described above could create a very professional looking content submission form for many different applications, and limit incidents of new user error.
Related Forum Posts
http://community.wikidot.com/forum/t-72301/wiki-style-textarea
Rate this Wish
We encourage you to "rate" the suggestions. The higher the rating, the better the chance of the wish being granted (well, possibly).
My title isn't great, but I'm too tired to think of another. If someone else can think of a better way to say it, I'd be grateful.
Overall, these custom forms would allow certain users to contribute content without having to "see how the sausage is made" (without having to see the wiki source code), but would not hinder power users from digging in. I think it could be very powerful.
One of the best ideas i've seen. This would make adding content so much easier and more straightforward, while opening up so many possibilities for more complex uses of Wikidot—things that extend beyond the typical wikipedia style article. Sure, plenty of complex things can be done already, but having template pages filled with wiki code just scares people away from adding pages. Even when condensing as much code as possible into [[include]]s, the user still has to put considerable effort into figuring out where to add content within the code, and it runs the risk of someone messing up the page design completely.
Brilliant!
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
Why don't you just ask for a WYSIWYG editor. That's a lot better than forms since everyone who can use the internet obviously knows how to use MS Word.
http://community.wikidot.com/wishlist:wysiwyg-editor
this is a forum signature. really.
I actually don't want a wysiwyg editor. I want custom new page form creation for its versatility.
As far as which is better, I suppose it depends on what your goal is, but for my purposes, custom new pages works. I foresee a lot of other uses as well.
I agree. Such a form would be an extremely versatile resource, with a number of possible uses. For one of my sites, which also compiles online resources (links and descriptions of websites), it would be great having a way for users to automatically submit contributions. The key here is "standardized content," with certain items being obligatory (say, "name", "site description", or "email address") and others optional.
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
A link submission usage is a great idea. I could use that to let my users post their own websites and descriptions. That would increase the community feel of the site.
I would like the ability to set default tags for a new page as well.
An Innovator at heart.
Great idea David, I fully support this, and it must be implemented!
I also think that all the syntax options for editing a page should be available too within the form layout so there is no limitations on the versatility of creating page content. If the form does not have this feature then adding content becomes far too simplistic and limiting, which can deter people from adding content as much as the rather crude form a template can already generate in a edit page window.
Offering all the syntax options with a form is essential to its success. All a form needs to do is to create distinct areas so users can see what content is to go where within the structure of the template the page uses. The kind of boxes created when adding a comment to a thread like this is ideal for this purpose.
There's plenty of room for improvement over the syntax I suggested. I just grabbed what was available from the mail form maker as an example.
Any improvements or even complete changes can be added directly to the wish page itself (add headers for "Implementation Suggestion 1"… Implentation suggestion 2..etc) , and the wish would benefit from your input.
Personally, I'd like the syntax buttons to be optional—where I could choose not to include them the module options, but someone else could choose to include them. For some uses, like standardized content, it be helpful to limit options to avoid errors.
It seems to me that what is asked for here is one more way to (pre)customize a catégory of pages. We've got 4 tolls already :
and now :
This should be done as a new kind of template. The main difference seems to be that parts of the page should not be editable by the user. There may be a [fix] tag to indicate this. It seems much easier than passing a whole list of parameters for the editable texts.
In fact, I don't really see the need for so many different kinds of templates/modules… A single type with such features would fulfill all the wishes I guess :
What do you think ?
denis
I think the main difference between this form system and a template is that the form can be presented in a manner less daunting to regular internet users. Most Wikidot users cater to a wiki-wise crowd, but not all of us do, and with the new Wikidot blogging platform (in other words, with more members entering the wikidotverse from a less defined skill set), I think there's a real reason for this new manner of pre-customization.
The vast majority of my readers are people who's basic interaction with the web involve reading stuff and commenting on stuff. Those are their skills, and that is what they're comfortable with. Once you start asking them to make or edit pages, they get overwhelmed, and don't want that kind of burden. On the other hand, filling out a couple of blanks feels more like commenting to them, and they're more comfortable with it.
Other wikidot admins might find it useful to un-editable portions of regular/live templates, perhaps to keep ads where they want them without bothering their regular membership, or to ensure extra navigational elements stay in place. But that wouldn't suit the needs that I've layed out. The video submission system that I set up at WiiHD's video site would get a lot more usage if people didn't take one look at the template and freak out in confuzzlement.
So true. Tonight, I noticed this comment someone had about adding content to my wiki:
"i tried to submit one of my maps but in the details and info, IT WAS JUST TOO COMPLICATED! so i said screw it :( "
Another lost community member overwhelmed by the sight of a page template and some wiki syntax. Building a thriving community should not have to rely on each and every member becoming a Wikidot expert, or even worrying about the technical aspect at all. Anything beyond editing a page of plain text is too burdensome to those unaccustomed to wikis and is a huge brick wall to any real community participation. It's very unfortunate that our only options are either to make a very basic, boring wiki that is easy to understand or design an awesome wiki that no one has the patience to contribute to. It is truly sad that Wikidot's full potential as a web platform cannot be utilized without wrecking the end-user experience.
A Form based New Page module would allow us to architect powerful systems that are much more user friendly.
This is exactly the way I see it. Admins are motivated to become experts, and we love all those modules, but they can be very confusing for regular members. I would never advocate getting rid of Wikidot's incredible functionality and flexibility, but by giving admins the ability to create form-based custom new page modules, we could bring a lot more people into the wikidot community and create more, better, fresher content.
I strongly agree with this proposal, plus it would be nice to have the possibility of adding tags for the page within the same form!
This is very new..: on Syntax Changes you will see that there were some changes on the NewPage Module - with paretning and Tags..
OK, This is not yet a form…
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
First off, I'd love to see something like this as well. I was actually searching for a way to do this, and came up with a template and live template solution, but the problem being is that it does get very confusing as to what is going on when some one wants to add a new page. Even I have to take a few seconds to see what it is exactly going on in my template. Even though I'm not seeing the bulk of the code that is actually in an include box. A form type thing would have actually saved me a LOT of work (and still can, considering how much info I need to add).
I know this isn't implemented yet, but if it does, I'd like to see the page not display any blank fields. I run… I guess you'd call it database type wiki's and some fields just aren't pertinent to my all pages. I find myself using 'open for interpretation' fields in my templates now, because if I refine it, and don't use it, its just an ugly box with 'unknown' in the field.
Try to follow this howto:set-up-an-infobox
This would be more useful to me than all the other wishes combined. As Spir said, unifying all the template-like things would also be nice.
FYI, we are planning to bring forms to Wikidot, but it will take some time. I hope to keep it very simple and yet powerful enough to build simple applications with.
Portfolio
Thanks for poking around the wishlist pieter! I realize these things take time, but it's a morale boost just knowing you're watching and working on some of the more complicated items.
Is so good to know that the developers are hearing our requests! Thank you for that!
For what it's worth, I use Wikidot every single day, and have done so for almost three years, for dozens of web projects of every type. So I know what it's like to think, "Wikidot could do that!" and then have to wait for unbearably long before that vision becomes real. My personal wishlist of "stuff I'd like" is so long and detailed it makes the developers feel kind of sick. :-)
The complex items are perhaps not essential to getting popularity, but they are essential IMO to making Wikidot something we'll all use for a long time to come.
It makes me particularly happy when I see others with the same ideas (and complaints) as me, and the work you've done on this community project is really important in defining how Wikidot will be in the future.
Please never hesitate to email me directly with your ideas and comments, at moc.xitami|hp#moc.xitami|hp. Of course, it's better to discuss in public, so I'm going to be starting a central blog aimed at provoking discussion and explaining what our plans with Wikidot are.
Portfolio
Sounds great!
It is indeed a morale boost, as David says. I've been designing my pages (using live templates) with the possibility of a future form feature in mind. I hope there'll be a way to map form fields to contents (i.e. field 1 > %%content{1}%%, etc.). Is that likely?
Eduardo R. Ribeiro
Macro-Jê linguistics, &c.
Let's discuss this on the blog when it's up…
Portfolio
Has there been any recent developments on the forms implementation? This is such a good idea I'm looking forward to being able to use it.
I think a design spec is being created, or it's nearly finished. As for being implemented, it hasn't reached that stage yet. Hopefully soon! :)
Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.
Have a look on the design blog and it's last comment!
http://blog.wikidot.com/wiki:design-forms
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
Even better! They're available, in an early beta form, now!
http://blog.wikidot.com/design:18
Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.
Has anyone tried to implement the form and _template on their sites? I'm struggling with it, and can't yet figure out the basics.
I've posted to the projects site, but I'm checking here too.
Yes, the only joking site and my site are both using data forms.
We should keep discussion to the projects forum as much as possible
Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.
I can hardly contain myself, I want this to be implemented with ListPages support sooo badly.