Visual (WYSIWYG) topic templates?


(ljpp) #1

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.


Replies with specified fields
(rizka) #2

@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. :slight_smile:


(Simon Cossar) #3

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.


(ljpp) #4

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_Cossar 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.


(Simon Cossar) #5

Sorry, I’m just nitpicking. It’s a great idea.


(Tom Newsom) #6

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.


(Erlend Sogge Heggen) #7

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.


(Rafael dos Santos Silva) #8

I agree a lot with this.

And making a bridge from Google Forms to Discourse Topic afterwards could be built as an general purpose plugin.


(ljpp) #9

Hm…how would that work?

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.


(Tom Newsom) #10

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.

Someone make a plugin pretty please? :smiley:


(Rafael dos Santos Silva) #11

RFC:

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.

Would this work?


(Tom Newsom) #12

Feels too fragile to me.

  1. It’s dependent on a 3rd party
  2. Once the topic is created, the structure disappears and can be edited into a mess by any passing moderator.

I think it’s only worth doing if it’s all in-house. Otherwise, you may as well go and use some dedicated software for the task.


(ljpp) #13

I have to agree with this.

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.


(Rafael dos Santos Silva) #14

This, actually, would be a mid to big sized feature, rendering an html form with validations from markdown. And a this may be a bit of feature creep.

It can be very useful, I agree. It’s the same stuff people claimed for on the Dear GitHub incident.

But it isn’t simple and core do text discussion on the internet.