2014年01月の日記です

目次

03日 あけましておめでとうございます
15日 zepto で clone
22日 ボタンの左右位置
26日 iOS の position:fixed バグ回避方法


あけましておめでとうございます  2014-01-03 14:41:50  その他

▲目次へ ⇒この記事のURL

あけましておめでとうございます。


忙しくて最近日記書いてませんが、ここらでクリスマスあたりからの出来事をまとめておきましょう。


今年のクリスマスディナー。

ローストビーフ、オニオンスープ、ポテトサラダ、フランスパン。


ローストビーフを頑張って焼いたけど、次女と長女には不評。牛肉は薄く切っても少し硬かったか。

長男には大好評。


ビーフの付け添えに野菜などを一緒に焼いた。焼きりんご大好評。

このりんごの汁も含め、出た汁と醤油やレモン汁、マスタードなどを混ぜてソースを作る。



スープはみんなに好評。ポテトサラダは次女に大好評(もともと好き)。


大人はロゼのシャンパン、子供はロゼのシャンメリー。

もっとも、炭酸は長男しか飲めないので、長女と次女はリンゴジュース。



ビーフは1Kg 焼いたので、数日間残っていて、細切れにしてスクランブルエッグに入れたり、野菜炒めに入れたり、少しづつ消費しました。




今年のサンタさんからのプレゼント。


次女(4歳):NEWくみくみスロープ


長女(6歳):ヒューゴ オバケと鬼ごっこ


長男(9歳):Lego Crazy Action Contraptions



子供たちは最近ピクミンが好きで、ピクミン3欲しがっていたのだけどね。

Wii U 持ってないから全部買うと、子供向けのプレゼントの値段を超えてしまう。


まぁ、サンタさんが選んでくれたものだから、希望と違ってもきっといいものに違いないよ…



プレゼントの届いたクリスマスの日からは冬休み。

保育園は冬休み中も申し込めば保育してくれるのだけど、痛恨の申請忘れ。まぁ、長男は小学校が冬休みで家にいるし、みんな一緒に遊んでくれるので良いのだけど。


で、最初に人気だったのは次女の「くみくみスロープ」。

3歳からのおもちゃだけど、大人が見てもなかなか面白いもので、長男も一緒になって楽しんでいる。


長男のレゴブロックは、なかなか高度なもので長女・次女には難しい。

でも、最近家のレゴで造形を作ることが多い長男、早速組立図を見ながら「ゴム動力で動く自動車」を作ってみる。

なかなかよく動く。廊下を一直線に結構な速度で走る。

この段階では、長女・次女も大喜び。


ボードゲームだから一人では遊べない長女の「ヒューゴ」。

やってみようよ、とあけてルールを説明しても、「オバケが出てくるのこわい」と次女・長女は遊びたがらない。

でも、一度試しにやってみたら面白い。基本的にはすごろくで、運の大きいゲームだから次女でも勝てる。

運のみゲームではなく、考える部分もあるため、大人でも楽しめる。


知恵を使って運を制御しようとするが、最後はやっぱり運任せな部分もある、絶妙なゲームバランス。

1989年の原作発売以来、世界中で愛されているボードゲームだけのことはある。




今年のおせち。


煮豚(チャーシュー)、煮卵、鳥ハム、栗きんとん、いくらのしょうゆ漬け、伊達巻、数の子、松前漬け。

以上は僕。


煮〆を妻が作ってくれた。


煮豚はすでにネットに入ったものを買ってきて似ただけ。その煮汁に茹卵を漬けたのが煮卵。

鳥ハムは毎年恒例だが今年はおいしくできた。


栗きんとんは、秋に大量に栗を買ったら子供が食べなかったので、シロップ漬けにして冷凍しておいたものを使った。

芋も安かったので箱で買ってきたら、たくさん作りすぎた。裏ごしは子供が手伝った。


いくらは毎年恒例、秋に筋子から作ったもの。

伊達巻も毎年恒例だが、今年はおいしくできた。


数の子は塩漬けを買ってきて塩抜きし、味付けした。

