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.
**Movie title:**
Enter movie title here
**IMDB link**
Copy paste link here http://imdb.com/...
**Comments on the movie:**
Type here your comments and observations of the movie
**Movie rating**
[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.
Well our little community is one thing, but I see massive potential for Discourse in more visual templates. They would work wonders in:
Customer interface for standardized input, like error reports, feedback, requests.
Allow Discourse usage as a kind of a user driven database for anything, like the movies in my example.
Classified ads, as you also brought up.
@simon Why is WYSIWYG misleading? Now you see the markdown code and then get the visualized output. A more visual template would look pretty much the same as the end result.
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.
I understand the use case, but I honestly think this is asking a bit much from what Discourse is built to do.
Youâre dealing with structured data here, so what you really want is some kind of form interface like Google Forms or Airtable, or a purpose-built app for data entry.
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.
Person who wants to dictate every single bit of the formating on a category goes on and creates a Google Form with everything he needs. This forms saves to a Google Excel-thingy.
Discourse plugins poll the excel and adds new entries as a new topic on a configurable category. It applies a template using the sheet columns as variables on the template.
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
G
