【#TechBuzz】10/7 第26回HTML5+JS勉強会 in 代々木に参加してきました

東京出張での打合せがありましたので、

そのまま勉強会に参加してきました。
http://html5js.connpass.com/event/33011/
https://atnd.org/events/78125
↑これです。

まとめを兼ねて、久しぶりにブログ書きます。

Webアニメーションについて

川上 和義さん(@saruyama_monki)

ディズニー社で培われてきたというアニメーションの基本原則12の紹介をWebアニメーションで実装するとどんな風になるのか?という内容を、実際に作成してCSSアニメーションの実例で見せていただき勉強になりました。
アニメーションの要望は高まっているように感じていますが、ついついJS側で実装してしまうのですが、メンテナンス性とかを考えるとCSSアニメーションでできるものはCSSで実装する方がいいのかもな。と考えを新たに。本腰をいれて勉強せねば。

HTML/CSS3のイマドキコーディング技術

ICS 鹿野壮さん(@tonkotsuboy_com)

フロントエンドの前線で仕事をされている鹿野さんによる「フロントエンドの技術は数年前のをそのままやっていると、作り手にもクライアントにもよくないので、新しいものを学びハッピーなフロントエンジニアライフをおくりましょう」的な講義。8つのあるあるネタを元に現場ではこういうのをやっているよという内容を教えていただきました。
中でも、古いブラウザ対応についても、現在はモダンブラウザがかなりのシェアをもっているので古いIEやベンダープレフィックスなどはある程度なくしていってもいいのでは?という呼びかけに、たしかにそうだよね。頷いてしまいました。

あと、「知らんかった・・・(汗)」ってなったのが、imgタグのsrcset属性について、これWordPressなどでもimgタグを出力する関数つかうと普通に実装されているので、HTML5で勧告済みなのかと勝手に思っていましたが、HTML5.1の仕様なんですね。まあsrc入れてるので互換性には問題ないですが勘違いでした。(ちゃんと調べてから使おう!)

さらには、講義後に鹿野さんと名刺交換させていただいたときにその話をさせてもらったんですが「あのエスアールシーセットってぇ・・・」て話したら「ソースセットね」ってやんわり訂正されて超恥ずかしい。。。(TT)
一人でやっていると、文字での情報は勉強できるけど、周りに普段から会話でやり取りできる人がいないのでコーディング周りの 「読み方」 は鬼門です。

全体的に、Flexboxとか普段から使いたいけど古いブラウザ的にどうだろう・・・という踏み切れない気持ちを強く後押ししてくれる講義でした。

名刺交換タイム

最後に名刺交換して交流を深めるタイムみたいのを設けていただいたので、フロントエンド界隈の人々と情報交換ができて知識と刺激を沢山いただいてきまいた。
なかでも、話題にでたのが「sass+compass」ってどうなの?というお話がホットでした。

  • compassをつかうとベンダープレフィックスを書かなくていいけど、コンパイルされたCSSにはもういらないようなベンダープレフィックスのズラズラついちゃうからスマートじゃない?
  • compassを使っていても、主にCSS3関連のベンダープレフィックスを省略できることくらいしか使わない?
  • どうせgulpとかのタスクランナーも併用するんだから、いっそのことsass+Autoprefixerでいいんじゃね?

というあたりの意見が交わされました。

これらは確かにそうかも。と思わせられて、これから検証していきたいと思いました。

トーキョーはこういう熱い勉強会がたくさんあってうらやましい今日このごろ。

ちなみにこの記事、高速バスで新潟に早朝に帰りついたはいいけど、家の鍵を持って出るのを忘れてしまい家には入れないので、しょんぼりしながら市内のコワーキングスペースcodeforで書いたことはヒミツです。

Vagrant+Scotch Box にphpMyAdminをインストール

VagrantでPHP開発環境をつくりたいんだけど、最低限PHPとMySQLが動けばいいくらいであとは細かいことは気にしなくていいって、感じの軽い開発のときに、そういう環境がさくっと立ち上げられるScotchBoxが重宝しそうです。
PHPとか新しいバージョンのがはいっているのでLaravelとかも動きます。
ただ、phpMyAdminが入っていない?のか見当たらなかったので、ScotchBoxの立ち上げから、phpMyAdminのインストールまで。

これで、PHPとmySQLが動いている「とりあえずなPHP開発環境は揃うはず」