松前漬けは簡単に作れる、千切りにしたセット品。


毎年仕上がりが年が明けてからになるので、今年は早めに…と作りはじめたつもりだったが、結局完成は年が明けてから。

子供たちが大きくなってきて手伝ってくれたのと、自分たちだけで部屋の片づけ(大掃除)をさせたため、大幅に時間がかかったため。


親がやっちゃった方が速い、ってことだけど、お手伝いはいい経験なのでやらせたい。




元日に、初日の出を見てみよう、と近所の公園へ。

水星を見るために日の出を観察したりすることもある妻が、そこなら見えそうだといったため。


でも、冬は日の登る位置がずいぶん南側にずれる。

周囲が明るくなっても山に隠れて日が見えない、とわかる。


じゃぁ、明るそうなところを探そう、と早朝から家族で近所探検。

近所の坂がピンポイントで、谷間から出てきた初日の出を、2軒の家の隙間から見えることが判明。


日の出時刻は7時半くらいかな。水平線から登るのが6時50分くらいだから、近所で見ようとするとずいぶん遅い。



大掃除、おせちと忙しくしたためか、正月になって気を抜いたら熱が出る。

午前中寝込んでしまい、午後から近所の神社に初もうで。


今年の正月は空気が暖かい。




昨日2日は、親戚一同集まった。

とはいえ、妹は今年も参加できず(毎年正月は旦那さんの実家に行くため)、次兄は風邪を惹いて出席できず。


長女は「ヒューゴ」をみんなで遊びたい! と持っていった。

次女もくみくみスロープを持っていく。親戚が沢山集まる場所で広げるようなものではないのだが、言い出したら聞かない性格なので持っていく。


母(子供から見れば祖母)、長男夫妻とその子供2名、次姉夫妻と次女(長女はバイトで来られず)、そしてうちの家族5名だけが参加者。

今年は少し寂しかったが、子供がこれだけ集まればうちの子供たちも非常に楽しい。


ヒューゴは大好評で、遊んだ人皆が面白いと言っていた。

次姉の次女は、昔友達の家で遊んだことがあるらしい。結構歴史あるゲームだからな。


でも、日本でもたびたび絶版になっては再版され、今の版は日本オリジナルの「上級ルール」もある。

こちらも非常に盛り上がる。

(逆転の連続が起きやすいように工夫されている。最後まで展開が読めない)




僕と妻も、少し仕事を休んでのんびり。

子供と一緒にピクミン(GC 版の1)なんてやっております。


いきなり9日・85人クリアを目指しているのだけど、昔書いた攻略ノートは、9日・100人クリアようのものだった。85人は記してなかったかな…

事実上、再攻略している、ということです。


これもまた、親子で楽しんでいて楽しい。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

その他

別年同日の日記

03年 年賀回り

08年 あけましておめでとうございます

16年 三が日

18年 親戚廻り


申し訳ありませんが、現在意見投稿をできない状態にしています

zepto で clone  2014-01-15 10:18:48  コンピュータ

▲目次へ ⇒この記事のURL

最近忙しくて日記書いてません。


昨年末に、ちょっと新しい仕事を頼まれました。

個人で仕事をしていると、新しく頼んでいただけると言うことは非常にありがたいです。


詳細は秘密保持契約があるので書けませんが、スマホ向けのソーシャルゲームのクライアント側の作りこみの手伝いです。

要は、Javascript でいろいろ動かせばよい、ということ。




zepto というライブラリがありまして、jQuery のスマホ専用版です。


jQuery は便利なのですが、各種ブラウザの差異解消とか、ちょっと便利なセレクタとか、ちょっと便利な関数とかが多くて非常に巨大になりつつあります。

過去には jQuery のプラグイン構造を利用して、各種機能を全部プラグインに別ける…なんて話も出ていましたが、互換性の面から結局全部入りになっている様子。

(内部的には分離されていて、使う人が不要な機能を削ったりは出来るようですが)



