[chi2010]Integrating Text with Video and 3D Graphics: The Effects of Text Drawing Styles on Text Readability

source:  Jankowski, J., Samp, K., Irzynska, I., Jozwowicz, M., and Decker, S. 2010. Integrating Text with Video and 3D Graphics: The Effects of Text Drawing Styles on Text Readability. In Proceedings of the 28th international Conference on Human Factors in Computing Systems (Atlanta, Georgia, USA, April 10 – 15, 2010). CHI ’10. ACM, New York, NY, 1321-1330. DOI= http://doi.acm.org/10.1145/1753326.1753524

已經有許多的研究在電腦上的文字閱讀部分,但很少有研究探討3D圖形中與影片中的文字。本研究探討在不同的文字呈現面上(純文字、廣告看板式…)、圖片的對比度和背景的花色(影片或是3D)在閱讀上的影響。研究發現:1)背景的不同會影響閱讀  2)暗的背景比較好 3)看板式的呈現方式效果最好。

作者們先請6位博士生先導性臨床試驗,主要想找出幾個可能最佳的初始變數 1) 廣告式的文字的背景透明度 2)最佳的文字大小 。 得到的結果是背景為白色,字為黑色的情況下最好的透明度是 68.1%,反之則是 55.9%。文字大小則是較為分散,無法得到一個通用的結論。

本研究是個2x2x4的組內實驗,變數的階層如下:

文字呈現的樣式: a) 純文字 b) 廣告看板式(文字顯示在半透明的背景上) c) 抗干擾的文字效果 d) 具有陰影效果

背景圖片的對比: a)暗圖片、亮文字 b) 暗文字、亮圖片。

背景: a) 具有城市跟自然的影片 b) 魔獸世界中的遊戲畫面

研究找來了二十位受測者,每位都有正常或是接近正常的視力,其中有十位是以英語為母語,有四位是女性,年齡分布在24到55歲之間。均是受過高等教育的學生,80%的受測者一天要看六個小時以上的螢幕。受測者結束測試後可以得到一瓶葡萄酒。

本研究有幾個假設: 1) 暗的背景較易閱讀 2)廣告看版型的樣式較易閱讀 3)純文字較難閱讀 4) 越複雜的背景(像是影片)其上的文字越難閱讀。

客觀的研究數據有: 1)閱讀時間 2)閱讀的準確度(作者)

主觀的研究數據有: 1)美觀程度 2) 可讀性(從問卷來計分) 3) 背景的可見度

結果顯示廣告看板的文字樣式在讀取速度和準確度上最佳,而受測者也不致於覺得過於醜陋。因此研究者建議3D遊戲、虛擬實境跟影像都應該使用廣告看板式的文字呈現模式。

廣告

沙漠

最近看了幾本青春型小說(自己取的),吉田修一在《最後的兒子》中的短篇 water (最後的兒子跟碎片這兩篇我倒是沒啥感覺)、森見登美彥 的《春宵苦短,少女前進吧!》和 伊坂幸太郎 的《沙漠》。沙漠這本實在太可怕了,我早上借,晚上就看完了……。之前一直不敢繼續借時光之輪,因為阿…那個第一頁一打開,不讀完是睡不著得阿…  好險沙漠這本只有 473頁,要是跟時光之輪一樣我就慘了阿阿阿阿阿~~~~(是說 冰與火之歌也是同等級的怪物就是…)

《春宵苦短,少女前進吧!》是本熱熱鬧鬧的惡搞之作(反應一定很兩極,我是覺得很有趣啦 :P), water 則是一群高中生想在最後一次縣運會的游泳比賽奪冠的故事。真的是很熱血阿! 我國中最有印象看的書(不是漫畫)應該就是林清玄跟劉墉了,古人說 少不看水滸,老不看三國。我真的是執行的很徹底阿~~~~ 不過我不知道書的來源是哪來的?該不會是雙親的陰謀? 看完之後的副作用不是沒有叛逆期,反而是叛逆期往後延 XD

伊坂真是個有趣的人,之前的書裡面的音樂都是爵士、爵士、爵士。這本書反而把爵士壓低,龐克搖滾拉到主角的位置。該不成是為了搭配熱血的大學生?  開頭第一句話很妙:

四月,大學生活揭幕,沒有裝腔作勢的開場白

