Quantcast
Channel: WFU BLOG
Viewing all 784 articles
Browse latest View live

利用隱藏的 Iframe 跨域傳送訊息實作﹍postMessage

$
0
0
最近處理的案子需要在 A 網域登入後,同時在 B 網域一樣能保持登入的狀態。這就像登入 Google 一次後,旗下的各種服務例如 Gmail、Google Drive 等等,就算不同網域也不需要再重新登入。

實作的方式可以將登入資訊儲存在 HTML5 的 localStorage (就像以往的 cookie),在跨域的狀態下利用隱藏的 Iframe 來傳送請求,來取得另一網域的 localStorage。

以往跨域傳值很麻煩,而 HTML5 提供了 postMessage API 讓這件事變得簡單許多。本篇筆記將整理 postMessage 的以下操作:

  • 跨域傳值範例
  • 如何確保安全性
  • 傳送各種資料型態(包含物件、函數)

(圖片出處: pixabay.com)


一、postMessage 使用方法



根據以上說明文件連結,postMessage 的使用方式大致如下:

  • 在頁面上開一個 Iframe 窗口,或是使用 window.open 開啟一個視窗
  • 取得這個 Iframe 窗口或是新視窗的對象,方式如下:
    • Iframe:var newFrame = window.frames["自訂名稱"]
    • 新視窗:var newWindow = window.open("網址", 參數)
  • 利用窗口對象發送 postMessage,例如 newWindow.postMessage(訊息內容, "目標網域")
  • 在 Iframe 或新視窗之內,執行 addEventListener 監聽 message,可取得訊息內容

瞭解原理後,以下來看實際範例。



二、跨域傳值範例










上面的內嵌 IFRAME,為了示範傳值效果,因此沒有隱藏。在跨域傳值的實作上,這個 IFRAME 並不需要顯示出來,請用 CSS 將內嵌的 IFRAME 隱藏即可。

這個範例的作用如下:

  • 本站母視窗網域為 www.wfublog.com,IFRAME 的網域為 demo.wfublog.com,是不同網域(網站 logo 有連結)
  • 在母視窗輸入框填入任意字串後,會將字串傳送到 IFRAME 的網域,並顯示在該網頁上
  • IFRAME 網頁並同時統計輸入的筆數,將數值存在該網頁的 js 變數
  • IFRAME 網域每次接收到資料後,會統計資料筆數,並將數值回傳到母視窗網域
  • 最後母視窗用 alert 彈跳訊息,顯示總輸入筆數
  • 整個流程傳送、接收訊息時,為了維持安全性的因素,都會檢查發送的網域,不接收其他網域的訊息,以免被駭客攻擊

讀者可自行輸入資料來測試 IFRAME 跨域傳值效果。



三、母視窗程式碼範例


上面展示效果的母視窗程式碼,範例如下:

<!--載入 query-->
<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>

<!--跨域 IFRAME-->
<iframe name="WFU_frame" src="http://demo.wfublog.com/p/cross-domain-postmessage-iframe.html" onload="sendMessage()" style="width: 100%; height: 300px;"></iframe>

<!--Bootstrap 輸入框-->
<div class="input-group">
<input id="input_message" class="form-control input-lg" placeholder="請輸入傳輸字串" type="text">
<span class="input-group-btn">
<button id="submit_message" class="btn btn-primary btn-lg" style="margin-left:20px;">輸入</button>
</span>
</div>

<script>
//<![CDATA[
function sendMessage() {
// 送出字串
$("#submit_message").click(function() {
submit_message();
});
}

// 傳送訊息到 IFRAME 網域
function submit_message() {
// 發送訊息 要取得資料
window.frames["WFU_frame"].postMessage($("#input_message").val(), "http://demo.wfublog.com/p/cross-domain-postmessage-iframe.html");
$("#input_message").val("");
}

// 監聽 IFRAME 網域回傳的訊息
window.addEventListener("message", function(e) {
console.log(e.origin);
// 加強安全性 判斷數據發送方是否為可靠的網域; 不安全的網域不處理
if (e.origin.indexOf("demo.wfublog.com") < 0) {
return;
}
var data = e.data;
// 彈跳訊息框顯示回傳的筆數
alert(data);
});
</script>


簡單說明如下:

  • js 使用了 jQuery,所以先載入 jQuery
  • Iframe 實作上可用 css 隱藏起來
  • Iframe 網頁載入後,自動執行 sendMessage 函數
  • Bootstrap 輸入框的實作說明,可參考「Bootstrap 簡易版面實作範例﹍網格+面板+表單輸入+按鈕
  • submit_message 函數,會將輸入框的字串,傳送到 IFRAME 的指定網址
  • 同時送出字串後,母視窗開始監聽 IFRAME 網域回傳的資料
  • 如果回傳訊息非來自指定網域,則不處理
  • 最後 alert 資料筆數



四、IFRAME 程式碼範例


上面展示效果的 IFRAME 程式碼,範例如下:

<script>
// 設定計數器, 起始值為 0
var count = 0;

// 監聽母視窗傳來的訊息
window.addEventListener('message', function(e) {
// 判斷數據發送方是否為可靠的地址
if (e.origin.indexOf("www.wfublog.com") < 0) {
return;
}

// 計數器 +1
count++;

// 回傳計數器數值
e.source.postMessage("已輸入 " + count + " 筆資料", e.origin);
});
</script>


流程簡單說明如下:

  • 先設定計數器
  • 開始監聽母視窗的訊息
  • 如果傳來的訊息非來自指定網域,則不處理
  • 每次收到資料,計數器 +1
  • 最後回傳計數器的數值到母視窗



五、傳送的變數型態


一開始 postMessage API 只能傳送字串,這使得應用層面較狹隘且操作麻煩,例如要傳送陣列、物件前,得先執行 toString() 轉換成字串,然後接收到後再還原,真的多此一舉。

現在 postMessage 任何變數型態都能傳送了,例如物件、函數都可以,不要太舊的瀏覽器都可支援,以下是官網說明:

在 Gecko 6.0 之前 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3), message 参数必须是一个字符串。从 Gecko 6.0 (Firefox 6.0 / Thunderbird 6.0 / SeaMonkey 2.3) 开始,信息参数使用 结构化克隆算法 进行序列化。这意味着您可以将各种各样的数据对象安全地传递到目标窗口而无须自行序列化


更多 Javascript 相關技巧:

Blogger 自訂網址出現 404 錯誤﹍事件紀錄及處理方法

$
0
0
blogger-custom-domain-404-error.jpg-Blogger 自訂網址出現 404 錯誤﹍事件紀錄及處理方法前兩天開始,Blogger 使用自訂網址的網站,開始會間歇出現 404 錯誤連不上。出現這個狀況的原因很複雜,最後經由「FB 社團」大家的討論,總算釐出一些頭緒。

同時回顧這個事件,也可當成一個很好的借鏡與教材,因此整理成這篇心得留存。

(圖片出處: 699pic.com)


一、事件的開始


1. 瀏覽器問題

前天早上用 Chrome 打開自己的網站 WFU BLOG 時,突然發現變成 404 網址,一開始是嚇了一跳,心想該不會是被惡意檢舉,網站被刪除了?

blogger-custom-domain-404-error-1.jpg-Blogger 自訂網址出現 404 錯誤﹍事件紀錄及處理方法

不過擔心沒有多久就結束了,因為分別用 IE、Opera、Firefox 開啟後,有的可以連、有的不能連,代表可能是「瀏覽器」的問題,至少排除網站被刪除的原因。

因此我把 Chrome 的瀏覽紀錄資料清除後,或使用無痕模式看,後來就可以了,也沒把這件事放在心上。


2. 網址代理商

到了下午,有客戶很著急地跟我聯絡,表示網站都連不上,很多粉絲都看不到她的文章。既然這現象不是個案,那麼得分析一下原因才行。

因為我的網址是跟 Godaddy 買的,所以查了一下所有客戶的網站,發現 Godaddy 的網站的確會出問題,但並不是同一時間都連不上。

想要致電 Godaddy,但他們六、日不上班,所以一時之間也只好等待星期一再處理了,同時跟客戶回報一下觀察到的狀況。


3. 自訂網域

到了晚上,在 PTT 發現有人回報跟 Google Domain 買的網址連不上,這下代表我的猜測錯了,並不是 Godaddy 的問題,所以就排除了網址代理商的因素,看來是所有自訂網址都出問題,那麼可能就是 Google 伺服器的問題。



二、社團的討論


第二天在「FB 社團」這件事有更多討論,例如中華電信(ISP業者)、路由器、連外線路等等因素。也有成員請硬體工程師進行測試,表示有可能是:

到美國的主機線路出包了,非固定制的 IP 無法連線或有問題,應該是Google 採取分流連線,所以有的人可以連,有的人無法連

由於我沒有網路硬體設備的相關知識,無法評估測試結果,但是這兩天我持續搜尋國外的論壇、相關討論,並沒有任何的相關訊息或災情傳出,那麼這個 Blogger 自訂網址 404 錯誤,就很有可能只是台灣的局部性問題。

若真的是台灣局部性問題,那麼 Google、Blogger 出錯的可能性就會被排除,這狀況很類似前幾年的幾次事件:

  • 連外海底電纜斷裂
  • 台灣連不上 Google 相關服務

一步步推估下來,工程師的測試結果可信度就很高了。



三、修改 TCP/IP DNS 設定


各種出問題的狀況,最麻煩的是中華電信連到 Google 伺服器這一段,如果出錯的話很難知道,也很難跟誰反應。

我找到幾篇過去類似事件的後續報導:


提到的解決方法是修改 TCP/IP 的 DNS 設定,因為一般 Windows 下會預設為「自動取得 DNS 伺服器網址」,此時可先改為中華電信的 168.95.1.1 及 168.95.192.1。

如需圖文操作步驟,可參考這篇「如何排除連線上網時出現 「DNS錯誤」?

手機要改 DNS 的話,步驟可參考這篇「換個 DNS,讓手機使用中華電信 WiFi 速度變快!」,Android、iOS 的教學都有。

經過我在不同電腦的多次測試,原本發生 404 的 Blogger 自訂網址,TCP/IP 設定成中華電信的 DNS 後,重開瀏覽器就能立刻看到網站,證實這個方法是有效的,那麼的確是中華電信連 Google 的某些設定有些問題。

雖然有時還是會看到 404 畫面,不過重開瀏覽器,看起來又可以正常。

要 100% 恢復的話,還是得等中華電信這一段完全修復才行了,可以到中華電信粉絲團留言請他們查明原因:




四、各種應變方式


整理幾種其他不同狀況的 404 錯誤解決方法:

1. 網址代理商問題

如果能確定其他代理商正常,只有你的網址代理商會出問題,就可跟他們聯絡、要求處理。

不過這種情況的機率會比較低,因為他們有 24 小時處理的工程師,也會比我們早先發現問題,以及發佈公告。


2. 自訂網址 DNS 設定

機率比較高的反而是我們自訂網址的 DNS 設定錯誤,導致進不了網站。

如果使用 Godaddy 的話,可以參考我的設定心得「Blogger 自訂網址﹍設定子網域的技巧


3. Google 伺服器問題

Google 出錯的機率不是沒有,但是跟「1. 網址代理商問題」的情況類似,在國外應該會是大事件,24 小時會有很多人回報、也搜尋得到相關討論。



五、總結


如果看過網路連線原理的相關書籍,會瞭解要順利連上網站,是多麼不容易的一件事,從我們的電腦一直到網站主機,中間所有的節點,不可以出一點差錯。只要有環節出問題,就得從頭到尾一個個排除錯誤,就跟寫程式 debug 差不多。

這件事的處理過程,客戶曾對 Blogger 感到灰心,時間點位於當時判斷可能是 Google 伺服器出錯之時。

其實我們都常常發生這樣的狀況,當所處的高度還不夠時,常常依據手上觀察到的現象驟下定論,或是產生先入為主的偏見。

然而當所在的高度提升時,事情的全貌看得更多,真相往往出乎意料,就像我萬萬想不到這次的問題會是出在台灣到美國的線路這一段。

所以我上的這一課是,對於自己不擅長的領域,多聽、多看、多查找資料,但列為參考資訊就好;在有把握看清事情全貌之前,保持客觀開放的態度,不過早下結論。


更多 Blogger 自訂網址相關文章:

網頁最強的文字編輯器 CKEditor﹍安裝使用心得整理

$
0
0
ckeditor.jpg-網頁最強的文字編輯器 CKEditor﹍安裝使用心得整理當初為了架設「Blogger 中文論壇」,如何讓使用者發佈文章時,能有個「所見即所得」(WYSIWYG)的文字編輯器,是滿棘手的一件事。總不能隨便做個 Textarea,讓使用者輸入純文字吧!

因為有太多種情境需要考慮,發佈文章可能會有這些需求:

  • 插入程式碼
  • 引用文字
  • 插入圖片

再加上一些基本的需求,如粗體、斜體、上色等等,沒有安裝一套文字編輯器是不行的。

還好已經有不少免費外掛,本篇要介紹的 CKEditor 是非常老牌、且重量級的超強工具,甚至比 WP 預設的還好用,本篇就來分享我的安裝使用心得。



一、安裝問題


1. 選擇功能


進入以上 V4 版本官網後,馬上有展示區塊可看到這個編輯器的效果,大致操作一下就可知道這是不是你要的工具。



這個編輯器由於太強大,功能非常之細,也不太容易上手,從以上的下載頁面就看得出來,有太多選項可以選擇,有些難以抉擇。

可下載 "基本"、"標準"、"完整" 功能,也能只下載需要的功能。


2. 網頁空間

但是下載完後,也是麻煩的開始,如果有自己的網頁空間當然沒問題,但注意不能用「Dropbox」這類的免費空間,因為不支援目錄資料夾結構。

要用免費空間的話,只能選擇「Github」,才能支援完整的目錄資料夾上傳。


3. 官方 CDN


最省事的方法,就是使用 CDN,可不用操心網頁空間,而且速度又更快。上面的官網 CDN 頁面,官方提供了 CDN 連結,格式像這樣:

<script src="https://cdn.ckeditor.com/4.7.3/standard/ckeditor.js"></script>

  • 請參考官網說明來修改,例如可更改 4.7.3 版本號
  • "standard" 代表標準功能,官方提供了 5 種安裝類別:basic, standard, standard-all, full , full-all
  • 這個頁面還有簡易的安裝、執行範例,比較方便上手

因為 CKEditor 提供了強大的客製功能,除了官方提供的外掛,也會有許多使用者自製的外掛。

而使用 CDN 的缺點就是,要使用官方、自製外掛就比較麻煩,可能要使用下載檔案、放到自己空間的方式才能符合需求。


4. 簡易範例

根據官方提供的 CDN 程式碼,只要以下簡單的程式碼,就可以在網頁上出現文字編輯器了:

<script src="https://cdn.ckeditor.com/4.7.3/standard/ckeditor.js"></script>
<textarea name="editor1"></textarea>
<script>CKEDITOR.replace("editor1");</script>



二、CDN 使用附加功能


1. 非官方 CDN


以上非官方的 CDN 網址也提供了 CKEditor 的連結,雖然無法像官方的檔案那麼有彈性,不過如果你需要的功能比較普遍、沒有那麼細的話,對於客製功能反而是不錯的選擇。


2. 插入程式碼功能

舉例來說,由於本站的性質,我需要的文字編輯器必須提供「插入程式碼功能」(Code Snippet),但這個外掛並不在官方的 5 種安裝版本之中,必須另外安裝。

運氣不錯的是,這算是常用功能,因此上一點的 CDNJS 網站,這裡可以找到 Code Snippet 這個外掛的 CDN 相關連結。

以下會提供這個外掛的 CDN 安裝範例



三、「插入程式碼」安裝範例


1. 安裝程式碼

<script src="https://cdn.ckeditor.com/4.7.3/standard-all/ckeditor.js"></script>
<textarea name="editor1"></textarea>
<script>
CKEDITOR.plugins.addExternal("codesnippet", "https://cdnjs.cloudflare.com/ajax/libs/ckeditor/4.7.3/plugins/codesnippet/plugin.js", "");
CKEDITOR.replace("editor1", {
extraPlugins: "codesnippet",
codeSnippet_theme: "solarized_dark"
});
</script>

  • 必須至少 standard-all 這個安裝版本
  • 可注意一下安裝外掛的語法,兩處綠色字串 codesnippet 需一致
  • 紅色連結 plugin.js 就是從非官方 CDN 取得的連結
  • 這個外掛還能選擇佈景主題,我使用了最喜歡的 solarized_dark

使用以上程式碼就能看到「插入程式碼」這個按鈕及功能


2. 展示頁面


以上連結可看到官網 Code Snippet 的展示效果,下拉選單可選擇各種佈景主題。


ckeditor-code-snippet-demo.jpg-網頁最強的文字編輯器 CKEditor﹍安裝使用心得整理

按下上圖「插入程式碼片段」的圖示後,會出現另外的輸入視窗,可選擇各種程式碼語言,例如 Javascript。

輸入完之後,可看到上圖自動為 Javascript 格式的程式碼上色效果。



3. 進階設定


上面連結為官網的 Code Snippet 介紹頁面。

如果需要瞭解這個外掛的進階設定、操作說明,可點擊「Documentation」,只不過全是英文,不太好啃。



四、自訂面板及功能


1. 修改預設值

這篇「CKeditor編輯器選項配置」整理了非常詳盡的官方預設值,想要修改數值的話務必參考這篇。

需要注意的是,官方很多設定值是用小寫逗號 "," 的方式隔開,但之前掉的坑是逗號前後使用了空格,導致程式無法執行或異常,因此記得盡量不要使用空格,例如以下範例:

CKEDITOR.config.extraPlugins = 'myplugin,anotherplugin'; // 載入外掛的語法,每個外掛字串前後不可出現空格


2. 自訂面板

另外這篇「神調校讓 CKEditor 更好用」的心得、概念,也值得想修改 CKEditor 的讀者參考。

面板上不想顯示的功能、圖示,這篇有提到可使用 removeButtons 設定為不顯示,例如將執行的程式碼改成以下:

CKEDITOR.replace("editor1", {
removeButtons: "Image,Scayt,PasteText,PasteFromWord,Outdent,Indent", // 不要的按鈕
});

同樣注意,每個按鈕字串之間不要有空格。


3. 工具列 + 圖示按鈕一覽

要怎麼知道哪些圖示按鈕,所對應的字串是哪些呢?請參考官網「CKEditor Toolbar」,這裡詳細列出了:

  • 工具列名稱:例如 insert 代表「插入」相關的工具列
  • 圖示按鈕名稱:例如 insert 工具列的按鈕有 Image(插入圖片)、Table(插入表格)等等這些



五、新增功能


除了官方、熱心使用者所寫的外掛,也許會想要自己在工具列製作一個按鈕,執行自訂的功能。

參考這個討論串「How to add a custom button to the toolbar that calls a JavaScript function?」的語法,假設我要自製一個上傳圖片的功能,以下提供一個範例:

var editor = CKEDITOR.replace("editor1");

editor.addCommand("insertImg", {
exec: function(edt) {
// 這裡是插入圖片的程式碼
}
});

editor.ui.addButton('uploadImgBtn', {
label: "上傳圖片",
command: "insertImg",
toolbar: "insert", // 要放在哪個工具列
icon: "https://cdnjs.cloudflare.com/ajax/libs/ckeditor/4.7.3/plugins/image2/icons/hidpi/image.png"
});

  • 兩處藍字 "insertImg" 使用相同字串,設定這個新增功能的名稱
  • 綠字程式碼的地方,改成你要執行的 js 內容,當使用者按下這個按鈕時就會執行。
  • label 處設定的字串,滑鼠停留在這個按鈕時會顯示。
  • toolbar 處設定這個按鈕,要放在哪個工具列,要使用什麼字串請參閱「四、自訂面板及功能」→「3. 工具列 + 圖示按鈕一覽」
  • icon 則設定要顯示的圖示網址,比較方便的作法是直接使用官方圖示,利用 CDN 連結,就不用自己做圖示,以免風格不搭。
  • 可以在「二、CDN 使用附加功能」→「1. 非官方 CDN」這裡,找找合適的圖示網址。