で、zepto は jQuery セミ互換で書きなおされたもので、iPhone と Android の標準ブラウザ…つまりは、webkit だけ動けばよい、という考えになっています。非常に小さいです。


と言っても、zepto も開発が進み、徐々に大きくなりつつあります。

とはいっても jQuery よりはるかに小さいのですが、少しでも小さいのが好きな人は、最初のバージョンの zepto を使っています。




先に書いた仕事、スマホ用なので jQuery は使わず最初のバージョンの zepto で、となっていたのですが、納期をすでに過ぎているために細かなことを言っていられなくなり、必要なら jQuery でもなんでも使って良いことになっています。


僕は基本的に zepto で…とやっていたのですが、ほかの人が jQuery を読み込んでいたソースをいじっていたときに、ついうっかり clone を使ってしまいました。

clone 、非常に便利な機能ですが、zepto にはありません。というか無いことを知らずに使ってしまいました。


僕の作った部分を別のファイルでも使うことになり、コピーしたら…うごかない。

clone のためだけに非常に巨大な jQuery を呼び出すのは気が引ける。



というか、最近の zepto には clone あるんですけどね。

当初の zepto にはない。WEB の掲示板でも情報を探すと「欲しければ最近の zepto 使え」というだけで、あまり良い答えがない。


というわけで、作りました。



$.fn.clone = function(){ var ar = []; for(var i=0;i<this.length;i++){ ar[i] = this[i].cloneNode(true); } return $(ar); }


前ふり長かったけど、これが書きたかっただけだよ…

zepto 読み込んでから、clone を使うまでの間にこれを定義すれば、clone が使えるようになります。


あくまで簡易 clone です。zepto の最近のバージョンでも簡易版しかない。

jQuery の clone はオプションでいろいろあるけど、それはナシです。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

iOS の position:fixed バグ回避方法【日記 14/01/26】

別年同日の日記

04年 ぎょうざ

10年 ポケモンスクランブル

13年 マインスイーパー

17年 あの頃のインターネット


申し訳ありませんが、現在意見投稿をできない状態にしています

ボタンの左右位置  2014-01-22 11:02:57  コンピュータ

▲目次へ ⇒この記事のURL

現在お手伝いさせてもらっている仕事で話題になったので、メモ書き程度に。


そのお仕事では、スマホ向けのアプリを作っている。iOS / Android 共用。

なぜか、「OK/ Cancel 位置の入れ替え」という指示があった。


それまでは、OK/Yes/進む などが右に、Cancel/No/やめる などが左にあった。

これを逆にしたいのだという。


なんでそんな指示が出たのかは知らない。

お仕事を手伝っている立場なので、上が決定したのであれば従って作業をする。


でも、その指示がどんなにおかしいものであるかは、ひとこと口を挟んでおいた。




Windows を使っていると、OK は左に、Cancel は右にくる。

恐らくは、指示はこれを踏まえてのことだ。普及している Windows にあわせよう、となったのだろう。


でも、作っているアプリはスマホ向けだ。

iOS では OK は右に来ることになっている。


ややこしいのは Android で、2.x までは OK は左に、だった。

でも、4.0 以降は OK は右に、と推奨されている。このため、アプリの作られた時期により OK ボタンの位置が変わり、使いにくいことこの上ない。


ともかく、スマホでは今後は OK は右だ。

今から OK を左にしたい、と言っている意味がわからない。

(ちなみに、今は締切1週間前だ。こんなことに時間を割いている余裕はないはず。

 もっとも、締め切りはもう何度も延長されているため、だれも1週間後が本当の締切だとは思っていない様子)





iOS で OK を右にする理由は簡単で、MacOS がそうだからだ。

じゃぁ、MacOS はなぜ OK が右なのか、といえば、初代 Mac (白黒のやつだ)が作られた際に、熟考の末そう決められたからだ。


Mac の元になった Lisa には、従うべきガイドラインは無かった。

Lisa のアイディアの元となった Smalltalk でも、特にガイドラインは無い。

(そもそも、Smalltalk はそれほど GUI ではない)


