or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
20180725 會議記錄
檢討「送出文章理由」
初衷
提案:20180110 https://hackmd.io/OsA3T197TYmye6INymxOGQ#Proposal-LINE-bot「詢問爭點」功能
討論:20180124 https://hackmd.io/s/SyivqlIrf#謠言回不完
數據
「減少送出」有顯著效果。
資料庫裡的所有送出文章理由
送出文章理由:
https://docs.google.com/spreadsheets/d/1v7H4QMBrHHX9S9dpi3Lkuz0s53fQCpPPekY47W80_q0/edit#gid=0
–> 亂輸入的機率過半!
好/瞎:
–> 有好好填的理由,編輯大多覺得有用
亂輸入時所送的資料
Log + 理由 (非公開,含個資)
https://docs.google.com/spreadsheets/d/1vvnPv6EWmfndWd1foHER-LBBcFmpB_2WOIiryW_yP9Y/edit#gid=0
1.所有手動輸入的理由都會放在這個篩選器
2.但你看這些理由是另一篇文章,他就不是手動
3.第二個是chat bot log
過去七天,使用者打了什麼state還有user id都會和其它對在一起,還有log的時間表,artical replied created
LINE BOT裡面查的訊息,從這邊看得到pattern,這些就是亂填的狀況呢,我最後有一個調查的column,最右邊下面的調查我去看訊息他的傳進來的時候,一定是停在輸入理由的state,使用者又直接輸出了。所以我在這裡寫說,原文停下來的地方是它傳一則訊息然後放置,他停在請填寫理由的state,然後又直接走了。再之後又傳一篇近來,他問你是這個理由嗎,文字很長他不看,他又直接送進來。可以看到他的天數可能是好幾天以前,或是兩分鐘前傳進來,不想填理由,又轉一篇進來。
orz:調查有東西的值大概是下面這一些。
但如果好好打的理由,大部分又其實還不錯。我們需要排除這種誤送的狀況。
Gore:
傳進來被當成理由,他看起來也沒有要查一次
使用者似乎沒有在看字。
桓:
一個 filter 的狀況是
大部分用手打的 不會有 new line
但不知道要怎麼處理手打的,但是又分成好幾行的那一種
文武:
問理由功能是不是要繼續放在 line bot 上
因為
Gore:
分辨是不是亂送的。
高達 6 成是亂送的,是不是證明了使用者心態上就是在亂送
文武:
素質吧,有按鈕就按
orz:LIF可以做一個使用者按下去就讓他有個表單的功能
我們在這裡寫一些按鈕,那就不用作重送confirm的動作
至少有這四成訊息編輯會比較有方向學習媒體識讀。
可以考慮一點是,不送的話是真的沒有價值還是。
有一種辦法是把理由變成選填。
gore:
我自己傳進來就是想知道,所以不會想到什麼理由。
桓:
但這還是不能解決轉傳訊息進來變成理由的問題
Orz:
嗯這是兩個分開的問題
Bil:
我希望有寫理由再送進來。
或者是如果有「我覺得這是謠言」「我覺得這不是謠言,需要澄清」的 sample
我會希望這個東西被傳進來是因為這是謠言有必要傳進來,而不是跟朋友分享的東西都被傳進來。
我們沒對理由做限制,但不要。
關乎公眾利益
Gore:
現在大家都是放棄
Bil:
如果是不想打字,那可以幫他打
桓:
放棄的是真的不想想,還是不想打字
文武:
就算有選項,可是他傳進來大部分都覺得是假的?
Bil:
但現在確實就是有「哇這個好美,俄羅斯舞曲有這麼驚人的表演」等等
文武:
但他們還是有可能還是覺得這是假的,然後送進來
Bil:
那我們就可以說這個人是在亂玩我們的系統,可以封鎖他。
確實現在沒有色情訊息了。
文武:
那我們可以直接把過去傳進來的人做封鎖就可以了?
Bil:
我們也有說亂寫理由要封鎖,可是還沒封鎖,嚇嚇大家。
Orz:
如果要做選項,
我們可以看看現在的理由裡面有沒有什麼可以用的
文武:
這不就跟我們直接做標籤給他是一樣的道理?
例如說「我覺得這是謠言」「只是玩玩」這種
Orz:
「謝謝您這麼誠實,訊息沒有送出。」
用 URL scheme 可以做到
按一個按鈕幫他填:我覺得…
文武:
因為做按鈕太方便
送出新文章
如果理由這邊要做「你真的要送出」
讓他自己輸入文字去跟 LINE bot 互動,就不會有文字都不看就送出的問題。
就是把「放棄送出理由」的門檻調高一點
Orz:
但如果他不會看字「請問您確定這個是理由」
那不管我們叫它做什麼,例如說回答 1+2 是什麼
他也會照著回答 3
Gore:
終於發現了一個使用者有嚐試第二次了!
感覺像是沒有傳達好,讓大家卡在那個狀態
所以這個人是真的有在看字,所以傳錯之後還會再傳一次。
文武:
也可以先放著看看誤傳率會不會下降
gore:
放棄的人可能也會變多
只是現在還沒有看到很惡意的人。
桓:
如果什麼都沒找到,那我們就會問他們要不要送出。
但如果是新手,他根本不會知道現在停在 submit 的狀態,他就會不管。
今天如果她送東西沒找到,我們一次送很多 message 給他
他不會再往上捲把東西看仔細一點
會不會是因為送的東西太多了?
Orz:
如果是字太多,我們也可以用 flex message
我在想如果這個成立,那我們或許可以在進入 free form text 輸入之前,先問他們「要不要輸入理由」,那沒有看字的人就會卡在這個步驟,若接下來傳進來的是很長的文字,我們就能確定這是新訊息。
只是我還是覺得,使用者可能會按下「好我要填理由」但又停這個 state,直到下一次把東西轉傳進來。
如果只是要解決誤傳,那 LIFF 可能比較合理。
而且如果做成 LIFF,那我們也可以在 LIFF 裡面給他預填的選項。
Orz:
我們其實是問使用者「為何您會覺得這是一則謠言」
是有問題的
Gore:
然後使用者就
「我不知道耶」
然後按 home 鍵
下一次就會又把東西傳成理由
放棄人生
做這個機制只有在擋嗎?
Orz:
其實是希望使用者反思,
而且我們真的很想知道理由
Gore:
所以如果有選項讓他不填,就會失去意義
文武:
(看手機螢幕)但在手機上看,「為何您會覺得這是一則謠言」藏在文字裡面,太不明顯了。
Gore:
他會以為這是規則,所以就不看
唯一的按鈕是「要放棄嗎」但他絕對不會按放棄
就停下來了
第一眼看真的有點抓不太到
文武:
而且「以下是您傳送的理由」會被推到螢幕上面看不到
只會看到最後的「確定送出」按鈕
他就按了。
Gore:
所以是 UX 的問題呀!!
Orz:
那感覺可以用 flex message 調整 wording 再看狀況
這比 LIFF 好多了
可以做成「這是您想送出的文章:(節錄 10 字)這是您的理由:(節錄 10 字)請問要送進資料庫嗎?」
文武:
他自己填的理由就在上面,應該不用復述?
Orz: Flex message 像這樣
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →Code: https://gist.github.com/MrOrz/8ff98577f64d7376302ae0be88041a26
Gore:
紅字可以短一點。只要這樣就好:
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →https://gist.github.com/MrOrz/4e8518b28742ec2e2c1e4b87ac759b55
「傳理由給我們」可以用 URL scheme 做
桓:
也可以按「傳理由」之後打開 LIFF app
Orz:
但 LIFF 要花比較多時間開發,如果傳 url 還是沒改善,最後大絕再用 LIFF
好好填的理由要花使用者多久時間
https://cofacts.g0v.tw/article/13798inzeluww
這篇花了 3 分鐘寫理由。
Cancel submit 時所送的資料
Log 40 則(非公開):
https://docs.google.com/document/d/1EKJa-CPKHzOokBxBhx0SqMQADHLurIgJk5QAzWQweT0/edit
討論解法
Consider LIFF when receiving "reason"?
sendMessage()
,chatbot 方面無法分辨是在 LIFF 裡輸入的,還是 LIFF 外輸入的。決定先按照上面的討論,改 flex message + url scheme 看看是否能改善。
By: 桓
OGP updates
NDI 想給錢讓Cofacts做facebook messenger的版本,有沒有人可以全職投入做呢?
桓誠:
可以~
Bil:
耶咿謝謝~~~我去跟阿端說
桓:時程?
Bil:
還在確認意願的階段,時間都還不確定。
對方有經費而且想做。
桓:
現在的目標是 line bot 複製到 messenger
但只有 1 個月
Bil:
我有分享 cofacts,法國與巴西都想做,所以會有一些「你們的開發者能不能飛過來」之類的想法。
Other dev items
Orz: 覺得可以最後加一句
做在使用者覺得回應「有用」的回覆。
https://github.com/cofacts/rumors-line-bot/issues/88
對外聯絡
Matters
1500 字(Lucien)
https://hackmd.io/e0b7VM2STlSNx8XpLVU9Yg
比鄰稍微加了一些歡迎補充更正
翻譯
合約進度
翻譯狀況
貼圖進度
送貼圖的標準:200/400/800
第一波想上的圖
按照之前的計畫:
https://hackmd.io/xgMy4PTaTyGzuMdmOUPMkA
第一批 8 個
這種貼圖的標題設為「真的假的」可以嗎?或是你們有特別指定的名稱?
可以可以
「貼圖說明」是否有可用的文案?
現在有了:
Cofacts真的假的 是一個開源專案。OPEN DATA、群眾協作,想要獲得查證結果就從自己開始努力。
鼓勵大家都能主動查證謠言,貢獻一己之力到公共領域,如果有人傳送可疑訊息給你,不妨試試用這個貼圖一秒回應他們呀!
看看SyndAvant把圖畫得這麼漂亮。
成為闢謠編輯就是現在:
https://cofacts.g0v.tw/articles
「創意人名稱」可否填「SyndAvant」?
可以可以
「版權」可否填「SyndAvant & 真的假的」?
可以可以
The Splice Newsroom
貼了小聚的照片給 @kirsten
Deutsche Welle Brasil
已經解釋採訪共筆運作。
對方已經發送共筆:
https://docs.google.com/document/d/1uelEPp3TkGjLYXjxpx5W5P7y78h9YWYaVVUt7s3CpGk/edit?ts=5b5869c7