六、雜項整理


除了以上比較常會用到的功能,一併整理我的其他筆記如下:

1. callback 功能

想要 CKEditor 載入後,立刻執行自訂程式,可參考「How to retrieve the CKEDITOR.status “ready”?」,使用以下語法:

CKEDITOR.on( 'loaded', function( evt ) {
// 這裡是你要執行的程式碼
} );


2. 取得編輯器文字內容

如果要立即取得使用者填入編輯器的所有文字內容,可使用以下語法:

CKEDITOR.instances["editor1"].getData();
"editor1" 是目標 Textarea 的 id 字串。(CKEDITOR.editor → getData)


3. 用 Enter 換行

CKEditor 預設是用 <p> 換行,如果要改為用 <br>,也就是 Enter 的效果,可參考「How to configure ckeditor to not wrap content in p block?」:

CKEDITOR.editorConfig = function (config){
config.enterMode = CKEDITOR.ENTER_BR;
};


4. 在游標處插入內容

可參考「Insert text at the cursor position to a CKEditor using jQuery」,使用的官方語法可為:

  • insertText:插入純文字
  • insertHtml:插入 HTML

完整的範例語法為:

CKEDITOR.instances.["editor1"].insertText('這裡是插入的文字');


5. 在游標處插入圖片

如果要用 JS 插入圖片的話,沒想到意外遇到麻煩。雖然前面可知道 insertHtml 能插入 HTML 語法,但實際上若插入 img 標籤語法,是無法顯示圖片的。

查了一下才知道由於安全性因為,某些標籤預設是禁止執行的!想想也是,若使用者安插了惡意程式碼(例如 javascript),卻沒有排除掉,我們網站可就慘了!!

參考「insertHTML in CKEditor does not works only for images」後,需要增加的設定如下:

CKEDITOR.replace("editor1", {
extraAllowedContent: "img[src,alt,width,height]"
});



更多網站相關工具:

避免 Line 無用訊息浪費你的時間﹍建立重要待辦事項群組

$
0
0
最近長輩說「手機速度越來越慢,可能是 Line 的訊息很多,每天都要一直刪群組的訊息,不刪除的話空間很快就滿了,是不是要換手機?」

其實長輩會抱怨就是暗示我們主動幫她處理這件事的意思,但接手這種事不會有什麼好下場,有功無賞、無功還要算自己頭上。所以就打哈哈「那就換手機啊」。

看起來沒有達到效果,所以長輩又繼續抱怨「每天都傳一堆沒用的東西,什麼早安晚安圖,哪有那麼多時間看...」,於是我說「那就退出群組吧~叫他們有重要訊息私訊給你」,她回答「怎麼可能傳訊息給我,訊息都馬發在群組,重要聯絡訊息沒看到怎麼辦?」

我想這就是 Line 群組的問題所在,零星的重要訊息夾雜在大量的垃圾訊息之中,導致群組的每個人,每天都要浪費 100% 的時間,去挖出 5% 不到、比較有價值的訊息。而且我們不會有時間去教育長輩、其他人,不要一直轉貼有的沒的到群組。

對於每天都是空閒的人來說,浪費時間看這些訊息不會是困擾。不過對於一秒鐘幾十萬上下的人而言,就真的需要找出 Line 最有效率的使用方式。

(圖片出處: Line 官網)


一、Line 群組不如討論區


很久以前我曾加入幾個「網頁設計」(web design)的 Line 群組,群組成立的出發點當然是好的,可以互相幫助、交流業界相關資訊。

一開始大家的氣氛也是很熱絡,有人提出各種工作上、程式語法上的相關問題,也會有高手立刻提供解決方法、或相關資訊。

不過一陣子後,就會開始有人邀活動、見面,當然更多的是聊天、心情抒發,群組裡面有價值的訊息,比例急遽下降,這也代表花在看 Line 群組的時間價值越來越低。

曾經跟群組發起人建議,另外開個群組,只討論「網頁設計」的主題,而原來的群組當作聯誼性質就好,但是被否決,那麼這個群組對我而言就沒什麼意義,沒多久就退出了。

其實仔細想想,我需要的是「資訊」及「節省時間的獲取方式」,那麼 Line 群組顯然不適合我,而原本就在使用的「論壇」、「討論區」才是最適合的:


所以,對於時間使用效益而言,Line 群組是遠遠比不上 PTT 討論區的。



二、成立「公佈欄群組」


回到一開始長輩面對的問題,每天要看一大堆曬小孩的圖片、早晚安圖、農場轉貼文,而且一整天看下來,幾乎群組裡沒有一句人話,我想只有很閒的人,才有辦法掃完所有的訊息。

若想成為時間的主人,需要一開始就把無用訊息隔離。我建議長輩跟群組的人討論,另外開一個類似「公佈欄」的群組,裡面只能有重要訊息、公告事項,不可以有任何聊天、轉貼訊息。

把「聊天群組」跟「公佈欄群組」分隔開來後,垃圾自動完成分類,不想看無用訊息的人,聊天群組都不點開也沒關係,很閒的時候再去點。

而「公佈欄群組」雖然有可能一整個禮拜都沒訊息,但只要有訊息,就知道一定是要事,不用像過去擔心有遺漏。



三、建立「待辦事項群組」


這個「公佈欄群組」的概念,其實功用遠比想像更大,這也是我最近才體會到的。

像我們這樣熟悉數位工具的使用者,已經很習慣各種同步的服務,例如「Evernote」,因此在各種情境、不同場合產生的待辦事項,我會立刻紀錄到 Evernote,避免忘了處理。而我如何過濾 Line 產生的待辦事項,可參考:


但是,我們的家人、朋友、同事,不一定熟悉 Evernote,也不一定有處理待辦事項的概念,因為一般人很習慣用大腦去記所有的事情,而大腦隨著年紀,記憶力下降是一定的,那麼會發生什麼事呢?


階段 1

有時明明已經用 Line 通知家人要處理某件事,但過幾天後詢問才發現,家人會說「啊!我有看到,但後來就忘了」

所以第一階段會教家人養成習慣,不要隨時點開 Line 訊息,確定你有空、會處理點開訊息的時候,才打開 Line 訊息,這樣可以確保下的指令會被執行。


階段 2

雖然家人養成了待辦事項的觀念,把未讀訊息當成待辦事項,但有時還是會預先點開訊息,為什麼呢?

有太多可能的狀況會打開未讀訊息,例如:

  • 對方有重要訊息要傳遞給我們
  • 要報平安、知會地點
  • 要問問題、溝通等事宜
  • 表達當下的心情、喜怒哀樂等

只要在沒準備處理待辦事項的時候打開訊息,就會有很大的機率忘記處理。

要怎麼解決這樣的狀況呢?


階段 3

此時前面提的「公佈欄群組」概念就可以派上用場,跟家人之間,可以另外建立一個「待辦事項群組」,只用來傳送 "待辦事項"、"交付任務" 等等,不要傳遞私訊、也沒有情緒

那麼報平安、問問題、短暫的溝通、心情表達等訊息,就留在私訊的頻道,如此可以跟重要的 "待辦事項" 隔離,不會混雜在一起。

歷經這三個階段後,終於可以跟家人之間,利用 Line 建立起正確的訊息傳遞機制。



四、Line@ 的功用


這篇「老師們,請別再用 LINE 群組與家長連繫!」的作法,在特定情境下也是值得參考的。

作者建議老師們利用「Line@」發佈訊息給家長,可以避免使用 Line 群組產生的紛擾,這也是將 "待辦事項" 與無用訊息隔離的概念,適合「上對下」、「一對多」的使用方式

如果是比較廣泛的「一對一」、「多對多」使用族群,則建議回歸本篇的「公佈欄群組」,可以完美的利用 Line,讓重要訊息得以從最有效率的管道、在最短時間內,傳遞給每個人。


更多 Line 相關文章:

利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案

$
0
0
chrome-ios-device-debug-tool.jpg-利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案前端開發非常頭痛的是,除了跨瀏覽器的問題,各種行動裝置的效果也可能不一樣。其中最麻煩的,算是針對蘋果 iOS 裝置進行偵錯 debug。

資本夠粗的話最好,各種蘋果筆電、平板、手機都買上一台。但 iPhone、iPad 的問題是,就算硬體有了,debug 流程也沒有 Windows 系統來得方便。

在網路爬了很多資料,本篇整理一個相對方便的流程,可在 Windows 下連接 iOS 設備,用 Chrome 開發人員工具進行除錯,提供給資本不雄厚的前端開發者參考。



一、各種環境的開發工具


個人感想是,使用「Chrome 開發人員工具」最順手,操作介面最流暢、強悍,還有各種裝置、尺寸的即時模擬效果。

1. 總整理

但很多蘋果系統的錯誤,畢竟是模擬器無法模擬出來的,這篇「在 Windows 建立各種瀏覽器測試環境」整理了各種不同環境的測試方式,非常值得參考。

不過因為內容較多,所以各種方案的細節比較精簡,要深入的話可另外 Google 關鍵字來尋找。


2. iOS 各種方案

如果習慣使用 FireFox 的話,可參考這篇「在Windows上對IOS Safari進行除錯」。

另一個可使用 Chrome 除錯的方案是使用 Weinre,可參考這篇「使用 Weinre 調試移動網站」,不過只能針對 HTML/CSS 除錯。

如需要針對 HTTPS 網站 debug,可參考「Remote Debugging Localhost With Weinre ( and HTTPS Too )

使用 MacOS 模擬器接 iOS 裝置也是一個方法,會另外發一篇心得,可先參考「用 VMware Player 模擬 MAC OS X 心得」來安裝模擬器。



二、準備動作


本篇的流程主要參考「RemoteDebug iOS Webkit Adapter」、「iOS Safari 用 windows debug」,不過需要注意的是,只按照這兩篇流程來做的話,多半會卡關。想要順利除錯的話,還是請按照本篇的作法。


1. 安裝 iTune

  • 這是最重要的一點,在 Windows 下必須安裝過肥大的「 iTunes」,因為需要蘋果的相關驅動程式,否則 Chrome 無法抓到 iPhone、iPad 等裝置
  • 安裝完後,讓 iTunes 測試一下能否連接 iOS 裝置就行
  • 沒問題後,將來用 Chrome 偵錯時,不必執行 iTunes 也沒關係


2017.12.7 補充:

如果對電腦操作很熟練、敢於嘗試,不怕惡搞 iTune 的話,以下是我實驗後可行的流程,只抽取必要驅動程式來安裝,可不必安裝多餘的 iTune:

  • 下載後的 iTunes64Setup.exe 檔案,可用 7zip 解壓縮,會看到很多 msi 安裝檔
  • 如果你使用 64 位元系統,裡面我們需要的只有 2 個檔案
  • 按照順序,先安裝 AppleApplicationSupport64.msi
  • 再安裝 AppleMobileDeviceSupport6464.msi
  • 這樣就行了,其他檔案可不理,繼續本文剩下流程


2. 安裝 NodeJS

  • 這也是讓我卡關很久的地方,請勿必上官網安裝「NodeJS
  • 因為我曾安裝過 node,就沒再上官網,結果導致怎麼試都不成功,後來才發現是 node 版本過舊
  • 為了確保之後的流程順利,安裝最新版的 NodeJS 比較保險



三、安裝流程


準備動作都完成後,開啟 Windows 的「命令提示字元」。

你也可以依照按這個流程:開始 → 執行 → 輸入 "cmd" → 確定


1. 安裝 RemoteDebug iOS WebKit Adapter

在「命令提示字元」視窗輸入以下命令:

npm install remotedebug-ios-webkit-adapter -g
接著就會開始自動安裝,完成後會提示已安裝了什麼內容。

如果你的 NodeJS 版本過舊,可能會出現以下畫面,要改安裝最新版本再來:

chrome-ios-device-debug-tool-1.png-利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案


安裝成功後,在「命令提示字元」繼續輸入以下命令:

remotedebug_ios_webkit_adapter --port=9000
代表開始監聽 port 9000,請等到畫面出現 "iosAdapter.getTargets" 的字樣。


2. 連接 iOS 裝置

  • 現在可以打開 iPhone,瀏覽器開啟你要偵錯的網頁
  • 將 iPhone 用 USB 連上電腦
  • 如果你是開發人員,相信會事先到 iPhone 設定 → Safari → 進階 → 開啟「網頁檢閱器」

chrome-ios-device-debug-tool-2.png-利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案

如上圖,過程中應該會出現幾個要求連線的視窗,一律允許即可。


3. 使用 Chrome 偵錯

打開 Chrome,網址列輸入以下:

chrome://inspect

點擊「Configure」,參考下圖:

chrome-ios-device-debug-tool-3.png-利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案

新增 "localhost:9000",按「Done」,這樣就大功告成了。



四、進行除錯


chrome-ios-device-debug-tool-4.jpg-利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案

如果沒出現上圖紅框的部分,也就是沒抓到 "RemoteDebug iOS Webkit Adapter" 的話,應該重整一下頁面就會看到了。

成功的話,紅框可看到 iPhone 上開啟的網頁資料,同時請按下「inspect」按鈕,會出現「開發人員工具」的畫面


chrome-ios-device-debug-tool-5.jpg-利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案

如上圖:

  • 左邊出現預覽畫面,只是不能直接操作,要由 iPhone 操作
  • 右邊的畫面都跟一般 Chrome 偵錯的狀態一樣,可看到 HTML/CSS
  • 要進行 JS 偵錯也可以,切換到「console」就可以了

雖然預覽畫面不能操作是個遺憾,不過能做到這樣,比起其他的 iOS debug 方案,我覺得已經很棒了,而且不必再搞一個 MacOS 系統出來,算是一個節省預算、又快速方便的極佳方案。


更多 Chrome 相關文章:

讓 Kindle DX 起死回生﹍更換電池(淘寶艱辛紀實)

$
0
0
kindle-dx-battery.jpg-讓 Kindle DX 起死回生﹍更換電池(淘寶艱辛紀實)去年 Kindle DX 壽終正寢後,改買 Kindle 8 作為替代品,操作上比較方便(觸控)、反應速度又快,可參考「電子書閱讀器 Kindle 8 購買及使用心得」。

前陣子在 HBO 看到「The Wire」,開始想追完這部經典美劇,同時練習英文。以前的作法是把字幕檔複製到 Kindle DX 上看,這次也試著複製到 Kindle 8。

結果讓我滿訝異的,K8 的檔案管理功能覺得很不順暢,把 PC 上按照每一季分類的資料夾複製過去後,字幕檔並無法直接分類好,甚至很難找到這些字幕檔。

若是用 Wifi 透過 Amazon 伺服器傳輸就更悲劇,除了有時間差、速度慢,且更不方便分類。

於是開始懷念起 Kindle DX,雖然是舊時代產物、沒觸控、沒 Wifi、速度慢,但是很重要的是有 9.7",裝了「多看」後檔案管理超級方便,因此想試試看能否把 Kindle DX 救活!

(圖片出處: pixabay.com)


一、找出故障原因


我的狀況是,Kindle DX 螢幕顯示電池已耗盡的圖示,但插上電源時,又無法亮燈,完全無法充電:

kindle-dx-battery-empty.jpg-讓 Kindle DX 起死回生﹍更換電池(淘寶艱辛紀實)


每個人故障的狀況及原因可能都不一樣,找到這篇「Why Kindle not Charging and How to Fix It」,把各種情形整理地非常詳細,讀者可參考自己的狀況來除錯。

我按照教學,把各種可能都嘗試過後仍然無效,只好猜測是電池的緣故,說不定換個電池就能繼續用了,於是開始找尋更換電池的方法,以及如何買到 Kindle DX 的電池。



二、購買電池管道


1. 在台灣拍賣網站都找不到電池賣家,放棄。

2. 國外有不少賣家,價格也不算貴,但考慮到運輸、聯絡都不方便,也放棄這個管道。以事後來看,幸好沒跟國外賣家買,否則有很大的機率也是收不到貨。

3. 在淘寶上找到幾個賣家,價格低到出乎意料,語言溝通更方便,很快就下單了:

  • 有幾個售價 RMB 28:標榜 Amazon 原裝電池,但我不敢買,除了價格比較便宜,我會懷疑是否拿回收官方電池來賣,電量會比較低。
  • 有一個售價 RMB 36:雖然售價高一些(反正還是很便宜),但至少可確定不是回收電池,也有保固一年。

讀者有需要的話,這是賣家網址「UP 旗艦店」,基本上買電池都會送拆卸工具組。

kindle-dx-battery-1.jpg-讓 Kindle DX 起死回生﹍更換電池(淘寶艱辛紀實)



三、拆卸 Kindle DX 外殼


更換 Kindle DX 說難不難,說簡單也不簡單。不難是因為網路可找到很多拆卸 Kindle DX 影片,依樣畫葫蘆即可,例如參考以下影片:




不過沒有適當的拆卸工具就進行的話,由於 Kindle 外殼是很脆弱的,不小心就會造成毀損。

像我就是找了起子來拆,結果把 Kindle DX 挖了個洞...


kindle-dx-battery-2.jpg-讓 Kindle DX 起死回生﹍更換電池(淘寶艱辛紀實)


其實買 Kindle DX 都會附工具,所以耐心等包裹寄達,用專門的塑膠起子來拆外殼,這件事就沒那麼困難了:

kindle-dx-battery-3.jpg-讓 Kindle DX 起死回生﹍更換電池(淘寶艱辛紀實)



四、電池是違禁品


1. 無法出關

等待包裹的過程可說是一波三折,從淘寶下單後好幾天,發現電池怎麼在一直集貨倉,根本沒有運到台灣。請賣家去問才發現,電池類的物品要出關很麻煩,幾乎是出不了關的。

後來賣家建議走私人的集貨運輸,也就是非官方的運輸方式,但是淘寶沒有操作的介面,必須自己跟私人集貨運輸公司聯絡,這又是個大工程,總之只好先跟賣家走退訂流程,等搞清楚怎麼進行後再來。


2. 處理退款

基本上淘寶的操作介面做得很好,流程也很直覺方便,不過退款這部分讓我卡關很久。

電池退款很簡單,介面上很容易找到選項,但會卡關的地方是運費。

當貨品入倉後,運輸公司會要求我們付清運費後,才會進行入關及海外段的運輸。

但這筆運費等到取消訂單後,在淘寶的介面跟本找不到「退還運費」的選項,藏得非常深。

在這裡紀錄一下「退運費」的網址,可在這裡找到選項,將來就不用翻箱倒櫃:




五、私人集運公司


這裡算是最後的補充,所有從淘寶購買、不能運送到台灣的物品,交由私人集運公司處理,通常就沒問題了,也會更快速。

可參考以下幾篇文章:


前面兩篇有比較詳細的教學、比較不同公司的優點。

我是直接使用「一路發」這一家,運送的物品記得勾選「含電池、粉末...」這一項,他們就會幫我們處理了,可以省去很多通關的麻煩。


更多 3C 產品相關心得:

Iframe 跨域傳值在 iOS 失效的解法﹍利用網址 + localStorage + cookie 並用

$
0
0
上一篇「利用隱藏的 Iframe 跨域傳送訊息實作」,很可惜在前端開發人員的大魔王(iOS)面前又失效了,在 iPhone 鬼打牆了很久才瞭解:

  • iOS 禁止 localStorage 跨域傳值
  • iOS 的 Safari 設定中,預設關閉 cookie
  • iOS 的 Chrome 跟一般 Chrome 不太一樣,封鎖了跨域的 localStorage 儲存

