lifeLOG + REPOsitory: ユーザ体験

ラベル ユーザ体験 の投稿を表示しています。すべての投稿を表示

2010-12-17

twitter より (2010-12-16)

18:34 Safari の Command + Ctrl + D を知らなかったよ。単語をダブルクリックで選択状態にして、Command + Ctrl + D。単語のそばに小さい辞書ウィンドウが開く。ナニコレ、便利すぎる。→ http://bit.ly/ethdtl

2010-11-29

設定の保存にまつわる問題 - 環境設定パネルを作る #2 (MacBloggerGlass)

設定を User Defaults に書き込むことは難しくない。設定値が NSString であるならなおさらだ。PreferenceController の実装部に以下のようなコードを埋め込むだけだ。

    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    NSString *accountID = [accountField stringValue];
    [defaults setObject:accountID forKey:@"AccountID"];

また参照する側 (AppController) では、以下のようにすれば良い。

    blogID = [blogIdField stringValue];
    if ([blogID length] == 0) {
        NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
        blogID = [defaults objectForKey:@"blogID"];
    }

今回の記事の内容は、設定を保存するコードではなく、設定の保存を中心としたユーザ体験上の問題について。

UI が提供するユーザ体験は、実際に動かしてみると、デザイン段階での「あら」があちこちに浮かび上がってくる。環境設定パネルでもアプリ本体とつないで見ると、いくつかの不備が見えてきた。今日、「Save」ボタンの機能を実装してみて、(そして動かしてみて)以下の 3 点について気付いた。

パスワードを User Defaults に保存するのはマズい。
「Save」ボタンを押した後のフィードバックがない。
ブログのリストと選択の状態が保存、復元されない。

設定を保存すると ~/Library/Preferences に置かれるファイルに書き込まれる。テキスト形式は言うに及ばず、バイナリ形式にしても、そこにパスワードを平文で書き込むのはマズい。パスワードを保存する場合には、キーチェーンと連携させるのが Mac アプリの作法だろう。とりあえず、パスワードは保存の対象から外しておく。キーチェーンとの連携は棚上げ。

アプリを使う際にさまざまな処理の結果がユーザに対して適切にフィードバックされるかどうかはユーザ体験に大きく影響する。「ボタンを押す」というユーザのアクションに対してユーザの目に見える反応が何も起こらないと、ユーザに不安を感じさせることになる。ありがちなフィードバックとしては「完了しましたダイアログ」を出すことだが、これは使いどころを間違えると、ただわずらわしいだけになる。

今回の環境設定パネルの場合、「Save」が押されたらパネル自体を消すというのが良いように思う。現状ではこのパネルの役割はアプリのメインウィンドウで表示するブログの選択のみだ。そこで「Save」ボタンが押されたのだから、保存処理が完了したのなら何も仕事は残っていない。だから、パネルを消せば処理が(成功のうちに)完了したことは十分に伝わるし、(わずらわしいダイアログのような)余分な UI も増えない。

今、悩んでいるのは、最後の環境設定パネルを(設定を保存し)一度閉じて再び開いたときに、元の状態を復元させる仕組みだ。必要な情報はブログ(タイトル)の一覧と選択された項目へのインデックス。ここで、問題が 2 つほど出てくる。

1 つは、「ブログ(タイトル)の一覧の保存」に関係する。前回の記事(→「表示するブログの選択」)で書いたように、環境設定パネル(右図)の表部分 (NSTableView) は、Cocoa Bindings によって(NSObjectController と NSArrayController を介して)モデルのプロパティに結びついている。表に出てくる項目は EntryBlog のプロパティであり、これを保存することは EntryBlog を保存することになる。Cocoa Bindings で結びついている以上、ブログのタイトルだけを NSStrings を抱えた NSMutableArray として保存しても意味はない。

そう、1 つ目の問題は環境設定パネルにとってのモデルである FeedBlog と EntryBlog の保存(永続化)の仕組みが必要だ、というものだ。

2 つ目の問題は、選択の状態をどうやって復元するか、というもの。何度も書いているようにパネルの表(ビュー)は Cocoa Bindings によってモデルと結びついている。だから、その選択の状態も Cocoa Bindings でどこかの何かと結びつけなければならない。Interface Builder で NSTableView の Bindings パネルを開くと Selection Indexes という「結びつき」を設定する項目がある。これを使えば選択の状態を Cocoa Bindings による結びつきで伝えられそうなんだが、問題はそれを「どこ」の「何」というプロパティにするか。

保存すべき情報という意味でこれもモデルの一部と言える。FeedBlog の一部にすることもできるが、抽象化の障壁に穴を空けてしまうようでイヤな感じだ。別のモデルオブジェクトとして独立させた方が良い。と言っても、情報自体は整数値 1 つなので、実際には PreferenceController に int のプロパティを増やすことになるか。

次回は表項目の「選択」のための結びつきを Cocoa Bindings で作ることを試してみよう。

まあ、ユーザ体験うんぬん以前に、ウィンドウの UI を考えるときに状態の保存と復元について考えていないのがそもそも悪い。経験不足だと切って捨ててしまえばそれまでだけど、Cocoa Bindings を使ってモデルとビューを同期させることに注意が引きつけられていたせいもあるだろう。

表示するブログの選択 - 環境設定パネルを作る (MacBloggerGlass)

2010-11-24

twitter より (2010-11-23)

18:13 iPad のアップデート中。アップデートが終わり、リブートした後の同期(バックアップ)に時間がかかるわ。雑誌の PDF データがでかいんだよね(Good Reader のデータになってる)。
19:05 AirPlay って iPhone や iPad から tv への配信のみなのか。逆はできない。ちょっと残念だけど、これだけでもオモシロイ。iPhone や iPod touch ならリモコン感覚で使えるしな(実際リモコンにもなる)→ http://bit.ly/h97C0V
19:06 AirPlay があると iPod touch に動画を溜めてみたくなる。
21:17 そうだ、iPad のメールも iPhone と同じで「全受信」が使えるようになったんだね。これに慣れてしまうと、iPad でメールを開いたときにいちいちアカウントを切り替えるのがメンドウでしかたなかった。地味だけど、これも 4.2.1 になって良かったことの 1 つだな。
21:34 お、いいね。.gitignore の設定集。プロジェクトごとだけじゃなく、グローバルに ignore を設定することもできるのね。OSX で git を使うときは便利だな。「.DS_Store」とか、いちいち足さなくても良くなる。→ http://bit.ly/fQxBqD
21:51 今どきの若者や子どもたちの中にはダイヤル式の電話なんか見たこともなかったりするんだろうな。きっと使い方もわからないんだろうな。→ http://inspire.2ia.pl/post/35068946/dial-the-old-fashion-way
21:55 ちょっと試してみたけど、おもしろかった。iPhone にも最適化されていて素敵。ただ、iPhone で開くとランダムボタンは出てこない。ちょっと残念。 → http://bit.ly/hLlA1V

2010-11-03

twitter より (2010-11-02)

