[持續更新] 2016 OCF 官網 Redesign
專案資訊
目前 (2016/06) 狀況
http://ocf.tw/
- 現行的 OCF 官網是 pofeng 挑的版型 + acechen 跟 tka 在 g0v 前端松的練習作業 + singing 一年半以來 workaround patches 有機成長的結果
- 經常有使用者反應看完官網還是搞不懂 OCF 是什麼
- et 跟 singing 喊網站改版喊了很久,但一直沒時間好好弄
遇到的問題
業務類
- singing / ttcat: OCF 漸漸長大,對外曝光機會增加,跟企業募款或跟合作單位聯絡的時候,要一直重複解釋「OCF 是什麼」「OCF 跟 g0v 有什麼不一樣」「什麼是開放文化」(換句話說,目前沒有一套固定的說明文案)
- et / singing: 維護專案資料時,需手動重複修改多個頁面的內容,很麻煩
介面類
- 捐款頁的專案琳瑯滿目,使用者連到這裡後可能會不知道要捐給誰 http://ocf.tw/donate/
- 捐款連結連到 neticrm 後就回不來 https://ocf.neticrm.tw/civicrm/contribute/transact?reset=1&id=11&_ga=1.130424521.715222481.1473081200
- 「線上捐款」跟「協力社群成果」內容有點像又不太一樣,容易混淆
- 已結束的專案的屍體不知道該封存到哪去
技術類
- 首頁 image slider 沒有 responsive
期望的目標
業務類
- singing / ttcat: 希望官網可以發揮自我介紹的作用,網址丟給別人後就不用再解釋。然後不要出現無關的圖文內容
- et / cl / singing: 希望有自動化的 DRY 專案資料維護方式,讓內容可以無痛同步,合作社群送 PR 來只要修改一個地方就可以套用到多處。需要同步內容的頁面包括:
- 專案列表(ocf.tw) http://ocf.tw/donate/ , http://ocf.tw/partner/
- 專案介紹頁(ocf.tw),以國際交流為例: http://ocf.tw/donate/intl.html
- 專案捐款頁(neticrm),以國際交流為例: https://ocf.neticrm.tw/civicrm/contribute/transact?reset=1&id=11&_ga=1.130424521.715222481.1473081200
- bob / singing: 需要給合作社群一個固定的 banner 尺寸或是 template 讓他們出圖 -> 1200 x 630
- jimmy: 需要有讓人看起來就覺得娃好厲害喔的志工列表,例如 https://www.junyiacademy.org/about/volunteersIntro
介面類
- 專案介紹頁(ocf.tw)跟專案捐款頁(neticrm)在不同平台上,但希望識別可以一致
- 可以從專案捐款頁(neticrm)回到上一頁,看是從哪來就回到哪去(瀏覽器 back?)
- 專案列表可明確區分進行中專案(需要捐款或宣傳)跟已結案成果(需要展示成果)
- 需要有地方存放每年的年度成果報告(每年初會發佈去年整年的)
- 需要讓合作社群的 banner 可以在各種尺寸下正常呈現(可能作法:用一張左右很寬的圖,中間有一塊區域是一定會看得到的) -> semantic ui built in card image
行銷類
- 是否會每則 facebook pages 貼文都連到 OCF 官網?
- 不一定,過去有直接連到 hackpad 網址的例子
- 目前 facebook pages 不會花太多力氣刻意經營,只發表新聞或電子報內容,重要消息由各自相關的合作社群發出,OCF 自己則採轉發
- SEO ... (據說是使用 adwords 中)
風格類
- pofeng: 個人偏好黑金屬 style、黑底螢光綠字 terminal 風格
技術類
- 希望有 RWD,包括首頁的 image slider
- 瀏覽器相容性... -> 不管 ie
- 希望不要用太高科技的開發方式,將來 singing 方便維護 -> jekyll + semantic ui
參考
- 類似網站
- http://charitywater.org
- https://www.mysociety.org/
- 性質相似的組織有
- http://www.openfoundry.org/
專案啟動導火線
2015/03 ~
- ET 擔任 OCF 核心志工,負責會議紀錄,因此對 OCF 業務有了基本瞭解
- ET 製作野生官網給 singing 挑合適的部分抄去交作業 http://etblue.github.io/wild.ocf.tw/public/join
- singing 自己看 semantic ui 官方文件生出各種業務上需要的頁面
2016/06 ~
- ET 放長假,又剛好想學 UX,拿 ocf 官網改版來當 UX 練習作業
專案的範疇
需求分析
- OCF project list
- 資料收集 https://drive.google.com/open?id=0B0NsS2a-Qx8ZQ3VuekpkTFVqb2c
- 資料欄位設計 https://docs.google.com/spreadsheets/d/1bmVNKXOQfM_nHKFK2M1SI09z--sojpl1iw3JPtNqDUk/pubhtml?gid=569652953&single=true
- OCF business model
- 架構設計 https://drive.google.com/file/d/0B0NsS2a-Qx8ZZURIR0pjOXBUSkk/view?usp=sharing
- 製圖與完稿 https://drive.google.com/open?id=0B0NsS2a-Qx8ZYnRCa3NQaWhGNzg
網站企劃
- user journey map https://drive.google.com/open?id=0B0NsS2a-Qx8ZNWUyeWJkNjhnX00
user flow
user interface flow
- content list
- site map
- wireframes
網站內容
- OCF.tw 官網內容 2016 版
- sales kit
- 自我介紹
- 合作模式 & 過去案例
- 窗口聯絡方式(看完還是不懂的狀況)
網頁設計
網頁前端
- jekyll template setup
- jekyll page generator setup
驗收頁面清單
理想的時程
時程上有相依性的專案包括
- 2016 年底募款餐會
- 2016 年底 OGP 活動(需英文版網站)
- 2017 農曆年前釋出 2016 成果報告
因此絕對死線為
以此倒推專案的 milestones
- 8 月底前完成需求分析
- 9 月底前完成網站企劃
- 9/20 前 user journey
- 9/27 前 sitemap |
f2e research
- 10/4 前 wireframe |
f2e research 首頁內容文案
- 10 月底前完成網站文案設計
- 10/11 前 about 頁內容文案
- 10/18 前 people, projects, mediakit, news 頁內容文案
- 10/25 前 首頁 html 初稿
- 11/1 前 部分內頁 html 初稿
- 11 月底前要有一個可出門見人的版本
- 11/6 前 所有內頁 html 初稿
- 11/7 ~ 11/20 內容調整 + 英文版 html
團隊組成
工作方式
- 每週二到 OCF 辦公室 cowork
- 2016 / 09 ~ 12 月底週三晚上的工作會議跟 OCF Staff 報告進度
- 優先順序:死線前有東西可見人 > 練功效果 > 品質
主要利害關係人
OCF 董事們:pofeng, bob, clkao, jimmy, honki
OCF 工作人員們:singing, rock, ttcat, mglee
OCF 合作伙伴:各大社群 conf、國際開源相關 NPO、相關政府單位等
OCF 贊助商:新竹物流等
OCF 捐助人:三百壯士等
技術資料
hero 區塊 image slider
- http://kenwheeler.github.io/slick/
html meta tags
- https://gist.github.com/kevinSuttle/1997924
jekyll data files
- https://jekyllrb.com/docs/datafiles/
募款頁捐款金額人數自動更新
- "您可以使用募款頁的募款小工具(募款頁設定 ->募款小工具 ),募款小工具會提供程式碼讓您能將已募得金額和進度條等資訊嵌入網頁,操作說明可參考 https://neticrm.tw/resources/148 [1] 如果僅需要已募得金額的資訊,目前自動產生的程式碼無法直接移除 html 因為會造成 js 錯誤,只能用 css 將資訊隱藏。若您會使用 js,亦可從募款小工具的程式碼找出需要資料其對應的 jsondata 後將其印至網頁上"
TEMP
- et 跟 ocf staff 確認網址帶年份的作法是否能接受
p.s. gh pages 的 folder 可以沒有斜線
|
網址格式 |
命名問題 |
長度問題 |
檔案整理問題 |
原案 |
ocf.tw/projects/coscup |
專案名會污染全域, |
無 |
coscup 2015 跟 2016 檔案會打架 -> 解法:指向當年的 |
A 案 |
ocf.tw/projects/2016/cosucp |
跨年度專案網址會變 |
網址略長 |
無 |
B 案 |
ocf.tw/p/2016/coscup |
同 A 案 |
無 |
無 |
C 案 |
ocf.tw/p/coscup-2016 |
同 A 案 |
無 |
專案目錄會有等同專案數量的 items,時間久了會變很多 |
(update: 最後採用 B 案)
pages
- level 1 pages
- home
- about
- people
- projects
- mediakit
- news
- 404
- 原 donate/ 下的
- admin
- intl
- movie
- otspace
- sysprogram
- g0vdathon
- osln
- 原 events/ 下的
- camp -> redirect 到官網
- jcconf2015
- makerconf
content
- 補資料:各專案 achievements
- pofeng 跟 et 確認志工名單
- pofeng 跟 et 確認網站上 sponsors 如何依照專案區分
- et 追蹤 pofeng 跟 aaron 協作文案情況(注意字數!)
- et 確認 CC 作品在 html 內的 citation 表現方式
partners logo: orgs 有敘述的話可以考慮放在 popup
f2e
- 成果報告頁在 ios 的 max height 問題
- windows 下的字體問題
- check all sample yml / html
- 404: redirect all /projects/ pages
- icon 正方小型去背
- avatar 正方
- logo 適合放在 logo 牆,橫式,但不太狹長
- cover 適合放 hero 區塊,橫式,接近 og_image 比例的
- banner 適合放側邊欄,直式,接近 x 展架比例
visual
- et 測試 300 壯士 bg image
- 300 壯士光明燈
- 收 rplus 的 f2e patch 調整 object-fit css
- 其他想加 / 想研究的
- jekyll site map https://github.com/jekyll/jekyll-sitemap
- mentions https://help.github.com/articles/mentions-on-github-pages/
- seo tag https://github.com/jekyll/jekyll-seo-tag#usage
- 新竹碼農 logo
- 專案頁 / 活動頁 建議規則
- 建議:沒事不要建頁面,除了 ocf 自己的專案 or 需要放 adwords 的之外,這樣 .yml 裡面的很多欄位資料可省略 www
2017/04/12 上線前微調松
今天開完會要跟 jimmy 報告上線時間
donate 不夠明顯,來到網站想捐款的人,好像會找不到方向
jimmy: 如果這一頁是作為跟社群合作的平台,要想一下怎麼特別 promote
他們的活動,或者是他們有自己的管道?
et: 宣傳好像都直接貼專業的網址,會來逛這一頁可能是會想了解 ocf 大概在幹嘛的人,這一頁的 call to action 只有 300 壯士。不知道跟現實狀況是不是吻合。
jimmy: 希望將來每個專案都有自己的頁面
結論:
- 專案頁長度問題:
- 目前先縮短文案跟 tag 數量
- 未來如果專案多,可以考慮改變列表形式,變成一頁可以看到四個專案(semantic ui items)
- 未來如果專案再更多,可以考慮分類變成 tab
- 專案頁排序問題:
- 如果要用專案 promote 基金會,則有名的擺在前面
- 如果是 ocf 很大了可以反過來 promote 專案,則需要推廣的擺在前面
- 專案獨立頁面
- 未來 eventually 每個專案都會有,也是為了 adwords
- 但目前上線可以先做部分,再慢慢補齊
- 優先順序:有給預算表的先做,sg 去威脅專案主沒有預算表就沒有專案頁(X
- 時間:
yml 編輯常見問題:
- 半形冒號會造成 yml 秀斗,資料內容用引號刮起來,避開文案內的半形冒號
- ocf.yml 英文版 description / 地址 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/people/orgs/ocf.yml#L11
- ET 先把列表上的捐款按鈕功能做好,等將來打開
- 在 LY, rplus, othree 指導下修正 object-fit 跟 img
- singing OT 新版捐款頁
- Rock Gcoin 新版捐款頁
- huangfu 確認蝦蝦的資料有沒有要更新上去
2017/02/07 成果網頁松
日期:2017/02/07
時間:12:30 - 18:00
地點:OCF 辦公室
與會:singing, rock, ttcat, huanfu, et
ET’s notes
- 解法 https://github.com/ocftw/beta.ocf.tw/commit/8c9257806b7b6a2b10228689d9b1091ec5fa949f
- yml 寫法 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/reports/_yyyy.yml#L116
- yml 寫法 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/reports/_yyyy.yml#L54
- 英文版網頁預覽 http://beta.ocf.tw/en/p/2016/
- 對應的 yml 檔案 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/reports/2016_en.yml
- 把原本的 url 先註解起來,寫上舊版網址,將來正式換網址時再把註解的部分恢復即可
- 範例 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/projects/2016/admin.yml#L13
- 安裝 local dev env for huanfu
- github for windows
- ruby
- jekyll
- jekyll redirect from
- 步驟
- 把原本要內嵌的網頁整個抓下來,分別存到網站資料夾內,目前位置是在 `/p/2016/` 底下的 `income.html` , `outcome.html` , `projects.html`
- 編輯抓下來的網頁,把 <body> 底下的第一個 <div> 加上 css 語法 `margin: 0 auto;`
- 編輯成果報告頁 yml 檔案,把內嵌網址改成我們編輯過的 html 檔案的網址
- 範例 https://github.com/ocftw/beta.ocf.tw/commit/841e9daae06985b169963542d9789a57974f38e1
- 不過那個圖表內的資料就不會自動更新了,每次改 gsheet 就要重新抓一次 html 檔案然後重新加一次 css
2017/01/23 成果報告網頁編輯會議
與會:singing, rock, huangfu, et
時間:14:00 - 15:20
地點:google hangout
討論事項
目前狀況
- 2016 成果報告的內容,要同時放到網頁跟 DM
- 目前 staff 正在使用 google doc 撰寫內容草稿
- 2/6 staff 會收到燕子的 DM 設計 ai 檔,然後把圖文填入
結論
- 成果報告網頁上線時間訂為 2017/02/10
- 訂在這個日期是為了讓網址可與印刷完成的 DM 同時寄出
相關連結
- 網頁:http://beta.ocf.tw/p/2016/
- 資料編輯:https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/reports/2016.yml
- 範例:https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/reports/_yyyy.yml
- 專案資料:https://github.com/ocftw/beta.ocf.tw/tree/gh-pages/_data/projects/2016
- 編輯步驟:https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/README.md
本次作業
ET
:ok: 專案名稱顯示全名
:ok: 支援內嵌 iframe
:ok: 導覽列連結指向舊官網
:ok: 示範新增標題 a. 政策倡議 b. 由衷感謝(sponsors, staff 可放這區)
singing, huangfu, rock
下次會議
日期:2017/02/07
時間:12:30 - 18:00
地點:OCF 辦公室(據說會有炸雞)
與會:同這次
預定內容:大家一起編輯成果報告頁同時鞭打 code 沒寫好的 et
2016/12/28 網站交接會議 part 2
與會:jimmy, et
時間:15:30
地點:google hangout
討論事項(上次會議結論)
1. template改善 - 專案頁左欄放純 html (現已可行)
2. image 目錄遷移,得討論是否要不要全部丟到同一個目錄(github直接上傳方便)
3. layout 拆散 - redirect / global 等一些 layout 看怎麼變單純
- 拆完 redirect 惹 https://github.com/ocftw/beta.ocf.tw/commit/d32cf7012f59008b102b0b925cdc2b8bbc56ce35
jm:
- global 裡面可以拆成 include & 底下 css 可以代變數一行解決 https://github.com/ocftw/beta.ocf.tw/commit/3de24c3f75766038983fc7d99acbf12101f8c7ae
- 架空 _layouts/page.html https://github.com/ocftw/beta.ocf.tw/commit/36288fad5967fd9777fef6d139269502a1e47991
jekyll redirect
pf: meta refresh 跟 window.location 都會掉 SEO,只有 jekyll 的 gem 不會掉。
結論
- 站外跳板:meta refresh
- 站內跳板:jekyll redirect
- beta 站裝 jekyll redirect 的 gem https://github.com/ocftw/beta.ocf.tw/commit/8cb6c857363af4b5f365e48a6c692d4f4914871b
2016/12/14 網站交接會議
與會: jimmy, pofeng, ttcat, et
時間:3pm
地點:google hangout
前置作業
et
會議紀錄
jm: 可以用但要討論 fallback 機制
業界的作法:
- 做後台
- 程式方面也會評估 e.g. 接手的人會不會 php linux 等
- 最前面挑選廠商或軟體前就是第一個門檻
我們的專案:
pf: 擔心後面無法接,想慢慢改。當初放 github 是希望不要有 administrator,因為 php 還要維護,所以一開始網站一定是靜態的。但靜態的改起來很累,所以要用 template engine,因為 gh 是用 jekyll 所以就用 jk。et 用很多方法去半自動化,但後面的人應該無法接手 & 改。如果不是很複雜的 template 我寧可兩份資料兩邊的人去改,對工程師來說很髒,但對兩個不同人以後維護比較輕鬆。比方說 osln 怎麼改都不會影響到 otspace。現在完全自動化之後,捐款進度條如果完全自動化,會擔心我改了以後會改到其他人的方法。jk 會生成兩個 template,一個是有進度條,一個沒有。et 寫得超級自動,連轉址也合併,所以想先把轉址拆出來。jm 的講法,不一口氣轉過去大家會懶得遷移,我沒辦法把 tp 拆開。
jm: 我覺得維護不是問題,有問題是新功能
pf: 就是新功能,比方說捐款不要進度條,那個人要新的東西,他會不知道怎麼拆 template 出來。
jm: 我有回 et 說我傾向有 fallback 機制,雖然現在用的是半自動系統但有辦法讓人家寫一下連到靜態頁面就 fallback 到純靜態頁面。舉例,今天有個專案很特別不想套模版...
pf: 那就自己編一個 html 就好啦
jm: 現在的作法比較容易維護,專案越多,後面是 html 蠻雜的,感覺這樣做對更多人參與有幫助
pf: 那我們就要換過去了嗎?還是怎樣?原來的 repo 變成 archive.ocf.tw?
jm: 換過去前先討論 fallback 機制的話未來遇到情況就可以... 我傾向換過去。
pf: fallback 機制只要把 template 換掉...
jm: 關於我們那邊比較 ok,因為就是 html,比較大的是工作夥伴跟專案成果
pf: 對新人來講沒那麼好維護,資料分散,image 要放在 image 目錄,id 要放 id 檔案,全新的人沒好維護,但講好了會習慣。image 可以改一下因為不直覺,無法放 data 裡面
jm: 工作夥伴可以照舊,計畫需要有... 可以換一個連結
pf: 希望怎麼設計舉個例子?換個 html 就可以取代,你希望怎麼換?用 jekyll tp 換嗎?
jm: 像是 ot 介紹,要連到一個 beta.ocf.tw/anotherproject 這可以直接從現在的去設,設了之後那頁怎麼做不管他
et: 手寫 yml
pf: 我無法 supervise migrate 會遇到問題去教大家,所以一直沒動,有人願意交接的話沒問題,take over 我很高興,換過去以後我還是會把功能一個一個抽出來,但 supervisor 不一定要同意我做。如果我當 supervisor 的話我會放到很後面。
jm: 可以接受往後延,但對 refirect 遇到問題不確定
pf: 沒問題,只是我不喜歡連 redirect 都去呼叫一個最長的 tp。
tt: 我都沒什麼問題欸
pf: 誰願意 take over 升級這東西
et: 內容...
jm: 需要有基金會的人松個一個早上或下午
tt: 要先確認內容。每個專案網址都可以設定?
et: 可以
jm: review 內容的時候一起改
pf: (分享螢幕)比如說要解釋 redirect,又呼叫 global,雖然參數可以共用,要教人家的時候一個功能要教四個檔案,應該要回到 jekyll 原始精神,一個功能一個 template。et 的作法是一個網站架構,沒有一個人去維護這架構。我願意改,如果有 supervisor 來不用也沒關係,至少我對這網站要懂,未來改得亂七八糟我還是要可以改我自己要用的。yml data 一定要歸在 data 目錄,image 要一個目錄、data 要到 yml、改 style 要在 html,注意力會很分散,無法在一個地方。因為跨專案參數太多所以引入很多東西,交接給別人比較困難
jm: 會喪失一些編輯 html 的彈性
pf: 我無法跟他說「你動這兩個就好,其他不要動」... 我也沒有一定要這樣,重點是,誰願意花這時間去 supervise。卡在人力。或者直接問 singing 跟 rock 跟阿端,因為他們是實際維護的人。
tt: 對我來說不是很困難啦,還是看其他人在改的時候會不會有問題。
pf: 大家都沒問題的話還是要有一個人來做
tt: 一個人是辦公室的人嗎?
pf: 不一定,不是 et 就好,妳要吃下來嗎
tt: 我不能答應
pf: 我也不想答應
jm: 分幾個階段,第一階段我跟 et workout 讓架構更友善,教學我就比較無法。
pf: 我們繼續討論架構,我把我喜歡的 style 寫一下,但我盡量不依賴程式,我先寫出來,yml 我就等 1/15 成果報告結束後大家比較閒再跟 s r 更新資料
jm: yml 做資料維護應該不太需要動,還是不要有 yml?
pf: 我覺得可以,但是用得太兇了
jm: 如果方向上是這樣,這種 metadata 用 yml... 這裡面整包,進去裡面的東西要有彈性。左邊彈性,右邊一致。工作夥伴用 yml 也 ok 因為少少的。
pf: 最重要優先的:更新資料,然後跨專案的表現以外資料放在檔頭
jm: 第三個會想動的是 image 目錄,需要再研究一下
pf: 有沒有辦法一頁的資料相關的 yml html image 都集中?
et: yml 以外都可以
pf: github 上有支援 symbolic link 就可以,我以前在 local 都用這方是整理
jm: image 下面分專案目錄?
pf: 我也覺得年份是不需要
et: (解釋年份用途)
pf: 可以讓 sg 跟 rock 先學年度成果報告怎麼寫,那可以提前做,練習看看
pf: compress 壓縮 html 用的,可以先拿掉
jm: 現在大多用 f12,我也覺得不需要 compress 還好
jm: 先做 report 的時候來看誰之後要來處理 migrate 可嗎
pf: f12 錯誤訊息在哪?
et: jekyll 訊息要在 local server
tt: 對我來說太多新東西... 上線的想法?我可以 supervise 內容,現在所有的內容、圖片、文字
pf: 蠻累的,大家一起幫忙。內容好了搬家過去搞不好不會不好改
tt: afi 跟 mg 沒有 html 編輯經驗
pf: 希望直接在 gh 改,直接 gh 上傳圖片
jm: (發現自己沒有 push 權限)
結論:github repo 不要 rename,直接 domain 去切就好
pf: 第三版要取 mutant!不准改了
會議結論
分工
- 用成果報告測試用起來有沒有困難,這件事情誰要? -> pf,就放 beta 不用搬家,提早練習 yml
- image 目錄等架構更動 -> jm + et
- template改善 - 專案頁左欄放純 html (現已可行)
- image 目錄遷移,得討論是否要不要全部丟到同一個目錄(github直接上傳方便)
- layout 拆散 - redirect / global 等一些 layout 看怎麼變單純
- 上線前文案跟內容 review -> ttcat
上線方式
其他
- 下一版網站的 repo 名稱是 mutant.ocf.tw
TODOS
2016/11/28 ~
:ok: 接上 neticrm 捐款進度 api , e.g.
- http://beta.ocf.tw/p/2016/otspace/
- http://beta.ocf.tw/p/intl/
- http://beta.ocf.tw/p/2016/sysprogram/
:ok: 專案頁校對工具 http://beta.ocf.tw/design/actions/
:ok: 設定長期專案頁,以無年份的網址為主,不會 redirect 到有年份的去 e.g.
- http://beta.ocf.tw/p/intl/
- http://beta.ocf.tw/p/movie/
- http://beta.ocf.tw/p/admin/
- http://beta.ocf.tw/p/g0vdathon/
- http://beta.ocf.tw/news/ reversed
- 補 sample 內的註解
- 補完文件:如何跨年
- ER diagram -> sitemap - data / sitemap - content relationship diagram
- http://beta.ocf.tw/design/data/
- http://beta.ocf.tw/design/content/
- design guideline
- http://beta.ocf.tw/design/ui/
- folders
- 首頁 what we do 改連到歷年成果
- 核對原 partner 頁
- 專案 new 表單
- http://beta.ocf.tw/p/new/
成果報告支援 event_id -> 算了 XD
- fix project page navbar highlight
11/30 晚上工作會議報告事項
- 目前進度
- html 本身都好了,但網站內容... www http://beta.ocf.tw/
- 維護的文件 https://github.com/ocftw/beta.ocf.tw
- 外界沒事不會連到的頁面
- http://beta.ocf.tw/backend/
- http://beta.ocf.tw/design/
- 可能要先確認的內容
- 據說是 12 月初要用的英文版 http://beta.ocf.tw/en/
- 第二優先要確認的內容
- http://beta.ocf.tw/about/ 一堆假文
- http://beta.ocf.tw/mediakit/ 下載檔是假的、文案是草稿狀態
- http://beta.ocf.tw/projects/ 若干專案資料待補
- http://beta.ocf.tw/news/ 今年度的電子報待補
- 成果頁
- singing: 提醒大家成果報告也要有個網頁!
- http://beta.ocf.tw/p/2016/
- 資料來源 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/_data/reports/2016.yml
- 交接?
- Pofeng: 現在的code滿複雜的,擔心交接的問題
- TODO: jimmy: 我來call個會議找pofeng&clkao來討論一下 (clkao: 好)
- ttcat: 先前 office 有拉到年底的工作時間,當時我有承諾paris回來後,可以協助成果報告的網頁。Jimmy會議可以找我。
- etblue: 不要擔心改東西,我第一次弄,可以儘量改。
2016/11/21~
:ok: 製作驗收文件:新舊網站 url 對照表
- 規劃版 https://docs.google.com/spreadsheets/d/11sW-RvCIx0jtSyLvXD4wJvrTqeB3XJ7xNYWrf7r1qBg/edit?usp=sharing
- 確認版 http://beta.ocf.tw/design/redirect/
:ok: 製作驗收文件:全站 metadata 清單 http://beta.ocf.tw/design/meta/
:ok: 製作暫時性 404 頁 http://beta.ocf.tw/404
:ok: 影展專案頁 http://beta.ocf.tw/projects/2016/movie/
- 文件:盡量 link 就好,註解在 code 裡面
- project 最好不要有年份 -> pofeng 接手後會自己改改看
- 開小房間給自己人 http://ocf.tw/activities/ -> /b (backend) 編輯連結放最上方
- events data 直接寫在同一 proj yml 內,目標:同一專案維護同一檔案
- 盡量同一專案工作區同一地方
優先 TODOs
- 改到 beta repo 開發
- 英文版頁面
- proj page staff 先註解掉
- 拿掉 proj 外部 redirect(for google adwords)
次優先 TODOs
- project header image /og image fall back 機制
- proj achievements optional (可塞 hackpad)
- orgs / individuals / projects 資料切開,events 資料合併
11/23 Wed. 3pm 第一次驗收會議
- 進度報告
- 因為 github pages 不支援的關係,使用到 jekyll plugin 的部分(markdown 語法)已全面移除
- 所有跳板頁面製作完成,詳新舊網站 url 對照表。目前原則:
- 專案本身有做漂亮官網的,會直接導向他們自己的官網,ocf 這邊的頁面只放 og data
- 專案本身沒有漂亮官網的,就幫他們在 ocf 站內做一個單獨 project page
- 確定會長期進行的專案在 projects 根目錄放跳板,自動指向當年度的專案頁
- yml data 結構設計完成,全站總共有 6 種類型的資料
- people
- projects
- events
- reports
- news
- in_news
- 所有 templates 設計完成,全站總共有 6 種樣版
- homepage
- level 1 pages
- project
- event
- report
- redirect
- 專案頁面:剩 5 個還沒做完
- osln
- sotm2015
- makerconf
- gcoin
- umaker
- 活動頁面:剩 1 個還沒做完
- 英文版:沒進度 www
- 規格確認
- 12/1 第一階段上線時,哪幾個頁面要有英文版? -> about , header footer zh
- 英文版網址都放在 /en/ 底下可嗎? one pager
- 現在所有合作夥伴的 data 都混在同一個檔案,為了方便將來收 PR 是不是切開比較好?我自己是有點想切開
- 12/1 正式上線前
- 分工
- 英文版頁面文字 -> 先把 hackpad 複製過來
- 英文版頁面 html / ET
- 時程
- 11/25 Fri. 前 html 完成
- 11/28 Mon. 前英文文案套版完成
- deploy
- 舊網站 -> archive.ocf.tw
- 新網站 (beta.ocf.tw) -> ocf.tw
- 12/1 正式上線後
- 若要開發新功能,一樣在 development branch 作業,將 beta.ocf.tw 當作 staging site,測試完才 deploy 到正式站
心得
- 全站 metadata 清單
- 原本想用 jekyll 內建的功能以 server side rendering 產生,結果遇到跟之前做 redirect 頁面時一樣的問題,就是變數只能往內傳,無法往外傳,因此 page 可以吃 layout 的變數,但外面要吃 page 內的變數則不行。所以如果想要把每個 page 內部算出來的 go_title og_image og_description 等變數往外傳出,列在另一個網頁上的話... 無理 de su
- 最後解法:用 jquery ajax 暴力 get 所有頁面 =w=
- 聽接手的人 (pofeng) 意見才發現維護者也有 ux 問題,盡量讓「同一個人做同一件事情在同一個地方」是最好的,因此又稍微調整了架構
2016/11/14~
:ok: about 頁 http://beta.ocf.tw/about/
:ok: 確認 jekyll plugin 在 github pages 上... 不支援 QQ 之後正式上線要把 markdown 功能拿掉,哭哭
:ok: 又改了資料結構(遠目)events 大表化
:ok: 確認 projects 跟 events 的定義:前者有獨立的成案過程,後者沒有。兩者都可以是成果列表的 item
:ok: 完成 event page template http://beta.ocf.tw/projects/2015/intl/dalc/ , http://beta.ocf.tw/projects/2015/intl/socp/
:ok: 更新 project page template,移除 jekyll plugin dependency
- 以後要寫 markdown 的話就用 hackmd 寫然後複製 hackmd 轉出來的 html 吧 QQ
:ok: 收子龍跟 neko 的 design patch 調整了
- project 頁右側邊欄的清單樣式
- 全站的 line-height(從 semantic ui 內建的 1.4xxx 改到 1.7)
:ok: mediakit page survey + proto
:ok: normalize menus
:ok: normalize og data
心得
- about 頁的 toc 超難產,足足花了一整天。。。
- 業務範圍規模差太多的組織的 about 比較難參考:業務比我們廣很多的組織 about 會很複雜,且 about 跟 faq 可能會獨立分開,業務比我們窄很多的組織 about 則會很簡略。最後選了 givewell 來模仿,about 跟 faq 合併。
- 合併下的 about 標題不能像一般 faq 那樣隨便擺,必須有前後連貫性,因此在問題順序的安排上也花了點腦筋,最好前一題的答案裡面正好有後一題的問題內的關鍵字。
- 有趣的是,原本寫 about 時很可能會當作標題的東西如「組織章程」,在問題導向的 faq 式作文下絕對不會變成標題,畢竟沒有人會想問「你們的組織章程長什麼樣子?」... 所以這些枯燥的「重點」就變成某題 faq 底下的隨附連結了。故事告訴我們問題導向學習對教育界的重要性(?)
- 整理原官網的 events/ 頁面後發現... achievements 又要改架構惹 QQ 應該是跟 people 一樣,所有 events 在同一張表,然後各專案用 id list 去存取才對
- 第一版架構是用 a 專案的成就列表可以呼叫 b 專案的成就列表中的特定項目,結果為此把所有列表都從 array 改成 hash。。。但是 hash key 大部分情況下是用不到的,形同虛設
- 遭遇到 schema 一直修改導致欄位不一致的問題
- survey 了 json / yml gui editors 大多是「避免麻瓜打錯字」用的,不是大量修改資料用的,理論上用試算表最理想,到巢狀的部分又無法在試算表中處理...
- 結論:寫一個 sample yml 規範完整格式和必填的欄位,裡面資料用不到的部分就直接缺欄吧反正對 jekyll 來說,資料是空的話有沒有缺欄位結果是沒差別的 www
- 名詞定義懶人包 http://www.slideshare.net/socialwriter/understanding-media-kits-press-kits-brand-kits-and-the-one-sheet
- media kit -> 記者寫報導時可以使用的素材
- press kit -> 也是記者寫報導時可以使用的素材,但內容 focus 在當次記者會 / 活動要強調的事情
- eletrictronic press kit -> press kit 的電子版 www
- brand kit (學名 identity kit)-> 告訴別人拿 vi 去用的時候要怎麼處理,避免破壞品牌識別
- one sheet -> 一頁式 media kit / press kit / e press kit,給沒耐心的讀者 www
- 給 NPO 的策略教學文 http://help4nonprofits.com/NP_Bd_MissionVisionValues_Art.htm
- vision:未來怎樣的話我們就算成功
- mission:做什麼來達成那個未來
- value:做的過程中有哪些原則
2016/11/7~
:ok: project 頁 template
:ok: project: 行政中心 http://beta.ocf.tw/projects/2016/admin/ (合併原 activities)
:ok: project: 國際交流 http://beta.ocf.tw/projects/2016/intl/
:ok: project: g0v 大松 http://beta.ocf.tw/projects/2016/g0vdathon/
:ok: project: jserv http://beta.ocf.tw/projects/2016/sysprogram/
:ok: project: otspace http://beta.ocf.tw/projects/2016/otspace/
:ok: news 頁 http://beta.ocf.tw/news/
:ok: rock 提供 givawell 的首頁供參考,發現之前規劃網站內容時完全漏掉 in the news(!)於是要預留 in the news 區塊在 news about 頁跟首頁
- 內頁
- news 頁:考慮放在過往電子報上方 -> 這頁的 TA 原本是圈內人,不是大眾,TA 不同好像不適合放在一起
- mediakit 頁:這頁的 TA 是媒體人,也不是大眾,TA 不同好像也不適合放在一起...
- 意外發現當初 ux 文件裡面忘記把媒體放進去 www
- rock 給的參考網站是放在 about 底下 http://www.givewell.org/about/what-others-are-saying
- 結論:放在 about
- 首頁:插在 what they say 下方
:ok: 想出了一個折衷的網址方案:長期專案擁有不帶年份的網址當作跳板,跳板會導向當年的年份,一般專案則繼續用年份分 scope。此方案還要 email 跟 staff 確認。
- 在整理專案資料的地獄中偶得的靈感,後來覺得越想越合理,兼顧網址永久性跟 name scope 專一性,不同性質的專案可以有不同的對待方式,過期的網址也不會消失
筆記
- news 頁面做出來以後突然覺得好像可以放在顯眼一點的地方(?
- 後來想想 TA 跟操作意圖的問題... 還是放在 footer 跟訂閱一起比較對,不要輕易打破自己的 ux report XD
- 整理專案資料超吐血,以後聽到人家講 open data 我第一個問題一定要問「所以是誰要負責整理 data?」 www
- 整理到 achievements 的時候,開始對資料庫正規化有所領悟,終於知道為什麼 gw2 的 api 要那樣設計了。
- 問題:同一個 ipa,有時候是 volunteer 有時候是 coordinator,原本把 ipa 的資料寫在 volunteer 裡面,結果在另一個 ipa 是 coordinator 的專案裡,資料就必須複製到 coordinator 的檔案中,不然就是 jekyll 呼叫 data 的地方程式必須出現額外的判斷式...
- 最後把所有法人跟個人的資料本體放在兩張大表裡面(只要欄位相同,就是同一張表),其他都只存 id... 改架構好抖 www
2016/10/31~
:ok: 完成 projects 頁面的 filter... 感謝 tka 幫除蟲 www
:ok: 既然分了 tag 要在 project 框框內標註,像是 coscup 議程表
:ok: 完成 reports 頁面 yml 結構與 template http://beta.ocf.tw/projects/2016/
:ok: rock 提供 charity navigator 的大事紀供電子報頁面排版參考,可依年份折疊(後來因為電子報份數太少沒折疊...)
et 要問 poga 的問題
- projects 網址命名規則
- 業主需求:網址盡量短,e.g. /projects/intl/
- 短網址的問題:
- 會造成的現象是,同樣是 /projects/xxx,有的專案是當期的,有的專案是過期的
- 每個專案 id 命名時都必須考慮全域的影響,一次性專案也會永久佔據網址
- 目前作法:
- poga 見解:一般做這樣是因為...
- 一般人沒在看網址(子龍:對)
- 網址主要是為了 seo,要短的話可以把 projects 砍成 p,既然不是 api 也沒有要顧 seo 就沒差,像是萌典網址也是 a/ 啥的,網址是給內行人看的。萌典加個 ` 就是台語。萌典 api 是單個英文字母。
- 命名統一就好,目前沒有 best practice,但有 - 比較安全,以免 project name 本身帶有數字的情況
- 何時用 - 跟 _ 也是爽就好,以游標跳字方式來說 _ 是屬於同一個字... 同時有 _ 跟 - 很醜 www
- 結論:
- ocf.tw/p/intl-2016/
- ocf.tw/p/coscup-2016/
- ocf.tw/p/sitconcamp-2016/
- ocf.tw/p/2016/
- projects 圖檔跟 html 檔整理方式
- A 案:一起放 /p/project_id/ 資料夾內
- B 案:所有 html 放在 /p/ 底下
- 利用 404 parse 網址,導向正確的頁面,樣只要放一個地方
- 結論:先不要管 404 的問題,先做出來,有需要的話再導過去就好
- update: 結果發現 github pages 會自動把沒有 / 的導向有 / 的,問題解決 O_O
- 有可能在 jekyll 的 yaml front matter 裡面插入變數嗎?目前看來是不行 www
- 需求:已經分享出去的舊網址,轉址之外,希望保留 og 資訊,讓分享出去的舊網址仍能正確地在 social media 內顯示預覽
- 確定不行在 front matter 裡面寫 jekyll 變數,要寫在內文
- A 案:反正是舊的專案,只會寫入一次,就直接 html 進去
- B 案:開個 ruby script 然後把資料集中整理在一個 yml 裡面
- 兩案花的時間差不多,poga 會選 A,成為老鳥的過程就是適當地放棄 DRY。。。
- 結論:ET 先整理資料,反正不管怎樣都要整理資料
- 萬一想不開要寫 rb 的話:
- require ’yaml’
- require ’erb’
- YAML.load(’xxx.yaml’).eachKey do |path, data|
- erb.load(path.template).compile(data).write(path)
- end
- 11/03 update: 發現不只是 legacy 的 project 獨立頁面,新的頁面也會遇到一樣問題,凡是有從某列表點進去的獨立頁面,就會有「同一份 metadata 要用在列表中,也要用在獨立頁面的 head 標籤內,導致現行架構下的 yml front matter 要複製 data files 內容」的狀況。全部盤點一番後發現有這需求的其實也就兩種頁面
- 嘗試在 page 裡面從 yml front matter 的資料 assign variable 套用到 layout 的 head 標籤中,結果失敗。內層變數無法往外層傳遞。
- 最後 solution:在 layouts 裡面寫 if else 判斷式,在不同情境下各自以不同方式利用 page 內的資料 assign 變數
- 在 console 裡叫出 js 全域變數... 不是直接打就好嗎 QQ
- 結果發現包在 document.ready 裡面的不是全域 zzz
- 喔喔喔喔對吼 wwwww
- it works on my machine... ROCK.JPG
- mac 忽略大小寫所以改檔名大小寫不會進去 git 裡面
- 但 github 會分大小寫 so...
- mac 下檔名全部轉小寫
- http://stackoverflow.com/questions/7787029/how-do-i-rename-all-files-to-lowercase
- 為了在 project list 內插入 tag 的中文名稱而產生 yml 到底要用 hash 還是 array 的問題
- 技術上 ok,在 jekyll 內 hash 也可以輕鬆地 iterate:
- http://stackoverflow.com/questions/8206869/iterate-over-hashes-in-liquid-templates
- 適合用 hash 的情況
- key 是 unique 的
- key 是 string
- 所使用的 language 對 hash 實做有支援
- 實際上有 access by key 的需求
- 如果是 api 等很多人要用的資料,大多不會用 key 存取,資料都存 array,因為各語言對 array 的實做都有基本完整的功能。
- 開發到一半更改資料結構是常見的,但就是看改得痛不痛,如果只有自己再用改了不痛那就沒差
心得
- 卡超久的 js 蠢 bug 結果是值更新後沒有把變數重新 assign 給自己一次(a.k.a. 寫 ruby 沒有用 ! 號)
- 發現 jekyll 的 data files 只吃 string,但 yml front matter 裡面寫數字會被認定是 int,所以想把 yml front matter 裡面設定的變數丟到 data files uri 的時候就會悲劇
- 解決方式:想辦法在 jekyll 裡面把 int 轉成 string
- 但是 jekyll 用的是 liquid,不是 erb,沒有內建 int to_s(但是有 date to_s...)
- workaround 解決方式:在數字後面 append 一個空字串
- tka 短評:大便就是這樣生出來的
- what we do 的文案設計過程
- 有幾個不同面向的點可以寫成 what we do
- landing page 要發揮 sales kit 的功能,也就是回答讀者「我可以跟你買什麼?」這個問題,因此選擇以業務形態做為 what we do 的分類基準
- what we do 的版面設計過程
- 原本三欄卡片式的排版 pattern 跟專案列表太過相似,會造成混淆
- 因此改成兩欄排版,將內容湊成雙數
- 進一步區隔 pattern:抽象概念一律用 icon 表示,具體專案或人物才用複雜的照片圖片。如 people 頁面上方大標題區塊是 icon,底下每個人才是照片
- about 文案內容與網站資訊架構的對應
- 把 keywords 做成專案的 tag 並且在 projects 頁面可以依此 filter,證明這些 keywords 不是空口說白話
- poga:一般不會先去點 filter,期待在列表內直接看到每個專案的 tag
- 整理 reports 頁面感想:
- 保留舊版的頁面跟做新的差不多困難,一堆 dependency 啊(倒)雖然解完以後也覺得沒什麼就是了...
- 原本想說把舊的網站內容貼過來就好了,但發現拼裝車的文案放在拼裝車的版面裡沒有違和感,但放在有邏輯的版面裡就怎麼看怎麼不對勁,設計跟文案是無法切割的啊... 所以好多文案都重寫過,因此花了很多額外的時間(淚
2016/10/24~
:ok: et 設定 jekyll data files + 用 .yml 完成 people 頁面
:ok: et 在 10/26 wed. 工作會議報告目前進度,報告內容如 2016 OCF Redesign: 2016/10/24~
:ok: 依工作會議結論:people 頁面順序改為 staff > consultants > alumni > volunteers > board > partners > sponsors > donors
:ok: 依工作會議結論:people 頁面的 partners / sponsors 跟首頁一樣純 logo 沒有敘述
:ok: et 設定 jekyll data files + 用 .yml 完成 projects 頁面
:fast_forward: 整理 projects yml 資料
- 目前進度:
- 因為 beep 所以落後了,但是因為改規格(省略設計!)所以又稍微追上了,目前比預定中(10/30 beta 版上線)落後約一週 XD
- 首頁 desktop, mobile, data* http://beta.ocf.tw/
- people 頁 desktop, data http://beta.ocf.tw/people/
- 預定進度:
- 本週 10/30 前完成
- people 頁 mobile
- projects 頁 desktop, mobile, data
- 下週 11/6 前完成
- about 頁 desktop, mobile
- mediakit 頁 desktop, mobile
- news 頁 desktop, mobile, data
- 404 頁 desktop, mobile(無梗單調版)
- 下下週 11/13 前
- 需要 ocf staff 校正 data 內容
- 需要 ocf staff 校正文案
- 需要 ocf staff 提供英文版內容
- 下下下週 11/20 電影日前
- 其他已實做的許願:
- 原本的專案頁網址會自動跳轉,像這樣 https://github.com/ocftw/beta.ocf.tw/blob/gh-pages/300/index.html
- people 頁維護方式是編輯這些 .yml 檔案 https://github.com/ocftw/ocf.tw/tree/development/_data/people
- projects 頁維護方式會比照辦理
- 將來需要向合作單位索取的 mediakit 至少有
- 社群 logo,長寬比不限,會出現在 partners 列表
- 專案 cover,採 fb og image 尺寸 1200 * 630,會出現在 projects 列表
- 進一步內容等下週 projects 的資料整理好會再列到 hackpad
- 沒實做的許願:
- 有人許願過首頁要放國發會活動照片,原本要放 image slider,但重新設計完以後 image slider 拿掉,所以這個許願可能無法實現了
- 三百壯士 靈骨塔(x) 光明燈(o) 預定放三百壯士專案頁面內,優先順序比較後面,等 level 1 頁面弄完再看看
- 「勸募捐款公開徵信區」如果有的話,會跟「捐款徵信」的連結一樣放在 footer。目前沒有替「捐款徵信」設計頁面,是直接連到 blog,想在官網裡面做捐款 / 捐物 / 勸募徵信頁面的話,下一梯次改版可以來做
- 首頁
- 文案之後要改可以盡量控制在差不多的字數
- what we do 區塊因為排版需要希望是偶數
- what they say 區塊故意做成 carousel 讓人搞不清楚到底有哪些人
- 上周董事會粗略共識「open source , open data , open government 的議題各佔基金會(行政基金)的力量 1/3」已寫入 footer 文案
- people 頁
- 新增 alumni 區
- 志工區目前加入我知道有幫忙兩個以上專案的人,如 muka 跟 yaya(& 我不想排第一個。。。)
- TODO: 確認志工名單
- TODO: 確認 partners 跟 sponsors 區域是 logo 就好還是要有文字描述
- pf: 先 logo 不要描述
- pf: 專門捐給 civic tech grant 的話要放進來嗎?
- cl: 可以分 section ,各專案有大額的想放上來的話,稍微區分
- pf: rc 我在跟 et 討論,有點複雜
- jm: 董事放上面會不會太強調?希望 staff 放上面
- TODO: pofeng 跟 aaron 協作文案,cc 給 et
2016/10/17(因公流會)
:ok: et 完成其他 level 1 頁面內容初稿
:ok: et 完成 repo 資料夾結構(跟現在一樣,可以直接按 github 鉛筆按鈕維護)
:ok: 因應 yayared 被上班,網站規格改 plan B(無設計,套用 semantic ui 的 style)
:ok: 和 bobchao singing 確認社群 banner 可採 fb og image 尺寸 1200 * 630 px
:ok: et 完成 landing page html / css 初稿
:ok: et 設定好 staging site repo: github.com/ocftw/beta.ocf.tw
:ok: pofeng 設定好 staging site 網址: beta.ocf.tw
et 跟 yaya 走過頁面內容
感想:
- 網站內容整理需要花的時間比想像中久,因為一邊整理,一邊要修改成適合 mockup 的樣子,所以不只是剪剪貼貼,還要大幅度的編輯,過去因為接案子的內容都是客戶提供,所以太小看產生內容這件事情了,沒有特別把時間估進去。應該要視為一個跟 wireframe 同等級的 task 才對。
- 啊,真是辛苦了 ! 不好意思 !
2016/10/11
:ok: et 完成 landing page 內容初稿
感想:
- 簡介文案好難寫。第一個難關在於瞭解組織存在的脈絡,第二個難關在於挑選出適合 TA 的點來寫。
- 對不懂的觀眾來說,第一個問題是定位問題,也就是 why 這個組織 / 專案要存在?在世界上扮演了什麼角色?接下來才是 how 跟瑣碎的 what 執行細節。要解釋 why 的話,要指出想解決什麼問題、以及為什麼選擇使用這個方式去解決問題,說服讀者相信這個組織 / 專案的存在是有意義、值得支持,而且有前瞻性,不會很快就過氣淘汰的。
- 簡介的內容雖然字數不見得多到哪去,涵蓋的面向卻很廣,要決定從裡面瞄準哪些點來寫,則是跟文案的 TA 有關,不同的 TA(例如 2B 跟 2C)需要知道的資訊可能不太一樣。
- 組織 / 專案因為 why 而成立,但成立後,執行的內容都是 what 或 how,常常容易因為 why 已經內化為理所當然而渾然不覺,只注意到 what 跟 how,結果就是寫介紹文案的時候也會一直寫 what 跟 how,在完全沒有背景資訊的讀者眼中,就形成一種「不知道為什麼但做就對了」的印象。
2016/10/04
:ok: 首頁 mockup 素材(大致上)
:ok: yaya 跟 ET 核對要填進去 moqups 的字
:ok: yaya 跟 ET 討論 10/17 前時程
- 原本時程忘記把 review 時間算進去
- design guide line 在 mockup 完成後才出現
文案的眉角
- 不懂的人通常第一個產生的問題是 why 但當事人腦袋裡想的通常是 what
mockup 的意見
- post 呈現形式、layout
- 字的內容在 html 改即可
- et: 把 wireframes 區塊編號,方便之後討論
2016/09/23~09/30 意見收集區
關於 Sitemap 的意見
網址規劃 (pofeng)
- /donate/* 下面的 url 希望能 REDIRECT 到新的 URL/URI
- 實做:靜態網頁可能是要用 <meta http-equiv="refresh" content="0; url=http://new-domain.com/" /> ( HTTP 301 )
- gitpage 的放上 html 檔之後, URL 不需要結尾的 .html
- 所以我原本的
- ocf.tw/300/index.html => 可以用 http://ocf.tw/300/ 連
- 直接改成 ocf.tw/300.html 就好了=> 可以用 http://ocf.tw/300 連
關於 Wireframes 的意見
/projects
上稿方式
- 之後還是會像填寫 hackpad 一樣嗎?還是有什麼神奇的魔法,可以分年份顯示。 ->
- 目前打算把專案資料寫在某個 json 或 yaml 檔案裡,資料內容包括年份(同名稱不同年份視為不同專案),然後用某種方式讓 jekyll 自動依照專案的年份套版
- 當年的專案套到 projects/ 的版型
- 陳年的專案套到 projects/20xx 的版型
/people
贊助商 logo 位置 (singing)
- 目前沒有特別限制,當初有答應新竹物流放在OCF「 贊助夥伴」區域(將在 協力社群成果( http://ocf.tw/partner/ )新規劃「贊助夥伴」區域),如果有修改,我可以再聯絡對方。
離職同事列名方式 (singing)
/about
/mediakit
2016/09/27(颱風假)
(收集意見 & 打混中。。。)
- ET 整理 sitemap / wireframes 意見
2016/09/21 工作會議
結論:
- google drive 公開沒問題
- project list 放抽成,不放確切數字
- project list 只放成案的,不放洽談中的
- project list 標題欄用字要斟酌
- 投稿 COSCUP 是一定要的
- 校稿細節 email 討論
2016/09/20 網站暨平面小精靈松
poga, yaya, et
隔天晚上的 OCF 工作會議要 staff 報告的事情
- 8/31 ~ 9/20 的進度 (TL;DR: on schedule)
- 繼上個月 poga 加入後,這個月 yaya 也加入了
- 已完成 project list > biz model > user journey > content list
- 目前成果: https://docs.google.com/presentation/d/1fc5d9jjqp5Jfwx-a4mGl0DIdo0sHFBFupYH1LQJ6N0w/edit?usp=sharing
- 接下來的 schedule
- 9/27 前 sitemap (yaya) | f2e research (et)
- 10/4 前 wireframe (yaya) | f2e research (et)
- 10/11 前 visual guide (yaya) | f2e dev (et)
- 10/18 前 mockup (yaya) | f2e dev (et)
- 10/25 前 html + css (yaya) | f2e dev (et)
- 11/1 前合體!beta online
- 今天想跟 staff 確認
- 合作夥伴的 logo 位置是否有什麼限制?在談贊助答應人家一定要放哪邊?
- level 1 頁面若打成剩下四頁,網址跟原本不同,會造成什麼問題嗎?
- people(董事、顧問、員工、志工、合作夥伴、贊助商、捐助人)
- projects(進行中專案 list、歷年成果 list)
- about(宗旨與願景、緣起與歷史、組織章程與各種字號、捐款捐物徵信 link、財務報表 link)
- mediakit
- 將來專案頁面跟成果報告打算自動生成,導致每個專案都有獨立頁面,會造成什麼問題嗎?
- 下週二 wireframe 出來後會需要 staff 幫忙的
- review wireframe, sitemap
- 補完 wireframe 裡面的文案
- 資料夾權限目前設定為公開,有何不妥? https://drive.google.com/open?id=0B0NsS2a-Qx8ZZEkxRHBTaHVPV2M
- 所有文件打算 CC 釋出,以 OCF 志工專案的身份投稿明年 COSCUP,有何不妥?主軸可能是
UX 小夥伴心得交流
- poga: et 發推可以用這個就不會洗我版,社群小編工具 https://buffer.com
- et: content 標題寫起來很多但沒想到貼到白板以後覺得蠻少的...
- 做 sitemap 的時候,實體的白板跟便利貼比用 hackpad / paper 列表來得順手,因為有 temp 區、有 history、有空間感,可以任意擺位置。直接用 hackpad / paper 常常覺得阿雜
- design thinking 是一種沒自尊的做事方式,要到處收集意見,讓別人來打臉自己的假設,不能用腦補的。比較容易出現在
- 1. 沒有一個老闆很強烈要求要做什麼東西
- 2. 探索新的產品,要從使用者那邊得到答案
- brainstorming 會議適合控制在一個 pizza 可以吃飽的人數(3-6人),再多就沒效率
- 網站組目前做的事情,在 OCF.tw 改版專案中的角色類似 ux 顧問,像 HPX 扮演的角色
hot fix:
本週 9/19 ~
:ok: et 和 poga, yaya 確認明天工作會議要報告的事情
:ok: et, yaya 和 poga 討論完稿後的 user journeys,合併重複的部分,詳 gslides https://docs.google.com/presentation/d/1fc5d9jjqp5Jfwx-a4mGl0DIdo0sHFBFupYH1LQJ6N0w/edit?usp=sharing
:ok: poga, yaya, et 用白板和便利貼把 gslides 上的網站內容標題排列組合,變成 sitemap 與 landing page wireframe。照片詳 https://drive.google.com/open?id=0B0NsS2a-Qx8ZbEFKbUEwR3lCRTQ
:ok: singing, yaya 同步文件樣版進度,本週挑色(文件跟網站共用的)下週會有看得到的東西
:ok: singing, et 補完三百壯士貼紙許願頁面,準備明天工作會議上報告 300 Emoji
:ok: singing, et 赫然發現 mglee 還沒放上官網
家庭作業
:ok: et 跟 pofeng 確認 staff 頁面加入 mglee 的方式
:fast_forward: et 開始研究 jeckyll data files
:fast_forward: yaya 把 sitemap 跟首頁 wireframes 數位化
工作會議 9/21
下週 9/26~
- yaya 和 et 討論 sitemap & wireframes
- et 報告 jeckyll 研究進度
- et 開始跟 ocf staff 收集意見與網站內容素材
- singing 和 yaya 討論文件範本
- singing 和 et 討論三百壯士貼圖投稿狀況
2016/09/12 網站小精靈 kick-off meeting Part 2
yaya, singing, mg, et
UX 小夥伴心得交流
- et: 雖然簡報上是 project list -> biz model -> user journey,但實際上是做了 user journey 才發現不知道 biz model,做了 biz model 才發現沒有 project list,所以是倒著回去做。感覺 user journey 像是一面照妖鏡,一做下去就會發現自己缺少了什麼。
- et: 發現外包接案公司很難碰到 UX 的規劃面,要做就得在 in house 做,但在 in house 要能好好做的機會也很難得,所以 OCF 官網剛好是一隻很好的白老鼠... XD
- yaya: in house 其實也很難,因為老闆會覺得太費時,為了 time to market 就不做了。不然就是有做但是沒有實際訪談收集資料,自己腦補一個理想的 user 來做 persona,導致做完也沒新發現。真正的 persona 應該是去訪談多個使用者後把他們濃縮成一個案例。
- yaya: OCF 官網目前發展是 ok 的(狀態顯示為批可)
- et: OCF 的好處是不是從零開始,已經實際上 run 了兩年,有累積真實的資料。如果是剛成立時什麼情報都沒有的狀況下要我們做 user journey 應該也做不出來。
- et: user journey map 一個眉角是河道是主詞、框框是動詞加受詞、箭頭是資訊流,一開始有卡住一下,寫成全部都是名詞沒有動詞... blah
本週 9/12 ~
:ok: 官網組吸收新下線 yayared,由 singing 幫加 slack
:ok: et 為了迎接 yayared 將目前無為止所有 UX 文件整理至簡報中 https://docs.google.com/presentation/d/1fc5d9jjqp5Jfwx-a4mGl0DIdo0sHFBFupYH1LQJ6N0w/edit?usp=sharing
:ok: et 跟 yayared 報告上週為止的進度、討論 UX 發展過程和開發心得、一起讀了 poga 的天書。心得寫在這 2016 OCF Redesign: 2016/09/12 網站小精靈 kick off meet
:ok: et 和 yayared 確認企劃階段分工: yayared 做部分 user journey、sitemap、wireframe,et 做剩下的 user journey ,poga 在旁邊飄
:ok: et 和 yayared 確認企劃階段時程:9/20 前 user journey,9/27 前 sitemap,10/4 前 wireframe(?)
:ok: yayared 確認接下來的工作方式:跟 et 一起每週二進 OCF 辦公室
:ok: yayared 幫自己挖了一個坑: sales kit 製作
:ok: yayared 和 singing 討論了聯合勸募計畫的文件排版事宜,發現可以跟 sales kit 整合起來做
:ok: yayared 又幫自己挖了一個坑: 文件範本(列印用)、簡報範本(投影用)編排設計,從 muka 的視覺元素延伸
:ok: et 提供 yayared singing 先前 ttcat 和 muka 討論 VI 的文件供參考 https://ocf-tw.hackpad.com/visual-brand-identity
:ok: singing 開了 #design 來收集官網、文件範本、簡報範本、視覺設計的相關討論
:ok: singing 和 et 討論三百壯士貼紙貼圖表情符號許願池的文件格式 300 Emoji
家庭作業
:fast_forward: ET 把 user journey map 標題弄出來給 yayared 選
:fast_forward: ET 整理之前收集到的關於網站內容的許願,準備下週給 yayared 做 sitemap
:fast_forward: yayared 挑一兩個 TA 畫 user journey map
:fast_forward: yayared 研究一下 singing 提供的贊助計畫書文件內容
:fast_forward: singing 把贊助計畫書可能用到的素材連結收集給 yayared,如各社群 logo、相簿網址... etc.
下週 9/19~
- et 和 yayared 討論 user journey、準備進行 sitemap
- et 和 singing 討論 300 壯士許願池
- singing 和 yayared 討論列印用文件範本
2016/09/06 網站小精靈 kick-off meeting
與會:poga, et
UX 小夥伴心得交流
- 從 user journeys 可以看出網站的用途主要有三種:
- 讓人出錢或出力
- sales kit
- 徵信
- 因此黃金版位可以留給這些內容,其他東西沒那麼重要的可以塞在次要版位
- 在 landing page 放 image slider 是已經證實沒用的東西,靜態就好(?)
:ok: ET 和 poga 交代專案來龍去脈、OCF biz model、專案類型、stakeholders 等
:ok: poga 挑了幾種 TA 做 user journey map:社群活動參與者、個人捐款者、社群合作夥伴、法人合作夥伴、企業贊助者
:ok: poga 根據 user journey map 整理了整體網站與 landing page 資訊架構 https://drive.google.com/open?id=0B0NsS2a-Qx8ZNWUyeWJkNjhnX00
:ok: ET 和 poga 確認接下來的時程與分工(時程:依原訂計畫走著瞧,分工:poga 當 ET 的召喚獸)
:ok: ET 拿 bob 的書回家啃(poga 想看的兩本子龍都有了)
:ok: ET 和 singing 討論 300 壯士回饋貼紙的主題挑選方式
:ok: ET 和 bobchao singing 討論合作單位 logo 的 RWD 尺寸
家庭作業
:fast_forward: ET 整理 poga 的草本天書,免得過兩天作者自己也看不懂
下週 9/12 ~
- ET 接續製作全站 sketch 版 wireframes
2016/08/30 自 COSCUP 回歸,確認社群參與方式
:ok: 和 singing , rockhung99 , mglee 發想 300 壯士回饋貼紙方案,預定由 singing 在明天工作會議提出
:ok: 和 pofeng , singing 確認 ocf 網站改版的社群參與方式,預定下次開始邀請 poga 參與志工日(image slider 有人修了 lol)
:ok: 和 singing, rockhung99 確認 ocf 網站更新許願池內容,預定持續開著卡片收集許願,之後一併放入網站規劃中
:ok: 敲定官網改版時程表,預定 8/31 工作會議向大家報告
家庭作業
:fast_forward: user journey map 前製作業:OCF business model 圖解
2016/08/23 COSCUP 回血中遠端
:ok: 替自己開了 trello 河道,歡迎大家來關心(?)
:ok: 回血中,申請 8/23 遠端
:ok: 建立官網改版的 milestone,依照上次工作會議內容
:ok: 找時間和 singing sync 一下官網相關的 trello 卡片
:ok: 找時間和 singing pofeng 確認官網改版的社群參與方式
家庭作業
:fast_forward: 著手製作官網 user journey map (edited)
2016/07/27 工作會議
:ok: 進度報告
:ok: 和大家確認網站改版 milestone
:ok: 個人對此專案的想法報告
2016/07/26 ET 在家遠端
:ok: 整理過去 hackpad 內容,建立網站資訊架構初稿(在 hackpad,置頂)
:ok: 更新 project list,加入「OCF 掛名」欄位
家庭作業
:fast_forward: user journey map TA 族群界定,目前預計區分 TA 的方式有
1.對 open source 的熟悉程度
2.瀏覽官網的動機是來自社群專案或來自OCF本身
3.在 open source 界的角色是 C/U/P
2016/07/19 ET 請假
:ok: ocf project list 資料整理(權限:staff only)
:ok: ocf 官網專案頁面自動化流程初步發想(權限:public,可考慮從此 published data 生成網頁) https://docs.google.com/spreadsheets/d/1bmVNKXOQfM_nHKFK2M1SI09z--sojpl1iw3JPtNqDUk/pubhtml?gid=569652953&single=true
下週
- 預定:某種流程圖 (edited)
2016/07/12 OCF 專案大盤點 && 梅君 orientation
:ok: 中午聽 ipa ttcat 討論揪松
:ok: 下午和 singing rockhung99 mglee 製作 ocf 專案列表
:ok: 下午和 singing 確認 VI 需求
:ok: 晚上和 ttcat muka 討論 OCF VI 發想
家庭作業
:fast_forward: 整理 projects metadata
下週
- 請假回台中
下次
- 預定:官網 user journey map && VI 聯合討論會 (edited)
和 singing, rock, mg 合力整理出 OCF 專案列表
成果
- 白板照片
- 將專案列表整理成 gsheet
- 網站內容發想(已搬到網站資訊架構區)
2016/07/05 需求訪談官網松
:ok: 旁聽發票討論會(聽一半,到 rock 很多錢為止...)
:ok: 陪窗簾師傅 3F 施工
:ok: 找時間對 singing rockhung99 ttcat 做官網需求訪談,訪綱: 2016 OCF Redesign: 2016/07/05 需求訪談官網松
:ok: 和 ttcat muka 約討論 ocf VI 的時間 -> 暫約週四晚上 -> 因颱風改到下週二晚上
下週:
- OCF 官網重構:和 singing rockhung99 梅君一起製作 OCF 專案列表 (edited)
時間:___ pm ~ ___ pm(預計 1hrs)
地點:OCF 辦公室
與會:singing, rock, ttcat, et
OCF 員工使用官網的時機與對象是?
活動開場會介紹合作夥伴、怎麼成立的,因為有社群夥伴,用簡報,但簡報沒有太多東西,是從網站 print screen。我們辦的活動大部分對象都認識我們或認識合作夥伴了,即使金主也要稍微知道我們,如果不認識這個領域的,可能因為活動得知
可能知道我們跟政府開會,但不知道在做什麼。或者高村長很有名,慕名而來但不知道他在幹嘛,或是從台權會記者會得知。就像是去陌生的組織開會,也會想知道人家幹嘛。開放,是開放什麼?哪個領域的開放?
問 singing 開放文化是啥?通常是陌生人,活動參與者。零星的個案。之前去面試工程師不知道 COSCUP 是什麼。
ttcat 不知道怎麼跟人解釋我在哪工作,大家都問那啥?就卡住了。如果連 g0v 都不知道的人就無法解釋。
OCF 專案可以分成哪些類型?可以根據哪些屬性分類?
自己 run 的專案:行政中心(pofeng)、國際交流(clkao)、影展(bob)
執行狀態的專案:umaker、...
活動 OCF 出人力支援
金流 + 帳務
純金流
專案定義:有經費、有成果的
主要:主辦的,CCTW、國際交流、影展、U Maker 經銷
次要:協辦的,COSCUP、pycon、g0v summit
收集各專案的掛名資訊
OCF 專案的生命週期分成幾個階段?其中哪些階段會跟官網有關?
持續型:國際交流
持續一次性:社群年會
一次性:活動
(結論:以年度分)
維護目前官網的困難處有哪些?
討論區
希望將來官網有個 mediakit 下載的地方,上面可以放 muka 的 credit(類似 doodle 放作者照片一樣)
2016/06/28 Tue. 每週ET志工日
:ok: 和 singing rockhung99 組櫃子健身
:ok: 前天勞基松成果 hot fix,重新設定 facebook 相簿,搬到草稿區,以免誤導人 -> https://www.facebook.com/ETBlue/media_set?set=a.10207390760459930.1073741854.1014354995&type=3
:ok: ocf 官網重構:整理上週 pofeng 訪談紀錄 -> 2016 OCF Redesign: 2016/06/24 Fri. 玻璃吸管官網松
:ok: ocf 官網重構:草擬需求訪談大綱 -> 寫好後先丟給 singing rockhung99 ttcat 共筆 -> 2016 OCF Redesign: 2016/07/05 需求訪談官網松
下週預定
- ocf 官網重構:約 singing rockhung99 ttcat 需求訪談,約 1hr / 每人 (edited)
討論:singing, et
旁聽:rock
待辦事項
- ET 草擬需求訪談大綱
- ET 約大家問問題 -> 7/5 Tue. 下午
2016/06/24 Fri. 玻璃吸管官網松
:ok: ocf 官網重構:對 pofeng 需求訪談
:ok: ocf 官網重構:semantic ui 版 hot fix,header footer bg image 與原 theme 統一 -> aea8b3d831089ef041051415c735bcaf9285aea2 , c86d059e70a284eeb280e70b62ce702d14fe897e , 85b13918c1261ee7d0191534aacd4b32757c4b50 , f5a5781297315863a2a1baaddd567b8a1815f798 , 95f1f30971463ab874cdbf03d59a6ba13a5a9d86
地點:OCF 辦公室
與會:pofeng, et
旁聽:singing, ttcat
前情提要:拿玻璃吸管給 singing 遇到 pofeng 因此順便聊聊官網
會議目的:收集 pofeng 觀察到的官網需求
會議記錄
整體視覺風格
pofeng 視覺偏好
背景偏好深色金屬質感
搭配 terminal 螢光綠字尤佳
可採用原本 theme 的 background image
首頁
image slider
(已放棄)版位有考慮過拿來賣給相關單位,但談起來麻煩,首頁也沒人看,還要花人力維護,因此放棄這個想法。要賣的話賣 adwords 比較實際。
- 因為維護考量,內容以不太需要變動的為主。
- 要放的內容:宣揚開放文化理念。
(已放棄)除了理念以外,幾個長期專案也不太需要變動,但一旦決定在 hero 放專案,就會有資源分配是否公平的問題,處理起來麻煩,因此暫時放棄這個想法。
捐款專案列表頁
使用者問題
專案太多不知道要捐給誰
連到 neticrm 後就回不來
設計者問題
- 例外:國際交流專案有[「申請」的 action button
- 其他有的是捐款,有的是捐人,基本上都是「捐」
捐款專案頁
需求
neticrm 與官網一致header footer 統一
頁面內容統一
以上做成新的 template,舊的就先不管
neticrm 維護方式許願希望編輯一次就可以同時更新兩處的內容(目前手動複製貼上)
類似 kickstarter 有 goal
- 版位可以考慮區分 OCF 宣傳的主力專案(上面)、社群自己宣傳的專案(下面)
成果專案列表頁
目前放合作夥伴專案,分成法人、非法人
通常放每年都會 repeat 一次的 conf
介紹文案
外界常見疑問
- OCF 就是 g0v 嗎?(需要把 ocf 跟 g0v 切割開)
- 什麼是開放文化?(樂高 youtube 影片,jimmy 翻譯的那個,可以考慮放首頁。這邊盡量不講電腦)
OCF 主要組成社群
pycon
coscup
g0v
其他 pofeng 想幫忙的對象
開發方式
原則:日後任何人都好接手(考慮 pure html + css)
網路行銷策略
- 不刻意經營OCF粉專,只發表新聞或電子報內容,重要的消息請COSCUP或g0v粉專轉發即可。粉專的目標:製造歸屬感、鎖定潛在貢獻者
待辦事項
pofeng
ET
- 查 responsive image slider
- 問 singing 有沒有回答到長繭的 FAQs
下次會議
線上討論,或每週二 ET 到辦公室時討論
網站規劃初步發想
要解決什麼問題
要跟企業募款,但企業從官網看不懂我們在做什麼
現有的小 bugs
要怎麼解決上面的問題
首頁第一眼要能簡單表達 OCF 的定位
網站會給誰用、他們各自會怎麼用
- 捐款人:從官網瞭解基金會性質與定位→判斷是否適合作為捐款標的→分享給朋友 / 直接捐款
- 企業
- 個人
- 合作夥伴:從官網瞭解基金會性質與定位→判斷適合的合作形式→分享給同事 / 與窗口聯絡洽談
- 學校
- 民間團體
- 企業
- 媒體
- 政府
- open source 開發者:從官網瞭解基金會性質與定位→找到適合自己的開發資源→分享給朋友 / 取用資源 / 改良或貢獻資源
- 開放硬體開發者
- 3D 列印
- 主機板
- 開源軟體開發者
- 韌體類
- 作業系統類
- 桌面應用類
- 輸入法...
- 行動應用類
- android app
- ios app
- 網路服務類
- 開發工具類
- 開放授權創作者
- 視覺
- 設計類
- 藝術類
- 攝影類
- 音樂
- 數位創作類
- 初音類。。。
- 音像
- 動畫類
- 紀錄片類
- 文字
- 開放授權法律研究者
- OSD
- CC
- open source 使用者:從官網瞭解基金會性質與定位→找到免錢好康→分享給朋友 / 取用資源
- 硬體使用者
- ...
- 軟體使用者
- android os
- XXX ime
參考
現有 prototype http://ocf.tw/
相似組織 http://www.openfoundry.org/
Wireframe
Staff 頁
參考資料
產品規劃空白模版
User Story 空白模版