このため、操作が混乱することがあり、使いやすさを求めた Mac では、多数のモニタリングテストの末に、使いやすいガイドラインがまとめられたのだ。

(メモリ容量が小さく、同じ部品を使いまわさねばならなかったという事情もある)



文章は左から右に読む。(ここでは、アラビア語圏などのことは考えられていない)

これを前提にすれば、ボタンを2つ並べた時、左側のボタンが先に目に入ることになる。


先に目にしたボタンを押したくなったとしよう。

この時、2つボタンがあるにもかかわらず、最初に目についたボタンを押したのだとすれば、内容をよく理解していない。


そんな状態で先に進んでしまい、戻れない状態になってはいけない。

左側にあるのは、やり直しが利くボタンであるべきだ。


つまり、左はキャンセルにするのが良い。



ボタンは通常一番下に置かれる。

その中でも、一番右に置かれるものは、一番最後に目に入ることになる。


つまり、右側は「次の動作に移る一番最後のもの」だ。

ここに、次の動作を開始するためのものが来るのは、非常に自然なことだ。


そのため、OK ボタンは右側に置かれるのが自然だ、と言うことになる。


主にこれらの理由で、Apple は Mac の作成時に Cancel を左に、OK を右に置くことにした。


このガイドラインは非常に優れた論文でもあり、多くのことを考慮に入れて作り上げられた、素晴らしいものだった。

Apple もその後、このガイドラインを超えるような設計指針は示せていないし、後の GUI デザインの規範となった。




じゃぁなんで Windows は逆なのさ、と言う話。


Mac に対抗して逆にしたんじゃないか、という推測や、訴訟になった際に「似せていない」と主張するためだったという説、単にプログラマが何もわからずに間違えたんじゃないかという説もある。


でも、これは案外根が深い。


DOS 時代をご存知な人は、DOS でもテキストグラフィックでボタンを模倣することがあったのを覚えているだろうか?

なにも、ボタンデザインは GUI だけの特権ではない。テキストだってボタンを表示することくらいできる。


模倣だけでなく、テキスト画面でマウスが使える環境だってあったのだ。

マウスを動かすと、カーソルが文字単位で動く。慣れれば案外使いやすいものだ。



もっとも、これらは Mac 発表以降に作られたものだ。

Mac は 1985 年発表。マイクロソフトは、ワープロや表計算など、よく使われるソフトをまとめた「MS-Works」を発売。


その後、MS-Works は MS-DOS 用に移植されるが、この時に MS-DOS でも GUI を模倣している。

注目すべきはボタンの位置で、OK が左に来る。


なぜか? この時点では Mac のソフトを移植しただけで、Mac を模倣した OS を作ったわけではない。

対抗して逆にする理由もないし、もちろん裁判対策などではない。


プログラマが何も考えていなかったのであれば、Mac をそのまま真似して OK が右に来ただろう。



当時のこの手のソフトを使っていた人なら、もったいぶらずとも答えはもうわかっていると思う。


当時はマウスがないのが当たり前。

ボタンを押すのだって、キーボードでボタンを「選んで」リターンキーで「押した」のだ。



部品の移動は TAB で行われる。

多数ある部品を TAB で順次選び、「一番最後付近の」 OK ボタンまで進む…だけで一苦労だ。

ここで、ついうっかりよく読まずにボタンを押してしまう、と言う危険性は、まずないと考えてよい。


うっかりミスを防ぐ、という名目で Cancel が左側にある理由などないのだ。


もっとも、わざわざ TAB キーを押して部品間を移動しないでも、大抵はキーボードで動作を選択できた。

Cancel は、ESC キーに割り振られているのが普通だった。

間違えた画面に進んだな、とおもったら、いつでも ESC キーを押せばよい。キーの名前の通り脱出(エスケープ)してくれる。


問題は OK / 保存 / 次へ…などのキーだ。

大抵は、キーの機能の頭文字のキーを押せばよいようになっている。 OK の O 、Save の S 、Next の N など。

そこで、どのキーを押せばよいのかを、素早く探せる必要があった。


…つまり、目につきやすい左側にあるのが操作しやすい。