09:34 なるほど。Air ってそういう位置付けだと思えばいいのか。革新(と核心)は SSD の搭載にあったってことか。軽くて(薄くて)サクサク動く。唯一の弱点は電池の持ちの悪さだな。 → http://bit.ly/cSud1e
11:25 いまさらだけど、先日の Apple Special Event のビデオを見た(新しい Air が発表になったやつ)。これを見ると、今度の Air が、Mac というよりむしろ iOS デバイスに近いと思えてくる。キーボードがついて、OSX が動く iPad に見えてくる。
11:27 来年(2011)の夏、Lion がリリースされて、Launchpad や Mission Control が利用できるようになれば、ますますその感が強くなるに違いない。
11:30 iPhoto 11 のデモを見ていて感じたのは「あれ、これってiPadなのか(・ω・)？」ってことだ。それぐらい、iPadアプリの影響が色濃く現れていた。画面のデザイン(意匠)はとくに。
11:31 iPhoto 11 のような(外観の)アプリを、Xcode 標準のビューやコントロールだけで作れるんだろうか？
13:31 Mac OS X Lion の新機能として挙げられていた(説明はなかったけど)、(アプリの)自動セーブと起動時のレジューム(これもアプリの話だよね)が実現されると実は画期的なことだと思う。
13:35 前者はアプリユーザをファイルの管理と操作から解放してくれるし、後者もアプリの使い方を大きく変えるはず。もちろん、アプリ側での対応ができてからの話。ま、どちらも iOS アプリでは当たり前のことだけどね。
13:38 けど、はたしてユーザに受け入れられるだろうか？ iOS アプリを使い慣れているユーザなら問題ない。Launche PadとMission Control に支えられたフルスクリーンアプリ(自動セーブとレジューム付き)は、iOS アプリのユーザ体験をそのまま取り込んだものだから。
13:40 iOSって何、それオイシイの？と思うユーザにとってはどうだろうか。データを保存するタイミングが自由にならないことにとまどわないだろうか。ファイルが表に出てこないことに違和感を感じないだろうか。
13:43 ああ、そうか。iTunes や iPhoto なんかでファイルを意識しないアプリには慣れているかもな。アプリによるってことかな。ファイルを意識させないユーザ体験を提供できるアプリは新しい操作環境で使われ、ファイルベースの古臭いアプリは旧来のデスクトップの下で使われる、と。

2010-10-27

絞り込み検索とパンくずリスト

Blogger Glass を「iPhone アプリらしく」仕立てるためのアレコレを考えていて、ラベルによる絞り込み検索というモノを思い付いた(「iOS デバイスに対応する (基礎編) - Blogger Glass」の「もっと iPhone らしく」を参照)。

ユーザ体験としてはこんな感じになる。

「一覧画面」から「ラベル検索画面」を開く。
元の「一覧画面」に出ていた記事それぞれに付いていたラベルがまとめて表示されている。
ラベルの中から 1 つ選ぶと、検索実行。
「検索結果画面」になる。 (*)
絞り込みをする場合、再度「ラベル検索画面」を開く。
さきほどの「検索結果画面」の記事それぞれに付いていたラベルがまとめて表示されている。
ラベルの中から 1 つ選ぶと、検索実行。このときは、先に選んだラベルとの複合検索(AND)になる。
(*) に戻る。

最初に「一覧表示」から開いた「ラベル検索画面」では、すべての記事に付いているラベルを表示する方が良いかも。

パンくずリスト

日本語では「パンくずリスト」、英語では「breadcrumbs」あるいは「breadcrum trail」と呼ばれるモノがある。現在表示中のウェブページの位置を、たどってきたパスの階層構造等で表現するナビゲーションアイテムだ。Mac OS X の Finder で、表示中のフォルダの階層構造を示すために使われている「パスバー」もこの一種だ(Finder に表示されていなければ、メニューから「表示」>「パスバーを表示」を選ぶ)。

Finder のパンくずリスト

上述の「ラベル検索」では、検索に使われたラベルをユーザにフィードバックしなければならない。そのためにも「パンくずリスト」が適しているはず。これならユーザが選んだ順序をふくめて表現できる。検索結果はラベルを選んだ順序によらないが、ユーザにとっては自分の操作を正確にフィードバックしてくれる方が良い(少なくともわたしはそうだ)し、なにより「パンくずリスト」なら、逆にたどって以前の画面(検索結果)に戻っていける(という機能をわかりやすく提示できる)。

文字入力させたら負けだと思う

iPhone のように使用状況を選ばないデバイス(歩きながらでも、満員電車で吊り革につかまっているときでも使えるし、使いたい)では、文字入力のような複雑な操作はなるべく避けたい。項目をタップし、画面をドラッグそれにスワイプする。片手で操作できるなら歩きながらでも使える。

検索では、最初にラベルを複数選んでおいてから検索実行、という方式も考えられる。だが iPhone で実現するなら、操作が自ずと小さなステップに分割され、さらに個々のステップでフィードバックも得られる「順次絞り込み」タイプの方が適している。また、現在の状況と操作の履歴を同時に表現できる「パンくずリスト」はナビゲーションの仕組みとして最適だろう。

ま、実際に使ってみない間は、ただの一般論でしかないがな。

2010-10-25

iOS デバイスに対応する (基礎編) - Blogger Glass

Blogger の提供するスタイルにあれこれ変更を加え始めたのは何より iPhone (と iPad) で見やすくしたかったからだ。それが高じてブログの記事を表示する GAE アプリを作るまでに至った。ある程度の実用性を備えた今こそ、iOS デバイスの対応を始めるときだ。

iOS デバイスへの対応と言っても、これまでのように単にスタイルを最適化する程度で終わりたくない。ブログコンテンツを表示するためのアプリと呼べるものに仕上げたいのだ。最終的には Blogger Glass を iOS デバイス用のウェブアプリと呼ぶにふさわしいモノにするつもり。何をどこまで作り込めばそう呼べるかはまだわからない。そもそも BG 自体まだ機能的に不足しているし、実装ずみの機能も洗練されているとは言えないしな。課題は(見えないものもふくめて)多いが、まずは一歩を踏み出そう。そうすれば次に進むべき方向も見えてくるから。

今回は基礎編。まずは以前の成果(スタイル定義)を流用して、現在、Blogger (の LOG+REPO) を iOS デバイスで開いたときと同等の外観を実現する。それには主に以下の 2 つの作業が必要だ。

Viewport の設定
デバイスごとの CSS ファイルの用意

それでは順番に見ていこう。

viewport の設定

(「iPhoneアプリケーション開発ガイド―HTML+CSS+JavaScript による開発手法」p.17)
特に指定がない場合、iPhone 版の Safari ではページの横幅が 980 ピクセルであるとみなされます(図2-3)。多くの場合はこの設定でも問題はありませんが、iPhone の小さな画面に特化したコンテンツを作成するためには横幅を明示する必要があります。

さて、この横幅の指定は meta タグによって「viewport」を設定することで行う。viewport の設定(の meta タグ)は(iOS デバイスの Safari)以外のブラウザでは無視されるということだ(→「iPhoneアプリケーション開発ガイド」p.18)が、そこはウェブアプリなのだからリクエストデバイスに応じて追加するようにしたい。

それが以下の部分だ。app オブジェクトの is_ios_device 属性が True のときだけ viewport 設定のmeta タグを追加している。

