Topic templates are a great feature of Discourse. The Markdown however, makes them visually non-appealing and even difficult to understand for a non-tech user.
Enter movie title here
Copy paste link here http://imdb.com/...
**Comments on the movie:**
Type here your comments and observations of the movie
[poll type=number min=0 max=10][/poll]
Here is an imaginary example for a movies community. It would be great if templates were like web forms, instead of showing the Markdown code. This would enable great use cases for making a structured topic opening post a whole lot easier.
@ljpp has a point. Topic templates aren’t very appealing visually. Even more, they are tough to use with mobile devices. All the erasing, copying and selecting and pasting tends to be too much work for users at our site.
The site is a fan forum for an ice hockey team, and three of the categories currently have topic templates. For instance we have topics for each match Tappara plays, and the opening post is supposed to have links to the web site of the league for line-ups and to Tappara’s site for match preview. It’s really painful a job to do with my phone while with my laptop it’s much more comfortable. A consequence is that sometimes when no staff members are online around noon when it’s the optimal time to create the topic, nobody bothers to do it. When somebody finally creates the topic in late afternoon, it usually gets plenty of posts in a short period of time which suggests that everybody has been eagerly waiting for somebody to do the boring job. The bad thing is that the match is already starting so there is no time for deeper discussion.
A somewhat different example is the marketplace category, where you can sell and give stuff: match tickets, fan merchandice or anything. The topic template doesn’t require any links or anything. It has just two things we want every first post to have: the price and the preferred method of delivery. It also has some guidelines for how the title should be which the user is supposed to erase. What regularly happens is that the user ignores the template, writes a few sentences below the template and sends the message. Really annoying! The protocol is that we send the user a PM in which we ask him to edit his post immidiately or the post will get deleted. I don’t enjoy sending those messages at all.
A long story but in a nutshell, topic templates have two problems: they are laborious to use as illustrated by the first example and they are visually unappealing as illustrated by the second example. They have great upsides, though, which is why they are worth improving. I think the new topic UI could be a form. It would have fields which could be mandatory to fill or not. A field would accept a number, a string or whatever admin wants. The form would have guidelines above the fields which tell you what you are supposed to type. When the user reaches the bottom, he presses the post button and a nicely formatted post is created. No erasing and no selecting the right position for the cursor so the labour is cut to a half. Also, no more ignoring topic templates so no more angry moderators.
My use case is a topic template for creating a bilingual dictionary. It works, but it’s very easy for the user to break it. It would be great if a topic template could be made out of web form elements. What would be even better would be if css classes could be added to the form elements. The WYSIWYG in the topic title is misleading.
Custom topic fields are a thing in the database already IIRC. Its always struck me as a useful thng to have for more structured topic types. I think I’d prefer to have each field as a separate DB entry, rather than having a UI for populating a regular post. It would ensure consistency and allow for easier integration with other features and plugins.
And you’d definitely want to define the available fields on a per-category basis, with cross-category linking for identically named fields (eg. “Director” field in the “animation” and “comedy” subcategories of “movie reviews”)
EDIT: You’d probably want data types too. Text, Yes/No, Bounded and Unbounded numbers. Maybe URL.
Lets say that you have community where one or more categories have templates, but not all of them. You need to take the user to the form, which is external to Discourse and back.
But yeah, my idea is pushing it if you think Discourse purely as a discussion platform. I for some reason tend to consider Discourse as a social interface. It is already so much better suited for that than any classic forum software, even with it’s limitations.
It’s something I think all forum software wrestles with. When the specification is narrow, the work is easy: “This is software for having discussions”
But when you start using that software to provide discussion space for a community that is actually about something other than just discussion then you find the scope starts to creep. When the community spends all its time in an online space talking about X, they’ll want to actually do some X in the same space.
And then you (as a developer) have not one but a multitude of design briefs, marching off into the distance, one for every customer. Some software bears the scars of trying to fulfill all those briefs. I can’t remember how many subsystems vbulletin has. I do remember drowning in config screens.
So you’ve got to pick your battles. You obviously can’t expect Discourse Core to replicate the functionality of other complex platforms, but I think it is worth talking about flexible generic tools. FWIW, I think this idea of multiple data fields per topic is one that would be flexible enough to fulfill many different uses.
I don’t see any point in bringing in a third party - after all my feature suggestion is not actually introducing new functionality. The templates are already there, have proven to be useful - my proposal is only concerning how they are rendered on screen.
How about a record of things posted via a topic template. I have a form via TT that users hit to report something that needs attention. A maintenance incident report if you will. Is there a way to collect them all in a db report? Sorry, new guy here