除非前端開發人員敢在網頁顯示提示訊息,例如建議「不要使用 iPhone、iPad」、或是「不要使用 Safari」、或是「iPhone 下不要用 Chorme」,否則遲早要面對、解決以上這些狀況。

以下紀錄如何處理這些難題的過程、以及範例程式碼。

(圖片出處: pixabay.com)


一、利用網址傳值


1. Safari 的預設選項

測試 iPhone 裝置的除錯工具,可參考這篇「利用 Chrome 對 iOS 裝置進行除錯(iPhone、iPad)的絕佳方案」。

根據這個討論串「Iframe localStorage on Safari and Safari mobile」,Safari 瀏覽器的設定中,雖然有「允許使用 cookie、允許跨域」的選項,但預設值竟然是關閉的,所以開發人員很可能測試半天也找不出無法跨域的原因。

但就算我們開啟了 Safari 跨域的選項,不代表其他使用者知道要去開啟這個選項,那麼我們做的網頁依然無法使用。


2. 利用網址傳值

還好有看到這篇「localstorage的跨域存储方案」提出了很棒的構想:

  • 利用網址參數傳值

把要傳送的數值放在 Iframe 裡面的網址,當成參數傳遞,就可以完美地繞過 localStorage 與 cookie 的限制!



二、iOS 的 Chrome 跨域問題


利用前述的「網址傳值」技巧,在 iOS 的 Safari,可以成功把跨 Iframe 傳的值,儲存在 localStorage 使用,不過接下來的關卡是 "iOS 的 Chrome"。

很神奇的,Safari 可以把傳過來的值儲存在 localStorage,但 Chrome 竟然無法儲存在 localStorage。說白話一點,iOS 下的 Chrome:

  • 可以儲存任何 localStorage
  • 唯獨 Iframe 跨域網址傳過來的資料,無法存在 localStorage

這個現象實在不知如何解釋,但又不能叫 iOS 使用者不准用 Chrome。

幸好還是發現了解決方法,Safari 預設會封鎖 cookie,但 Chrome 是不會封鎖 cookie 的。所以完美的解法就是,Iframe 用網址跨域傳遞的值:

  • Safari 存在 localStorage
  • Chrome 存在 cookie



三、範例程式碼


以下提供範例:

1. 母視窗

<!--載入 query-->
<script src="//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>

<!--跨域 IFRAME-->
<iframe id="WFU_frame" src=""></iframe>

<script>
(function($) {
// 網址先編碼
var token = encodeURIComponent("第一筆資料"), // 填入跨域資料
userId = encodeURIComponent("第二筆資料"), // 填入跨域資料
href = "http://demo.wfublog.com/p/cross-domain-postmessage-iframe.html", // 填入跨域網址
search = "token=" + token + "&userId=" + userId, // 網址傳值參數
iframeSrc = href + "?" + search; // 完整 iframe 網址

// iframe 網址傳值
$("#WFU_frame").attr("src", iframeSrc);
})(jQuery);
</script>

修改說明請參照註解文字。


2. Iframe 頁面

<!--載入 jquery cookie-->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.4.1/jquery.cookie.min.js"></script>

<script>
// 分解網址參數 字串先解碼
var searchSet = decodeURIComponent(window.location.search).substring(1).split("&"),
i, token, userId;

// 從網址找出跨域傳值
for (i in searchSet) {
if (searchSet[i].indexOf("token") === 0) {
token = searchSet[i].split("=")[1];
}
if (searchSet[i].indexOf("userId") === 0) {
userId = searchSet[i].split("=")[1];
}
}

// 跨域傳值寫入 localStorage, for Safari
localStorage.token = token;
localStorage.userId = userId;

// 跨域傳值寫入 cookie, for Chrome
$.cookie("token", token, {
expires: 365,
path: "/"
});
$.cookie("userId", userId, {
expires: 365,
path: "/"
});
</script>

修改說明請參照註解文字。


更多 Javascript 相關技巧:

部落格從搜尋引擎而來的流量,是不會有感情的﹍找回經營網站的動力

$
0
0
近期製作網站需要大量使用 Bootstrap,因此寫了不少「Bootstrap 相關文章」,其中這篇「Bootstrap 3 & 4 速查表」,曾介紹 kkbruce.tw 製作的繁中版說明書。

有次搜尋相關資料時,又跳到了 kkbruce.tw,可見這個網站吃下了多數 Bootstrap 關鍵字,但赫然發現作者已將他翻譯的中文版內容下架了!

看了作者的公告,原因大致是:

  • 網站提供了多種留言管道,但訪客都不留言
  • 少數幾個收到的郵件內容,是寫信去抱怨、指責
  • 辛辛苦苦的付出得不到鼓勵,反而只有負面的回饋

因為歐美(西方)的風氣屬於「加分教育」,訪客會習慣留言感激、讚美;台灣(東方)是「減(扣)分教育」,訪客多數是有問題、抱怨才會留言。kkbruce 這個事件真的是大環境使然,若會改變也可能是一個世代以上的時間。

身為站長,該怎麼看待訪客留言這件事會比較好呢?

(圖片出處: pixabay.com)


一、寫網站的動力


為什麼遊戲可以讓人上癮,有動力不吃不喝一直玩下去呢?因為好的遊戲在設計上,會很快速地提供正面的回饋機制。例如做了正確的事就能得到金幣、有清脆的響聲等等,誘使玩家不斷地產生動力、持續想要獲得回饋

FB 也有類似的設計,不斷增加的通知數、留言數,這些都是會讓人上癮的回饋。

寫網站可能會獲得哪些回饋呢?

  • 每天的瀏覽數據增加
  • 廣告點擊數、收入增加
  • 訪客的留言互動

這些回饋都可能成為支撐我們寫下去的動力之一。

有時想想,照顧網站也很像是照顧寵物,給我們的互動、回饋越多,就照顧地越起勁。

直到有一天,數據減緩了、收入減少了,甚至沒人留言、或是留言都是負面情緒時,可能就會萌生停筆、關站的念頭。



二、哪些網站容易有回饋?


雖然寫部落格的門檻很低,現在越來越多人加入,不過我真心覺得,不是每個人都適合寫,也可以說不是每個人都能寫的好,又或者說,不是每個人都能適應寫網站的回饋機制。

寫文章想要獲得好的回饋,想要有良好的留言互動,我認為有這三個先天條件比較容易:

  • 專家
  • 好文筆
  • 放棄隱私

三者非全部必要,只要有一個就足以出頭。


1. 專家

如果本來就是某個領域的專家,想必已經具有知名度,所寫的內容接受度一定極高,自然會有很多讀者推崇、求助等等,這一點可不用多著墨。


2. 文筆

寫網站是利用文字來打動人心,我認為具有好文筆的人,在三個條件之中,寫部落格最容易成功。

如果念的是文學院,文字駕馭能力超越一般部落客,能夠短時間量產文章,同時內容又更有渲染力,讀者實在很難不產生共鳴。

一個很好的例子,「電腦玩物」 +esor huang 就是這樣的背景,我相信所有數位資訊類的部落格,讀者最喜歡閱讀的,一定是 Esor 的文章,同時「電腦玩物」也一定是同類型網站中,留言互動最多的。


3. 放棄隱私

相信願意拋頭露面的站長,可以比較拉近與讀者的距離、增加信任度,除了網站人氣比較高,自然也容易與粉絲有互動。



三、哪些網站不容易有交流?


如果不是前面提的三個條件,真的要非常努力才行。而如果網站內容屬於 "教科書式"、"XX攻略" 這一類的話,由於內容比較死板,很少能有發揮文字功力的地方,讀者就不一定有忠誠度了。

其實多數屬於「資訊提供」的網站,都會有這樣相同的情形,訪客主要的流量來源是搜尋引擎,找到資料就會離開,不太會有什麼交流的想法,所以站長很難得到正面的回饋。

除非你寫的資訊量十分龐大,多到變成資料庫等級,訪客怎麼搜尋都會跑到你的網站,經年累月下來,網站名稱才可能被訪客記住。由於受到的幫助很多,哪天想到就有可能跟站長留言道謝。



四、如何獲得回饋


如果沒有三大要件,網站很難撐到出名,因為沒有夠多的回饋,早就喪失動力而陣亡了。

但是為了獲得各種形式的回饋,我看到很多站長找偏了方向,例如:

  • 想要藉由 SEO 來增加流量
  • 想要看到廣告收入數字的上升,而放了很多廣告

如果是本站忠實讀者,相信知道我不斷勸導少花時間在 SEO 上,例如可參考「部落格網站是否加強 SEO 就能帶來流量?」,因為我建議把時間花在更重要的事。

而廣告過多這件事則是會帶給讀者不佳的閱讀體驗,短期或許可增加收入,長期來看是打壞網站的招牌。

在獲得回饋這件事上,我的建議是:「盡量把自己抽離網站,真正的回饋不在網站上



五、短期目標


前面提的三要件,可能多數人一開始都不算是,但我們有沒有可能取得這些要件呢?

或許一開始我們都會把目標擺在自己的部落格成長,所以回饋也是在網站上尋找。但如果目標擺在自己身上,「追求自己的成長」,是不是就不會因為部落格而失落了呢

三要件裡面,只有不推薦把「放棄隱私」當成目標,因為這是短期快速獲利,但無法走得長遠的作法。


1. 成為專家

或許一開始我們只是對某個領域有興趣,而開始玩票性質的寫作。

但如果把 "成為專家" 當成目標,自然會蒐集、研究、分析更多這個領域的主題,同時還要想著如何用簡單明瞭的文字,讓讀者能夠理解。

當自己寫得越多,對這個領域懂得越多,這樣子的滿足感,整個成長過程就會是很好的回饋。


2. 精進文筆

這一點比較困難一些,甚至要有一些天分,不過至少可以先從有條理地表達想法,讓文章架構有組織、脈絡可循,內容可以被讀者吸收這些來做起。

其實這些能力不需要做到頂尖,經由觀摩、訓練、上課都可達到一定水平。

我相信把時間花在以上這兩件事上,也就是投資自己,所獲得的會遠比花在網站本身更好。



六、長期的回饋


投資自己的好處是,成為某領域的專家後,部落格就成為了我們的品牌

跟實體店面招牌不一樣的是,店面招牌只有路過的人會看到,而網路的招牌,24 小時都可能有人搜尋、慕名而來。

友站「小說界的李洛克」原本在部落格教導如何寫小說,算是很冷門的領域,但 +李洛克 的文章內容絕對是這領域的專家,再加上 "寫小說" 先天就具備的 "文筆" 加成(其實他三要件都具備),因此獲得了實體出版社的主動邀約及給職。

而「電腦玩物」也是忙於各種演講邀約、開課、出書,這代表網站給予我們最大的回饋,會是在實體世界的各種機會



七、小結


只要眼光放遠,為自己建立長期規劃,就不會被眼前短暫的網站回饋所限制住。到頭來你會發現,若能成為某領域的佼佼者,部落格的實質意義,就成了我們的一個行銷工具,而不再是需要照顧的寵物。

寫部落格也非常多年了,歲末有感而發,提供一點小小經驗,讓新手站長們可以參考,能夠找到如何走下去的動力。


更多 SEO 相關文章:

電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得

$
0
0
paperlike-pro-eink.jpg-電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得為了解決眼睛長時間看螢幕會不舒服的問題,十多年來一直關注「非背光」螢幕顯示器的發展,以及各種解決方案。除了買過各種廠牌、尺寸的「電子墨水 Eink 產品」,去年也買過淘寶賣家自行改裝的「10吋 富士通反射屏」黑白顯示器。

前兩年也關注過「大上科技」的電子墨水顯示器 paperlike,但一方面售價極為昂貴,另外最主要的是,電子墨水拿來當顯示器有先天無法克服的技術問題,例如反應時間、殘影需要不斷刷屏等。

而 10" 富士通反射屏這段時間使用下來,可以長時間打字、查資料、寫 code。但是不方便的地方在於,前端開發需要常常使用「Chrome 開發人員工具」來查看網頁內容、除錯,但 10 吋實在無法沒有足夠的空間來顯示除錯工具內容,因此有必要使用更大的顯示器。

前陣子再次關注大上的電子墨水顯示器,發現已經推出第二版,而且展示效果超乎預期,雖然一樣是天價,但基於工作、健康,還是咬牙下了單。

這樣的產品全世界就這麼一家中國公司在研發,由於產業不算成熟,因此購買前也做足了心理準備,有最艱辛、最壞的打算。沒辦法,眼睛無法對抗 LED 背光,所以就來充當白老鼠,擔任先鋒測試員吧。

(圖片出處: dasung.com)


一、Paperlike Pro 展示效果


根據「百度貼吧」查詢的使用經驗,第一代 Paperlike 有不少問題,結論是只有 Win7 比較可以使用。

前陣子 2017 年底出的二代產品 Paperlike Pro 最新版(carta 螢幕),除了各平台相容性較佳,還支援了 HDMI 接頭,還免驅動程式(這一點讓我比較好奇)。

從這篇「入手大上paperlike pro无锁版感受」的使用心得,看起來是可以一試的產品。

所謂「無鎖版」需要說明一下,Paperlike Pro 出了兩個版本,標準版在一定時間後會進入螢幕保護模式,而無鎖版不會,可參考「官方說明」。



上面是官方放在 Youtube 的宣傳影片,顯示器的效果十分令我驚艷,讓人感覺不出電子墨水的傳統效果,反應非常快、殘影不明顯,竟然還可以流暢地捲頁,讓我購買信心增加不少。



二、淘寶購買紀實


1. 下單

官方在淘寶的下單網址在此:


我是選擇「無鎖版」,螢幕的保固期限短很多,但長時間使用比較不會被打斷作業

由於單價非常高,RMB 5199 將近台幣兩萬四,手續費相對也很高,記得參考「國外網站用外幣刷卡購物,要哪種信用卡、如何處理,匯率+手續費才能最划算?」→「六、淘寶刷卡也很可怕」,用網路 ATM 轉帳手續費會便宜很多 (1%)。

同時我選的是預付海外運費,省得進倉時還要追蹤再付一次錢。


2. 溝通聯絡要主動

大上是一家公司,不是一般積極的淘寶賣家,不會有專人一直在顧訂單,因此我就遇上鳥事,說是 24hr 會出貨,結果下單付錢過了四天,淘寶上面的紀錄依然是「待出貨」。

產品下面留了言問是什麼狀況結果被刪,發私訊沒回應,請淘寶催出貨也沒下文,簡直氣炸了,當下認為這家公司可能做不出貨在擺爛。

等到我準備去退貨時,發私訊忽然間跟大上聯絡上了,結果竟然跟我說付錢的隔天就出貨了,現在應該在深圳倉庫(北京發貨)。

中間還有一大段故事,因為不知道這類產品會不會卡關、而無法出到台灣,所以準備退訂、改走自己的集運公司,還好最後結果沒事,就省略不提了。

後來跟轉運公司聯絡上,查詢的結果跟我說有收到貨,但要求我付海外運費,但我明明海外運費已經預付了啊??

最後搞了半天,原來大上的出貨狀態一直沒更新,過了那麼久依然是「待出貨」,所以轉運公司也查不到紀錄,不知道我有沒有付運費。

總之給讀者一個提醒,跟不成熟的公司下單,真的自己皮要繃緊一點。


3. 收貨

持續追蹤轉運到台灣的狀態,還好一路順利,很快貨就送上門了。但下單後的倒楣事太多了,加上產品又是高單價,所以提醒讀者,快遞上門後,產品拆封之前記得全程錄影,以免橫生枝節。



三、開箱心得


1. 開箱

收到包裹後,產品外盒包裝還滿有質感的。不過接下來不準備一一放開箱照片,以免篇幅太長。


需要看開箱圖片的讀者可參考這個國外網友的影片,內容物不完全一樣,因為出貨有分國外版本。


2. 螢幕會反光

使用後才發現,Paperlike Pro 螢幕竟然會有點反光,猜不透大上在想什麼,使用電子墨水就是要保護眼睛,為何還用這樣的材質呢?

我一向在任何螢幕都不喜歡用保護貼,無論是手機、平板、筆電。Paperlike Pro 是有附上保護貼的,而且發現品質還滿不錯的,擠壓空氣效果不錯,也很好貼,所以建議一定要貼。

據說另一款產品 Paperlike HD 是磨砂屏、不反光,但售價多了 RMB 800 左右。


3. 說明書

內容很簡陋,很多使用者該知道的操作、說明、系統顯卡最低要求等資訊都找不到,真的很有當白老鼠的感覺。


4. 支撐腳架

paperlike-pro-1.jpg-電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得

說明書兩光的結果,導致附的腳架不知道如何組合,研究了半天才抓到訣竅。請參考上圖,如果能組成這個形狀,就代表成功了,趕快用螺絲起子鎖緊。



四、安裝螢幕


終於到了可以正式安裝螢幕的時刻,接下來又是災難的開始...

1. HDMI + USB

這個螢幕需要同時接 HDMI 及 USB 接頭,所以我們的電腦除了原本的顯示器插頭,最好有額外的 HDMI 可接。官方 FAQ 有說,不要使用 HDMI 分接器。

由於這個螢幕不需要電源,那麼供電完全靠 USB,所以最好準備一個獨立的 USB 3.0 接頭,確保電源穩定。如果有 USB 轉電源的插頭,也可直接把 USB 接到電源。


2. 硬體設備要新一點

我的兩台準系統都是 3~4 年前買的,設備不算新,分別測試的結果裝上螢幕後都抓不到,無法顯示畫面。

趕緊另外測試 2017 年才買的筆電、Win10 系統,結果依然抓不到這台螢幕,一度讓我覺得買到機王了。

由於說明書沒有最低顯示卡要求的資料,現在想想,當初看到「免驅動程式」這件事,結果成了大問題,到底是機器有問題、還是電腦沒有驅動程式才抓不到螢幕,根本無法判斷。

特地到官網下載了所有相關程式,可惜沒有半點作用。準備退貨的前一刻,決定作個最後測試,不成功就放棄了。


3. 更新顯示卡驅動程式

我的兩台準系統,一台顯卡為「HD Graphics 4000」,另一台則沒有顯示(為系統預設值)。於是上網找了「HD Graphics 4000」最新驅動程式來安裝,重開機後,竟然可以抓到 Paperlike Pro 了!!

從這件事大概瞭解為何免驅動程式了,原來靠的是現成顯卡的驅動程式,這也代表大上若想要節省成本,開發環境只測試比較新的機器,而不管舊機器的相容性,那麼使用者就要小心了,家裡的電腦、顯示卡要夠新才行。

而我的筆電,可能沒有獨立顯卡,導致也沒有新的驅動程式可用,所以雖然是很新的筆電,一樣抓不到 Paperlike Pro



五、基本操作及設定


歷經一波三折後,也可以說是上天眷顧,我終於可以開使用 Paperlike Pro 了,看到清晰的黑白畫面還滿感動的。

以下放兩張寫 code、及上 PTT 的畫面:

paperlike-pro-2.jpg-電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得

paperlike-pro-3.jpg-電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得

螢幕上方還是要放個檯燈,眼睛看起來會更舒服

接下來說明一些基本操作及設定:


1. 官方軟體

建議一定要到官網下載軟體:



paperlike-pro-4.png-電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得

執行後,出現上圖視窗,個人習慣使用「A2」模式,畫面看起來比較乾淨,就是單純的黑白兩色畫面,缺點為看圖片是悲劇。

不過要看圖片時,windows 系統再按 Win+P 快速鍵切換到彩色螢幕就好,不算大問題。