(src/base.html より)
<title>{{ app.title }}</title>
{% if app.is_ios_device %}
  <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1, maximum-scale=1">
{% endif %}
<link type='text/css' rel='stylesheet' href="{{ app.stylesheet }}">

app オブジェクトは、各リクエストハンドラからわたってくる info.AppInfo クラスのインスタンスだ。このオブジェクトに情報を詰めているのが、util.fill_appinfo 関数で、リクエストデバイスの識別を行う util.get_device 関数を利用してデバイスごとの情報を生成している。それにはデバイス専用の CSS ファイルもふくまれている。

(src/util.py より)
def fill_appinfo(appinfo, request_url, user_agent):
    [...snip...]
    device = get_device(user_agent)
    if device == 'iphone':
        appinfo.is_ios_device = True
        appinfo.stylesheet = '/stylesheets/iphone.css'
    elif device == 'ipad':
        appinfo.is_ios_device = True
        appinfo.stylesheet = '/stylesheets/ipad.css'
    else:
        appinfo.is_ios_device = False
        appinfo.stylesheet = settings.get('stylesheet')

デバイスの識別はユーザエージェント文字列中のデバイス名によるもので、3 つのタイプを返す(iphone、ipad、そして mac)。iOS デバイス以外は mac 扱いにしている。

(src/util.py より)
def get_device(user_agent):
    if user_agent.find('iPad') > -1:
        device = 'ipad'
    elif user_agent.find('iPhone') > -1 or user_agent.find('iPod') > -1:
        device = 'iphone'
    else:
        device = 'mac'
    return device

デバイスごとの CSS ファイルの用意

デフォルトスタイルの時と同様に、Style Repository で LOG+REPO 用に提供している各デバイス用のスタイルをほぼそのまま流用した。

iPhone 用では実験的に少し色を変更してあるが、これはすぐに変更することになる(後述)。

Blogger Glass が生成する HTML は HTML5 に準拠することを目指している。header や section、そして footer のような区画分けのための要素を使っているのも、そのためだ。今回、iPad 用のスタイルを用意していて、現在の iPad 上の Safari (OS: 3.2.2 (7B500)) ではこれら区画分けの要素に単独で指定したスタイルが効かないことがわかった。具体的には以下のような定義が無効になる。

(区画分け要素のスタイル)
header {
    background-color: #eeffcc;
}

同じ定義が iPhone および iPod touch (どちらも OS 4.1 (8B117)) では有効になる。iPad の OS がアップデートされれば解決されるだろう。

ま、わたし自身が十分に HTML5 のスペックを読み込んでいないため、BG の HTML5 準拠も手探りだからな。BG が生成する HTML の構造もまだまだ変わる。スタイルもそれに合わせて変えなくてはならない。今のスタイルも暫定版でしかない。

もっと iPhone らしく

さて、以上が iOS デバイス対応の基礎編だ。ここから先は、デバイス対応というよりも、むしろ BG の iOS デバイス専用ウェブアプリ化になる。その手始めとして、今、実験中のスタイル定義によるスクショを示す。iPod touch による表示だ。

これは「iPhoneアプリケーション開発ガイド」の p.19 〜 23 の書かれている手法を適用したものだ。少しリストと見出しのスタイルをいじるだけで、ずいぶん iPhone アプリらしくなる。

ゴールを、iPhone でも使えるモノから iPhone で専ら使うモノに変えると、機能のデザインも(とくにユーザ体験に関して)いろいろと変わってくる。たとえば、ラベル検索による絞り込みも、Mac (上の Safari)で使うことが前提なら、詳細検索画面を作って複数のラベルを指定させて、なんていう拡張を考える。けれど iPhone に特化するなら、まずラベルを 1 つ選択して検索し、その結果表示画面でさらにもう 1 つラベルを選択して(2 つのラベルによる複合検索で)絞り込む、というような使い方を考える。

iPhone では一度に表示できる情報が限られているし、モバイル機器であるためユーザとの対話は短いほど望ましい(ユーザは椅子に座ってじっくりと iPhone の画面を眺めているとは限らない)。そういった機器の特性はユーザ体験のデザインに大きく影響する。ウェブアプリとして実現されていたとしても、iPhone 用を標榜するなら、iPhone アプリらしくあらねばならない。単にスタイルを変えるだけで済む問題ではないってことだ。

参考文献

iPhoneアプリケーション開発ガイド―HTML+CSS+JavaScript による開発手法

Jonathan Stark
オライリージャパン ( 2010-08-07 )
ISBN: 9784873114613
おすすめ度: アマゾンおすすめ度

物読みファイル (別館)で詳細を見る

MediaMarker

2010-10-24

ページ切り替え機構の切り替え - Blogger Glass

今回はちょっと実験。2 種類のページ切り替えの仕組みを用意し、どちらが使いやすいかを確かめる実験だ。

「ページ切り替え」と言うのは、Blogger Glass の一覧表示系の画面の下部に出てくるもののこと。リストする項目が多いときには複数のページに分割する。そのページを切り替えるための仕組みだ。

現状では、Google の検索結果に出てくるモノ(Goooooooooogle! のようになるアレだ)を真似ている。これをもっとシンプルな「Next」「Prev」ボタンのものと比較してみようと思ったのだ。

2 つの方式の比較

実験というからには、2 つを比較できなければ意味がない。旧来の方式と新しい方式を両方使えるようにしておいて、実際に使ってみて試すわけだ。

幸い、一覧表示系の画面(機能)は「一覧画面」と「検索結果画面」の 2 種類がある。このうち、「一覧画面」のみを新方式にして、「検索結果画面」の方は従来のままにしておく。そうすれば、どちらの方式も試すことができる。

まあ、配備ずみの正式版(appspot で稼動しているもの)と開発中のローカル版(SDK で動かしているもの)で比較するという手もあるんだがね。

リファクタリング

「ページ切り替え機構」を簡単に取り替えられるようにするため、src/info.py、さらに src/main.py と src/searchview.py にも手を入れる。

具体的には、「ページ切り替え機構」そのものを ViewInfo のインスタンスで抱え、表示対象のページ番号や全ページ数は「ページ切り替え機構」の属性に押し込める。リクエストハンドラは「ページ切り替え機構」を選び、ViewInfo のインスタンスにセットすることになる。

「ページ切り替え機構」は、util.Pager クラスを基底として派生させる。旧方式は util.GlassPager と名付けた。

(src/util.py より)
class Pager(object):
    PAGESIZE = 25
    def __init__(self, page_num, total_posts):
        self.current = page_num
        self.total_pages = 0
        if total_posts > 0:
            self.total_pages = (total_posts - 1) // Pager.PAGESIZE + 1
        else:
            self.total_pages = 1

class GlassPager(Pager):
    class Page(object):
        def __init__(self, number, current=False):
            self.number = number
            self.current = current

    def __init__(self, page_num, total_posts):
        Pager.__init__(self, page_num, total_posts)
        self.pages = []
        for p in range(self.total_pages):
            self.pages.append(GlassPager.Page(p, p == page_num))

src/main.py の MainHandler で「ページ切り替え機構」をセットする付近のコードを示す。

