shortcut Webデザインとかガジェットについてつらつらと書き連ねています

277月/060

skeditを使ってみる

先日六本木ヒルズで行われたイベント「web標準の日」のSession:Bでプレゼンを行った長谷川 恭久さんが使用してた「SKEdit」というHTMLエディタが使いやすそうだったので、試用しています。

基本的にはテキストエディタタイプのHTMLエディタですが、

  • 動作が軽快
  • タグの補完
  • ファイルビューとタブによる複数ファイルの閲覧・編集
  • コードをスニペットとして追加(ショートカットもつけられる)
  • perlやシェルスクリプトを使用可能
  • FTP/SFTP/WebDAVに接続
  • CVS/Subversionなどのバージョン管理システムにコミット

と、必要最低限にして必要十分な機能を備えている気の利いたHTMLエディタです。Windowsでは、ez-HTMLがほぼ同機能のHTMLエディタのようです。
スニペットやスクリプトがかなり柔軟にカスタマイズできるので、使い込むほどに手になじんでいくタイプのアプリケーションですね。

とりあえず下記の設定を追加してみました。

スニペット

選択した文字列をH要素でマークアップ(cmd+1〜6に割り当て)

# %%%{SKKeyEquivalent=@1}%%%
<h1>[*sel]</h1>

スクリプト

Another HTML-lintでチェック

#!/bin/sh
#
# htmllint.sh
#
# -- PB User Script Info --
# %%%{PBXName=Another HTML-lint}%%%
# %%%{PBXInput=None}%%%
# %%%{PBXOutput=AppendToAllText}%%%
# %%%{PBXKeyEquivalent=}%%%
#
perl ~/bin/htmllint/htmllint -w short %%%{PBXFilePath}%%% | iconv -f EUC-JP -t UTF-8 > ~/temp/htmllint.txt
cat ~/temp/htmllint.txt

SKEditはHTML Tidyを内蔵しているのでそちらを使用してもいいのですが、HTML Tidyは整形が強烈すぎて多少使いづらい(おかしなHTMLを整形するとすべて削除される)のと、Another HTML-lintの説明の方が解りやすいので、しばらくは併用して使っていこうと思います。

Another HTML-lintは実行結果をEUC-JPで出力しますが、SKEditはUTF-8以外の文字コードを返すと落ちてしまうので、iconvで変換しています。

また、長いHTMLやチェック箇所の多いHTMLをチェックすると、スクリプトを実行したきり帰ってこない場合があるので、ログを生成してから結果を返すようにしました。

Filed under: mac No Comments
257月/061

webデザイナーと呼ばれる人

多少気になったもので。

世間的には、「webデザイナー」というと、webでの静的な実装を行う人、という認識だろうけど、昨今ではインフォメーションデザインやってインタフェースデザインやってグラフィックやってHTMLやflashやajaxで実装するなんて、とても一人ではできません。
webサイトの社会的な重要度が上がるにつれて、各々のフェーズがかなり専門的になってきていますので、それを「webデザイナー」というくくりで大ざっぱにくくってしまうのはちと無理があるような気がします。

また、デザイナーというと、PhotoshopやDreamweaverを使えるかどうかに話に終始しがちですが、アプリケーション使えるのと何らかのデザインができるのは全然イコールではないんですよね。どちらかというと、案件に対してどれだけイメージを膨らませることができて、「こういうデザインです」と、人とイメージを共有できる能力の方が大事で、そこまでの作業なら手書きでも口頭でもイメージが伝われば全然かまわないと思います。
そこから先の作業は、時間と根性で解決できるオペレーター的な作業か、あるいはひとつの作業に完全に特化した人による職人技の世界なので、デザイン作業とは異なる作業です。一般的には相当混同されていて、実際その根性作業(サイトの全ページのリンクを張り直すとか)がメインの仕事なんかもありますが、厳密に言うとデザインの作業ではありません。

そんな訳で、デザイナーとオペレーターと職人さんの呼び名は分けてほしいなぁと思ったりもしますが、作業を端から見ていても全然違いなんて分からないから難しいだろうなぁ…。

制作会社の大手では、インフォメーションデザインならインフォメーションアーキテクト、HTMLならマークアップスペシャリスト、と言った具合にそれぞれのデザインに特化したエキスパートを立てて分業していますが、近い将来、一般的にも「インフォメーションアーキテクト」とか「マークアップスペシャリスト」なんかの肩書きが浸透して、きちんと仕事と肩書きが一致するようになってほしいですね。
今はまだなんとなく「スカしている」というイメージが強いですが、ここがきちんと浸透しないと、プログラマーのように「javaを書ければ誰でもOK」というように非常に大雑把なくくりで見られてしまいそうな気がします。