参考にさせていただいたサイト

Scotch BoxをインストールしてphpMyAdminを動かす

  1. 任意の場所で
    git clone https://github.com/scotch-io/scotch-box.git <フォルダ名>

    これで、フォルダ内に必要ファイルが入ります。

  2. 上記のフォルダを見ると、「Vagrantfile」とうファイルがあるので任意で編集。
    Vagrant.configure("2") do |config|
    
        config.vm.box = "scotch/box"
        config.vm.network "private_network", ip: "192.168.33.10"
        config.vm.hostname = "scotchbox"
        config.vm.synced_folder ".", "/var/www", :nfs => { :mount_options => ["dmode=777","fmode=666"] }
    
    end
    

    上記でいうところの

    config.vm.hostname = "scotchbox"
    

    scotchbox がホスト名になります。私のChromeだと、アドレスバーにscotchboxとだけ打つと検索しにいってしまうことがあって不便だったので、scotchbox.local みたいなアドレスっぽい名前に修正しました。

    config.vm.synced_folder "."・・・・
    

    の “.” がローカルの作業フォルダになります。通常は、上記でcloneしたときに作ったフォルダの中にpublicていうのができててそれが作業フォルダになります。ここを変えると作業フォルダを変更できますが、ここで指定したフォルダの中にpublicというフォルダができてそれが作業フォルダになります。
    例えば、

    config.vm.synced_folder "./www/"・・・・
    

    としたときには、wwwフォルダのなかのpublicフォルダが公開フォルダになります。
    そのままのほうがわかりやすいかも。

  3. あとは
    vagrant up
    
  4. で、環境が立ち上がって先ほど決めたホスト名でのアクセスを確認できたらphpMyAdminのインストールをします。
    まずは

    vagrant ssh
    
  5. ScotchBoxのOSはUbuntuなのでphpMyAdminインストールは
    sudo apt-get install phpmyadmin

    インストール中にいろいろ聞かれますが、
    Webサーバーはapachを選択。
    Configuring phpmyadmin は「No」
    ・・・
    でインストールは終了しますが、このままだと<ホスト名>/phpmyadmin でアクセスできません。

  6. Ubuntuの公式にしたがって
    sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf-available/phpmyadmin.conf
    sudo a2enconf phpmyadmin
    sudo /etc/init.d/apache2 reload
    

    これでOK。
    <ホスト名>/phpmyadmin
    でphpMyAdminにアクセスできたら成功です。

  7. ちなみに、ScotchBoxが最初から準備してくれているDBへのアクセスは
    ユーザ名:root
    パスワード:root
    です。

以上、まあようするにUbuntuへのphpMyAdminのインストール方法なんですが、まとまった情報がなかったので
まとめ+備忘録を兼ねて。

CSS Nite新潟版Vol.4 に参加してきました。

6月6日に開催された、「CSS Nite新潟版Vol.4」 に参加してきました。

http://cssnite.jp/niigata/vol04/

いろいろと学べる事が多い会でしたので、まとめを。

初参加ですが、思ったよりも大きな会場で、なおかつ人もたくさん集まっていて新潟って、Webをやっている人たち、いっぱいいるんだなぁという印象でした。

丸山純一郎さんのセッションの中で(みんなの共通認識として)言われていましたが
「お客さんが何のためにホームページをつくるのか?それは売上を上げるためですよね」
ってことと同じように、CSS Niteに集まった人たちも、やっぱり何のためにこういう会に参加するのか?というと最終的には自分たちの売上を上げるためなのだと思います。
Webをやって飯をくっていくために・・というか。。

だから、よりよいものを作るため、よりよい仕事をするために知識を深め、技術を磨いており、そのために勉強会などに参加しているわけです。

そう考えた時に、
鷹野雅弘さんのセッション「Illustrator+Photoshop最新テクニック」と松田直樹さんのセッション「これからのWebサイト設計〜CSSフレームワークでつくるマルチデバイス対応サイト」はWebデザインをしていくなかで、とても実のある内容でした。お二人のセッションから、Web制作のなかで「作業」をどうやって軽減していくか?いつもの作業を「変数化・関数化・自動化」していくことで製作者の作業をガサッと減らす方法をデザインとコーディングの部分で学ばせていいただけました。
なぜ作業を軽減するのか?については、講師の皆さんが言葉は違うけど触れておられたように、「作業を軽減して、その分ちゃんと考える時間を作りましょう。」ってことですよね。
普段一人で仕事することが多いので、つい、いつもの慣れた方法に落ち着いてしまうことが多いのですが、毎回ではなくても、ちょっと余裕のあるときに、学習コストをかけてでも、新しい環境や新しい機能、Tipsを取り入れることで、その後の作業が格段に楽になることがありますが、そういうことのキッカケとモチベーションをいただけました。