(src/main.py)
            total_posts = int(feed.total_results.text)
            self.viewinfo.pager = util.PrevNextPager(page, total_posts)
            self.viewinfo.start_index = start_index

結果として、ページ切り替えに関する情報の生成と詰め直しを追い出したことになり、少しすっきりした。

シンプルなページ切り替え

ごく単純な「Prev」「Next」の 2 つのボタン(リンク)のある方式で、最初と最後へのショートカットを持っている。つまり、こんな感じになる。

[Top] [Prev] <current page #> [Next] [Last]

また、現在のページが最初のときは「Top」と「Prev」は表示せず、最後のときは同様に「Next」と「Last」を表示しない。

これを実現するための util.Pager の派生クラスは以下のようになる。

(src/util.py より)
class PrevNextPager(Pager):
    def __init__(self, page_num, total_posts):
        Pager.__init__(self, page_num, total_posts)

        if self.total_pages > 0:
            self.last = self.total_pages - 1

        if self.current != 0:
            self.is_top = False
            self.prev = self.current - 1
        else:
            self.is_top = True
            self.prev = 0

        if self.current != self.last:
            self.is_last = False
            self.next = self.current + 1
        else:
            self.is_last = True
            self.next = self.last

で、これを表示するテンプレートはこう。

(src/listview.html より)
{% block view_footer %}
<nav>
  <div class="pager">
    {% if not view.pager.is_top %}
    <span class="l-button"><a href="/?page=0">Top</a></span>
    <span class="l-button"><a href="/?page={{ view.pager.prev }}">Prev</a></span>
    {% endif %}
    <span id="pager-current">{{ view.pager.current }}</span>
    {% if not view.pager.is_last %}
    <span class="r-button"><a href="/?page={{ view.pager.next }}">Next</a></span>
    <span class="r-button"><a href="/?page={{ view.pager.last }}">Last</a></span>
    {% endif %}
  </div>
</nav>
{% endblock %}

info.Menu クラスと同様に、util.Pager クラス(とそのサブクラス)は info モジュールに移すべきかな。

「Goooooooooogle!」方式と「前後」方式

実際に使ってみたところ、「Goooooooooogle!」方式にはとくにメリットがないと感じた。この方式では途中のページにダイレクトに飛べるわけだが、そこに何がリストされているかがわかっていない限りほとんど意味がない。リストを順にたどって見るようなときには「前後」方式の方が切り替えやすい(マウスを動かさなくても良いから)。まとめて何ページも先を開くなら「Goooooooooogle!」方式の方が便利だが、実用上そういう場面が思い浮かばない。

特定の時期に書かれた記事を探すなら大きく前後に移動できた方が便利だが、そういう便利さを実現したいなら月や週で検索できる画面(ビュー)を用意した方が良い。

iPhone のような画面の狭いデバイスの場合も「前後」方式が適している。特定のページを直接開くというユーザ体験を実現するなら、それ専用の画面(ビュー)を作るべきだ。

「一覧」や「検索」といった機能を実行した結果が複数のページに分かれる場合、シンプルな前後方式の方が汎用性が高い(画面のサイズを選ばないから)。そもそも(大量の)複数ページに分かれているという点でユーザ体験としては減点だろう。ユーザが意識して「全部を順番に見たい」というのでない限り、適切に絞り込む手段を提供すべき。そして、適切に絞り込めるなら(ページ数にしてせいぜい 2 〜 3)「前後」方式が(ユーザに余分なことを考えさせないという意味で)直感的だ。

2010-10-22

twitter より (2010-10-21)

12:00 何だか良くわかんないラインナップだなあ > new MacBook Air。11インチだけなら「世界で一番薄くて軽いMac」でわかりやすかっただろうに。 → http://bit.ly/a7VMie
12:03 あと、バッテリーの駆動時間が MacBook の半分ってどういうことだ？計測の基準が違うのか？いくら薄くて軽くてもバッテリーが持たないんじゃ持ち歩きにくいだろうに。やっぱ、良くわからん。
12:15 Lion はまだ1年近く先か。Mac App Storeを別にすれば、LaunchPadもフルスクリーンアプリもMission Controlも、ぜんぶ画面の小さなMac用に思えるよ。→ http://www.apple.com/jp/macosx/lion/

2010-10-10

twitter より (2010-10-09)

00:16 ノート型だと縦方向が不足していると感じる。とくにPDFのようにページに区切られたコンテンツを見るときには。けどスクロール前提のコンテンツ(ブラウザとか)だと、縦に長くてもやっぱりスクロールしているよ。 → http://bit.ly/dgSCYY
00:17 縦に収まり切らないんだからスクロールしないと隠れている部分が見えないのは当然なんだけど、そうじゃなくて、見えている部分だとしても、スクロールさせて視線の位置まで持ってきているってこと。
00:20 縦方向が 1440 だろうが、1600 だろうが変わらない。横方向には視線を移動させるんだけど、縦方向には不思議と視線を移動させない。その変わりコンテンツを移動させる。画面の上下に視線を移動させるのって、コードを読むときぐらいじゃないかな。
00:23 一方、本(電子書籍をふくむ)のようにページで区切られたコンテンツだと視線の移動を強制される。どっちが読みやすいんだろう？
00:29 Magic TrackPad に慣れると、コンテンツをスクロールさせることが、ほとんど無意識に行えるようになる。視線を移動させるのと同じぐらい無意識に。そのことも、視線の移動の代わりにコンテンツをスクロールさせる読み方に貢献しているのかも。
00:38 これ(27インチシネマ)も、昔の30インチシネマに比べて縦方向は減ってるんですがね(1600→1440)。(スラドの記事の)縦方向の減少といい、表面の仕上げ(グレアとノングレア)といい、ディスプレイの変化の方向がユーザ体験の向上を目指してのものだとは思えないんですよね。
00:54 あ、ふと思ったけど、ヒトの首って左右にくらべて上下は稼動(って言葉で良いのかな？)可能な範囲が、ぐっと狭いんだよ。それでいて動かすことによる負担も大きい。ひょっとしたら目玉も左右に動かすより上下に動かす方が大変だったりする？縦方向はあまり大きくても使いにくいのかもな。
10:27 ブクマ代わり。あとで読む。「スーパーコンピューティングの将来」 → http://www.artcompsci.org/~makino/articles/future_sc/face.html

2010-09-13

twitter より (2010-09-12)

14:58 Amazonに発注したiPadスタンドが届いたので早速使ってみた。なんてゆうか、やられたわ。iPadってこうやって使うべきものだったんだ。iPadに対する印象がすっかり変わるゾ。→ http://bit.ly/9OgV92
15:31 う〜ん。iPadのスタンドにはまいった。想像だけではユーザ体験は語れないってことの証拠になる。無意識のうちに、iPadを「ちょっと大きいiPhone」と認識していたのかもな。だからiPhoneと同じような使い方をしなきゃならないと思い込んでいた。スタンドなんて邪道だよ、と。
15:36 しかし、大きさという特性は利用の仕方も変えるものだったんだ。iPhoneにスタンドは不要だが、iPadにはスタンドはぜひとも必要。そしてiPad+スタンドは「読む」という体験を根本から変える。「本を手に持たずに読む」ことが実用的になる。むしろ本はこう読むべきだったと気付く。
15:39 紙の本を「手に持たずに読む」には 2 通りの方法が考えられる。(1) 机の上に本を水平に置く、(2) ブックスタンドを使う。(1) は首を下に向けて読むことになるから首に負担がかかる。(2) はiPad+スタンドに近い体験となるが、ページがめくりにくいという欠点がある。
15:44 参考書を机に広げて作業することを考えると、iPadが複数台あっても良い気がしてきた。もうこれ以上、机の上にディスプレイは置けないけど、iPad なら置けるしな。加えて、iPadなら指先で直接触れられる分、画面にPDFを表示させるよりもページ送りなんかの操作感は上だ。
15:45 とはいえ、さすがに同じものを2台、3台と買う気にはなれないので、早く新しいiPadを出してください。> Apple
21:04 バイオハザードか。3は見てないんだよな。