以上の理由により、MS-Works では左に OK を、右に Cancel ボタンを配置してあるのが使いやすいことになる。



実は、この操作系は Windows 1.0 でも踏襲される。

当時はまだマウスは普及しておらず、Windows はキーボードのみでも操作できるように作られていたのだ。


いや、今だってそうだ。

基本的に、Windows はいまでもキーボードのみで操作できる。

そして、キーボードで操作する前提においては、左側に OK が来ている方が使いやすい。


今ではマウスで操作するほうが多数派だろうし、そう考えると Apple のガイドラインに従う方が理に適っているように思える。

とはいえ、DOS 時代から続く伝統はすでに変えられないだろうし、キーボードでも操作することを考えるとこちらのほうが適切なのだろう。




初代 Mac 発売に当たり、Jobs はキーボードを別売りにしたがった、と言うエピソードがある。

Mac はマウスだけで操作できるようにまとめ上げた環境で、キーボードなどいらない、というのだ。


結局これは見送られたが、Mac がマウスだけで操作できたのは事実だし(文字を入力したいときは、ソフトウェアキーボードがあった)、キーボードで操作させてくれない部分もあって、面倒でもある。


Windows は、DOS から乗り換えることを想定していたため、マウスなどなくても操作できなくてはならなかった。

そのため、キーボードだけでも操作しやすいようにチューンされている。

マウス操作を前提とすると疑問に思うような(今回の話のような)ことも、キーボードで操作しやすいように作ってある、ということがある。



この違いをもっと端的に言うならば、Mac は当初何も持っていなかったが、Windows は DOS 資産の引き継ぎが義務だった。

Mac では理想を追い求めて設計できたが、Windows はそういうわけにはいかなかったのだ。


Windows がおかしい、と責め立てるのは、そもそもの出自を理解していないのだ。



マウス操作なら OK は右にあったほうが良いだろうし、キーボード操作なら OK は左にあったほうがよい。

それが、当時のユーザーが望んだスタイルだったことになる。

どちらも、ユーザーの要望に応えようと頑張った結果、正反対の結論が導かれている。


Mac に対抗したとか、訴訟対策だったとか、そんなちっぽけな理由で逆になっているのではないのだ。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

バーベキュー【日記 17/07/02】

WEBページの検索順位をあげる方法(2/2)【日記 18/10/06】

Programming Tips

別年同日の日記

03年 FCE Ultra for C700

04年 2冊のファミコン本

07年 ドーラと大冒険!

13年 Tweetの取得

16年 デビッド・ローゼン 誕生日(1930)

19年 SEGA TETRIS


申し訳ありませんが、現在意見投稿をできない状態にしています

あきよし】 指摘ありがとうございます。書き間違えていました。記事は修正済みです。 (2014-12-17 10:38:29)

【まのん】 >そして、キーボードで操作する前提においては、右側に OK が来ている方が使いやすい →文脈から見て、これって「左」ではないですかね? (2014-12-07 20:37:53)

【nix】 AndroidのOKボタンが左右どっちにあるべきか調べてただけなんですが思わぬ勉強になりましたw 記事の事実と右利きの人が多い+OKのほうが押す機会が多い⇒指に近いほうがいいこともあるので右にOKを配置しようと思います。 (2014-09-16 14:32:07)

iOS の position:fixed バグ回避方法  2014-01-26 17:32:32  コンピュータ

▲目次へ ⇒この記事のURL

お手伝いしている仕事で、バッドノウハウばかりが溜まっていく気がする…


デザイン上の都合で、CSS で position:fixed が使われていた。


テキスト入力を促す箇所で、画面の真ん中に入力窓が出てくる。

まぁ、ネットではよく見るインターフェイスです。


ところが、これは iOS では「使ってはならない」技だった。

バグ報告があり、たまたまバグが出た個所が僕の担当箇所だったので僕が調べることに。


でも、プログラムのバグではなく、iOS のバグだと判明。




position:fixed では、ページをスクロールさせても、ウィンドウに対して常に同じ位置に要素を表示できる。