つくったサイトが、ちゃんとお客さんのお役に立てるように、設計にアタマをつかう時間の確保していかねばなりません。

また、つくるだけでなく、つくったものをどうやって運用していくか?
小杉聖さんのセッション「成果を重視したウェブ活用の基礎体力がつく資格・ウェブ解析士 〜テレビショッピング的な5分間〜」で、小杉さんが言われていたように、アクセス解析の数値を、Webの体温や血圧のように見る。って言葉たとても印象的で、単純に訪問者・閲覧数が増えたねとか減ったねっていう話ではなく、、設計段階で目的がしっかりしたサイトをつくるからこそ、それがちゃんと活かされているかを、測るための数値として見ることができるんですよね。

Webで良い仕事をするためには、作ることが目的ではなく、設計と運用が大事になってくるし、そこをちゃんとやらないとこれからは「おまんま食い上げ」ですよ。という中で、地方でWebをやっていくヒントとなったのが丸山純一郎さんのセッション「Uターンして実感する地域格差、Web事業をどう展開していくか?」でした。
いきなりお客様に難しい事を言っても話が噛み合わない。だからこそ設計→制作という流れではなく、あえて、まずは制作。そしてつくって動かしたものをちゃんと検証して、それを元に改善していくなかで「設計」していく。
「設計→制作」ではなく、あえて「制作→設計」という流れをつくる。
というのは、実際に普段の仕事の中でとても共感出来る内容でした。

田舎での仕事は、Webについて(というかIT全般について)詳しくないお客様がほとんどですから、いくら技術がありますという話をしても、お客様にはピンと来ない。
そういうときに活きてくるのは、やっぱり「信頼」だと思うんですよね。
我々はWebの知識や技術は持っている。でもそれを100%活かせるシーンてなかなかないのですが、お客様から「信頼」をいただけて、「お前がやるなら全部まかせるよ」と言ってもらえて仕事ができたら、大変だしプレッシャーもあるけど、ただ、自分の知識や、また周りの人の協力も全部つかって全力で仕事できるわけで、一番幸せで楽しい仕事なんじゃないかと思うのです。
そういうために、まずは「制作」って事だと思ったのですが、この制作の時にはやっぱり「デザイン」が実際問題として大事になってくると思います。
「制作」において、お客さんにいくらWebマーケティングや顧客動線の話、ましてやCSSやらJavascriptの話をしても通じませんから、実際には「ぱっと見」の「おぉ!」って感激が大事になってきてしまうんですね。

本来のデザインが持つ目的とずれた話になりますが、お客様に提案していく中での現実問題として、やっぱり「制作→設計」の流れの中で、お客様にまずはつくってみましょう。という言わせるためのポイントとして「見た目がかっこいい!うちのサイトこんなにすごいのになるの!」という感動があるかどうか?は、やっぱり現実問題として、最初の提案が通りやすいかどうか?に大きく関わってくるってのはあると感じています。

原一浩さんのセッション「Webデザイントレンド:キャプチャで振り返る2014-2015年の潮流」は、その資料の膨大さに度肝を抜かれたというか、なんかすげーって圧倒されながら見てたのですが、カッコ良い・キレイなサイトには、一つ一つのパーツにやっぱり時代とかお客様の環境の変化の中で、ちゃんとした意味があって、それを適切につかうこと。松田さんのセッションで醤油差しの話がでてきましたが、機能性と見た目の美しさってのはやっぱり同じ方向を向いているんだな。と感じさせられました。
あと、デザイントレンドを追っていくことで、世界中で試されているABテストの結果を手に入れることができる。ってのは、一朝一夕でできることではないけど、とても腑に落ちる表現でした。
そして、早速活かされている人がいてとてもためになりました。^^
http://dtp.jdash.info/archives/Hamburger_Menu_Test_2014
こういう風に他の方が復習してくれるのって、とても勉強になりますので、ネットっていいなって思います。