2010-09-11

直感的って何だろう？

(グラフィカルユーザインタフェース - Wikipedia より)
グラフィカルユーザインタフェースは、視認性、操作性に優れ、直感的な操作が可能なため、広く普及し、現在では主流のインタフェースになっている。

「直感的」と言う言葉(英語では intuitive)は、初代 Macintosh の登場以来、GUI に対して代名詞的に使われるようになった。GUI であれば直感的、直感的なインタフェースは GUI だ、と言うように。

ただし、GUI が直感的であるのは、それ以前の GUI ではない(GUI と対比して CUI と呼ばれる)コンピュータシステムとの比較においてだ。いくらデスクトップと呼んでみたところで、9 インチのモノクロの画面に表示される「絵」を現実の机と思い込むことはできなかったはず。メタファとは、あらかじめそうだと教えてもらわなければ、関連性を理解できないものだ。

また、Macintosh が当時の他のコンピュータと比較して使いやすいと言われたのは、そもそも使いやすくなるように設計されたものだったからだ。GUI やマウスを備えていたから使いやすくなったわけじゃない。使いやすくする手段(の一部)として GUI やマウスを採用したのだ。

ところが、いつからか本末が逆転するようになっていく。GUI は (CUI より) 直感的、GUI (を備えた Mac)は使いやすい、だから、直感的なインタフェースは使いやすい。論理の飛躍が生まれた。いや、飛躍というより横滑りというべきか。

しかし、本来、「直感的」と「使いやすさ」は別のことを指すはず。

訓練しなければ使えません

確かに、Mac 以前のコンピュータはユーザを選ぶものであった。利用するために特別な訓練を必要とするものだった。けれど、利用に特別な訓練を必要とするという事実と、使いにくいという印象は同じことを意味するわけではない。

たとえば、クルマの運転は法律の上からも、安全という観点からも、特別な訓練を必要とする。だからといって、クルマを使いにくいと言うヒトはいない。クルマの運転が難しいと言う場合も「そう感じる」という事実を単純に表明しているだけで、「もっと簡単にできるはずのことが、道具の作り方が悪いせいでことさら難しくなっている」などといった意味が込められてはいない。

また、当時のコンピュータは(現在の基準からすれば)非力な割に高価な機械であって、ユーザの便益のために割く処理能力の余裕はなかったのだ。だから、訓練によってヒトが機械に近づかなければならなかったのだ。

論理ではなく感覚による把握

言葉の定義からすると、直感とは、推理や考察によるのではなく感覚によって物事をとらえること、だと言う。もう少し噛み砕くと、問題となる状況を見たとき理由はわからないけど答えが思い浮かぶ、そういう状況と言える。なぜそうなるのか、どうしてこれが正しいのか、そのロジックはわからない。だけど、答えはコレだとわかる。それが直感だ。脳内で起きるパターン認識だと言っても良い。

では、なぜ「パッと見ただけで、どう操作すれば良いのかがわかる」のだろう？

それは、過去に、似たような何かを操作する、という経験をしたことがあるから。いま、目の前にある様子が過去に経験した別の何かと似ているために、過去にした行動をいままた適用すれば望む結果が得られる、と判断するわけだ。

ボタンのように見えるモノを見たら押せるに違いないと思う。ハンドルのように見えるモノがそこにあれば、回せるはずだと思う。それが直感だ。

デジタルなモノをアナログな物に似せて作る

われわれは生まれてからずっと様々な物に囲まれて暮らしている。日々の暮らしの中で、周囲にある物に対する働きかけの方法を学んでいる。ボタンは押すし、ハンドルは回す。誰かに教えられることもあれば、試行錯誤の中で適切な方法を身に付けることもある。

もし、デジタルなモノが、われわれが慣れ親しんだアナログな世界の物に良く似ていたら、われわれはモノの利用の仕方を改めて学ばなくても良い。ボタンに見えるモノは押すし、ハンドルっぽいモノは回す。特別な訓練は必要ない。

ただし、外見が似ているだけではダメだ。振る舞いも同様になるように作られていなければならない。デジタルなボタンを押すのではなく回すように作ったり、ハンドルを決して回らないように作ってしまっては、ユーザから文句が来るだろう。「直感的ではない」、と。

デジタルなモノをデジタルなモノに似せて作る

われわれの暮らしの中にデジタルなモノが入り込むようになれば、日々の暮らしの中でデジタルなモノの振る舞いにも慣れてくる。ファミコンでドラクエや FF の操作に慣れた子どもたちは、階層化されたメニューをたどることに対して特別な説明を必要としないだろう。

アナログな物であれ、デジタルなモノであれ、ユーザが十分に慣れ親しんでいるのであれば、それに似せることで「直感的に」操作可能なシステムを作ることができる。「○○のように見えるモノ」が「○○のように振る舞う」とき、ユーザは直感的だと感じるのだ。

つまるところ、「直感的」は、ユーザが熟知している既存のシステムを模倣することによって生み出される、ユーザの脳内に生まれる認識のショートカット(近道)なのだ。

「直感的で使いやすい」って本当？

上述の議論で「直感的」については少しわかった。では「使いやすい」はどうだろう？ユーザはどんなときに「使いやすい」と感じるのだろう？それは「わかりやすい」とか「覚えやすい」と似ているのだろうか？それとも全然、別のことか？

「使いやすい」という特性は、より根源的な他の特性に分解できるのだろうか？もっと言えば、あなたの「使いやすい」は、わたしの「使いやすい」と同じなのだろうか？もし同じなら、わたしにとって「使いやすい」システムを作れば、あなたや彼や彼女にとっても「使いやすい」ものになるはず。一方、もし異なるなら、どうすればあなたの「使いやすい」を知ることができるのだろう？

2010-09-04

隠れたウィンドウは見えない、見えないウィンドウは存在しないも同然 #2

前回に引き続き、ウィンドウにおけるアプリケーションウィンドウの配置問題について。今回は、ユーザが行う工夫について考える。

前回の最後に書いたように、ウィンドウを重ならないようにするためにユーザが取り得る工夫は、おおよそ次の 3 つになる。

より大きな画面を手に入れる。
アプリ内で余分な情報は表示しないようにする。
ウィンドウを重ならないように並べる。

より大きな画面を手に入れる

たとえば、新しく iMac の購入を検討しているとする。現行の iMac (Mid 2010) には 21.5 インチと 27 インチの 2 つのモデルがある。予算が許すなら 27 インチの方を手に入れる。画素数でくらべて約 1.8 倍になる。あるいは、置き場所に余裕があるなら、iMac は小さいモデルを選択し、その代わり差額(約 5 万円)で 2 台目のディスプレイを購入するという手もある。

すでにパソコンがある場合はどうするか？ 2 台目のディスプレイをつなげることを検討しよう。すべての機種、モデルでそれができるわけではないが、もし可能なら(そして予算と置き場所が許せば)やってみるべきだ。画面の広さが 2 倍(以上)になる。

古くても良いから単体のディスプレイは捨てずに取っておき、新しいパソコン (iMac など) につなげてみると良い。CRT の頃、ディスプレイはとにかく場所を取ったものだが、液晶ディスプレイが普及してからは、机の上に 2 台のディスプレイを並べることも手軽にできるようになった。

物理的に画面を大きくできない場合は「仮想デスクトップ」を利用するという方法もある。Mac なら標準で利用できる機能だ。ただし、「仮想デスクトップ」は一度に見える領域が増えるわけではない。この機能は、むしろユーザが作業コンテキストを明確にするためにあるものだ。

作業コンテキストとは関連のある複数の作業から構成される作業場(ワークスペース)のようなもの。たとえば、twitter クライアントでタイムラインを眺めている時、誰かのツィートにある URL を開きたくなる。そのときブラウザはすぐそばにあるべきだろう。ブラウザでウェブを見ているときにツィートしたくなったなら、twitter クライアントがブラウザの横にあるとウレシイ。この 2 つがそばにあることで「情報探索とコミュニケーション」のための作業場が生まれる。

わたしはブログの記事を Emacs で書いている。自分が書いた記事もふくめて、あちこちのウェブページを参照することになるから、Emacs のすぐ右横には Safari が開いている。左横にはターミナルのウィンドウが 2 つ。記事のネタになるプログラムを走らせたり、man を参照したり(ウェブで見るより手軽)と、これも良く使う。Mail.app にはメモが置いてあるから、これも近くに開いておく。これらがわたしにとっての「ブログを書く」という作業場を構成している。

人は作業に集中すると、他のことが気にならなくなる。そして気にならない情報は見えていなくても良いのだ。むしろ、見えていると気が散って作業の邪魔になる。だから、複数のデスクトップを切り替えられる「仮想デスクトップ」は作業コンテキストの構築に適している。

2010-09-03

隠れたウィンドウは見えない、見えないウィンドウは存在しないも同然

今回のお題は、ウィンドウシステムにおけるアプリケーションウィンドウの配置問題。

なぜ、ウィンドウは重なるのか？

画面は資源、そして資源はいつも不足している

Mac を使っているのであれ、あるいは PC を使っているのであれ、(それが余程古いものでない限り)今のパソコンを使っているユーザの前では、その画面にいくつものウィンドウが開いていることだろう。ブラウザや iTunes を始めとして、twitter クライアントにメールクライアント、などなど。プログラマなら IDE あるいはエディタとターミナルなんかも加わるに違いない。

ここが肝心な点なんだが、それらいくつものウィンドウを広げるには、Mac や PC の画面はあまりにも小さい。それがノート型なら言うに及ばず、デスクトップ型で 20 インチ以上の画面を備えていたとしても十分とは言えない。

画面が小さい結果として、ウィンドウは互いに重なりあう。みな、それが必然だとわかっている。いくつものアプリを同時に立ち上げるためには避けられないのだ、と。誰もがこれを当たり前だと思っている。他に方法はないのだ、と。

まだ、画面は小さいのだろうか？

(一部の研究者を除いて)人々が初めてコンピュータの画面にウィンドウを見たのは 1984 年 1 月 24 日のことだ。それが備えていた 9 インチ、512 × 342 ピクセルの画面は 2010 年の感覚で見ると余りにも小さい。大きさで言えば iPad (9.7 インチ)に近く、画素数で言えば iPad (1024 x 768) の 1/4 以下だ。