哈哈! 大學生活替換成這本書也說的通阿 !!

沙漠這本書主要是描寫一群大學生的生活。是說,人生跟寫程式一樣,都要寫完了(過完了)才知道該怎麼做,但是又不可能重寫一次。於是就把這次學到的教訓挪到下次來用,但是下次遇到的狀況又不會完全一樣阿阿阿。

有一段對話是整本書的精華,很值得我花時間打出來:

鳩麥舔著手上的起司,「我們每天拚命生活,還是不了解該怎麼做才是對的!」她平靜地說,「誰都不知道該做什麼才能得到幸福,對吧!」

「嗯,是阿。」南點點頭

「打個奇怪的比方,這不就像是被扔進沙漠裡,然後對方要求「接下來請自由發揮」嗎?」

「自由發揮?」

「沒錯!沒有人告訴我們該怎麼生活,我覺得自由發揮,反而更痛苦。」

「什麼意思?」

「每個人都想知道正確答案,就算不是正確答案,至少能獲得些線索。因此,大家才會依賴一些指標-例如,買透天厝的注意事項、必勝的育兒法則之類的-只要遵守哪些準則就不會出問題。」

「是阿!」南同意說。

「或許。」我也點頭。

「實際上,人生並沒有這種指標吧,也沒有注意事項或守則,完全都是自由發揮。所以,若是有人告訴我們,「只要進行這樣的修行,就會得到幸福」,或「只要忍耐這些,就可以獲得幸福」,我想人生應該會很輕鬆。就算再怎麼痛苦、需要多大的忍耐,若是有「只要這麼做就能獲得幸福」的指標,生還是會變得很輕鬆。像我們,從小時候起,該做的事情不是都已經決定好了嗎? 出生後幾個月要健檢、六歲上小學,還有參加考試之類的,就算不去思考,也會有指示。還有其他像是延續往年的做法之類的。我想,就算是不良少年,也會面臨退出江湖的階段。儘管如此,突然在人生的某個階段接到「請自由發揮」的指令,當然會陷入錯愕。」

「所以出現了宗教?」我問。「我是說,也有這種宗教。」鳩麥說,喝了一口水。「可疑的宗教,不是經常會出現階級的制度嗎?藉由修行,地位越來越高之類的。我覺得那種制度真的很高明,只要照著做就可以上升一級。如果越往上爬越幸福的話,心情就會變得很輕鬆吧?」

「會嗎?」

「雖然辛苦,但是很輕鬆。知道該怎麼做,而且看的到結果。可是,我們終究無法依賴那種東西,只能抱頭苦思「就算讓我們自由發揮,到底該怎麼做才好呢」,然後一面煩惱一面生活。」

所以啦,程式有所謂的 Design patterns 但是人生有所謂的 Design patterns 嗎?  我也不知道,或許跟星座一樣是有的吧?  只是分的很細很細,有非常多種而已。

mamp & yii

如果 yii 要搭配 mac上的 MAMP 使用,請把connectionString 從

mysql:host=127.0.0.1;dbname=playaround

改成

mysql:dbname=playaround;unix_socket=/Applications/MAMP/tmp/mysql/mysql.sock

即可

yii extensions

剛用了一些 extension 就發現一些小問題..

我用了 yii-user & images

yii-users

在 modules/user/views/admin/_menu.php 裡面的