其他模式看圖片比較清楚,但我不喜歡背景灰灰糊糊的感覺。


2. 軟體設定

按下「Paperlike Pro Setting」可進入設定畫面

paperlike-pro-5.png-電子墨水 (E-ink) 護眼顯示器 Paperlike Pro﹍(1) 入手及開箱心得

建議如上圖設定就好:

  • Alt + R 這裡是自訂快速鍵,可用熱鍵刷新螢幕。不過其實用不太到,因為螢幕殘影不嚴重,這是需要誇獎的地方
  • Contrast 這裡可以調整對比,尤其在 A2 模式下,如果常用的程式顯示效果不佳、不清楚,建議來這裡調整
  • 下面兩個自訂的快速鍵 "Ctrl+,"、"Ctrl+.",可以用熱鍵調整對比程度
  • Save setting 記得要勾選,否則每次都要重新設定


3. Windows 佈景改為黑白

如果跟我一樣比較喜歡 A2 模式,建議將 Windows 佈景配色改為黑白,這部分的操作可參考「護眼神器富士通反射屏﹍讓 Windows 作業環境最佳化」→「一、切換雙螢幕佈景主題」。


4. 關閉系統特效

最後要做的動作是,Windows 下進入控制台,找出滑鼠、系統相關設定,把 Windows 預設的一些特效都關閉,例如陰影、動畫等等,也就是讓畫面有最簡單的呈現,不要有任何渲染的效果,可以讓電子墨水看得更清楚。


以上的內容很長,做到這裡終於可以使用這台顯示器來作業了。提醒一下,這樣的螢幕我想不會適合大部分的人使用,可能文字工作者、工程師這類需要長時間作業的族群比較需要

在 Windows 下的軟體使用、環境調校等心得,留待下一篇分享。


更多 Eink 產品相關文章:

滑動開關切換按鈕﹍CSS 語法產生器

$
0
0
on-off-flipswitch-css.jpg-滑動開關切換按鈕﹍CSS 語法產生器最簡單的切換選項效果,是使用 Input 元素的 radio 型態,也就是單選(非複選)的效果,長得像這樣:



之前接到一個需求,希望切換效果做得有質感,像是蘋果系統的切換按鈕,例如下面的範例:



原以為這樣的效果,需要用 JS 才能做出來,沒想到純 CSS 就能有很棒的效果,請見本篇的介紹。



一、Proto.io


Proto.io 是一個收費的網頁服務,不過也提供了一些免費的小工具,其中這個是本篇要介紹的 CSS 語法產生器,能做出各種美觀的滑動切換開關按鈕:



進入網頁後,馬上就有一個 DEMO 切換按鈕可以看效果,同時也提供了各種參數可以自訂:

on-off-flipswitch-css-1.jpg-滑動開關切換按鈕﹍CSS 語法產生器

  • Style: 這裡有四種樣式可以選擇,例如選 iOS10 的話,就是 iPhone 常見的開關效果
  • 其他不管是字體大小、各種底色等 CSS 設定,都可以自訂
  • 上方都會出現即時的預覽效果
  • 下方也會出現即時變更的 CSS、HTML 程式碼

調整出滿意的效果後,直接複製 HTML、CSS 就可在網頁上使用。



二、範例效果


以下提供一個範例,說明比較重要的修改之處。




程式碼:

<div class="center">
<div class="switch_demo">
<input type="checkbox" name="switch_demo" class="switch_demo-checkbox" id="switch_demo" checked>
<label class="switch_demo-label" for="switch_demo">
<span class="switch_demo-inner"></span>
<span class="switch_demo-switch"></span>
</label>
</div>
</div>
<style>
.switch_demo {
position: relative;
width: 150px;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
}
.switch_demo-checkbox {
display: none;
}
.switch_demo-label {
display: block;
overflow: hidden;
cursor: pointer;
border: 2px solid #999999;
border-radius: 20px;
}
.switch_demo-inner {
display: block;
width: 200%;
margin-left: -100%;
transition: margin 0.3s ease-in 0s;
}
.switch_demo-inner:before,
.switch_demo-inner:after {
display: block;
float: left;
width: 50%;
height: 30px;
padding: 0;
line-height: 30px;
font-size: 14px;
color: white;
font-family: Trebuchet, Arial, sans-serif;
font-weight: bold;
box-sizing: border-box;
}
.switch_demo-inner:before {
content: "開啟";
padding-left: 10px;
background-color: #34A7C1;
color: #FFFFFF;
}
.switch_demo-inner:after {
content: "關閉";
padding-right: 10px;
background-color: #EEEEEE;
color: #999999;
text-align: right;
}
.switch_demo-switch {
display: block;
width: 18px;
margin: 6px;
background: #FFFFFF;
position: absolute;
top: 0;
bottom: 0;
right: 116px;
border: 2px solid #999999;
border-radius: 20px;
transition: all 0.3s ease-in 0s;
}
.switch_demo-checkbox:checked + .switch_demo-label .switch_demo-inner {
margin-left: 0;
}
.switch_demo-checkbox:checked + .switch_demo-label .switch_demo-switch {
right: 0px;
}
</style>

  • 紅字的地方,"開啟"、"關閉" 就是原本預設會顯示 "ON"、"OFF" 之處,可改為自訂字串。
  • 如果要修改整個開關的寬度,那麼直接改藍字這裡,版面效果會不如預期。最好直接從官網的項目 "Sizing" 這裡,直接調整寬度(width) 的值,再複製產生的 CSS 即可。



更多 CSS 相關文章:

從小編到總編之路﹍如何成為部落客中的佼佼者

$
0
0
how-to-become-top-blog-writer-從小編到總編之路﹍如何成為部落客中的佼佼者前陣子這篇「部落格從搜尋引擎而來的流量,是不會有感情的﹍找回經營網站的動力」寫完後,有位美食部落格客戶,同時也算本站長期讀者,問了一些 SEO 問題。其實滿訝異的,既然是忠實讀者,想必知道我希望讀者將注意力放在 SEO 以外的地方。

瞭解她詢問的原因後,覺得這段對話可以看到一些普遍性的現象,並非只是個案,值得探究哪些站長會特別關注 SEO。

但是與這位老朋友的對話也讓我瞭解,事情的發展、環境的因素,很多時候無法按照正規步調走,因此被迫需要注重 SEO、與其他網站競爭 SEO 細節。

既然商業為主的部落格很多,我會另外為這個族群寫相關的 SEO 文章。而本篇依然會藉著對話讓讀者瞭解,如果有機會走正規途徑的話,不強調 SEO 的力量才是最強大的

(圖片出處: pixabay.com)


一、成為佼佼者


1. 成功三要件

先複習一下上一篇,我認為網站要出人頭地,最好有以下三個條件之一:

  • 成為專家
  • 有好的文筆
  • 具備顏值

如果靠顏值,光是「佼佼者」的等級還不夠,可能要達到「頂尖」,因為永遠有更年輕的正妹、小鮮肉出現。

不管是哪一項,我們都要讓自己的能力或條件成為「佼佼者」,至少要把「佼佼者」當成目標來努力。


2. 進行差異化

很多時候,光是成為佼佼者還不足以出頭,因為該領域的佼佼者實在太多了。就像 MLB 美國職棒、NBA 籃球,滿山滿谷都是萬中選一的練武奇才,體能勁爆成了只是基本條件而已,這時怎麼辦呢?

當體能不再成為出頭的優勢時,必須讓自己的優點跟別人不一樣,自己有的別人沒有、自己會的別人不會,也就是進行「差異化」。

看別人寫懶人包效果很好,所以跟著寫懶人包,這樣就不是差異化了,因為無法成為佼佼者,至少要是不同角度、或是不同表現手法的懶人包。

只要能想出跟別人不一樣的特色,往那個方向前進,因為這條路走的人不多,你就是這條路的佼佼者。

「差異化」在實質上,也是成為「佼佼者」的一種方法。



二、如果不是佼佼者的話呢?


前面這麼強調成為「佼佼者」的重要性,或許還不足以讓你行動,因為看起來很像在寫作文、唱高調,對吧?

那我們來看看沒有成為佼佼者,會有什麼樣的際遇。


1. 業務

很多老闆都是業務出身,一開始也許在公司當業務,把所有業務技巧都學到後,跟客戶關係也打好後,覺得能力夠了便自立門戶,甚至客戶也會跟著他出走。

可以想像一下,不是頂尖的業務,敢自己開公司接單嗎?不要說搶別間公司的生意,自己就被客戶吃死玩死了。


2. 社會底層

所謂低端人口,很多其實不是資質不夠,而是出於無奈,家裡沒有資源讓小孩唸書,或是需要補貼家計被迫提早進入社會。

在條件不如人的情況下,無法選擇較好的職業,或是為了錢而不得已走偏鋒。

如果有足夠的資源、時間,社會底層的孩童一樣有辦法培養成佼佼者,是可以出頭的。


3. 學徒

想像一下身為學徒,經過數年辛苦的學習,終於熬到出師可以自立門戶,憑著專業技能與知識,相信開業後的問題不大,屆時需要再進修的比較會是行銷、管理觀念,就像吳寶春一樣。

如果還沒全部學成就想著要賺錢、開餐廳,手藝不如人的情況下,客人一吃就知道底細,很難有回頭客。

但是店開了總不能輕易地關,於是想盡辦法靠關係、拉客人上門,例如打折優惠、買廣告宣傳、重新裝潢門面、找正妹當櫃臺...,也就是用盡各種行銷手法。

這些優化業績、優化帳面收入的手段短時間內會有效,但長期呢?沒辦法養出一批忠實客戶,由於經濟壓力家有老小要養,只好無止境地想新手法拉(拐)客人,這是一個痛苦的循環。已經沒有時間回頭重新學藝,只能想辦法把手上這副牌打好。

如果有機會重來一次,如果可以有選擇權的話,你會希望經歷學徒成長過程短期的痛,還是經歷過早投入商業戰場長期的痛?



三、精實創業


1. 創業概念

之前在這篇「部落格網站在那個階段,需要開始加強 SEO?」提到「精實創業」的概念,先讓部落格在市場上具有競爭優勢,確認你的產品是成熟、可以存活下去時,那麼就可以來談優化,例如加強 SEO、行銷宣傳廣告等等;反之的話,過早優化就是資源錯置。


2. 競爭優勢

如果認為自己可以出師了,可以開業賺錢了,我會希望站長們問自己一個問題:

  • 部落格的核心競爭優勢是什麼?

網站的「利基」是什麼?網站的什麼主題、有何特性足以成為佼佼者?有什麼是其他網站沒有的?

只要能夠回答得出來,我大力支持你開始研究 SEO 優化,撥預算買廣告行銷。


3. 充實自己、立定方向

如果還回答不出來,或是其實你早有努力的方向,只是還沒達到目標,那麼我會建議別急著過早投入商業活動,別急著開店,別急著優化網站,先把時間花在讓自己成為佼佼者。

我相信多數的部落格站長,一開始寫網站應該是出於分享,出發點不是為了賺錢,那麼手中應該是握有選擇的權利,不是被環境所迫要開始營利。

技能、專業的養成需要時間,多給自己一些時間,培育期是很辛苦,但不會比揠苗助長來得痛苦。



四、讀者對話


說完前言,以下進入正題,這是與讀者之間的對話。

我看得出你的觀點 你就是覺得太多人瘋SEO了 從最新的文就看得出來 只是,我們多少都希望綜合分數一點 我也不是要走邪魔歪道~哈哈

感到欣慰,覺得我的文章還是有起到一點作用~


我覺得~我們不是要用SEO去爭贏別人文章寫得比較好的、或是明明就是別人觀看人數比較多的 我真正怕的是.....我們慢到,已經是google的處罰 或著列為差勁的網站

如果真的害怕網站速度慢,那麼我的「網站效能」相關文章可找到解決方法,例如減少圖片、少放廣告及外掛。

比較麻煩的是,美食旅遊網站需要高品質圖片,圖片可選擇的壓縮程度有限;當網站需要廣告營收時,會無法割捨廣告的數量;為了行銷功能需要裝各種追蹤成效外掛、平台聯播外掛等,也是不容易放棄。

進入商業營收模式後,是另一套玩法,需要捨得撥預算請專業人員規劃廣告、取捨外掛。


你的新文寫得很明確,如果我在美食界如同你在電腦界一樣,至少blogger你是第一名,那我就不用在意SEO。我甚至連圖片都不用在意,因為很多文章是你有能力寫出來,別人根本寫不出來,那你SEO分數在差,你的文章質量就是好,甚至沒競爭者,你當然就不用擔心那些需要微微調整的數據上,你甚至真的要專注,只要在體驗上就好,然後王道就是寫出能夠解決消費者問題的文章。

但我不一樣,我只是個遍佈都是的美食部落客,很多時候比來比去照片文字可能都差不多,我一點也不會奢望用SEO來加分,只希望做到不是被扣分的,所以我看到紅字,才會又緊張了起來,但我自己也清楚知道,是我自己要裝很多外掛讓自己變輕鬆讓使用者體驗變好,但程式我們沒那麼懂,總是想再問問會不會有速度改善的不一樣的可能

事實上,美食的領域,可以寫出差別性的文實在太有限了,除了FB外
如果單靠部落格這件事,照片技術精進是很需要美感
也很需要訓練跟經驗的,一定大家都在進步中
但不會有突然多大的改變 文字就真的大家差不到哪裡去了

這段陳述我相信是實情,有時網路上搜尋美食資訊時,其實也真的很少看到讓我印象深刻的網站或文章,畢竟使用者目的只是要獲得資訊而已。這類型的網站要冒出頭並不容易,進入門檻不高,競爭激烈程度可以說是刀刀見骨。

因為我的個性不喜歡做跟別人一樣的事,所以很佩服敢投入完全競爭市場的參與者。不過我想鼓勵讀者,準備好後再上,或者也可選擇不上。如果已經準備在殺戮戰場跟別人輸贏,真的需要先釐清自己網站的優勢有哪些?有哪方面可以稱得上是佼佼者?

上一篇有提過,三要件裡面,只有不推薦把「顏值」當成目標。不少旅遊美食網站是靠顏值崛起,一開始可以讓網站快速到達一個高度,起跑點也算是比其他網站前面。不過更年輕的正妹永遠不會少,這類網站成長曲線一段時間後可能就會趨平。

那麼時間拉長來看很容易陷入一個困境,網站經營沒多久就因為可以獲利,而過早進入商業模式。一般部落格在起步時有很長一段時間可以自我成長、累積實力,而進入商業模式後就是收割時期,已經不允許請假一年出國充電、培養自己成為佼佼者,因為網站開天窗就等於一切歸零


...切入法,這個我也寫了很多不同的方式,但畢竟寫的東西是「美食」這個差異真的差不到哪去

美食與程式領域不同
同樣的文章也許程式界同一個問題有5-7人寫文解答,已經算很多人了

美食界的40-50人寫同一家也不足為奇,而且外縣市的也會跨過來寫,然後愛食記、愛評網、窩客島、東森,這些平台每個人都把部落格的文搜納為己有,加一加隨便一家紅店都會破百人寫,所以差別性真的太小了、文章也多的跟甚麼似的

我們的興趣就是美食,所以就是寫美食的,總也不可能跨去別行

如果不每個分數都加權重一下,一點分數差別就敗了!
若不是文字、圖片能精進的都精進了,不會想到不熟的領域SEO去,重點是...我絕對不是你想的那種SEO走火入魔的狂人,我充其量就是希望至少不要是在這件事被扣分,就萬幸了

我只是想跟你提,不是我看不懂你的SEO文,或者沒看又再亂講,相反的是我真的有看你寫的,我知道你的觀點,你講的也都是事實與好的建議,但問題在我不是在稀少類,我在紅海,只有一個本領那很快就會退出這市場了

很感謝她跟我分享這個領域的困境,我也算是因為這段話,才瞭解為何這麼多網站拼命想要優化 SEO,因為在完全競爭市場,任何一個優化、任何一個小細節,都有可能會造成影響。

這也說明了我的 SEO 文章是給正規部落客看的,商業網站不是我的受眾(TA),那麼討論起 SEO 概念就不會有交集了。

因為完全競爭市場屬於商業領域,而商業上要如何操作如前所提,會另外寫文章討論。

而讀者們瞭解市場的現況後,可以選擇的是,不要進入完全競爭市場,或者是,當你自認可以在市場中存活後,也就是成為佼佼者後再進入,別過早進入。



五、小編的努力方向


因為我沒有美食、旅遊方面的專業,所以不敢給予這類部落格短期明確的(戰術)作法,只能提供長期的(策略)努力方向,藉以跳脫完全競爭市場,不過相信這樣的原則所有類型的網站都適用。

1. 培養獨特觀點

前面提到的差異化、獨特性,也都是佼佼者的一種。事實上每個人都是獨特的個體,都會有自己的看法、觀點,不會完全一樣,只是容易被僵化的教育搞成想法都差不多,或是看到別人成功就照著做。

部落格就是抒發自己想法、觀點的地方,敢於說自己想說的,文字寫出自己的風格,是能做出差異化的。

可以參考各種美食評論家的書籍,學習專家怎麼闡述自己的觀點,投入時間磨練。


2. 目標成為總編

另一個成為佼佼者的方式,可以把目標擺在將自己的位階升級,例如你的角色目前是小編的話,那麼想辦法擁有總編輯的實力。

如果你的資訊整理、描述能力都很好,已經成為一位合格的小編,一段時間後的瓶頸會是,大家都是合格的小編,你要拿什麼贏人家呢?

如果把網站名稱遮住,你的文章放在別人的網站沒有任何違和感,也就是這篇文章在任何地方出現都不足為奇,那麼很可惜,表示這樣的文章大家都寫得出來,也代表這樣的文章跟農場文差不多,我們會想要自己的部落格變得跟代工農場一樣,只是拿來賺廣告點擊嗎?(其實農場還真的會雇用這樣的小編)

身為部落客有選擇的權利,我們並沒有被任何人雇用,也可以選擇想要寫出專欄等級的文章,不以小編等級為滿。

只要願意磨練自己,我相信目標是成為總編的話,將來足以勝過市場上所有的小編。


3. 目標成為專家

美食旅遊網站,還可以有不同角度的努力目標,例如以高品質攝影作品為主,以高檔餐廳為主,以特殊國家旅遊為主...,這部分就依個人喜好、能力、資源決定。

有辦法成為不同切入點的專家,就能在市場上勝出。



六、是否把部落客當職業?


這是本篇的結論,我不建議一開始就把部落客當職業,除非你開始之前就已經準備好了。

我的 SEO 文章不斷強調「內容為王」,產品是最重要的,其實就是本篇一再強調的 "佼佼者" 概念。先確定你已經成為佼佼者了,再進入市場,否則就會遇到前面提及的「學徒困境」

成為佼佼者要花幾年的時間呢?我相信不會是兩、三個月,也不會是一年。

部落客不像當業務、當學徒,有前輩、師傅每天手把手帶領學習專業知識。學徒就算天天磨練都還要好幾年才能學成,部落客只能自己摸索、找課程上、觀摩前輩的網站,投資了這麼多時間都還不曉得能不能出頭,也沒有固定收入,你說適合當飯吃嗎?

因此我建議部落客應該要有正職,不要讓部落格影響生計,寫著寫著、磨練幾年後,覺得自己好像還不賴,比同類型網站厲害多了,或是藉著網站找到了可以獲利的模式,這個時候再來商業化、進入市場。

你的手中握有何時進場的選擇權,不貿然進場就不會輸。只要確保網站商業化時,你的確是佼佼者,之後要選擇辭職全心投入都行。這個時候進場,就不會喪失自我成長的時間;不會為了生計、流量,將資源投入錯誤的方向,讓網站失去更上一層樓的機會。


更多 SEO 相關文章:

