Work

ロゴを考えたときの話

そういえば、ロゴの話をまだ書いてませんでした。

logo0901

去年の春に開業をしたときに、名刺やら伝票やらに使うロゴが必要になりました。

…が、私、こういうCIデザインが大の苦手です。
(たまに依頼が来ることがありますが、今のところ正式なものはお断りしてます)

そこで、要点だけ踏まえて
できるだけ楽そうなのを作ることにしました。

どんなふうに考えたのか、まとめておきます。

キーカラーは一色のみ

企業ロゴには二色使用されているものもありますが、
色の組み合わせを考えているだけで日が暮れてしまいます。
どうせモノクロで使うことが多いのだから、一色で済むようなデザインにしようと思いました。

とりあえず身近なもので

ふつうの企業ロゴは、企業イニシャルとキーアイテムを様式化して組み合わせデザインして…という流れですが
そんなものは私には無理です

身近なものを適当に使って、できるだけすぐ描けそうなマークを作ることにしました。

ふと見ると、目の前にモニターがあるじゃないですか。
なんだ、これでいいやと。

関係ありそうなものをくっつける

さらに、私はモニターを通してお客様と接することが多いです。
なので顔文字の「:D」を書きました。

何故「:D」なのかというと、不機嫌でも笑い過ぎでもない、ちょうどいいニコ加減だからです。お客様をそのくらいのニコ加減にしたいところです。

そんなわけで、ロゴマークができました。
個人的に「うぇびんたん」という愛称で呼んでます。
非モテなんだから「たん」ぐらい使わせろ。

ちなみにこれ、中身が顔文字なので

e38186e38187e381b3e382931

移転前のウェビンブログでは「:P」、

e38186e38187e381b3e382932

はてなでのアイコンは「:)」になってます。

既存のフォントをちょっといじる

「WebbingStudio」の文字の部分は、このロゴマークに合わせて均一な太さのフォント「Zekton」を選びました。
けっこう有名なフォントです。

Zektonでそのまま「WebbingStudio」と入力するとこうなりますが、

zekton

「g」のところをぐいーんとのばして、ロゴのモニターの足部分とつなぎました。

zekton2

あとは字形や文字間隔を調整して、ロゴの出来上がりです。


こうやって文章にすると、あっという間にできたように見えますが
丸一日かかってます…orz
しかもロゴマークだけだと何なのかわからないという…orz

CIデザインは長い付き合いになるものなので、難しいですね。
お仕事としては当分無理だなあ。

CMS

WordPress、好きじゃないんだけどな

webbinblog0901

今のブログは、「Sandbox for MovableType」テンプレートセットを一部改編したものです。

Sandboxはもともと、WordPressのカスタマイズ用テーマでした。
最近の個人ブログツールのシェアは、MovableTypeから、このWordPressに大きく流れている状況です。
欧米では、既にシェアは逆転しているのですが、バージョンアップに伴って、日本でも本格的になってきたようです。

ほぼ毎日、仕事で両方を利用している私としても、

MovableType=小規模→中規模の企業向けCMS
WordPress=個人→小規模のブログ

という住み分けが最適だろうと思います。

なので、このブログももっと更新しやすくて、PHPで気軽に拡張できるWordPressに切り替えた方が良いのではないかと考えはじめていますが…

個人的に苦手なのです、WordPress。
WordPressへの不満などグダグダ書き出してみます。

内蔵の関数がひどい

HTMLタグのような書式で記述したものを内部変換させるMovableTypeに対して、WordPressはPHPのプログラム(ユーザー関数)をそのまま記述します。

例えば <?php bloginfo(‘name’) ?> というのは
「name」という引数を渡すとブログ名を返す、「bloginfo」という関数
という意味です。

PHPを勉強している人にはわかりやすい仕様なのですが、いろいろな人の手を経て何度も拡張を繰り返してきたためか、関数の仕様に一貫性がありません。

bloginfo のような、引数がほとんどないものはいいのですが、何個もの引数を要求し、しかも順番が間違ってると動作しない関数も多く、あとでテーマファイルを見ても、引数だけだとそれで何をしようとしたのか、さっぱり見通しがききません。

「&lorem=TRUE&ipsum=0」のように、必要なモディファイアだけ指定する「クエリ式」が使える関数も増えたとはいえ、このクエリ式が使える・使えない関数もまたバラバラで、新しい情報をまめにチェックしなければいけません。

文章整形フォーマットが使いにくい

WordPressの本文自動成型は、かなり融通がきかないことで有名です。
普通の文章なら問題ないのですが、改行込みのHTMLタグを書いたり、アフィリエイトバナーを貼ったりすると、大抵思うようにいきません。

最新版の2.7で向上するかと思いましたが、過去のバージョンとの互換性が足を引っ張っているからか、あんまり良くなっていません。