常に同じ、というとスクロールさせるのをサボるだけで難しくないように思われるが、話は逆だ。

画面に収まらない大きな板があって、その一部を表示しているのがスクロールだ。

通常の WEB ページは、この方法で作られている。


それを、「常に画面に対して同じ位置」に表示しようとすると、スクロールのたびに位置を計算し続けなくてはならなくなる。

これは結構大変な作業で、iOS では 5 から搭載された。それ以前は使えなかったのだ。


でも、7 になった現在でも、バグが残っている。



バグと言うのはこういうことだ。

先に書いた通り、「スクロールのたびに位置を計算する」のが、position:fixed による表示だ。


ところで、iOS にはソフトウェアキーボードと言うものがある。

キーボードを出すと、画面は上の方に寄せられ、狭くなる。

逆にキーボードを消すと、出ていたときに比べて広くなる。


でも、キーボードが出るのはスクロールではない。要素の位置は再計算されない。


まぁそれでも、キーボードが出て、消えるだけなら元に戻るだけなので心配はいらない。

問題は、キーボードを出している間にスクロールが行われ、その後キーボードが消える場合だ。


狭い画面でスクロールが行われ、その画面に対して要素の位置が計算される。

その後画面を広げても、要素の位置は再計算されず、結果的に本来指定したものとは違うものとなっている。



うん。何も問題はない。キーボードは「表示」されるだけで、スクロールが起きるわけではない。

画面が狭くなるのだからリサイズイベントは起こしてほしい気がするが、これも起きない。

こちらはバグっぽい気もするが、iOS ではリサイズ=画面の向き(縦・横)変更、というルールがあるので仕様と言うべきなのだろう。


でも、結果的に意図しない画面になっているのであれば、バグだと考える人もいる。

そして、今回がそのケースだった。




試行錯誤の末、次の方法で回避。


問題はキーボードが消えるときだ。

iOS でキーボードが出る条件は、文字入力が行われる時だ。


WEB 的には、INPUT TYPE=TEXT の要素にフォーカスした際にキーボードが出る。

そして、フォーカスが失われるとキーボードが消える。


フォーカスが失われることを、Javascript では blur と呼ぶ。

そこで、INPUT TYPE=TEXT の blur イベントを拾い、画面表示を更新してやれば良い。


画面表示の更新は、しつこく書いたようにスクロールによって起こる。

だから、スクロールしてやれば良いだけ。

この際、blur してからキーボードがアニメーションしながら消え、完全に消えるまでに 0.1 秒ほどかかることを考慮する必要がある。


スクロールすると言っても、blur のたびに画面が動いていくのは困るので、blur の時に下に 1px、キーボードの消え失せた 0.2秒後に上に 1px 動かし、結果としてスクロールは起こらないことにした。



今回の仕事は iOS 用だった。このため、jQuery は「重いから使わない」との判断で、ある程度互換性を持ちながら、機能を削減して軽くした zepto が使われている。


そこで、zepto 用のプログラムは次のようになる。



$(function(){
  $("input").each(function(){
    if(this.type!="text")return;
    $(this).bind("blur",function(e){
      window.scrollBy(0,1);
      setTimeout(function(){window.scrollBy(0,-1)},200);
    });
  });
});


window に仕掛けてバブリングしてきたものをキャプチャ出来るといいのだが、残念ながら blur イベントはバブリングしない。

そのため、input を取り出し、type=text のときだけ blur を付ける、という泥臭い方法になっている。

(zepto のセレクタでは input[type=text] のような属性フィルタは使えない)


もちろん、DOM 構築以降に動的生成された input が position:fixed だったりすると困ったことになる。

今回の仕事ではそのようなことは無さそうなので、そこは割り切った。


textarea にも対応させてやるとよさそうだが、そこも仕事では無さそうなので割り切り。


とりあえずこれでバグ回避できた。


▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

関連ページ

バーベキュー【日記 17/07/02】

Programming Tips

別年同日の日記

17年 後藤英一 誕生日(1931)


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -