議程表 description 跟講者 bio 支援 markdown

[bobchao]

For better styling/reading experience.

[david50407]

@bingluen fyi https://www.npmjs.com/package/@nuxtjs/markdownit support static/dynamic render

[bingluen]

Must consider Android and iOS app. To implement for support markdown on website, if both of them support markdown.

[bobchao]

Well, if there's something not supported on any of the platforms, we can make an unsupported-syntax list and prevent to use that specific syntax. (Or, we might still use it after all, just like what we did on the current website.)

[david50407]

How about given two variants of the content on API? One is for formatting string, and another is human-readable string (a.k.a. zero-syntax string). And if the renderer doesn't support markdown, just show the zero-syntax one. :)

[bingluen]

How about given two variants of the content on API? One is for formatting string, and another is human-readable string (a.k.a. zero-syntax string). And if the renderer doesn't support markdown, just show the zero-syntax one. :)

Two variants of the content on API is unreasonable.

First, It must be acknowledged that how the content of API is generated:

The volunteer about session fill in the information of program(i.e. description, speaker and etc. of program) on the google spreadsheet that we have defined sheets and columns for COSCUP 2019, then we use an script (Specificity for COSCUP 2019, written on node.js) to convert the spreadsheet to json file (i.e. format of API content).

The script to generator unusually use only once (i.e. just for one conferences).

So, there are two way to implement that more than one of the content on API:

1. Add an column which is markdown content for each field about the information of program into the google spreadsheet, then script just copy it.
2. Do NOT add any column into the google spreadsheet, but write on markdown format, then modify the script of convert(or call generator) to parsing markdown syntax and generate the zero-syntax string column.

To implement this idea, the cost to maintain the JSON generator (i.e. script) for API content or to maintain google spreadsheet will increase.

That's the first reason I think this idea is unreasonable.

Whatever which implementation be chosen, the app (i.e. OPass) of both mobile platform must support this API content change (a.k.a implementation of the class of data structure is flexible without modify code or just a little).

That's why I say:

Must consider Android and iOS app. To implement for support markdown on website, if both of them support markdown.

In my option, I can NOT recognize that modify or event refactor app source code of both or one of mobile platform on this time, if there is exists platform do not support markdown parsing or data structure is not flexible.

If both platform are support markdown parsing:

1. The script of convert do not need to be modified.
2. The volunteer just maintain information of program on markdown format on spreadsheet. (i.e. Avoid data inconsistencies)

Under the above premise, it is reasonable that to consider that allow using markdown syntax on information of program.

To support markdown, we also need to consider which features will be implemented on both mobile platform and website. As far as I know, the OPass app on iOS platform has implemented markdown parser, but one of the basic feature of markdown, to insert an image into content, is not supported case by the implementation that how to show image inside app. I guess this problem also occurs on Android.

@denny0223 and @Haraguroicha, can you share your experience about compatibility of markdown on iOS and Android ?

[yoyo930021]

Markdown has no problems on Android and iOS. @denny0223 and @Haraguroicha will add to app. So I add Markdown support on website.