if ( count($list)) {

要改成

if (isset($list)&&  count($list)) {

然後 images的設定那邊錯了

<pre>'import'=>array(
    ...
    'application.helpers.*',
    ...
),

應該是

<pre>'import'=>array(
    ...
    'application.extensions.helpers.*',
    ...
),

因為是解到 base/extensions/helpers/ 底下阿!!

黑塔

今天上課老師放得是 趨勢科技創辦人 張明正先生的訪談。最讓我印象深特的是,他說 最幸福的事,就是找到自己的天命,然後一路前進。 最近在看史蒂芬·金 的黑塔,裡頭的槍客也是如此,槍客有自己的黑塔,然後跟隨著光束前進(在書中,光束的方向是道指引)。 不過前兩本有點悶,還在撿拾夥伴的階段,要到第三集才比較有趣。不過比不上英倫魔法師前面沉悶就是。

今天從客運下來,往學校的方向走,101就矗立在遠方,然後我就這樣往前一直走。 事後想起來,很有追尋的意象在。

希望有一天我可以清楚地找到我自己的黑塔、我的業(ka)、我的共業夥伴,然後再度尋著光束前進,重溫小時候第一次看到電腦螢幕閃動的游標那種不顧一切的感動。

[chi2010]Apatite: A New Interface for Exploring APIS

source:  Eisenberg, D. S., Stylos, J., and Myers, B. A. 2010. Apatite: a new interface for exploring APIs. In Proceedings of the 28th international Conference on Human Factors in Computing Systems (Atlanta, Georgia, USA, April 10 – 15, 2010). CHI ’10. ACM, New York, NY, 1331-1334. DOI= http://doi.acm.org/10.1145/1753326.1753525

當前的api 文件設計均是由上往下的樹狀結構。這對於複雜的系統來說過於侷限,使用者無法在不知道上層結構的情況找到特定動作相關的資料,如檔案存取。Apatite 則是可以允許使用者在不同的階層中搜尋且根據搜尋引擎的資料來判斷相關性再藉由多欄式的介面呈現。Apatitle 通過了使用性測試,且可以在網路上試用。

諸多程式設計師花費相當多的時間在api文件的查詢上,而龐大的api 庫,像是 .net 或是 java ,有經驗的工程師也無法熟悉每個部份。這使得工程師們經常需要以任務為導向來搜尋api。有些學生會搭配搜尋引擎來找到相關的討論或是範例,但此舉有利有弊,壞處在於仍然參雜了許多不相關的資料進來。

作者提出的 Apatite 有四個特點:

  1. 在一張圖中呈現所有的資訊
  2. 呈現出來的元素都是最常使用的
  3. 選擇了其中一個元素,Apatitie會連著帶出相關的元素
  4. 使用者可以從”動作”或是方法的角度切入api文件,不再是從類別開始

本研究以javadoc 為改造對象。如上圖一所示,一開始會秀出最常見的元素,且用字體大小來表示其常用的程度。點選了一個元素之後,第二欄被帶出,顯示與被選定的元素相關的資料。

每個api元素的熱門程度是藉著透過全名去google所得到的結果排序而來,動作的分組則是根據完整名稱前面的第一個駝峰字是否為動詞,舉例來說: read 出現的頻率 = readInt 的頻率+ readLine 的頻率。兩者的相關性是透過搜尋一個名稱的前一百個結果中,另一個組合元素出現的次數來計算。

作者認為Apatitie 對於api文件的使用性上有諸多貢獻。例如可以幫助api設計者得知最常用的組合為何、相關的元素為何。最後作者提到如果可以一開始透過名詞與動詞兩個類別來展開api文件會對使用者相當有幫助,他們也正在實驗從api文件中拿出動詞的更好作法。

note:

網址在 http://www.cs.cmu.edu/~apatite

activerecord & php

最近在研究 yii,因為前一陣子用cakephp 有點感覺不順,尤其是 model 之間的關係對應。這幾天看了yii 才發現,應該是php/ruby 語言的差異。

看一下 rails裡面的定義這樣寫:


class Project < ActiveRecord::Base

belongs_to              :portfolio

has_one                 :project_manager

has_many                :milestones

has_and_belongs_to_many :categories

end

cakephp 裡面是這樣:


class User extends AppModel {

var $name = 'User';

var $hasOne = 'Profile';

var $hasMany = array(

'Recipe' => array(

'className'  => 'Recipe',

'conditions' => array('Recipe.approved' => '1'),

'order'      => 'Recipe.created DESC'

)

);

}

yii 裡面長這樣(定義在函式裡面):


public function relations()

{

return array(

'author'=>array(self::BELONGS_TO, 'User', 'authorId'),

'comments'=>array(self::HAS_MANY, 'Comment', 'postId',

'order'=>'comments.createTime'),

'tagFilter'=>array(self::MANY_MANY, 'Tag', 'PostTag(postId, tagId)',

'together'=>true,

'joinType'=>'INNER JOIN',

'condition'=>'tagFilter.name=:tag'),

);

}

我個人是覺的 rails 的最直覺 cakephp次之, yii 的則稍嫌麻煩了些。不過我覺的這php用hash實做起來不太順….。不知道其他框架有沒有別的實做方式就是了