Blogger 網址買了很後悔,可以再搬到新網址嗎?

$
0
0
前幾天有讀者表示,網址已經買了很多年,最近快要到期,想要換個新的網址,但又怕原來的網站連結就失效了,詢問我可不可以搬到新網址。

她的文章有 1500 篇,算是相當不小的規模,本站連她的一半都不到!規模中上的網站的確需要一個比較有記憶性、或與網站特色連結的網址,但一開始經營網站時有可能沒想那麼多,或是網站成長超過預期也是沒辦法的事。而網站既然要長期經營的話,能夠改網址自然是越早越好,長痛不如短痛。

不過她詢問能否換網址時,當下我的直覺反應是:

  • Blogger 沒有提供 301 轉址的功能
  • 這代表 SEO 將完全歸零
  • 多年來的經營等於從頭開始

所以要她考慮清楚,從頭來是非常非常痛的一件事,讚數歸零是小事,所有原網站的外連、或搜尋而來的訪客,都只會進入 404 頁面,沒有人會知道新網站、或是知道怎麼連往新網址。

其實這些她都知道(部落客當這麼久了當然不是混假的),所以她的目的是要問我有沒有解決的方法(早說清楚就不用花時間解釋了..XD)。但我反射性地認為 Blogger 沒有 301 就是無解,所以耐心地請她再詳細考慮,就準備結束這段對話。

有時就是這樣,話說的太滿時會忽然有點心虛,想著會不會有什麼沒考慮到的點?結果聯想到「協助痞客邦搬家到 Blogger」的經驗,那麼拿來套用到「Blogger 自訂網址搬到 Blogger 自訂網址」,其實情況不也一樣嗎?

瞬間找到了解決方法,也大概跟她描述了一下原理,本篇就來說明可以處理的過程。

(圖片出處: pexels.com)


一、網址取名要點


首先用一點小篇幅說明一下網址取名的要點,可參考「網址命名要點流程 SOP」:

  • 網址越短越好
  • 使用有意義的單字

這兩點比較重要。

案主多年前買了 "英文字母 + 一串數字" 的組合,有點類似像學號這樣,比較看不出跟網站的關聯性,算是滿吃虧的。一方面缺少容易記憶的英文單字,一方面如果要把網站當品牌經營的話,通常會使用含自己英文名字的字串、或跟中文網站名稱相關的英文字串。

如果網站客群以台灣為主的話,可挑 .tw 網域購買,選擇性比 .com 多,網址也短。如果長期目標想含括台灣以外的市場,建議還是買 .com 的網址,前瞻性比較高。

而買網址還有很重要的是避免挑便宜的買,要挑龍頭廠商,萬一出問題會比較有保障,就像免費部落格首選一定是 Google 旗下產品 Blogger,除非有比 Google 能讓你放心的公司。我能提供的購買經驗是「Godaddy」,可參考這個標籤的所有相關文章。



二、搬家流程


1. 買新網址 + 舊網址續約

除了購買新網址之外,原來的舊網址到期後,必須再續約一年以上,也就是同時養兩個網址。

舊網站是為了將 SEO 轉到新網站之用,每篇文章都放搬家畫面,讓訪客連到新網站對應的文章。

同時續約一年到期之前,觀察舊網站的流量數據,是否還是一直有訪客連過來,如果持續都有一定的流量,那麼建議一年一約,除非你要放棄這些連到舊網站的流量。

當舊網站流量減少到一定程度,也就是認為沒有花費一年續約的價值時,就可以正式放棄舊網站了。


2. 匯出 + 匯入文章

從舊網站後台 → 設定 → 其他 → 備份內容,可以匯出 XML 檔,連留言也能順利移轉。

但別急著匯入新網站,請先參考「解決 Blogger 匯入文章時"繼續閱讀"出錯的問題」,處理完後再匯入,否則新網站的首頁會很慘的,沒有繼續閱讀會顯示完整的文章內容。

然而文章匯入新網站後,並不會保留文章原本的 "自訂網址" 字串,所以必須手動一篇篇重新設定,可參考「Blogger 自訂文章網址的要訣」→「三、永久連結」。



三、搬家畫面


這裡說明一下搬家的原理,當文章匯入新網站後,新、舊兩個網站的文章內容都一模一樣,會被 Google 搜尋引擎判定為複製內容,所以 SEO 會受到處罰。

為了避免這件事,必須將舊網站每篇文章只留前幾行的內容,就不會有複製文章的問題。

同時舊網站的文章要製作搬家畫面,提醒訪客該篇文章已經有了新網址,給個連結到新網站對應的文章,這樣 SEO 就會慢慢移轉到新網站了

以上的流程如果文章數不多,或許可以手動自己處理。但如果數量龐大,像本次案例有 1500 篇的話,那麼需要用程式跑才行,以下的流程建議交由本站處理:


1. 更換文章連結

如果舊網站的文章,會引用自己的文章連結,那麼匯入新網站後,文章中依然會留著這些舊網站的連結,那麼將來放棄舊網站後,就會變成 404 連結了。

所以必須將新網站的文章,文章中的舊網站連結,全部置換為對應的新網站連結。


2. 處理舊網站文章

為了防止被 Google 判定為複製文章,需要把舊網站所有文章,刪除大部分內容,只留前幾行。


3. 製作搬家畫面

在舊網站的所有文章,開頭處擺個提醒的區塊,告訴訪客網站已經搬家,這篇文章的網址已經改為新網站的連結,讓訪客連過去。

以上這三個流程,都不方便手動進行,還是交給程式跑比較不容易出錯、且省時間。



四、搬家後續


以上都處理完後,就可以為新網站「提交網站地圖」,讓 Google 開始收錄新網站的文章。

接下來還有很多瑣碎的事要處理,例如把各處舊網站的連結改為新的(FB 簡介、名片、各處的關於我...),在各處發佈公告等等,不過都不會比搬家的過程更難。

簡單做個小結,有了以上的搬家解決方案後,以往我的一些觀念就需要調整了:



更多自訂網址相關主題:

免 iPhone、iPad 開發人員就能進行除錯﹍MacOS 模擬器 + Xcode 妙用

$
0
0
macos-simulator-xocde-debug-iphone-ipad.jpg-免 iPhone、iPad 開發人員就能進行除錯﹍MacOS 模擬器 + Xcode 妙用之前這篇「利用 Chrome 對 iOS 裝置進行除錯」可以讓開發人員很方便地對 iPhone、iPad 等裝置進行偵錯,不過並非所有前端開發者都有辦法買齊各種昂貴的蘋果裝置來測試,因此本篇將會介紹一個比較省錢的解決方案。

雖然不用花錢,不過必須花時間跑模擬器,電腦的 CPU 要夠強,記憶體要夠多,否則模擬器會很卡。

MacOS 官方提供了一個強大的開發工具 Xcode,可以很正確地模擬 iPhone、iPad 的使用環境。我經過實測後發現,一些 iOS 才會發生的網頁錯誤,Xcode 是真的可以模擬出來的。

這樣子的錯誤,光是使用 Chrome 開發人員工具模擬不出來,那麼以下就來看看如何在 Windows 下藉著模擬器執行 Xcode 進行除錯。

(圖片出處: apple.com)


一、WMware 模擬器


  • 首先假設讀者的硬體設備都準備妥當了,否則請放棄這個方案。
  • 請詳讀「Windows 用 VMware Player 模擬 MAC OS X 心得」內容
    • 從「三、準備相關工具」下載及安裝好 WMware
    • 蘋果系統映像檔請想辦法取得
    • 如有 FB 帳號可免費加入本站會員,看到隱藏內容連結

按照以上流程處理完後,很重要的一點是記住你使用的蘋果系統版本,例如「Yosemite 10.10」,之後會用到。



二、下載 Xcode


1. Xcode 版本

如果 MacOS 版本很新,Xcode 可在 App Store 自動下載對應的版本。

否則的話,不同的 MacOS 版本只能對應特定版本的 Xcode,可參考此資訊:


必須說這個表可以參考,但可能無法 100% 正確,例如我的版本 Yosemite 10.10,不過 Xcode 的版本一直下載、不斷降版本,直到嘗試了 6.0.1 才能安裝。


2. 下載 Xcode

如果到蘋果官網下載,很難找到各種 Xcode 版本的連結頁面,通常只能找到最新版本。以下提供幾個連結,可不必這麼麻煩,請找自己需要的版本下載:


下載之前,先準備好自己的 Apple ID 帳號密碼,沒有的話先申請一個。



三、利用 Xcode 進行除錯


1. 打開模擬器

安裝完 Xcode 後,可參考這篇「利用Xcode在Mac大玩iOS模擬器」的流程,開啟 iOS 模擬器。

例如模擬 iPhone 後,點擊 iPhone 桌面上的 Safari 瀏覽器,進入要 Debug 的網址:

macos-simulator-xocde-debug-iphone-ipad-1.jpg-免 iPhone、iPad 開發人員就能進行除錯﹍MacOS 模擬器 + Xcode 妙用


2. 開始除錯

接者開啟 VMware 模擬的 MacOS 系統中的 Safari 瀏覽器:

macos-simulator-xocde-debug-iphone-ipad-2.jpg-免 iPhone、iPad 開發人員就能進行除錯﹍MacOS 模擬器 + Xcode 妙用

如上圖 Develop → iOS Simulator → Safari → 選擇開啟的網址


macos-simulator-xocde-debug-iphone-ipad-3.jpg-免 iPhone、iPad 開發人員就能進行除錯﹍MacOS 模擬器 + Xcode 妙用

接下來就能使用 Safari 對著 Xcode 模擬的 iPhone 進行偵錯了。

以上就是沒有任何實體蘋果裝置的開發人員處理方案,一時之間找不到機器除錯時,是個很好的備用方案。


更多 iOS 相關技巧:

部落格載入速度太慢,要如何判斷哪些外掛可以移除?

$
0
0
重視 SEO 的站長自然都會關注網頁的載入速度,因為這也是 Google 的排名評分項目之一。過去寫過一系列「網站效能」的相關文章,有興趣的站長可以瞭解不同的主題要如何處理。

由於提升「網頁載入速度」的詢問度一直很高,以往就算請讀者看這些相關文章,一段時間後還是可能回頭問一樣的問題,因此本篇決定整理出比較簡單、清楚的判斷流程,讓站長們可以自行健檢,決定哪些會拖慢網站速度的外掛需要移除。

(圖片出處: pixabay.com)


一、影響網頁速度的關鍵


由於科技進步的速度太快,現在電腦、行動裝置的效能之好,已經讓我們可以很輕易地排除影響網頁速度的因素。以往 Javascript 的執行效能可能會因為 CPU、瀏覽器的解譯引擎而有所影響,但現在大部分使用者的強大 CPU、記憶體容量、瀏覽器新版本,讓 JS 可以一瞬間就執行完畢,甚至某些 CSS3 還可能需要比 JS 花費更多的 CPU 運算。

現在網頁的執行,多半是在等待網路傳輸的時間,也就是各種 HTTP 請求

  • 圖片網址
  • 外連 JS 網址
  • 外連 CSS 網址
  • Iframe 外連網址

總之,在範本中看到很多 JS 不用太緊張,有看到 HTTP 開頭的網址字串才需要學著辨別(註1),是否這個外連、外掛需要移除?

需要注意的是,A 標籤」也有 HTTP 連結,但這是點擊後才會連往他處網站,不代表要在我們網站載入這個 HTTP 連結的內容,所以不會影響網頁速度


註1:不是每個網址都會以 HTTP 開頭,網址的表示方式還有相對網址(例如以斜線 "/" 開頭是其中一種),也可以雙斜線 "//" 開頭,這也增加了新手辨識的困難。



二、影響載入速度的層次


以下由輕微到嚴重,說明影響網站載入速度的因素:

1. 超連結

也就是前面提到的 A 標籤,不影響網頁速度。

既然不影響,為何要特別提出呢?因為之後會提到外掛的替代方案,讓讀者先有個印象。


2. 使用 CDN 的 HTTP 請求

有提供「CDN」服務的 HTTP 請求,會自動找到地球上距離訪客最近的節點伺服器,可減少一大段網路傳輸距離、時間。

對於 Blogger 使用者而言,這是我們很大的優勢,根據官方論壇「Loading speed and page optimization questions」,藉由 Google 的 CDN 存放 Blogger 平台的資料,我們網站的存取速度絕對比其他部落格都快


3. 非 CDN 的 HTTP 請求

沒有 CDN 的 HTTP 請求,就回歸到正常的網路傳輸,跟伺服器主機的反應速度,還有經過的國家、節點數量也都會有影響。

建議部落格要使用的各種外連,例如 JS/CSS/圖片,最好都有 CDN 服務能提供,否則網頁開啟速度會受到很大影響。

基本上 WFU BLOG 近幾年來介紹的外掛,都是以 CDN 外連為主,就是這個原因。


4. 有用到 IFRAME 的外掛

這個有點難辨別,因為要開「Chrome 開發人員工具」才能看到,這個外掛有沒有在網頁上產生 IFRAME。

簡單舉幾個例子,Adsense 廣告、FB 讚按鈕、Google 地圖,這些都會產生 IFRAME。

為何 IFRAME 比一般 JS 外連影響大呢?因為 IFRAME 代表載入一整個 HTTP 網址,裡面的內容有可能包山包海,也可能另外執行了好幾個 JS 外連,載入多個圖片、影音檔等。

最好的例子是 Adsense 廣告,用 Chrome 開發人員工具看一下就知道很精彩。所以只要網站少放幾個 Adsense 廣告,就能有感提升網頁效能。



三、評估外掛是否移除


有了以上概念後,我們可以來評估看看一些部落格常用的外掛,需不需要移除,或是有沒有更好的替代方案。

1. 沒有 HTTP 外連的外掛

過去有很多讀者提問,擔心某某外掛會不會影響速度,其實問的那些外掛根本沒有 HTTP 外連,但要一般使用者分辨有無 HTTP 外連的確沒那麼容易。

一個比較簡單的判別方式:

  • 這個外掛是否需要取得外部資料來顯示?


以下列出幾個比較常見,沒有 HTTP 請求,所以不會影響速度的外掛:



2. 社群分享按鈕

很多網站會安裝類似 AddThis 這樣的社群分享按鈕外掛,如果以減少 HTTP 請求為前提的話,是完全可以不用安裝這類外掛的。

以 Blogger 為例,可參考這篇「改造 Blogger 官方分享按鈕」,在網站擺放超連結形式的社群分享按鈕,完全不需要使用外掛。


3 相關文章外掛

相關文章是部落格很重要的外掛,擺放在文末處可以有效提高讀者的黏著度、停留時間。

很多網站會裝 LinkWithin、或是 Adsense 推出的相關文章外掛,這些外掛內容比較複雜,速度也會慢一些。

因為取得自己網站相關文章的資訊,其實來自於自己的網域,以 Blogger 為例,可以改用以下外掛,速度更快:


速度更快的原因來自於程式碼沒那麼複雜,而且 HTTP 請求是 Blogger 伺服器,有 CDN。


4. 讚按鈕

是否擺放讚按鈕外掛,需要根據自己網站的特性進行評估。

以本站為例,經過長時間觀察後,發現很少有讀者會在網站上按讚,多半是分享到 FB 時才會按,因此本站採取不擺放任何讚、+1 按鈕。

但分享按鈕則是必須的,參考「2. 社群分享按鈕」的方式進行即可。


5. 留言板外掛

其實各種留言板外掛都很龐大,無論是 FB、G+、Disqus。這一項依然請站長根據自己網站的特性進行評估,確定留言板外掛的使用量,會比原生留言板來得大,再考慮留下。

其實部落格的原生留言板,除了速度快,還擁有任何外掛都無法比擬的 SEO 優點,因此本站只擺放 Blogger 官方留言板,可參考這篇「Blogger 官方留言板的優點及妙用﹍加強 SEO 搜尋排名」。


6. 側邊欄外掛


以上這幾個都是常見的側邊欄外掛,都是讀取自己網站的資料,也就是送出 Blogger 伺服器的 HTTP 請求。

如前所提,Blogger 伺服器有 CDN,反應、傳輸速度都是很快的,有相關需求的站長,可不必特地移除這類外掛。


7. 有 CDN 的 HTTP 外連

除了確定是讀取 Blogger 網域資料的外掛,其他的都會是外部 HTTP 請求,那麼使用這些外連時,無論是 JS/CSS,務必先尋找有沒有 CDN 服務,才能加快傳輸速度。

以下提供一些常見、有 CDN 外連的項目:



8. 其他 HTTP 請求的外掛

除了以上,就剩下 IFRAME 跟沒有 CDN 的外掛了(如果你真的找不到 CDN 的話)。

如前所提,IFRAME 載入的東西太多,可先評判是否移除有 IFRMAE 的外掛,再來是沒有 CDN 的外掛。想想這些剩下的外掛,其功能性、必要性是否大到不能割捨。

如果是的話,就安心使用、放下效能的執著吧,畢竟還是會有某些事比速度更重要!


更多「網站效能」相關文章:

輕鬆做出美觀的自適應 RWD 表格(Table)﹍jQuery 輕量外掛

$
0
0
jquery-responsive-table.jpg-輕鬆做出美觀的自適應 RWD 表格(Table)﹍jQuery 輕量外掛最近的案子處理行動版的表格效果時,發現以前的「Blogger 插入表格最佳流程 + 自適應寬度」,這個方式若用在商業網站,將沒有任何質感可言,甚至可以用簡陋來形容。

於是找了一下自適應 RWD 表格有沒有比較美觀,而且又簡便的處理方式。有發現幾個功能強大的外掛,但操作稍嫌複雜。

本篇要介紹的方案,比較能夠無腦套用,且現成的樣式、配色就很美觀,不用另外修改或研究 CSS 語法。





一、RWD 表格的原理


A. 各種方案

自適應表格可以有幾種處理方式:

  1. 隱藏部分內容
  2. 讓表格出現水平捲軸
  3. 將橫向標題欄位改為直向,重新排版

這個網頁「Responsive Table」很詳細地整理了以上幾種解決方案,同時頁面上也可直接看到各種方案的即時展示效果,請切換頁簽即可。

jquery-responsive-table-1.png-輕鬆做出美觀的自適應 RWD 表格(Table)﹍jQuery 輕量外掛


B. 優劣比較

  1. 隱藏部分內容:可根據不同寬度顯示不同內容,但製作、維護都不方便。
  2. 使用水平捲軸:最簡單的方式,但網站想要有質感的話,無法考慮這個方案。
  3. 橫向改直向重新排版:不必更動原表格內容,雖然表格拉得比較長,但版面美觀,製作及維護都很方便。

因此本篇會介紹第 3 種處理方式。



二、jQuery RWD 表格外掛


1. 各種外掛

這篇「Free jQuery responsive table Plugins」介紹了許多免費的 jQuery 自適應表格外掛,整理的非常好,每個外掛都分別提供了 Demo 展示頁面及下載連結。

jquery-responsive-table-2.jpg-輕鬆做出美觀的自適應 RWD 表格(Table)﹍jQuery 輕量外掛


上圖的外掛功能非常強大,可以處理各種不同情況的需求,只要懂 js 就能發揮外掛的威力。

如果是一般制式的表格,求版面美觀、容易處理就好,不一定要安裝功能太多的外掛,光是看說明書就很頭痛。


2. 簡易外掛 Basic Table

本篇要介紹的 jQuery 超輕量外掛 Basic Table,檔案很小,其實不必找外連空間,js/css 直接塞範本就好:




三、安裝外掛 Basic Table


1. 安裝外掛

在修改範本之前,如果第一次安裝本站工具的讀者,建議先閱讀「備份範本的訣竅」系列文章。