同じくCSS Niteに参加されていて、懇親会でお話させていただいた方が
http://mikubell.tumblr.com/post/121096042197/css-nite-2
という記事を書かれていますが、まさにその通りで、また逆に言うと、エンジニアもこれからは「デザイン」の領域まで入り込んでいかないとだめですよ。ってことだと思うのですが、やっぱり「全体」が見渡せて制作できて、デザインもコーディングもプログラミングも全部わかる人がいて、そこからパーツに落とし込めるか?ってことが
ないと、ちゃんとした成果のでるWebに辿りつけないのかな。。そういうところを目指さないと何も残らないなと強く思います。

エンジニアは、デザインの領域(とくに見た目よりも顧客の動線や感じ方などロジカルな部分)。
デザイナーは逆にエンジニアの領域に踏み込み、よりロジカルで「説明できる」・・・のは当たり前で、さらに一歩上を行って、ロジカルでなおかつ感動というかこころを動かすデザインをつくっていく必要があると感じました。

・・・

こういう会に参加させてもらう意義は、新しい知識や技術を手に入れるということはもちろんですが、すでに(明確にでも、潜在的にでも)わかっていることでもしっかり再確認できて、その上で、よしやるぞっていうモチベーションを上げていける。って事が大きいと思います。
いろいろな方と出会えて、お話ができて、そういう意味ではとても有意義な会でした。

Googleアドワーズのクーポンをいつでもだれでも取得できる方法

自分のサイトでも他社のサイトでもサイトを制作したり管理したりしている人なら一度は目にしたことがあると思いますが、Googleのアドワーズのクーポン。
2500円使うと7500円分のポイントをプレゼントします。というやつ。
特にGoogleの他のサービスとかで住所登録などをしたことがある場合や、Web制作業を営んでいる場合などは、しょっちゅうダイレクトメールで郵送されてきます。

私達のようなWebの制作や運用を生業にする人たちは、お客様からアカウント作成や設定・運用代行を依頼されることも多いので、このクーポン使う比率結構たかいんですよね。

まあ、実際にはアドワーズをやるときでないと使わないものなので、そこら辺に放っておいてしまったり捨ててしまったりするのですが、いざアドワーズを登録しようと思ったときに
「あ、そういえばアドワーズのクーポンあったよな」
と思い出して探すけど見つからない。

そんな経験はありませんか?

クーポンの内容がが2500円を使うと7500円分をプレゼントしまう。という条件なもので、実際にアドワーズをやろうという人にしてみれば一度クーポンを見ているだけに、使わないと損した気分になっちゃいますよね。(貧乏性^^;)

で、そんな時に、

実はあのクーポン、郵送ダイレクトメールを受け取った人でなくても、だれでもいつでも自分で発行できるのです。

やり方は・・・というかやり方も何もなく

http://www.google.co.jp/adwords/coupons

上記にアクセスして、必要事項を入力するだけ。
そうするとクーポンコードが表示されるので、あとはそのコードをアドワーズの管理画面から入力すれば使えます。
(クーポンコード入力方法はこちらをどうぞ)

※上記のクーポン発行ページですが、なんとなくあったよなぁ・・という覚えがあったのですが、検索しても見つけることができず、アドワーズのサポートに連絡したら教えてくれました。
私と同じように「アドワーズのアカウントつくりたいけどダイレクトメール捨てちゃった(TT)」というような困っている人がいるかもしれないので記事にしておきます。

【注意】
クーポンコードの使用に関してはいろいろな規約や条件があります。
発行できるからと乱発せずに、まずは規約を読み、当てはまる場合のみ発行するようにしましょうね。まじめに。

デザイニングインブラウザとフルスタックエンジニアとマテリアルデザインと私

ここ数年耳にすることが多くなった言葉として「デザイニング イン ブラウザ(インブラウザデザイン)」「フルスタックエンジニア」「マテリアルデザイン(フラットデザイン)」という言葉があります。
これらの言葉について、面白そうだなと思いつつも実際にはどうなんだろう・・・とか、あんまり一般化しないなとか・・・流行りで終わりそうだなとか・・・いろいろ思っていましたが、最近ようやくこれらのワードがつながってきたのでまとめます。

(田舎の、それこそ技術者が1〜2名しかいないような会社の、そういう環境にいる視点ですので、時代に遅れた感はあるけど、実際地方の現場ではこんな感じですという記事となります。^^)

デザイニング イン ブラウザ(インブラウザ デザイン)

Webデザインの現場において、今まではデザイナーがAdobeのソフトなどでデザインを作成し、それをプログラマーとかコーダーが、HTMLでコーディングしてつくり上げるという方法が一般的でしたが、いきなりブラウザ上でデザインを作成しちゃいましょう。という方法です。
(ちょっと乱暴な表現かも?)

たしかに、大枠で言えばHTML5、CSS3、細かな話でいえばWebフォントが一般的になりつつあり、レスポンシブWebデザインやパララックス(最近聞かない?)などがどんどん取り入れられている現状、Webの表現方法が非常に多彩になってきていますから、例えば見出しなどを目立たせたいと思ったときもわざわざデザインソフトでつくらなくてもコーディングのレベルでデザインを作ってしまえます。また、メンテナンスを考えた時も、見出しの文字が1文字変わるだけなのに、わざわざデザインソフトを立ち上げて修正して画像に書き出して貼り直す。なんてことをしたり、もっといえば、他所から引き継いだ案件などでは、デザインの元データが見当たらないのでつくりなおしなんてこともしょっちゅうあるので、この点だけ考えても、メリットは大きいと思います。

また、お客様視点からしても、「この見出しの部分を1文字なおして」と業者に依頼したのに、「実はその部分は画像で貼り付けてありまして修正に手間がかかるので追加料金となります」といわれても、「いや、文字修正でしょ?消して打ち直せばすぐじゃん。なんで?」となることも多く、この意味でも、やっぱりテキストなどを画像にして貼り付けるという行為はやり方としてスマートではないですね。

デザインの打合せのときも、デザインについてあれこれ意見がでるけど、(その場にAdobeのソフトがないために)結局それを一度持ち帰ってデザイナーに修正してもらって、後日診てもらう。というよりも、その場でコードを修正して「こんなでどうでしょ?」ということができたら話が早いと思います。

また、HTML5の時代ですから、これからは、レスポンシブWebデザインはもちろん、当然、動きのあるサイトデザインが一般的になってくるでしょう。それらを紙ベースやPDFで見てもらってもなかなかイメージがつかないと思います。
打合せの段階でブラウザで確認できることはもちろん、打合せ担当のディレクターにある程度のコードの知識があれば、テキストエディタがあればある程度の修正がその場でできますから、お客様の要望に合わせて「こんな動きもできますよ」という提案ができたら、とても良いと思います。

とくにWordpressの案件などでは、Wordpress自体はCloud9などを使えばものの10分で環境構築+プラグインのインストールまでできますから、仮でもテストサイトを立ち上げて、その場でコーディングによってデザインや動きを見せながら打合せができたら、かなり工数を削減できると思いますし、あとから「なんかサイトができたら思ってたのと違った」というのを低減できるのではないかと思います。

我々コーダー、プログラマー寄りのWeb制作者にとっては、なんかいろいろ変わっていきそうな気がする「デザイニング イン ブラウザ(インブラウザデザイン)」です。

でも、実際にはなかなか広まっていかないな。。というのもあります。
多分それは、制作側のスキルの問題が大きんじゃないだろうかと思います。

例えばWordpressがこれだけ広まったのも、PHPとか知らなくてもお問い合わせフォームや新着情報機能が実装できるってあたりの、技術がない人でも使いやすい。ってのが最大要因な気がします。

デザイニングインブラウザ(インブラウザデザイン)が、今ひとつ広がらないのは、デザインからコーディング+ちょっとしたプログラムまで全部できる人が実は少ないので、実際にブラウザ上でデザインといっても、難しいのだろうな。というふうに思います。

そこで、今後のWeb関連のエンジニアに求めらているのが、フルスタックであること。。になってきます。

フルスタックエンジニア

最初に、フルスタックエンジニアと言う言葉を聞いた時は、(なんかカッコイイことばだな)と思いました。
でも実際にその言葉がつかわれているのが、転職サイトなど人材系のサイトばかりで、どうも現場でいわれているというよりも、転職業者のあいだで人を募集するための言葉とかなのか?という印象で終わりました。

ただ、上記で述べたようにWebの表現方法やできる事がどんどん多彩になっていく中で、紙で印刷したものを見ながら「どんなふうにつくりましょうか」というのはいずれは限界が来ると思います。また、昨今はクラウドソーシングもどんどん広がっているようですから、紙にデザインを作るとか、紙に印刷された固定的なものをコーディングする。という仕事はどんどん安いところに流れていきます。
たとえばクラウドソーシングには「Gengo」のような翻訳サービスもあるわけですから、それとIT技術系のクラウドソーシングがシームレスに連携するだけで、日本語しかできなくてもアジア圏などにも外注をだせるわけです。

そう考えると、今実際にWebデザインを紙でつくれます。紙で作ってもらえればコーディングできます。というように、「指示書」や「要求定義」があれば作業ができるレベルの仕事は少なくなっていくと思います。
(少なくなっていくというよりは、資本があって投資ができて、人件費を削減できる仕組みを構築できる大きな企業に利益が集中していくので、田舎で中途半端にやっているところに回ってくる仕事は減っていくといったほうが近いですね)

そんななかで、我々Webに関わるエンジニアが生き残っていくためには、やっぱりここなのかな。と思わずにいられません。
前項でも書きましたが、インブラウザでデザインから構築できると、出来上がりがイメージしやすいだけでなく、工数の削減にもなりますし、なにより、地方ってお客さんがWebに詳しくなかったりして、「やりたいことはあるけど、どうやって実現したらいいのかわからない」って人がたくさんいます。
なので、紙で書いたもので打合せするよりも、その場で簡単にプロトタイプを組みながら、ああでもないこおでもないと打合せできるような環境をつくってあげると、イメージがしやすく、そして話が早く、最終的にはお客様のマーケティング計画に近いものが出来上がる可能性が高くなります。

実際に言われている「フルスタックエンジニア」ってどちらかというと、サーバからWebデザインまで全部みたいな作る側の人のことを指していると思いますが、人材が不足している地方においては、それにさらにディレクターや営業やコンサルなど、お客様と直接やりとりするためのスキルも含めて「フルスタックエンジニア」がこれから求められて行き、そういうのになっていかないと、おまんまを食べていけなくなるのではないか?と考えます。

とは言いつつも、そんなに悲観しているわけではなく、私の周りなどはそうなんですけど、フリーランスで直接お客さんとやりとりしてWeb作っているような人達って、フルスタックな人たくさんいるんですよね。

そりゃそうですよね。我々地方の技術者は、ホームページだけでなく、インターネットの設定やプリンタのインストール、はてはエクセルの使い方までお客様から聞かれちゃう何でも屋をやっるところも多いのではないかと思います。
「ホームページが映らなくなったんだけど」と言われても「サーバは専門外なのでわかりません」とは言えません。
「ここにバナーを追加したい」と言われても「デザイナーじゃないのでできません」とは言えません。
お客さんにとっては、インターネットに詳しい人、パソコンに詳しい人として相談してくれるのだから、それらに答えるのが仕事。としてやってきているような人が多いので、結果フルスタックに近い人達が沢山いるのです。

そういう人たちが、今後重宝されてくるといいな。なんて思います。

マテリアルデザイン

もう1つ「マテリアルデザイン(フラットデザイン)」という言葉もよく耳にします。
これ、最初にでてきたときには、ただの「流行り」かと思っていました。一部デザインに先進的な皆様の間で流行っているだけで、田舎のWeb屋には、あまり関係ない話なのかと。。。
でも、このインブラウザでデザインを進めていくのと、とっても相性がよいのがこのマテリアルデザインであるということがわかってきました。
マテリアルデザインの元となっている「マテリアルオネスティ」という考え方があるのですが、要するに素材を活かしたものこそが美しいという考え方のようです。

↓↓詳しくはココ↓↓
http://contentmarketinglab.jp/trend-in-japan/responsive-web-design-2.html

ここを読んで、たしかにそうだなと思ったのが、Webデザインにわざわざ影をつけるのって変じゃね?ってことです。
だって画面には光源なんてないのだから、フラットなものなのです。

じゃあなんで、Webデザインに影をつけるのか?

それは「目立たせるため」ですよね。「お問い合わせはこちら」とか、「お申し込みは今すぐクリック!」みたいなボタンをつくるのに、周りの部品に埋もれさせないために、ドロップシャドウをつけて目立たせたりします。

でも、そのために、例えばAdobeでわざわざ影付きのデザインをつくって貼り付けたり、CSSで頑張って影をつけたり。。
そのために、たとえばレスポンシブデザインの際に、わざわざ影の位置や広さを調節したりが必要になるかもしれません。そんな感じでメンテナンスが大変、というのはどうでしょうか。

目的にたちかえって「目立たせるため」ということだけを考えれば、デザインそのものを見なおして、マテリアルデザインという考え方にのっとって作ってみるというのはどうでしょうか。

まだマテリアルデザインの全貌を理解しているわけではないのですが、例えばGoogleのアプリなどマテリアルデザインを採用しているアプリやWebサイトをいじってみると、ボタンを目立たせるというよりも、ボタンがよりタップしやすい場所に、タップしやすいカタチで配置されていたりといった工夫がされているものが多いです。

いままで紙ベースでデザインしてきた場合は、上から読み始めて下に読み進めていく。
という流れがあたりまえです。その視線の流れにそって、途中で「目立つボタン」を設置してクリック率を高めよう。というのは当然だと思います。

でも、今後はどうでしょうか?デバイスは多彩になり、スマホ、タブレット、スマートテレビ、携帯ゲーム機、PC。。。いろいろなデバイスでのアクセスを考えて時には、かならずしも上から下に、左から右に読み進めるのが、ユーザにとって優しいとは限りませんよね。

そうした中で、PCのディスプレイとマウスでの操作を前提としたものよりも、Webの本来の「素材」である「画面」という考え方でデザインをしていったほうが、良い物が作れる気がするのです。

先ほどの「目立つボタン」をつくりたいのなら、片手持ちのスマホで閲覧を想定するさいには、つねに右下にフロートさせたボタンをおいておくというてもあります。
ページを読み進めていくなかで、アニメーションさせることで目立たせることもできます。
同じように目立たせるというものが、いままでの固定的なデザインから、動的なものに変わっていく中で、そのガイドラインとなるのが、マテリアルデザインではないかと思いました。

また、インブラウザデザインと相性がよいといったメリットもあります。
ブラウザのなかでコーディングしてデザインをつくっていく手法では、なるべく余計な装飾が少なく、それでいて見やすい、操作しやすいデザインを作る必要があります。そういう意味ではCSSでざっくりコーディングしちゃって、あとで修正していけるマテリアルデザインはとても相性が良いといえます。

そういう、インブラウザでのデザインをつくっていく中での一つのガイドラインを、マテリアルデザインが示していくれているのかな。なんて考えております。

最後に

なんかとりとめのない話になっちゃったな。
実際には地方にはまだホームページって何?みたいなお客さんもいるし、いまだに「社長、これからはホームページですよ」なんつって、どうしようもないホームページを高く売りつけている業者も存在しています。
なので、明日から何かが変わりますという話ではないかもしれないけど、
でも、企業側からすれば、これから若い人たちが経営層に入ってくれば、当然、マーケティングを見据えたWeb運用というものがはじまってくるし、そうしたときにテンプレートとコピペで作ったホームページを売っていたら、「それなら自分たちでつくりますけど」となってしまうのではないかと思います。

そうした中で、(半年後どうなっているかわからないけど)今の時点では、技術的な分野で「取り組みたいな」と思えるものとその方向を書いてみました、

Chromebookと相性抜群のCloud9が凄すぎてゲボ吐きそうになるレベル。

Chromebookを大変便利につかわせていただいている毎日ですが、開発環境とかどうやろうか?といろいろ探しているうちに出会った Cloud9
ブラウザからいじれるWebアプリ開発の統合開発環境とのことで、最初は、色物っぽいけどなかなか面白そな試みですな。なんて上から目線での試してみたけど、そのすごさに度肝を抜かれて、「この世に神はいた」って思えるくらいな今日この頃。

これ、本当にすごいです

まずは、こちらの記事を
Cloud9でクラウド上にWordPressのテスト環境を10分で作成する方法、もちろん無料
http://nelog.jp/cloud9-wordpress-test

ほんとに10分あれば構築できます。