まずは、きちんと自分の仕事を全うして認めてもらうところから始めましょうか。

と、書いては見たものの、僕が一番器用貧乏でどっちつかずなんですよねぇ…。困ったことに…。

Filed under: web 1 Comment
107月/060

VAIO Uを触ってみた。

ついこないだ、VAIO Uを店頭で触る機会があったので、いろいろいじってみました。

なんというか、端的に言うとごついビューワーですね。

一応キーボードはついていますが、タッチタイピングできるサイズではないので、文字入力はあくまで補助手段という扱いです。
他のPCから取り込んだデータを外で見るとか、ネットに繋いでwebをブラウズするという、軽い使い方がどこでもできるという「モバイル」であることを強調したPCです。
CLIEもそんなコンセプトだったような気もしますが、CLIEの場合、SONYの思惑にPalm OSが全然ついてきていなかったので良い結果にはなりませんでした。もともと徹底的に機能を削ぎ落としたOSなので、はじめから無茶だったといえばそれまでですが…。
それでも、Windowsが走るくらいパワーがあれば、動画でも音声でもネットでも問題なく扱えますので、色々使い方が広がるのではないでしょうか。

一応ドッグに繋げば外部モニタとかキーボードを使えるようにはなっていますが、手持ちサイズのデバイスはどうしても扱いが雑になりがちなので、これ一台ですべてをこなすよりは、他にPCを持っていて、外に出歩くときにVAIO Uにデータを入れて持ち歩く、という使い方がいいのかな? と思います。ノートPCとは全く違うカテゴリーの製品に感じました。まあ、外観を見れば分かりますね。これはマニア向けのPCだぞ、と。

そんな訳で、思っていたよりはそそられる製品ではありませんでした。残念。あと、あの超高解像度のモニターはかなり引きました。およそ2ミリ角の文字を読むのはかなりしんどかったです。

個人的には、持って使うデバイスはどうしても壊れやすいのであまりスペックは求める気になりません。それよりはバッテリーの持ちとか、2秒で起動できるような対応性の方が気になります。
NECのパネリーナとか、ΣブックやLIBRIeあたりをもう少し汎用的にした製品くらいがちょうどいいんですけどねぇ。

Filed under: PC No Comments
87月/060

もう夏ですねぇ。

気づいたら七夕も終わっていました。一年の半分が過ぎたなんて信じられません。

そういう訳で、僕らの季節(©KAN)です。女の人が薄着になってうれしい季節です。
家の近くの女子高の生徒もいつのまにか夏服になっていました。セーラー服です。

しかし、はやりなのか傾向なのか偶然なのか知りませんが、僕が見かける女子高生は、巨漢、もとい、体格の良い子ばかりです。モビルスーツで言うならドムです。きっと高出力にちがいありません。
そして、そういう子に限ってかなりスカートが短かったりします。中に履いているスパッツの裾が見えるくらいとか。あれは、機動性をあげるための措置なんでしょうか?

まあそんな訳で、全国的には夏ですが、局地的には(主に僕の心の中で)まだ雨雲が活発に活動しています。

Filed under: diary No Comments
77月/060

ワンソースマルチユースなHTMLについて

また否定的な話でアレですが。

Web標準のメリットとして「ひとつのHTMLでPCにも印刷にも携帯にも対応できる」という事が挙げられる場合があります。
その事自体には特に異論はありません。いちいちメディアごとにHTMLを用意するのはいろいろコストがかかりますからね。

ただ、印刷は基本的にPC向けの出力のハードコピーなのでまだ分かりますが、PCと携帯で同じHTMLを使い回すというのは、現在の携帯のブラウザではまだ無理があるような気がします。
ブラウザの画面の面積比が1:16くらいありますから、たとえCSSでレイアウトをいじれるにしても、PC向けに作成したページを携帯でみたとしたら、延々とスクロールされるページになります。
また、画像を使用していたら、携帯のブラウザではファイルの容量制限でみられない場合がほとんどでです。

なので、ワンソースマルチユースなHTMLは、技術的には可能かもしれませんが、現状はまだ環境が整っていないので有効ではないような気がします。
思想としては明快で合理的ではありますが、解像度・UIなどのメディアごとの特性を考えると、今の時点ではそれぞれのメディアごとにHTMLを起こした方が良いと思います。

追記(060707)
つらつら書いていたらこんな発言が。

現状はインフラ、ネットワークが非常に大きくなったり、携帯電話の端末自体も非常に高度化してくる中で、必ずしも加工が必要ではない。コンテンツがそのまま流通できるようなレベルに達している中で、我々のモバイルコンテンツの定義もすごく変わってきたというのが実情としてあります。

そうなんですか…。時代はすごい勢いでかわっているんですね…。

Filed under: web No Comments