あれから 26 年以上たってパソコンの画面も広大になった。いまどきのデスクトップ型なら 20 インチ以上、画素数も 1,920 × 1,080 (iMac 21' [Mid 2010]) 程度を備えるものはざらにある。最初の Macintosh の 4 倍の広さだ。さらに、2 台目のディスプレイをつなげることのできるものもある。そうなれば、画面の広さは倍増する。3 台目をつなげられるものはさすがに限られるが。

単純に考えると、4 倍の広さの画面には元のサイズのウィンドウを 4 つ、重なりあうことなく並べられるはず。ブラウザ、メールクライアント、twitter クライアントに iTunes、これで 4 つ。普段、使うアプリはこの程度に収まらないだろうか？もし、収まるなら、ウィンドウは重ならなくても良いはずだ。なぜ、まだ重なっているのだろう？

ウィンドウもコンテンツもでかくなった

この 26 年で起きたのは、画面の大型化だけじゃない。画面に収まるアプリのウィンドウも、ウィンドウに収まるコンテンツも大型化した。

メニューと比較的小さなツールパレットであとはすべてキャンバス、というアプリウィンドウの原型はもはや原型として十分ではない。ツールバーが生まれ、描画エリアはペインという名の領域に分割され、ツールパレットも大型化するか、そうでなければ分割された。とてもじゃないが、9 インチ、512 × 342 ピクセルには収まり切らない。

26 年前にウェブは存在していなかったけど、誕生以来、すでに 20 年近くが過ぎた(Wikipedia:ja によれば最初のウェブサーバの誕生は 1990 年末)。登場当時は幅 640 ピクセルに収まっていたウェブページも年々横長になり、今では 1000 ピクセルを超えるページも珍しくない。ページという概念を捨ててしまったために、縦に長くなる傾向はもっと大きい。

見えないのと見えるの、どっちが良い？

重なりあったウィンドウと重なることなく並んだウィンドウ、どちらが使いやすいかは考えるまでもない。隠れたウィンドウは見えない。見えないウィンドウに映し出された情報はユーザにとって利用できない情報だ。利用したければ隠れたウィンドウを表に出すしかない。しかし、そうすると別のウィンドウが隠れてしまい、別の情報が使えなくなってしまう。

2010-08-24

twitter より (2010-08-23)

17:13 Monaco がお気に入りなのは言うまでもない。それ以前は Andale Mono だったか。昨日、Droid Sans Mono を Google Font Directory で見つけた。記事にあるようにゼロだけが弱点だな。 → http://bit.ly/dTD5L
17:36 いま、ふと気付いたんだけど、TrackPad を操作する指は、1. 中指、2. 薬指、3. 人差し指、になってる。小指と親指は使わない。順番は指を増やすときの優先順位。つまり、1本のときは1、2本のときは1+2、3本のときは1+2+3、ってこと。
17:37 あ、親指はクリックで使っていたわ。
17:40 クリックについても意識して使ってみると、シングルは親指。ダブルは中指+薬指だった。あと、4本指のスワイプ(デフォルトでは Expose) のときは流石に小指を使ってた。
17:45 あと、2本指でのピンチのオープンとクローズは、中指+親指だった。指を開くジェスチャは親指との組み合わせでないと、やりにくいからな。
17:53 中指を多用するようになったのは、単に一番長い指だからっていう気がしてきた。というのも、TrackPadの特性上(複数指のタップを検出する)、1 本指での操作中、他の指は浮かせておかなきゃならない。短い指を使うと、他の長い指がジャマになる。必然的に一番浮かせにくい指が選ばれた、と。
17:59 iPhone は片手で持って(その手の親指で)操作することが多いから気付かなかったけど、iPad になるとやはり中指が大活躍する。ただし、iPad の場合は左手で本体を持って、右手(の指)で操作するから、左手で操作するTrackPadとは(同じ中指でも)違う指なんだよな。

2010-08-10

フローなメモならスティッキーズ

メモにはフローとストックの 2 種類がある。

たとえば、新しい iMac の製品発表を見て、あれこれ悩んだ末に買う決心をして、いざ Apple Store でポチろうとしたら出かける時間になり、忘れては困るので手元のポストイット®に「新しい iMac を買うこと。」と書き込んでディスプレイの端に貼りつけたとする。このメモはフローだ。iMac を買ってしまえばメモは不要になる。

ストックがどんなメモなのかについては別の機会に考えるとして、ここではフロータイプのメモを扱うツールに話をしぼる。

アナログの道具を使ってこのタイプのメモを書くならポスト・イット®に勝るものはない。貼りつけられるから風で飛んでしまうことはないし、どこかに紛れ込むこともない。目立つところに貼りつければ忘れるはずもない(たぶん)。そして用が済めば、はがして丸めて捨ててしまえば良い。

この便利な発明をそのままデジタルの世界に写し取ったかのようなツールがある。Mac OS X の標準アプリの一つ、「スティッキーズ.app」だ。

2010-08-06

twitter より (2010-08-05)

01:05 ふうん。タブって取り外せるのか > Safari タブをウィンドウの外(デスクトップ)にドラッグすると別ウィンドウになる。Safari のウィンドウ間でタブを移動することもできる。
01:07 ただ、Safari の場合、ウィンドウにタブが 1 つしかないとき(タブは表示されない)はタブを操作できない。Firefox なら常にタブを表示するっていうオプションがあるんだけどな。
01:14 Firefox でも、ウィンドウにタブが 1 つしかないときは移動はできないようだ。空のウィンドウって見たことないから仕方ないか。メニューに「ウィンドウをまとめる」項目があれば良いんだよな。
01:19 なんでこんなことを試したかって言うと、「オーバーラップタイプのウィンドウシステムって、画面の狭さという制約に起因する苦肉の策なんじゃないか？」と考え始めたから。
01:23 タブを切り替えて情報を探すのってイライラする。「あれが書かれてたのはどのサイトだっけ。で、それはどのタブで開いたんだっけ…」画面に余裕があるなら、タブなんかにして後ろに隠すことはないんだよ。全部ウィンドウにしてお互いを隠さないように並べれば良い(タイルタイプだな)。
01:28 いま、ごく当たり前になっていてそうであることに誰も何の疑問も抱かないようなデザイン(意匠も設計も)が、実は過去にあった種々の制約に起因する、ということがある。キーボードの QWERTY 配列なんかが代表例。他にもきっとあるはず。マルチウィンドウの方式もそうなんじゃないか？
01:35 オモシレ〜。 RT @mawakao: RT @kiri_tori: (管理人より) 「切り取り線lite」@k0_0t を公開しました。[...snip...]使い方→ http://bit.ly/aLVHXO
11:27 なんとぜいたくな数独ボード。→ http://jp.makezine.com/blog/2010/08/nixie-tube_sudoku_board.html

2010-08-03

iMac、届いた！

発注したのが 7/27で、出荷の知らせが来たのが 7/30。そして昨日(8/2)、はるばる上海から海を越えて届いた。

箱は思ったほどデカくはなかった。ほぼ iMac のサイズそのまま。これは付属品が少ないからだろう。

梱包を解き、保護のためのシートなんかを外す。(先週末に汗だくになって片付けた)作業机の上に置く。セカンドディスプレイにする予定のシネマと並べると、少し iMac の方が背が低い(その差、約2.5cm)。そこで、古い雑誌を敷いて上辺の高さを揃えてみた。それが→の状態。

キーボードは mini で使っていた Realforce 86U を使う。マウスは使わず、Magic Trackpad のみでいくつもりなんだけど、初期設定のあいだはこれまでどおり Apple Pro Mouse を使う。

初期設定および作業環境の移行もほぼ終わった。今は iTunes で音楽を鳴らしながら Emacs でこれを書いている。

新しいマシンだと言っても、同じ Mac だし、OS も MacBook と mini で使っている Snow Leopard だし、初期設定もウィザードで Apple ID と MobileMe のアカウントを指定すれば終わってしまうし、環境の移行にしたって iOS SDK を始めとするソフトをいくつかインストールするのと mini や MacBook からファイルをコピーするだけ。とくにハマるような点はない。まあ、すべてスムーズにいったわけではないんだけどね。そのことは別に書くつもり。

Time Machine のつなぎ先では少し悩んだ。Time Capsule と mini Server とどちらを Time Machine のバックアップ先にするか。決め手になる条件がなかったから。結局、mini の方にしたが、明確な理由は思いつかなかった。あえて挙げるとすれば、Capsule は相当熱くなるってことぐらい。それがどうしたと言われたら困るけど。

あ、そうそう、SSD+HDD の構成にした効果か、アプリの起動は確かに速い。だからどうしたって感じなんだけど、こういうのって地味に効いてくるんだと思う。こっちに慣れた後、MacBook や mini にもどったときに愕然とするんだろう。「え、なんでアイコンがドックの中ではねてるんだ(・д・)？」というように。

それと、Magic Trackpad はとにかく気持ち良い。MacBook に付いているのと同じだろう、と思うかもしれないが、タッチする面積が少し大きいことでユーザ体験が向上している。本当にマウスはもういらないと思える。iPhone/iPad でタッチ&タップに慣れているせいもある。けど、それだけじゃない。やっぱりこれは、もっと早く実現されているべきだったはずのもの、って感じがする。iPad と MacBook (というかノート型のパソコン全般)を見比べたときに感じるあの感覚。過去にあるべきだった未来だ。

このトラックパッド、PC の世界でもすぐに類似品が出回るんじゃないか。デザイン(意匠)がシンプルなだけに差別化は難しいだろうけど。

2010-07-29

twitter より (2010-07-28)

15:20 Google の画像検索の結果表示が変わった。改悪だとの見方もあるみたいだけど……普通に良いゾ。端末のメモリと回線幅には優しくないだろうけど。ちなみにリンク先は imac で検索させたもの。なかなか壮観。→ http://bit.ly/drnjMw

2010-07-28

iPad で Apple 提供の開発者向けドキュメントを読む

追記@2010-12-18

ここに書いたよりもっと良い方法が提供された。以下の記事を参照のこと。

iBook で Apple 提供の開発者向けドキュメントが読める

今のところ、提供されているのは(膨大な ADC ドキュメントのうち)ごく一部だけど。

まずは PDF で読んでみる

iPadに雑誌のPDFなんかを詰め込んでいたときに、Apple が提供する開発者向けのドキュメント(以前は、ADCドキュメントって呼んでいたんだけど、今はどう呼ぶべきだろう？)も、iPad に詰められたら良いのに、と思った。実際のところ、PDF版が用意されているから、それを iBooks や GoodReader に詰めることはできる。ただ、この PDF 版は印刷向けに作られているから、iPad で読むには文字が小さい(→)。文字がつぶれているわけではないから読めなくはないが、長時間このサイズの文字を見続けるのはつらい。

印刷用のためか、ADC の PDF は余白が大きく取られている(昔からの Apple ドキュメントの特徴だ)。これを除いて内容部分を拡大すれば文字は幾分大きくなる。ページをめくる度、いちいち拡大するのは面倒だが、GoodReader にはまさにそのための機能がある(version 2.8 になって追加された)。それが Crop Margines 。PDF の余白をトリミングし、その分内容を拡大表示してくれる。→ がその表示例。↑と同じドキュメント(の同じページ)を crop させたもの。かなり読みやすくなる。

(GoodReader for iPad の Help より)
If your file has large unnecessary page margins, you can get rid of them by cropping them out with this button. Set crop margins any way you like them. You can even define different crops for odd and even pages. Crop settings are memorized on per file basis.

実際、これはかなり優れものの機能だ。PDF ファイルのほとんどが印刷用にレイアウトされていることを思えば、むしろ必須と言えるかも。

もっと良い方法

実は PDF にこだわらなければ、そしてオンライン前提で良ければ、もっと良い方法がある。それは、iPad の Safari で Apple の Develper サイトのドキュメント(HTML版)を開くというもの。

いつからかわからないが、ここのドキュメントは iPad の Safari 対応になっている。Mac 等で開いたときに表示されるナビゲーションのための目次は、iPad のアプリを思わせるメニューになっていて、画面にはドキュメントの内容が一杯に表示される。文字サイズも iPad で読むのに適したサイズになっている。

どんな方法であれ一長一短があるのが世の習い。この方法も、ページをめくる代わりに縦スクロールと「Next」リンクを使わなければならない点がユーザ体験としては減点。また、Wi-Fi でしか使ったことがないから想像するしかないが、3G 回線では「Next」と「Previous」によるページ遷移で待たされるかもしれない。

HTMLでも十分にアプリが作れる

正直、HTML (+ CSS + JavaScript だろうな)でここまでできる(ポップオーバーなメニューとか)とは思ってもみなかった。もうほとんど電子ブックアプリと変わらないユーザ体験を実現している。iPad 専用が前提なら、コンテンツのサイズを調整して縦スクロールをなくすこともできるだろうし、ローカルにコンテンツを持つのであればオフラインでも使える。Apple はもっとこういうこと(Safari と HTML でここまでできる)をアピールすべきだろう。

ちなみに、2010年7月28日時点で、上記のドキュメントは iPhone 対応にはなっていない。少なくとも 3GS では Mac で開いたときと同じように表示される。ちょっと残念。

このブログも iPad 対応にしないとな。ま、そのうち、そのうち。

2010-07-27

iMac、買った

Apple Store がメンテに入ったことを知ったのが 21:20 頃。iMac を始めとする新製品が並んだことを知ったのが 21:45 頃。iMac が新しくなれば(よほど突飛な更新でない限り)買うつもりだった。すぐに Safari で Store を開き迷わず「クアッドコア」を選択。CPU、メモリ、キーボードあたりはすぐに決まった。迷ったのは SSD。

今回から、HDD (1TB or 2TB) に加えて SSD (256GB) が選択肢に加わり、さらに HDD + SSD の組み合せも選べるようになった。ただやはり SSD は高い。HDD(1TB) + SSD(256GB) の構成を選ぶと73,080円の↑。30分以上迷ったが、これまで SSD は使ったことがないってことで、HDD + SSD の構成を選んだ。

うちの Mac たちは使わないときはスリープ状態にしているから、OS の(再)起動はごくまれなことだ。また、アプリも(メモリが不足しない限り)立ち上げたままなので、アプリの起動に時間がかかることも気にならない。SSD に期待しているのは、むしろコンパイル時間の短縮だ。こればっかりは多数のファイルをごりごりと読み書きすることになるから、ディスクアクセスの高速化が効いてくるはず。ま、このあたりは実際に使って体感してみなければわからない。

さらに、今回の新製品のひとつでもある Magic Trackpad も付けた。実はこれこそ、今回の製品群の目玉だと考えている。初代の Mac が登場してから 26 年以上が過ぎたが、その間ずっとポインティングデバイスとしてはマウスが主流だった。デスクトップ型のパソコンに限って言えば、一部の特殊な用途を除いて、唯一マウスのみがユーザの意思をコンピュータに伝えるための道具だったと言って良い。ボタンの数や、機構(機械式から光学式へ)こそ変化したものの、ユーザ体験はほとんど変わらないままだった。

実際、MacBook を使っていると、2本指でウィンドウの内容をスクロールさせられるのは実に気持ち良い。新たなジェスチャを覚える必要があるものの、始めの数分か数時間が過ぎれば、ごく自然に指が動く。うちの MacBook は黒いやつなので他のジェスチャを OSX 上で試したことがないけれど、iPhone や iPad を使っていればスワイプや回転、ピンチにもすぐに慣れることは実感している。慣れるどころか、それがない(使えない)ことが不自然に思えるようになる。

新しい iMac が届くこと自体も楽しみだけど、それ以上に Magic Trackpad にはわくわくしている。iMac のオプションとしては Magic Trackpad 単独で選ぶことはできず、Magic Maouse との組み合せになってしまう。マウスを置き換える機器としてもっと前面に出しても良いと思うんだけど。

出荷予定日は 2〜4 営業日となっている。早ければこの週末に届く。

2010-12-17

2010-11-29

関連記事

2010-11-24

2010-11-03

2010-10-27

パンくずリスト

文字入力させたら負けだと思う

関連リンク

関連記事

2010-10-25

viewport の設定

デバイスごとの CSS ファイルの用意

もっと iPhone らしく

参考文献

関連リンク

関連記事

2010-10-24

2 つの方式の比較

リファクタリング

シンプルなページ切り替え

「Goooooooooogle!」方式と「前後」方式

関連リンク

関連記事

2010-10-22

2010-10-10

2010-09-13

2010-09-11

訓練しなければ使えません

論理ではなく感覚による把握

デジタルなモノをアナログな物に似せて作る

デジタルなモノをデジタルなモノに似せて作る

「直感的で使いやすい」って本当？

関連リンク

関連記事

2010-09-04

より大きな画面を手に入れる

2010-09-03

なぜ、ウィンドウは重なるのか？

画面は資源、そして資源はいつも不足している

まだ、画面は小さいのだろうか？

ウィンドウもコンテンツもでかくなった

見えないのと見えるの、どっちが良い？

2010-08-24

2010-08-10

2010-08-06

2010-08-03

関連リンク

関連記事

2010-07-29

2010-07-28

追記@2010-12-18

まずは PDF で読んでみる

もっと良い方法

HTMLでも十分にアプリが作れる

関連リンク

関連記事

2010-07-27

関連リンク

関連記事