以 Blogger 為例,安裝到範本的流程為,後台「主題」→「編輯 HTML」,游標點進範本區塊,按 Ctrl-F 搜尋 </head>這個字串,找到後在此字串的前一行,插入以下程式碼:

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<style>
/*jQuery Basic Table, Author: Jerry Low*/
table{background:white;border-collapse:collapse;margin:1.25em 0 0;width:100%}
table tr,table th,table td{border:none;border-bottom:1px solid #e4ebeb;font-family:'Lato',sans-serif;font-size:.875rem}
table th,table td{padding:10px 12px;text-align:left}
table th{background:#56a2cf;color:#ffffff;text-transform:uppercase}
table tr td{background:#eaf3f5;color:#999999}
table tr:nth-of-type(2n+2) td{background:#ffffff}
table.bt tfoot th,table.bt tfoot td,table.bt tbody td{font-size:.8125rem;padding:0}
table.bt tfoot th:before,table.bt tfoot td:before,table.bt tbody td:before{background:#56a2cf;color:white;margin-right:10px;padding:2px 10px}
table.bt tfoot th .bt-content,table.bt tfoot td .bt-content,table.bt tbody td .bt-content{display:inline-block;padding:2px 5px}
table.bt tfoot th:first-of-type:before,table.bt tfoot th:first-of-type .bt-content,table.bt tfoot td:first-of-type:before,table.bt tfoot td:first-of-type .bt-content,table.bt tbody td:first-of-type:before,table.bt tbody td:first-of-type .bt-content{padding-top:10px}
table.bt tfoot th:last-of-type:before,table.bt tfoot th:last-of-type .bt-content,table.bt tfoot td:last-of-type:before,table.bt tfoot td:last-of-type .bt-content,table.bt tbody td:last-of-type:before,table.bt tbody td:last-of-type .bt-content{padding-bottom:10px}
table.bt thead,table.bt tbody th{display:none}
table.bt tfoot th,table.bt tfoot td,table.bt tbody td{border:none;display:block;display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;vertical-align:top;float:left\9;width:100%\9}
table.bt tfoot th::before,table.bt tfoot td::before,table.bt tbody td::before{content:attr(data-th) ":";display:inline-block;-webkit-flex-shrink:0;-ms-flex-shrink:0;flex-shrink:0;font-weight:bold;width:6.5em}
table.bt tfoot th.bt-hide,table.bt tfoot td.bt-hide,table.bt tbody td.bt-hide{display:none}
table.bt tfoot th .bt-content,table.bt tfoot td .bt-content,table.bt tbody td .bt-content{vertical-align:top}
.bt-wrapper.active{max-height:310px;overflow:auto;-webkit-overflow-scrolling:touch}
</style>
<script>
//<![CDATA[
(function($){$.fn.basictable=function(options){var setup=function(table,data){var headings=[];if(data.tableWrap){table.wrap('<div class="bt-wrapper"></div>')}var format="";if(table.find("thead tr th").length){format="thead th"}else if(table.find("tbody tr th").length){format="tbody tr th"}else if(table.find("th").length){format="tr:first th"}else{format="tr:first td"}$.each(table.find(format),function(){var $heading=$(this);var colspan=parseInt($heading.attr("colspan"),10)||1;var row=$heading.closest("tr").index();if(!headings[row]){headings[row]=[]}for(var i=0;i<colspan;i++){headings[row].push($heading)}});$.each(table.find("tbody tr"),function(){setupRow($(this),headings,data)});$.each(table.find("tfoot tr"),function(){setupRow($(this),headings,data)})};var setupRow=function($row,headings,data){$row.children().each(function(){var $cell=$(this);if(($cell.html()===""||$cell.html()==="&nbsp;")&&!data.showEmptyCells){$cell.addClass("bt-hide")}else{var cellIndex=$cell.index();var headingText="";for(var j=0;j<headings.length;j++){if(j!=0){headingText+=": "}var $heading=headings[j][cellIndex];headingText+=$heading.text()}$cell.attr("data-th",headingText);if(data.contentWrap&&!$cell.children().hasClass("bt-content")){$cell.wrapInner('<span class="bt-content" />')}}})};var unwrap=function(table){$.each(table.find("td"),function(){var $cell=$(this);var content=$cell.children(".bt-content").html();$cell.html(content)})};var check=function(table,data){if(!data.forceResponsive){if(table.removeClass("bt").outerWidth()>table.parent().width()){start(table,data)}else{end(table,data)}}else{if(data.breakpoint!==null&&$(window).width()<=data.breakpoint||data.containerBreakpoint!==null&&table.parent().width()<=data.containerBreakpoint){start(table,data)}else{end(table,data)}}};var start=function(table,data){table.addClass("bt");if(data.tableWrap){table.parent(".bt-wrapper").addClass("active")}};var end=function(table,data){table.removeClass("bt");if(data.tableWrap){table.parent(".bt-wrapper").removeClass("active")}};var destroy=function(table,data){table.find("td").removeAttr("data-th");if(data.tableWrap){table.unwrap()}if(data.contentWrap){unwrap(table)}table.removeData("basictable")};var resize=function(table){if(table.data("basictable")){check(table,table.data("basictable"))}};this.each(function(){var table=$(this);if(table.length===0||table.data("basictable")){if(table.data("basictable")){if(options=="destroy"){destroy(table,table.data("basictable"))}else if(options==="start"){start(table,table.data("basictable"))}else if(options==="stop"){end(table,table.data("basictable"))}else{check(table,table.data("basictable"))}}return false}var settings=$.extend({},$.fn.basictable.defaults,options);var vars={breakpoint:settings.breakpoint,containerBreakpoint:settings.containerBreakpoint,contentWrap:settings.contentWrap,forceResponsive:settings.forceResponsive,noResize:settings.noResize,tableWrap:settings.tableWrap,showEmptyCells:settings.showEmptyCells};if(vars.breakpoint===null&&vars.containerBreakpoint===null){vars.breakpoint=568}table.data("basictable",vars);setup(table,table.data("basictable"));if(!vars.noResize){check(table,table.data("basictable"));$(window).bind("resize.basictable",function(){resize(table)})}})};$.fn.basictable.defaults={breakpoint:null,containerBreakpoint:null,contentWrap:true,forceResponsive:true,noResize:false,tableWrap:false,showEmptyCells:false}})(jQuery);
//]]>
</script>

第 1 行綠字可參考「引用 jQuery 的注意事項」,檢查範本是否已安裝過 jQuery,如果已經安裝過請刪除此行,以免重複安裝。


2. 表格 HTML 範例

以下是一個簡單表格 Table 的 HTML 範例:

<table id="RWD">
<thead>
<tr>
<th>姓名</th>
<th>身份證</th>
<th>性別</th>
<th>生日</th>
<th>行動電話</th>
<th>通訊地址</th>
</tr>
</thead>
<tbody>
<tr>
<td>Wayne</td>
<td>A123456789</td>
<td>男</td>
<td>2000-01-01</td>
<td>0912345678</td>
<td>台北市信義路五段5號</td>
</tr>
<tr>
<td>Mary</td>
<td>B987654321</td>
<td>女</td>
<td>2000-10-10</td>
<td>0987654321</td>
<td>台北市信義路五段7號</td>
</tr>
</tbody>
</table>

Table 標籤需要使用 ID 參數,紅色 ID 參數字串可自訂,請記下自己使用的字串,之後會用到。


3. 執行外掛

執行外掛的方式非常簡單,在範本中搜尋</body>這個字串,找到後在此字串的前一行,插入以下程式碼:

<script>
$("#RWD").basictable();
</script>

紅色字串請改為自己的參數即可。

需要看手機的 RWD 效果,請前往展示頁面:




四、補充修改說明


基本上本篇已經幫讀者把該安裝的 code 都整理好了,可直接無腦套用。不過如果要修改的話,有些地方官網的說明滿簡陋的,畢竟只是個簡單的小外掛,可參考以下我摸索過的補充。

1. 設定斷點

程式預設的寬度斷點值為 568,代表螢幕寬度為 568px 以下時,會使用 RWD 表格效果。

如果想要自訂 RWD 斷點,可使用以下參數:

$("#RWD").basictable({breakpoint: 768});
代表寬度 768px 以下 Table 會變成 RWD 效果。


2. 動態產生表格內容

如果表格的內容並非一開始就存在,曾經使用 js 動態產生的話,那麼 RWD 表格內容會異常,因為動態產生的內容不會被程式處理到。

因此官網提供了參數 start, stop, destroy 供不同用途使用。

當 Tabel 中有動態產生的內容後,我的處理方式如下:

// 先取消 RWD 表格
$("#RWD").basictable("destroy");
// 再重新產生 RWD 表格
$("#RWD").basictable({breakpoint: xxx});


3. 不同 CSS 用途

官網 DEMO 畫面提供了幾種不同用途的效果,但並沒有說明這些狀況下的 CSS 如何使用,可參考以下說明。

下載完官方提供的檔案、解壓縮後:

  • 根目錄的 basictable.css 內容一定要使用,請複製出來
  • demo 資料夾裡面的 css 資料夾,裡面的 style.css,註解標示了七個區塊,就是官網 DEMO 畫面的七種效果
  • 想要使用哪種效果,就複製那個區塊的 CSS 出來使用即可


更多 RWD 相關技巧:

究竟 Blogger 會不會關閉?從 Google 商業經營的角度分析

$
0
0
Blogger 會不會倒閉,是使用者長期以來的擔憂。過去曾在「Blogger 的未來」發表過看法,不過曾有讀者看完,一段時間後仍提出相同的問題。我想,這件事除非有官方說詞,否則疑問不會有停止的一天。

然而,Google 官方有可能發佈這樣的聲明嗎?我想不會的,連 Yahoo 這樣等級的網路龍頭都會因經營不善而被裁併,就算是 Facebook 也不敢保證自己不會倒閉。

一間公司、或產品的存留,是以有沒有替代品,能否持續獲利為前提。那麼本篇就來分析,Blogger 會不會有替代品,Google 能否靠 Blogger 營利來切入探討。

(圖片出處: 699pic.com)


一、簡易判斷方式


先看一下有什麼簡單的方法,可以判斷 Goolge 會不會結束 Blogger。

1. 有無更新

通常看不到未來的部門,公司不會願意繼續投入更多資源,那麼服務停止更新就會是個徵兆。

基本上 Blogger 一直都有看到更新,例如去年「Blogger 推出全新自適應 RWD 官方範本及佈景主題,並支援行動裝置」。

這個觀察方式雖然簡單,但卻很麻煩,站長們顧自己網站都來不及了,不太會有時間持續追蹤 Blogger 官網發佈的消息,因此評量其他因素會比較有明確的答案。


2. Adsense 廣告收入

Blogger 可以很方便就從後台新增 Adsense 廣告小工具,為自己的網站營利,同時 Google 也會抽成約 1/3 的廣告收益,這代表 Blogger 能為 Google 帶來不少收益。


3. 沒有客服支出

Blogger 的未來」一文明確指出,Blogger 沒有龐大的客服人員、首頁維護等固定成本,跟其他部落格平台相比,經營上已經立於不敗之地。

以上這些是之前提過的 Blogger 優勢,其實 Blogger 對於 Goolge 來說,還有一些更具核心的意義,讓我們繼續看下去。



二、Goolge 為何關閉其他服務


Google 曾推出的服務洋洋灑灑,但關閉的數量也不遑多讓,簡單分析一下原因。

1. 沒有商業價值

Google 是上市公司,獲利數字必須能對股東交代,那麼每年必定會檢討,哪些服務是純粹燒錢、而沒有任何獲利能力的。

Google Reader 關閉」是最好的例子,回過頭看,這真的是一個佛心服務,也很難想出 Google Reader 有效的商業模式。

只不過這個事件造成使用者的陰影,讓多數人害怕 Blogger 也會被關閉(但其實 Blogger 商業價值非常巨大)。


2. 有更好的替代品

當年「Google Code」關閉也是有不小的震撼,然而這個決策的確是對的。

如果讀者知道「Github」,近幾年來已變成世界最大的開源程式碼託管平台,Google Code 很早就無力抗衡。有了這麼強大的替代品,Google 的確不適合再投入資源。


3. 工程師不需要了

其實很多科技公司推出的服務,一開始都是自家工程師的需求,順便開放出來給大眾使用。既然是工程師要用的,就得視為公司的「費用」、「成本」,不能依照商業價值來評估去留。

2016 年 Google 曾推出一個服務「Spaces」,類似小型討論區的功能,我相信是 Google 內部某些工程師有這樣需求而做出來,只是當時我不覺得有什麼用處。

也許這種工具替代品太多,自己工程師後來也不用了,現在「Spaces 官網」只剩下關閉的字樣,根本不知道曾存活過多久。



三、沒被關閉的 Google 服務


這裡不是要討論可以賺大錢的 Google Map、Gmail(放在 G Suite 商業使用是可以賺錢的)、Youtube...等等,而是純粹討論看起來沒辦法直接產生收益的 Google 服務。

1. Google+

G+ 被當成「鬼城」已經好幾年了,使用者數量遠遠不及 FB,又沒有廣告收入,怎麼還沒被關閉呢?

實際上 G+ 多半是國外工程師、特定族群使用,而且 G+ 功能比 FB 強太多了,若不是在台灣根本沒人用,WFU 也不會轉而使用 FB。

在 G+ 發表過的內容可以很容易搜索、再利用,而 FB 一切船過水無痕,知識無法長久循環運用。我想只要 Google 的工程師沒找到替代品之前,G+ 的社群還是會持續存在。


2. Google 文件

Google 不是佛心公司,那麼為何 Google 文件、試算表、表單,這些強大、免費、又沒有賺錢的服務,可以一直存在呢?

針對企業收費的「G Suite」服務,可以選擇含括、連結上述這些服務,讓企業使用「G Suite」時更有生產力。

那麼 Google 文件等服務雖不能直接帶來收益,但能間接帶動、提升「G Suite」的銷售量,所以這些免費服務除了 Google 自己工程師要用,也都是具有龐大商業價值的。


3. Google Keep

Google Keep 也是一個明顯不會有任何收益、看不出有收費機制的服務,因為市面上替代品太多,真的收費就不會有人用了。

不過我相信這工具是 Google 工程師有需求而做出來的,因此是內部需求為主,再加上現在可以整合到 Google 文件、試算表...等服務,等於成了 Google Suite 的附加價值,要說有商業價值也是可以的。


4. Google 相簿

Google 相簿雖然有收費機制,但要達到收費標準還真是困難,圖片得非常大張才會開始列入配額容量計算。

雖然我們一般人看不出 Goolge 相簿要怎麼實質獲利,但是可以記住以下這幾段話:

  • Google 工程師都是頂尖中的最頂尖
  • 能夠長期存活下來的服務,對 Google 而言一定有其核心價值
  • Google 的核心服務,都能替 Google 蒐集到大量資訊、數據
  • Google 的頂尖人才,有辦法分析、解剖這些大數據,並轉換為商業價值
  • 一般公司就算拿到大數據,也不知道如何轉換為商業價值,或是缺乏有效轉換的能力,這就是與頂尖公司的差異

看看我們放在 Gmail、Google 文件、Google 相簿有多少資訊,會被怎麼運用、轉換?這部分算是 Google 的機密,無法多說、也只能點到為止。


5. Blogger

現在回來看 Blogger,他的存活符合哪些要點:

  • 工程師需要:Google 各種官網都架設在 Blogger,若沒有了 Blogger,各部門更新、發佈訊息,就得自己架網站、自己找圖床了。
  • 有無替代品:是否有其他免費部落格平台能與 Blogger 相比? Google 伺服器品質、維護、以及 CDN 服務,其他部落格都望塵莫及。
  • 商業價值:如同其他核心服務,Blogger 為 Google 直接或間接獲取了多少資訊、數據,可以轉換為收益?



四、搜尋引擎如何獲利


其實 Blogger 能帶來的商業價值太多了,這裡另外談談搜尋引擎這一塊。


1. Google 廣告收入

Google 做搜尋引擎起家,一開始的主要收益來自於賣廣告,也就是 Adwords。

商家為了搶關鍵字,很難靠自然排名搶到第一頁,通常只能跟 Google 買廣告,來搶第一頁的曝光率。

Google 賣廣告採競價的方式,越想搶的買主就得出越高價,競爭激烈的行業更是所費不貲。如果在特定節日、特定期間要搶,那麼得出天價才搶得到

藉由營造出競標的環境,Adwords 在這一塊的獲利可以說是 Google 的金雞母。


2. 搜尋引擎競爭對手

為了讓廣告買主在 Google 競標,而不是在 Yahoo、其他競爭對手競標,Google 得先營造出「我是最好的搜尋引擎」這樣的環境:

  • 索引速度快:Yahoo/Bing 的網站內容收錄速度之慢,這點看不到 Google 車尾燈。
  • 索引內容多:Yahoo/Bing 很多東西都搜尋不到,久了大家都知道要選擇 Google。
  • 最多人使用:大家最後都用 Google 搜尋,廣告主最終也必須選擇在 Google 下廣告,才能保證曝光度。


3. Blogger 的貢獻

Blogger 提供了 Google 大量的索引內容,也就是說 Blogger 有大量的優質內容會出現在 Google 搜尋結果,這帶來的影響是:

  • 越多優質內容,會對第一頁搜尋結果造成排擠
  • 只要擠不到第一頁、又想要尋求曝光的網站越多,代表 Google 的潛在廣告買主越多


4. Blogger 關閉的影響

所以很明顯的,假設 Google 某天想不開,決定把 Blogger 關閉了,將會造成這樣的結果:

  • Google 瞬間失去所有 Blogger 網站的索引內容
  • 所有其他網站排名瞬間大躍進
  • 原本某些擠不到第一頁的網站現在進得去了。
  • 原本潛在的廣告買主消失了
  • 因為競爭對手減少,Adwords 的投標金額可以不用那麼高了
  • Google 在 Adwords 的獲利大幅減少

以上是很簡單的推演,Google 這麼做的話,會很難面對股東、財報。

所以,隨著 Blogger 使用者逐日增加,內容的索引量只會增加不會減少,Google 只會越來越不願意關閉 Blogger。


5. 非 Blogger 網站的索引

或許有一種微小的可能性吧,反正把 Blogger 關了,這些網站也會另外找地方架站,這些內容以長期來講,一段時間後會再度被 Google 索引,對吧?

我認為從 Google 的角度考量,把提供內容的平台掌握在自己手上,才是最有利的:

  • 索引機器人爬自己的伺服器速度快、建立索引也快;爬別人的伺服器比較慢。
  • Blogger 網站的 HTML 架構絕對會依照,方便索引機器人作業的方式來建構,也會根據最新規範來更新,也就是利於 SEO。
  • 其他平台的 HTML 架構不一,解析、索引要花更多時間,更不用說遇到「Wix」這種另類的平台,內容用 JS 動態產生,對機器人是很大的負擔。
  • 只要 Google 將免費的 Blogger 做得越便利,越多使用者願意把 Blogger 當作內容提供的平台,代表索引機器人的工作越輕鬆,搜尋引擎的成本會越少,Google 索引的速度會越快、數量會越多,越拉開與其他搜尋引擎的距離



五、總結


本篇探討下來,除了很難找出 Blogger 必須關閉的理由,似乎 Google 需要 Blogger 的地方,越研究反而發現越多。

那麼當初拿來相提並論的「Google Reader」與「Blogger 」,現在會不會覺得兩者層級差太遠?

來下結論吧:

  • Blogger 網站越多,Google 搜尋引擎的工作越輕鬆
  • Blogger 提供的優質內容越多, 越能維持 Adwords 的出價及獲利
  • 只要 Google 有能力從各種旗下服務收集到的資訊、數據,進行分析並轉換為實質利益,就沒有關閉這類免費服務的理由,包含  Blogger。


更多 Blogger 相關文章:

Blogger 官方免費幫自訂網址升級 HTTPS! 設定處理流程注意事項整理

$
0
0
blogger-custom-domain-official-https-upgrade.jpg-Blogger 官方免費幫自訂網址升級 HTTPS! 設定處理流程注意事項整理這真的是最好的新年禮物了,過年前夕在「FB 社團」 +Vista Cheng 分享了「Blogger站長看過來:自訂網域的網誌,也可以支援HTTPS囉」 ,原來官方悄悄開始測試,可以讓自訂網域直接升級 HTTPS,這代表:

  • 不用付錢,Blogger 免費提供我們網站 SSL 憑證
  • 瀏覽器網址可以直接出現綠色鎖頭圖示,有助於 SEO 排名
  • 不必再倚賴第三方伺服器,例如 Cloudflare,可以大大提升網站的速度

就像公辦都更總比自己找建商張羅一切來得方便,除了以上這些優點,官方幫我們處理 HTTPS 這件事,可以省下很多原本要處理的事

藉著過年期間本站也升級為 HTTPS 了,順便整理一下 Blogger 幫我們都更的便利之處,以及其他的注意事項。

WFU 必須說,「Google 對 Blogger 的重視超乎一般人的想像」,自訂網址可升級 HTTPS 這件事,不但讓 Blogger 與免費部落格的差距越拉越遠,甚至我覺得花錢自架站的 CP 值遠低於 Blogger。套句熱門 Slogan,「你怎能不愛 Blogger」!

(圖片出處: goodfreephotos.com)


一、Blogger 測試版後台


1. 測試版後台

這個功能其實官方還在測試中,尚未正式發佈,不過可以從這裡看到選項:


根據官網說明「Introducing Blogger... in draft」,實驗性的功能會先出現在測試版後台,等測試都沒問題後,再發佈到「正式版後台」。

所以沒事到測試版後台晃晃,運氣好就可以看到 Google 工程師在為我們研發什麼功能了。


2. 設定步驟

進入測試版後台 → 設定 → HTTPS → HTTPS 可用性 → 是

blogger-custom-domain-official-https-upgrade-1.jpg-Blogger 官方免費幫自訂網址升級 HTTPS! 設定處理流程注意事項整理


出現上圖黃色訊息,代表官方開始進行轉換,需要一段時間,有可能一下子,也可能超過十分鐘,轉換期間網站會無法進入。我測試了兩個網站,狀況如下:


我的猜測是,「WFU BLOG 主站」的流量相對較大,為了不影響營運,官方會優先處理。而「Blogger 中文論壇」流量很低,所以可以慢慢來沒關係。


3. HTTPS 轉址

上圖的「HTTPS 重新導向」,在官方作業完成之前,選項是無法設定的。等作業完畢,請務必將「HTTPS 重新導向」設定為「是」

  • 因為升級 HTTPS 之後,我們的網站會同時存在兩種網址:HTTP 與 HTTPS
  • 這代表我們製造了兩個一模一樣的網站
  • 那麼就會有內容重複的問題,可參考「重複內容對網站 SEO 會有什麼影響
  • 而「HTTPS 重新導向」設定為「是」後,HTTP 網站會被 301 轉址到 HTTPS 網站
  • 這樣子 HTTP 網站就不會被搜尋引擎視為另一個網站了



二、官辦都更的優點


1. HTTP 連結

首先「BLOGGER 終於支援 HTTPS」詳細說明了 HTTPS 的各種優點。

不過這篇也提到:

只要切換為 https 模式,網頁中的所有連結,例如 js/css/jpg/html...,全部都要走 https,否則就會被判訂為 "混合內容"...請參考官網的中文教學:「修正網誌的混合內容」。

但是 WFU BLOG 轉換為 HTTPS 的結果,發現官方幫我們做了好多事:

  • 網站各處的超連結就算是 HTTP,都不會被判訂為「混合內容」,瀏覽器網址依然可以出現綠色鎖頭!!
  • 舊文章會留著多年前的 PICASA 圖床連結(HTTP 開頭),官方會自動幫我們改為雙斜線開頭 "//",因此不會成為「混合內容」
  • 如果文章使用外部圖床(HTTP 開頭),官方不會將網址改為雙斜線,但會產生 HTTPS 開頭的暫存圖片(放在 proxy)

這代表 Google 非常努力的在推動 HTTPS,讓我們舊文章各處的 HTTP 網址,無論是超連結或是圖片網址,不必再手動一一更改,就能無痛轉換為 HTTPS 網站!真的是非常感謝官方的付出。


2. 動態產生的連結

經過觀察,如果 HTTP 超連結網址是用 JS 動態產生,不會影響綠色鎖頭。

如果 HTTP 圖片網址是用 JS 動態產生,那麼就不會出現綠色鎖頭,因為網頁被判定存在混合內容

如果讀者的網站沒有裝什麼額外的外掛,一般不會出現這樣的狀況。但只要曾裝過外掛,就可能需要扮演柯南,逐一找出「混合內容」的出處到底在哪,研究如何解決。



三、轉換 HTTPS 的注意事項


以下列出目前我觀察到,轉換 HTTPS 後需要處理的要點。

1. 找出混合內容

官方提供的說明「修正網誌的混合內容」非常詳細,可按照教學處理,以下提供我的處理範例:


blogger-custom-domain-official-https-upgrade-2.jpg-Blogger 官方免費幫自訂網址升級 HTTPS! 設定處理流程注意事項整理

「Blogger 中文論壇」這個頁面的綠色鎖頭消失了,因為部分圖片使用了 JS 動態產生,且圖片網址是舊時代 PICASA 圖床,還沒使用 HTTPS 的網址。

使用 Chrome 瀏覽器 → 按 F12 → 切換到「Console」分頁,就可看到上圖的錯誤訊息,明確指出有 6 處同樣的混合內容(Mixed Content),錯誤原因為載入了這張圖片:

  • http://4.bp.blogspot.com/.../s100/blogger-community-orange.png

接著我們得靠經驗,看這張圖片是在文章、還是範本中產生,然後在那個地方,把網址改成 https 開頭,或是改成雙斜線開頭 "//" 都可,就能處理掉這個錯誤。


2. 簡易處理方式

可能需要修改的地方很多,這些 HTML 標籤都需要檢查:

  • link
  • script
  • iframe
  • video
  • audio


在範本中一處處尋找很費事,以下提供簡易的處理方式。但修改範本之前,建議先閱讀「備份範本的訣竅」系列文章。

儲存範本後,使用編輯軟體開啟範本檔:

  • 使用「替換字串」(replace all)功能,一次替換範本中所有字串
  • 將字串 "http://" 全部置換為 "//"
  • 另存新版本後,網站使用新的範本內容即可


3. 簡易方式後遺症

需要注意的是,這方法無法保證 100% 有效,也許可解決多數狀況,但可能會有這些情形:

  • 因為不知道第三方程式是怎麼寫的,也有可能讓某些外掛、js 當掉。若出問題的話,如果沒有 debug 能力,建議請專家處理。
  • 簡易替代字串的作法,是假設這些網址都能支援 HTTPS。實際上並非所有網站都支援 HTTPS,所以硬要消除「混合內容」的結果,就會造成載入不支援 HTTPS 的網址時失效。所以修改完後,仍須檢查 Chrome 的 Console 有無產生錯誤訊息,某些網址無法載入。
  • 另一種後遺症是,例如某些網站的網址原本是 HTTP,並沒有支援 HTTPS,但外連被我們改成雙斜線 "//" 之後,將來連過去會強制跳到 HTTPS 網址,那麼這些連結就會變成 404 狀態了。

所以必須回頭逐一檢查所有的超連結 A 標籤,如果這個網站未支援 HTTPS,請手動將 "//" 改回 "HTTP://",而這樣的修改不會影響到「混合內容」的判定。


4. 讚按鈕

FB 讚按鈕是依照網址來儲存數據,而 HTTP 與 HTTPS 會被視為不同網站,導致升級為 HTTPS 後,所有文章的讚數會歸零

其實讚數是浮雲,相信多數站長可接受 HTTPS > 讚數。

如果網站文章數很多,又希望能保留這些讚數當作回憶,那麼可再找 WFU 處理。


5. G+ 留言板

順帶一題,G+ 留言板也是依照網址來儲存資料,因為本站沒使用,所以不知道轉換 HTTPS 後會不會異常。不過既然是自家產品,我相信就算現在有問題,將來官方測試完畢後,正式版 HTTPS 也會修正 G+ 留言板的問題。



四、後續動作


既然 HTTP 與 HTTPS 對搜尋引擎而言是兩個不同的網站,那麼很重要的,在 HTTPS 轉換完畢後,我們需要重新提交網站地圖,幫助 Google 建立網站索引,以利於轉換 SEO。


blogger-custom-domain-official-https-upgrade-3.jpg-Blogger 官方免費幫自訂網址升級 HTTPS! 設定處理流程注意事項整理

一進入「網站管理員(Google Search Console)」就看到上圖提醒,要我們增加 HTTPS 網站。

如需要「網站管理員」、提交索引的操作,可參考這兩篇文章:




五、總結


過去所寫的「Blogger 自訂網址使用 HTTPS 是一條不歸路,請考慮周全」,原因在於 HTTPS 需要藉助第三方服務,而第三方將來要出什麼招我們無從猜測,命運掌握在別人手中是很可怕的一件事。萬一發生第三方無法存續、或價碼無法負擔之時,也就是我們網站的終結之日。

現在 Blogger 官方跳出來處理自訂網域的 HTTPS,也就是 Google 願意承擔我們的 SSL 憑證費用,那麼之前「不歸路」的擔憂就完全消失了。

現在起我們可以開心使用 HTTPS,網站有裝「聯絡表單」、「搜尋」工具的站長,除了將來瀏覽器不會出現「不安全」圖示,可以讓訪客填寫時更加安心,網站更值得信賴,而且「綠色鎖頭」圖示似乎也讓網站看起來更尊爵不凡呢!


更多「資訊安全」相關文章:


更多 Blogger 相關文章:

自製美觀的 RWD 時間軸效果(timeline)﹍jQuery + Bootstrap 外掛

$
0
0
jquery-bootstrap-timeline-eeyellow.jpg-自製美觀的 RWD 時間軸效果(timeline)﹍jQuery + Bootstrap 外掛雖然時間軸的效果看過不少網頁使用,不過倒是很少看到部落格站長放在文章內。這次接到的需求是,案主希望將單車行旅的圖文經歷,版面用時間軸效果串起來。

於是研究了相關的外掛,同時也要顧及手機的 RWD 效果,請見本篇的心得整理。



(圖片出處: eeyellow-Timeline)


一、時間軸外掛


以下這個頁面可看到各式各樣的時間軸效果:



在挑選上可注意的地方:

  • 如果是部落格使用,比較適合挑選垂直方向的外掛
  • 有的外掛將時間軸擺中間,讓顯示的項目一左一右依序排列,版面比較好看,適合沒有側邊欄的網站
  • 如果有側邊欄的話,由於文章區塊的寬度受限,比較適合只有單邊顯示的時間軸
  • 如果要考慮手機上的效果,最好注意外掛有沒有支援 RWD



二、eeyellow.Timeline


1. 外掛官網

本篇介紹的時間軸外掛特點如下:



標題收合後的效果像下圖這樣。

jquery-bootstrap-timeline-eeyellow-1.jpg-自製美觀的 RWD 時間軸效果(timeline)﹍jQuery + Bootstrap 外掛


介紹網頁包含下載、DEMO 連結,也有安裝操作說明。但你需要有網頁空間,才能依照英文說明內容成功安裝。

或是也可依照以下我整理後的中文流程來進行。


2. 安裝方式

由於時間軸多半不會使用輪播,因此我的安裝方式去除了輪播功能。

在修改範本之前,如果第一次安裝本站工具的讀者,建議先閱讀「備份範本的訣竅」系列文章。

安裝方式以 Blogger 為例,請到後台「主題」→「編輯 HTML」,游標點進範本區塊,按 Ctrl-F 搜尋 </head>這個字串,找到後在此字串的前一行,插入以下程式碼:

<script src='//ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js'></script>
<link href='//maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css' rel='stylesheet'></link>


<!--時間軸 js/css, Copyright (c) 2016 eeyellow-->
<style>
.VivaTimeline dl{position:relative;top:0;padding:20px 0;margin:0}.VivaTimeline dl:before{position:absolute;top:0;bottom:0;left:50%;z-index:1;width:2px;margin-left:-1px;content:'';background-color:#ccd1d9}.VivaTimeline dl dt{position:relative;top:30px;z-index:2;width:120px;padding:3px 5px;margin:0 auto 30px;font-weight:400;color:#fff;text-align:center;background-color:#aab2bd;border-radius:4px;-webkit-border-radius:4px;-moz-border-radius:4px}.VivaTimeline dl dd{position:relative;z-index:2}.VivaTimeline dl dd .circ{position:absolute;top:40px;left:50%;z-index:2;width:22px;height:22px;margin-left:-11px;background-color:#4fc1e9;border:4px solid #f5f7fa;border-radius:50%;-webkit-border-radius:50%;-moz-border-radius:50%}.VivaTimeline dl dd .time{position:absolute;top:31px;left:50%;display:inline-block;width:100px;padding:10px 20px;color:#4fc1e9}.VivaTimeline dl dd .events{position:relative;width:47%;padding:10px 0 0;margin-top:31px;background-color:#CCC;border-radius:4px;-webkit-border-radius:4px;-moz-border-radius:4px}.VivaTimeline dl dd .events:before{position:absolute;top:12px;width:0;height:0;content:'';border-style:solid;border-width:6px}.VivaTimeline dl dd .events .events-object{margin:0 auto}.VivaTimeline dl dd .events .events-header{min-height:30px;line-height:20px;text-align:center;font-size:16px;font-weight:bold;cursor:pointer}.VivaTimeline dl dd .events .events-body{overflow:hidden;zoom:1;background-color:#EEE;padding:10px}.VivaTimeline dl dd .events .events-body .row{display:none}.VivaTimeline dl dd .events .events-body .events-desc{text-indent:2em;padding:0 15px}.VivaTimeline dl dd .events .events-footer{text-align:center}.VivaTimeline dl dd .events .events-footer ol{list-style:none;margin:0 auto;padding:0}.VivaTimeline dl dd .events .events-footer ol li{background:#32b487;border-radius:5px;margin:10px;display:inline-block;width:10px;height:10px;cursor:pointer}.VivaTimeline dl dd .events .events-footer ol .active{transform:scale(2)}.VivaTimeline dl dd.pos-right .time{margin-left:-100px;text-align:right}.VivaTimeline dl dd.pos-right .events{float:right}.VivaTimeline dl dd.pos-right .events:before{left:-12px;border-color:transparent #CCC transparent transparent}.VivaTimeline dl dd.pos-left .time{margin-left:0;text-align:left}.VivaTimeline dl dd.pos-left .events{float:left}.VivaTimeline dl dd.pos-left .events:before{right:-12px;border-color:transparent transparent transparent #CCC}.VivaTimeline .carousel-indicators{bottom:0}@media screen and (max-width:767px){.VivaTimeline dl:before{left:90px}.VivaTimeline dl dt{margin:0 30px 30px}.VivaTimeline dl dd .circ{left:90px}.VivaTimeline dl dd .time{left:20px}.VivaTimeline dl dd.pos-left .time{padding:10px 0;margin-left:0;text-align:left}.VivaTimeline dl dd.pos-left .events{float:right;width:73%;margin-right:4%}.VivaTimeline dl dd.pos-left .events:before{left:-12px;border-color:transparent #CCC transparent transparent}.VivaTimeline dl dd.pos-right .time{padding:10px 0;margin-left:0;text-align:left}.VivaTimeline dl dd.pos-right .events{float:right;width:73%;margin-right:4%}/* .VivaTimeline dl dd .events .events-body{display:none}.VivaTimeline dl dd .events .events-footer{display:none}*/}
@media screen and (max-width:500px){.VivaTimeline dl dd.pos-left .events{float:right;width:63%;margin-right:4%}.VivaTimeline dl dd.pos-right .events{float:right;width:63%;margin-right:4%}}
</style>
<script>
//<![CDATA[
(function(e,b,a,f){var d="vivaTimeline";var c=function(h,g){this.target=h;this.carouselInterval;this.checkImgLoad;this.imgLoad=false;this._init(g);this._event()};c.options={carousel:true,carouselTime:10000};c.prototype={_init:function(h){var g=this;g.options=e.extend(true,{},c.options,h);g.target.find(".events-body").each(function(){var l=e(this).find(".row").length;if(l>1){var k="<ol>";for(var j=0;j<l;j++){k+="<li data-target='"+j+"'></li>"}k+="</ol>";e(this).siblings(".events-footer").html(k).find("li").first().addClass("active")}});g.target.find(".events-body").each(function(){e(this).find(".row").first().show().siblings().hide()});g.target.find("img").on("load",function(){g.target.find(".events-body").each(function(){var i=0;e(this).find(".row").each(function(){if(e(this).height()>i){i=e(this).height()}});e(this).find(".row").height(i)})})},_event:function(){var g=this;g.target.find(".events-header").click(function(){e(this).siblings(".events-body").slideToggle().end().siblings(".events-footer").toggle()});g.target.find(".events-footer li").click(function(){g._carousel(e(this))});if(g.options.carousel){g.carouselInterval=setInterval(function(){g._carousel()},g.options.carouselTime);g.target.find(".events").hover(function(){clearInterval(g.carouselInterval);g.carouselInterval=null},function(){if(g.carouselInterval==f){g.carouselInterval=setInterval(function(){g._carousel()},g.options.carouselTime)}})}},_carousel:function(h){var g=this;if(h==f){g.target.find(".events-footer .active").each(function(){var j;if(e(this).is(":last-child")){j=e(this).siblings().first()}else{j=e(this).next()}g._carousel(j)})}else{var i=h.data().target;h.addClass("active").siblings().removeClass("active");h.closest(".events-footer").siblings(".events-body").find(".row").eq(i).show().siblings().hide()}}};e.fn[d]=function(h,g){var i;this.each(function(){i=new c(e(this),h)});return this}})(jQuery,window,document);
//]]>
</script>
<!--時間軸 js/css-->

前 2 行綠字可參考「引用 jQuery 的注意事項」,檢查範本是否已安裝過 jQuery、Bootstrap,如果已經安裝過請刪除,以免重複安裝。


3. 執行程式碼

接著在範本中搜尋 </body>這個字串,找到後在此字串的前一行,插入以下程式碼:

<script>
//<![CDATA[
/*執行時間軸*/
$(".VivaTimeline").vivaTimeline();
//]]>
</script>

儲存範本即可。



三、時間軸內容 HTML 範例


在文章中或網頁上,要擺放的時間軸內容,請參考以下的 HTML 範例來修改:

<div class="VivaTimeline">
<dl>

<!--月份 1-->
<dt>Feb 2018</dt>

<!--左側文章 start-->
<dd class="pos-left clearfix">
<div class="circ"></div>
<div class="time">Feb 20</div><!--填入日期-->
<div class="events">
<div class="events-header">Blogger 官方免費幫自訂網址升級 HTTPS!</div><!--填入標題-->
<div class="events-body">
<div class="row">
<div class="col-md-6 pull-left">
<img class="events-object img-responsive img-rounded" src="https://4.bp.blogspot.com/-wXph1d9tAxM/WokCWJ06S6I/AAAAAAAAWZQ/kJcyc9mbSiIT99OE1yEx426CkET1NeHFgCLcBGAs/s1600/blogger-custom-domain-official-https-upgrade.jpg" /><!--填入圖片網址-->
</div>
<div class="events-desc">這真的是最好的新年禮物了,過年前夕在「 FB 社團 」 +Vista Cheng 分享了「 Blogger站長看過來:自訂網域的網誌,也可以支援HTTPS囉 」 ,原來官方悄悄開始測試,可以讓自訂網域直接升級 HTTPS,這代表: 不用付錢,Blogger 免費提供我們網...</div><!--填入描述-->
</div>
</div>
<div class="events-footer"><a href="https://www.wfublog.com/2018/02/blogger-custom-domain-official-https-upgrade.html" target="_blank">繼續閱讀</a></div><!--可填底部標題 或刪除-->
</div>
</dd>
<!--左側文章 end-->

<!--右側文章 start-->
<dd class="pos-right clearfix">
<div class="circ"></div>
<div class="time">Feb 13</div><!--填入日期-->
<div class="events">
<div class="events-header">究竟 Blogger 會不會關閉?從 Google 商業經營的角度分析</div><!--填入標題-->
<div class="events-body">
<div class="row">
<div class="col-md-6 pull-left">
<img class="events-object img-responsive img-rounded" src="https://2.bp.blogspot.com/-MQgmDdWOn5s/WoEcbqEIWPI/AAAAAAAAWXo/h8U_GHIW75obyskVvwgGQlD3ji0gjU7NACLcBGAs/s1600/will-google-close-blogger-business-analysis.jpg" /><!--填入圖片網址-->
</div>
<div class="events-desc">Blogger 會不會倒閉,是使用者長期以來的擔憂。過去曾在「 Blogger 的未來 」發表過看法,不過曾有讀者看完,一段時間後仍提出相同的問題。我想,這件事除非有官方說詞,否則疑問不會有停止的一天。 然而,Google 官方有可能發佈這樣的聲明嗎?我想不會的,連 Yaho...</div><!--填入描述-->
</div>
</div>
<div class="events-footer"><a href="https://www.wfublog.com/2018/02/blogger-custom-domain-official-https-upgrade.html" target="_blank">繼續閱讀</a></div><!--可填底部標題 或刪除-->
</div>
</dd>
<!--右側文章 end-->

<!--月份 2-->
<dt>Jan 2018</dt>

<!--左側文章 start-->
<dd class="pos-left clearfix">
<div class="circ"></div>
<div class="time">Jan 30</div><!--填入日期-->
<div class="events">
<div class="events-header">部落格載入速度太慢,要如何判斷哪些外掛可以移除?</div><!--填入標題-->
<div class="events-body">
<div class="row">
<div class="col-md-6 pull-left">
<img class="events-object img-responsive img-rounded" src="https://2.bp.blogspot.com/-kSoFOb5NBBo/Wm-wzn619hI/AAAAAAAAWVw/13tYUepFvuk3zD3XnU25wBixfDuAzC-0wCLcBGAs/s1600/pagespeed-slow-remove-plugin.jpg" /><!--填入圖片網址-->
</div>
<div class="events-desc">重視 SEO 的站長自然都會關注網頁的載入速度,因為這也是 Google 的排名評分項目之一。過去寫過一系列「 網站效能 」的相關文章,有興趣的站長可以瞭解不同的主題要如何處理。 由於提升「網頁載入速度」的詢問度一直很高,以往就算請讀者看這些相關文章,一段時間後還是可能回頭問...</div><!--填入描述-->
</div>
</div>
<div class="events-footer"><a href="https://www.wfublog.com/2018/01/pagespeed-slow-remove-plugin.html" target="_blank">繼續閱讀</a></div><!--可填底部標題 或刪除-->
</div>
</dd>
<!--左側文章 end-->

<!--右側文章 start-->
<dd class="pos-right clearfix">
<div class="circ"></div>
<div class="time">Jan 17</div><!--填入日期-->
<div class="events">
<div class="events-header">從小編到總編之路﹍如何成為部落客中的佼佼者</div><!--填入標題-->
<div class="events-body">
<div class="row">
<div class="col-md-6 pull-left">
<img class="events-object img-responsive img-rounded" src="https://3.bp.blogspot.com/-lo1NZ0KVZSU/WRrNvclwESI/AAAAAAAAPjQ/k50YaNha-1YlzwU0qtHwbhBoLfXPll1iACLcB/s780/how-to-become-top-blog-writer.jpg" /><!--填入圖片網址-->
</div>
<div class="events-desc">前陣子這篇「 部落格從搜尋引擎而來的流量,是不會有感情的﹍找回經營網站的動力 」寫完後,有位美食部落格客戶,同時也算本站長期讀者,問了一些 SEO 問題。其實滿訝異的,既然是忠實讀者,想必知道我希望讀者將注意力放在 SEO 以外的地方。 瞭解她詢問的原因後,覺得這段對話可以看...</div><!--填入描述-->
</div>
</div>
<div class="events-footer"><a href="https://www.wfublog.com/2018/01/how-to-become-top-blog-writer.html" target="_blank">繼續閱讀</a></div><!--可填底部標題 或刪除-->
</div>
</dd>
<!--右側文章 end-->

<!--月份 3-->
<dt>Dec 2017</dt>

<!--月份 4-->
<dt>Nov 2017</dt>
</dl>
</div>

修改說明:

  • 需要顯示月份的地方,複製綠色註釋字串「月份」的下一行,並修改內容
  • 需要顯示文章的地方,完整複製註釋「文章 start」~「文章 end」區間的 HTML 碼來修改
  • 在藍字註釋「填入日期」那一行修改日期
  • 在藍字註釋「填入標題」那一行修改標題
  • 在藍字註釋「填入圖片網址」那一行修改 src="" 之間的圖片網址
  • 在藍字註釋「填入描述」那一行修改描述內容
  • 在藍字註釋「底部標題 」那一行修改 HTML 碼
  • 不使用底部標題時,保留原本的字串 <div class="events-footer"></div> 即可

以上範例的效果,可前往 DEMO 頁面:



更多 jQuery 相關外掛:

Blogger 維護/架站 是否需要加工程師為管理員?只跟信任的對象合作是很重要的

$
0
0
blogger-add-engineer-as-administrator.jpg-Blogger 維護/架站 是否需要加工程師為管理員?只跟信任的對象合作是很重要的如果找本站進行 Blogger 架站,因為是比較大的工程,到後台進行作業是必須的,那麼必定要加 WFU 為管理員。

如果是維護的案件、或處理比較小的問題,有的客戶或許就有疑慮,會思考是否要加不認識的人為管理員,這樣網站比較安全。但是不加工程師為管理員,又希望能完美解決網站的問題,這兩件事是互相抵觸的。

其實碰到這類案主的機會極低,但只要遇上了就很麻煩,必須花極大的時間成本溝通,因為信任度無法短時間建立起來,那麼就會成為不划算的案件。有可能要考慮放棄案件,如果金額不大的話。

後來想想,把一些需要瞭解的概念整理起來,請客戶直接看這篇的內容,就可節省需要重複說明的時間。

(圖片出處: pixabay.com)


一、網站的獨特性


會找上 WFU 處理 Blogger 問題的案主,多半是本站的讀者,由於看過不少文章,大概可以瞭解 WFU 的調性,也能瞭解專業程度到哪裡,所以「建立信任度」這件事不太會有問題,比較不用思考「是否網站要加 WFU 為管理員」。

如果不是本站的讀者,由於對 WFU 不夠了解、沒看過本站文章、沒對 WFU BLOG 做過調查,直接找上本站尋求協助,就比較像一樁買賣交易,而非合作案件,類似一手交錢一手交貨。由於信任度還不夠,難免不希望網站的管理員交給不認識的人。

不過案主需要瞭解的是,每個網站都是創建者的延伸,每個人都是獨一無二的,所以每個網站也都是獨特的,需求也常常是獨特的,產生的問題往往不是常規性,不像市面販售的商品,錢付了就能解決需求。

那麼網站產生的問題,很難案主付了錢、拿到一段程式碼,自己拿回去裝了就能解決問題。所以,一手交錢一手交貨很難拿來套用在網站上,除非買的就是套裝軟體。

網站的案件跟房屋裝潢很類似,都需要溝通需求、建立規格,才能針對需求提出解決方案。這是一個非常客製化的領域,需要大量的溝通,因此稱為「合作案件」是很恰當的。

既然要合作的話,我會建議案主發案前,仔細挑選合作對象,進行背景調查,只挑選值得信任的對象來合作。如果合作對象沒有夠多的資訊足以判斷是否可靠,就不要與對方接洽,可節省雙方的時間,畢竟「信任」對於合作才是最重要的。



二、建立信任度


1. 瞭解 WFU

可以認識 WFU BLOG 的資訊還滿多的,有需要的案主,可參考以下管道:



2. 合作客戶

如果真的不放心加 WFU 為管理員,那麼下面這張圖或許可以提高一些信心:

customer-list.jpg-Blogger 維護/架站 是否需要加工程師為管理員?只跟信任的對象合作是很重要的

這是 Blogger 後台的畫面,目前有加 WFU 為管理員的客戶列表。由於名單太長,畫面上能看到的捲軸區塊只是一小部分而已。

既然有這麼多客戶選擇與 WFU 合作,有任何 Blogger 問題請放心交給本站即可。



三、不加管理員的缺點


曾經有個客戶告訴我,害怕加了我當管理員後,會不會 Blogger 比較容易被入侵?對於這樣的問題 WFU 只能苦笑,很有可能這個想法是她跟朋友聽來的,我也著實沒有時間跟她解釋 Blogger 會不會被入侵是 Google 工程師負責的,因為這些需要一定的網路、電腦知識才有辦法溝通。

其實這案例是「免費維護」的案件,也沒有賺一毛錢,所以我請她自行評估,願意信任我就加,合作案件不勉強。

如果您是案主,看完本篇以上內容,仍然不放心加 WFU 為管理員,那麼必須提醒,會有以下這些缺點及額外成本:

1. 測試網站

由於無法直接在主站作業,必須另外建立測試網站來作業,還可能要複製主站一些文章來測試,會增加額外的作業時間。


2. 無法完全複製主站環境

實際上有些情況下,主站環境是無法被完全複製的,例如:

  • 廣告可能會限定網域才能出現
  • 有些問題來自於特定文章頁面,但測試網站不會有主站的全部文章內容
  • 主站的後台設定跟測試網站不一樣,所以某些網頁效果也不一樣

這些都有可能導致某些問題在測試網站看不到,在主站才看到。


3. 增加往返測試時間

所以主站才能看到的問題,在測試網站模擬不出來,只好隔空把脈,徒然增加雙方的往返溝通、測試時間,這也會讓案主的費用增加很多。

所以結論就是,如果真的有不方便把工程師設定為網站管理員的原因,那麼案主必須做好心理準備,請大幅提高案件的預算,因為除了工程師不方便作業,也會大幅增加案件的處理、溝通時間,這些都需要列入案件的成本。


4. 額外寫教學的時間

因為不想加工程師為管理員,又希望日後可自己修改參數,有的案主便會要求 WFU 寫教學讓他自己改...

很多事情 WFU 自己處理很快就結束了,如果真的答應案主還額外寫教學,我看多花的時間要好幾倍,不知道案主是否接受多付幾倍的費用?



四、結論


其實不單案主不希望增加額外費用,工程師也不會喜歡增加可以避免的額外處理時間。而非常簡單的解決方式就是──「請加工程師為 Blogger 管理員」。

當然,這一切就回到了源頭的「信任」問題。所謂「疑人不用,用人不疑」,選擇只與信任的人合作,不但可以節省溝通時間,還可以節省費用,建議案主選擇合作對象前,看是要請朋友推薦,或是花一點時間徵信,可以確保日後合作順利。


網站服務項目:

部落格使用「結構化資料」的最佳作法 JSON-LD﹍提供「文章」型態的範例程式碼

$
0
0
structured-data-json-ld-blog-post.jpg-部落格使用「結構化資料」的最佳作法 JSON-LD﹍提供「文章」型態的範例程式碼過去曾寫過一篇「部落格如何處理結構化資料標記 + 修復錯誤訊息」,主要是因為鑽研 SEO 的站長,使用了 HTML 微資料(Microdata)語意標記後,拿「結構化資料測試工具」檢測總是會看到一堆錯誤。

該篇文章我也說了,部落格網站不理會結構化資料也沒什麼差,因為 Google 搜尋結果出現的字串,不會因為設定了結構化資料而有太大差別。

會寫本篇的主要原因是,前陣子接到特定類型網站的委託案件,想要優化部落格的結構化資料。而前一篇我有提到,特定類型、或商業網站有必要優化結構化資料,因此為這個案件詳細研究了「結構化資料」,也確實達到很好的搜尋效果。

那麼本篇整理一下研究的心得,並以部落格「文章」這個類型為例,說明結構化資料該怎麼做最簡單、快速、不會有錯誤訊息出現。



一、結構化資料最佳格式


1. 各種結構化資料格式

開始之前需要先瞭解基本概念,結構化資料發展到現在,一共有這些格式:

  • Microdata(微資料)
  • RDFa
  • JSON-LD

以往 Blogger 範本中使用的是 Microdata 這種格式,HTML 標籤中會穿插一堆 itemprop 這樣的屬性

由於 Microdata 的規範會不斷更改,追逐 SEO 的站長隔一陣子可能就要調整 Microdata 結構化資料的寫法,否則測試工具又要看到錯誤訊息了

我認為這算是滿浪費時間的作法,也從來不在意這些錯誤訊息。同時範本中各處佈滿了 itemprop 屬性,日後很不方便維護,程式碼也非常雜亂,一直覺得 Microdata 是很糟糕的一項設計。


2. 最佳格式 JSON-LD

這次仔細研究「結構化資料」後,發現 JSON-LD 這種格式真是太屌了,把所有結構化資料集中在一處,不再需要遍布整個範本,日後維護不需要找半天。

因為這麼方便,WFU 就會願意使用「結構化資料」來對搜尋引擎友善,讓 Goolge 快速、正確地索引自己的網站


3. 補充資料




二、可以使用結構化資料的部落格平台


1. 自架站

如果花錢自架站的話,例如 WP 平台,可以找到自動產生結構化資料的外掛來安裝,不用自己手動一篇篇處理。


2. 免費部落格

Blogger 以外的免費部落格平台,大部分應該都不能修改範本內容,那麼我相信很少站長會有毅力自己一篇篇手動貼上結構化資料內容。

少數能修改範本內容的部落格平台,我也不確定一定能自動為每篇文章產生結構化資料,那麼為了這件事,我建議最好的選擇是改用 Blogger。


3. Blogger

Blogger 身為 Goolge 的一份子,搜尋引擎需要的 SEO 功能自然不會缺席,從範本就可以很輕易地產生每篇文章的結構化資料,請見以下的詳細說明。



三、最佳方案:Blogger 官方 RWD 範本


之前在「究竟 Blogger 會不會關閉?從 Google 商業經營的角度分析」→「四、搜尋引擎如何獲利」→「5. 非 Blogger 網站的索引」有提到這段話:

Blogger 網站的 HTML 架構絕對會依照,方便索引機器人作業的方式來建構,也會根據最新規範來更新,也就是利於 SEO。

只要 Google 將免費的 Blogger 做得越便利,越多使用者願意把 Blogger 當作內容提供的平台,代表索引機器人的工作越輕鬆,搜尋引擎的成本會越少,Google 索引的速度會越快...

去年「Blogger 推出全新自適應 RWD 官方範本」,讀者可以檢查一下你的範本,如果是官方 RWD 範本,檢視網頁原始碼後會發現:

  • 舊有的 Microdata 標記已經全部消失
  • 使用 JSON-LD 格式的結構化資料
  • 使用測試工具不會看到錯誤


這有很重大的意義,因為:

  • 不再因為 Microdata 規格更新,而需要手動修改範本內容
  • 這些 JSON-LD 格式的結構化資料,在範本中我們甚至無法修改,是 Blogger 官方自動幫我們產生的
  • 因為是官方控制的結構化資料,代表將來 JSON-LD 就算規格更新了,官方也會自動調整內容,我們不必操心
  • 代表 Blogger 的使用者,只要套用官方 RWD 範本,基本上可以不必擔心許多 SEO 細節


所以結論就是,Blogger 官方 RWD 範本的使用者,什麼事都不必做,「結構化資料」已經自動設定好了。



四、Blogger 一般範本


根據 Google 官網說明「關於結構化資料標記協助工具」:

微資料與 JSON-LD 是兩種不同的標記資料方法 (兩者皆使用 schema.org 詞彙)。建議您擇一使用微資料或 JSON-LD, 避免在單一網頁或電子郵件同時使用這兩種方法

既然結構化資料改用 JSON-LD 格式是比較好的方案,那麼就得先刪除網頁中原本的 Microdata (微資料) 格式。

如果 Blogger 沒有使用最新的 RWD 範本,那麼請按照以下我的整理,來修正範本中的「結構化資料」。

在修改範本之前,建議先閱讀「備份範本的訣竅」系列文章。


1. 刪除 Microdata 標記

下圖是本站使用「Google 結構化資料測試工具」檢查的結果,一片紅通通慘不忍睹:

structured-data-json-ld-blog-post-1.jpg-部落格使用「結構化資料」的最佳作法 JSON-LD﹍提供「文章」型態的範例程式碼


可以點擊個別項目,來找到範本中的位置,也可按照以下要點來處理:

  • 刪除範本所有 itemprop 的相關內容,例如刪除 itemprop='image_url' 這樣的字串
  • 刪除所有 itemscope 的相關內容,作法同上
  • 刪除所有 itemtype 的相關內容,作法同上

都刪除完以後,再使用測試工具檢查,確定都沒有錯誤訊息後,再進行下一個動作。


2. 新增 JSON-LD 結構化資料

在範本中搜尋以下字串:

<b:includable id='post' var='post'>
找到後,在下一行插入以下程式碼:

<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "BlogPosting",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "<data:post.canonicalUrl></data:post>"
},
"headline": "<data:post.title></data:post>",
"description": "<data:blog.metaDescription></data:blog>",
"datePublished": "<data:post.timestampISO8601></data:post>",
"dateModified": "<data:post.timestampISO8601></data:post>",
"image": {
"@type": "ImageObject",
"url": "<data:post.firstImageUrl></data:post>"
},
"keywords": "<b:loop values='data:post.labels' var='label'><data:label.name></data:label><b:if cond='!data:label.isLast'>,</b:if></b:loop>",
"publisher": {
"@type": "Organization",
"name": "Blogger",
"logo": {
"@type": "ImageObject",
"url": "https://lh3.googleusercontent.com/ULB6iBuCeTVvSjjjU1A-O8e9ZpVba6uvyhtiWRti_rBAs9yMYOFBujxriJRZ-A=h60",
"width": 206,
"height": 60
}
},
"author": {
"@type": "Person",
"name": "<data:post.author></data:post>"
}
}
</script>

儲存後就可以了,讀者可以用測試工具來檢測個別的文章網址,都會產生對應的結構化資料。

從這裡也可看出 Blogger 比其他部落格平台強大的地方,只要範本設定好,每篇文章就不用個別手動設定。

重新檢測結構化標記,效果大致如下圖:

structured-data-json-ld-blog-post-2.jpg-部落格使用「結構化資料」的最佳作法 JSON-LD﹍提供「文章」型態的範例程式碼

除了看起來乾淨清爽,沒有錯誤訊息,而且所有結構化資料都非常整齊、一目了然。



五、總結


最後總結強調一下,本篇提供的結構化資料程式碼,是供部落格最基本的「文章型態」使用。如果是特定類型的部落格,例如電影、書評、產品、美食、旅遊...等等,光是套用通用的「文章型態」,不足以完全發揮結構化資料的威力。

之後會另外寫其他型態的結構化資料,提供不同的範例作為參考。


更多 SEO 相關文章:
Viewing all 784 articles
Browse latest View live