今までは、打合せとかしているときに「あ、それならWoedpressにあのプラグインをたしたら実現できそうじゃね?」とか思っても、その場でレンタルサーバを用意したりWordpressインストールしたりとかできないので、「じゃあ、今度サンプルてきなの作ってきますよ」的に”宿題”になっていたのですが、Cloud9ならホントに10分あればWodpressのテスト環境が構築できますから、その場で「それって、こんな感じでどうですかね?」とプロトタイプを提出できるようになります。
これは、ホントにすごいことで、今まで2回とか3回分の密な打合せが可能になります。

  1. こんなことできませんか?に対して
  2. 検索すると近いプラグインがでてくる。
  3. すぐにCloud9でテスト環境構築してプラグインをインストールしてみる。
  4. こんなでどうですか?とプレゼン。
  5. ここまでホントに15分程度

なにより、ブラウザから全部できるので、私のChromebookからもサックサクに動きました。
ここ数日、客先訪問のときはChromebook持ち歩いているので、かなり活躍してくれます。

ファイルマネージャ、テキストエディタ、ターミナル、そして確認用のブラウザ、まで全部ついてこのお値段(無料!)ってすごすぎてゲボ吐きそう・・・
Wordpressだけでなく、Railsやnode.jsなども試せるとなると、なんだかワクワク感すら感じてしまいますね。

WordPressプラグイン The Events Calendar 各テンプレートのカスタマイズ方法

仕事でちょっと関わったのですが情報が英語ばかりで手間取ったので備忘を兼ねて・・・

【プラグイン名】
TThe Events Calendar
https://wordpress.org/plugins/the-events-calendar/

公式サイト
https://theeventscalendar.com/

上記のプラグインはイベントカレンダーをWordpressに設置するプラグインなのですが非常に多機能で完成度が高いプラグインです。
ドキュメントやフォーラムも充実しています。(基本全部英語なんですが、コード探したりするだけなら英語できなくてもなんとなくあたりをつけて情報探したりできます)

今回の問題は、このプラグインが吐き出すカレンダーやウィジェットなどの見た目を変えたいというもの。

テンプレートファイル自体は、
WordPressインストールディレクトリ/wp-content/plugins/the-events-calendar/views
の中にいろいろと入っていますので、該当するっぽいテンプレートを編集すれば、見た目を変えることができます。
が、やっぱりというかなんというか、pluginsディレクトリ内のファイルなので、アップデートなどで元に戻ってしまう事があるようです。

そこで、下記の方法でテンプレートを上書きする方法がオススメです。

  1. 今使っているテーマのディレクトリ内に /tribe-events というディレクトリを作る
  2. その中に、プラグインの/viewsディレクトリと同じ階層でファイルを置くと、該当するテンプレートを置き換えることができます。

例):ウィジェットで表示される「リスト表示」の見た目を変える

  1. [プラグインディレクトリ]/the-events-calendar/views/widgets/list-widget.php を編集する。
  2. [今使っているテーマ]/tribe-events/widgets/list-widget.php としてアップロードする。

例):イベントの詳細表示(カレンダーとかからイベントをクリックしたとき開く)の見た目を変える

 

  1. [プラグインディレクトリ]/the-events-calendar/views/single-event.php を編集する。
  2. [今使っているテーマ]/tribe-events/single-event.php としてアップロードする。

 

以上で編集完了。

試していないけど同じ要領で、views内のテンプレートを自由に変更できると思われます。

これなら、テーマ内にテンプレートがあるので、アップデートなどで上書きされ元に戻ったりする心配はありません。

WordPress:カテゴリーにカスタムフィールドを「手作業」で追加する

WordPressをカスタマイズ。というお話で、イチバンでてくるのはカスタムフィールドじゃないかと思う。

カスタムフィールド自体はプラグインを使えば簡単に実装できるのですが、そのプラグインの中身はどんなコードが書かれているのか?を学ぶのはとても勉強になるように思います。

よくお世話になる機能ならなおさらですね。

どんなコードを書けば実装できるのか?がわかっていると、プラグインだけだとちょっと足りない・・というときに、チョイ足しで解決できることもあります。

で、投稿へのカスタムフィールドはよく使うのですが、普段あまり使わないけど、あったら便利だなという局面によく出くわすのが

カテゴリーのカスタムフィールドです。

こちらもプラグインを使えば実装できるようなのですが、実際にどんなコードで実装するのか?
が、詳しく書いてあるページを紹介します。(ちょっと昔の記事ですが・・・)

というより、実は以前に自分がコメント欄で質問させていただき、その時のカキコミ含めて、参考になるので、たまに見るページです。

WordPressのカテゴリーにカスタムフィールドを追加する