この辺りはプラグインの追加でも何とかなるのですが、できればデフォルトの方を何とかしてほしいものです。

2009/01/08追記:
WordPress2.7になって、自動整形機能はだいぶ改善されてきました。
正確にマークアップしたHTMLの改行タグを削除するようなふざけた挙動はなくなりましたが、コメントなどの連続ハイフン、textarea内のHTMLソースなどはやっぱり正確に表示できません。

独自タグの範囲内を成形させないRaw HTML、カスタムフィールドの内容を本文に入れ込む Content Ex等の併用が無難です。

本文と追記を別個として扱えない

MovableTypeをはじめ、HTMLを編集できるレンタルブログなどは「本文」と「追記」に対して、別個の独自タグが提供されています。
これは使い方によっては便利なもので、本文と追記に別の役割を与えることで、特殊なウェブサイトを簡単に構築することができます。

ところがWordPressは、更新を簡単にすることに重きを置いているからか、本文と追記の扱いが非常にあいまいで、また、本文だけ・追記だけを自由に切り出すことはできません。

excontentプラグインを作ったのも、そのような経緯からです。

区切りが本文中の<!–more–>だけなので、うっかりHTMLタグで囲んでしまうと、一覧ページが大変なことになるのも悩みです。

コーディングの融通が利かない

WordPressは、1つの命令文で大きな固まりのHTML群を書き出す関数が多くあります。
すぐにブログを構築したいときにはとても良いのですが、デザイン上の理由でコーディングを細かく修正しようとすると、コアファイルを参考に、追加の関数を自分で作成しなければなりません。

静的ファイルが残らない

WordPressは、アクセスするたびにページを生成するのが基本です。
サーバー内にページの実体はありません。
このため、頻繁に更新するブログほど、どんどん表示が遅くなっていきます。
(MovableTypeは再構築が遅くなるのでどっこいどっこいですが)

現時点ではWP Super Chacheプラグインがよく紹介されていますが、キャッシュ生成はWordPressのコアに関わるため、バージョンが変わると動かなくなってしまったり、サーバーとの相性が悪くて最初から動作しないということも多いようです。

安全性に難がある

初期状態でインストールすると、ユーザーIDはかならず「admin」になり、管理画面のURLはブログのルートと同じ階層になります。
これだと、推測ができないのはパスワードだけなので、セキュリティ面ではかなり危ういです。
WordPressの中の人にはもっと、この辺を啓蒙していただきたいものです。

もちろん、私はWordPress設置時は管理画面の階層、IDのどちらも変更しています。

中の人々の態度がでかい

すいませんすいません主観です。

和訳のせいかもしれないですけど、なんか偉そうじゃないですかあの人たち。

「2.7にはコルトレーンという偉大な名前を冠しましたよー」
「私たちはこーんなスバラシイツールを無償で提供してますよー」

ああなんかいやだむずむずするかゆいうま。


他にもいろいろとあるのですが、これらを勘定に入れても、PHPベースの簡単さと、オーバーライド方式のテンプレートは魅力的です。
MovableTypeの管理画面がどんどん重くなっていることや、Perlを勉強する予定がないこと、携帯対応の問題(これでかい)もあり、ウェビンブログはWordPressベースになるかもしれません。
(Sandboxテーマを入れれば、移行にもそんなにかからないしね)

需要があるのは確かだし、ある程度は妥協して、いい点をガンガン伸ばしていくしかないですね。

Life

久しぶりの更新が新年のご挨拶ってどういうことよ

2009nengajo

あけましておめでとうございます。
札幌はずいぶんと穏やかなお正月です。

昨年は公私共、
多くの方々のお世話になり無事に2008年を過ごすことができました。
今年もカスタマイズ職人、WebbingStudioを何卒宜しくお願い申し上げます。

この年賀状は、
実際に今年(というかつい昨日 汗)発送したものです。

Illustratorで4時間くらいで描いてます。
これについても、いずれ記事にするかもしれません。

…うぇびんぐにブロガーの神が降りてきたら

。・゜・ ノД`)・゜・。 スイマセーン

Life

ワーキングプアな白袴の紺屋

先月後半あたりから凄く忙しくなり、週の半分徹夜という生活をしております。
一ヶ月先まで予約的な何かがびっちり入ってますし。
しかもロングスパンのお仕事ばかりで納品にならないという…^^;

このブログも、11月になったのでハロウィンから変えたいんですが
何とか休みを取った今日、できなかったら無理かもー;;

お客様に
「MovableTypeのデフォルトテーマになりそうな悪い予感がします」
とメールに書いたところ

よく、紺屋の白袴といいますから確かにそんなものかも。

とお返事が来ました。

こうやのしろばかま。

と聞くとかっこいいのですが、Webに従事する人間にとって「サイトを更新しない」というのは、その後のお仕事やスキルにも、もろに影響してしまいます。

紺屋のはかまが白くても恥ずかしいだけだし、
医者が不養生で入院しても頑張って職場復帰すればなんとかなりますが、
Webクリエイターは、自分がWeb制作で得たことを書き留めたり、サイトの見栄えを変えることを定期的に積み重ねていかないと、あっという間に置いていかれてしまうのです。

めでたさを自分のために手に入れるにはどうすればいいか。宮崎駿さんがある講演会で言っていた、同じことを言わせてもらいます。「自分が手の届く範囲のことを一生懸命やることが一番の宝だ」というのは本当だと思います。年寄りの忠告になるんですけど、それを信じてやってほしい。どういうことかというと、男の人に特に言うが、エロサイト見てる暇あったら自分の技量を磨け。

「お前らの作品は所詮コピーだ」――富野由悠季さん、プロ論を語る (4/5)

言い得て妙ではないですか。

まぁ、昨日の晩「涙がでちゃうコピペ」見て小一時間くらいうるうるしてしまったのですが。

J(´ー`)し カーチャンに親孝行しなきゃねえ…

でもたぶん仕送りの方が喜ぶ ノД`)

CMS

MovableTypeカスタムフィールドの、filtersの動作について

Movable Type のカスタムフィールドで「テキスト(複数行)」という種類のフィールドを利用する際、テキストエリアへの入力内容に改行や空行を含めても、出力される文字列の改行や空行はすべて除去された状態で出力されてしまいます。

本エントリーでは、この事象を解消する方法を紹介します。
小粋空間:カスタムフィールドのテキストエリアに入力した改行をページに反映させる

mtformat

複数行のカスタムフィールドを、本文と同じように<p>と<br />でマークアップするには、「filters="default"」モディファイアを指定するのが良いとされています。

ですが、この方法では詳細に改行を制御できません。
旧来からあった「convert_breaks」モディファイアとどう違うのか、というのも気になりますが、シックスアパート社からも詳細な解説は出ていません。

MovableType4.2で、「改行を変換」「リッチテキスト」などの各フォーマットでのカスタムフィールドの挙動を、詳しく検証してみました。

結論から言うと、
「複数行カスタムフィールドの改行や空行は、再構築時に反映されない」
という解説は、MovableType4.2においては正解ではありません。

複数行カスタムフィールドにモディファイアを何も指定しなかった場合は、「各記事の本文・追記に指定したテキストフォーマット」が優先されるのです。

なので、IDが1の記事のフォーマットが「改行を変換」ならば本文と同じですが、IDが2の記事で「なし」や「リッチテキスト(WYSIWYGエディタ含む)」に変更すると、本文フォーマットが優先され、改行がなくなってしまいます。

MovableType4は後者のフォーマットで使っている人が多いために、上記のような定説ができたのか、バージョン4.0、4.1の挙動が違ったのかはちょっとわかりません。すいません。

mtformat2

なので、何らかのモディファイアでカスタムフィールドの書式を縛ることになるのですが、
一般に推薦される「filters="__default__"」は
完全に固定的なものではありません。

まれなケースですが、フォーマットを「markdown」にしたときのみ、<br />が書き出されず、意図した表示になりません。
また、

  • 「どんなフォーマットを使用しても改行を変換させない」
  • 「<p>はいらないが<br />は変換したい」

ということは、「filters="__default__"」ではできません。
(引数の__default__を別の値にする方法も考えられますが、MovableTypeのコアファイルを調べてもわかりませんでした)
この場合は、昔からあった「convert_breaks」を使用するのが確実なようです。

convert_breaksモディファイアは、本文でのテキストフォーマットを「常に無視」します。
また、「convert_breaks="0"」で、改行を変換させないようにできます。

<br />のみを変換する「nl2br」もconvert_breaksと同じ性質を持っているので、
ちょっと複雑になりますが、下記のようにすると<br />のみ有効になります。

<$mt:CF_HogeHoge convert_breaks="0" nl2br="1"$>

自分だけがブログをカスタマイズ・運用している場合や、カスタムフィールドが本文の一部であればフォーマットが変わっても良いのですが、
大抵のカスタムフィールドは特定のマークアップを行った箇所に出力したり、テーブルのセル内に出力したりと、イレギュラーな使われ方をします。
同じカスタムフィールドでも、出力先のテンプレートによって改行の個別制御が必要なこともあります。

「更新したときの気分」でフォーマットが変わってしまってはのちのち面倒ですし、CMSとしてMovableTypeの構築をする場合は、更新担当者のあらゆる設定変更を想定しなければなりません。

プログラミングにも通じることですが、的確なグローバル・モディファイアを指定することで、想定外の不具合をできるだけ予防しておきたいものです。