やまろぐはてな

yamanokuの技術メモとか戯言。真面目に見たり見なかったりしてください

javascript無効にしたときのユーザビリティとかについて

社内で話した内容で気づけてよかったことなのでまとめてみる。自戒も込めてます。

  • 最近はjavascript無効な環境とかに対して優しくする意識はないのではないか
    • SPAとかなんかjavascriptあり気なんだしでかいFlash1つ置いててiPhoneで見る場合のと同義っぽい(※SPAをdisってる訳ではない)
  • javascriptでガッチリ組みすぎてるのもアレだけど、とはいえ今のレイアウトはjavascriptありきのものばかりだよね
  • そうなるとjavascriptが動作してなくて崩れてたとしても情報はちゃんと見せてあげたい
  • リッチな表現はjavascriptにのみ任せて、それ以外の基本動作は抜きでもちゃんと機能するようにしたい
  • 以下例みたいな考え方をスタンダードにしたい
    • アコーディオンは通常時は出しておき、javascript読み込みで非表示にする
    • ローディングとかを入れる時、ローディング自体をすでに出しておきsetTimeOutで消えるみたいな処理にしない(消えなくなる)
    • Googleとかのウェブフォントも極力js読み込みなどを避ける
    • javascriptで動作しないと表示しないテキストをやめる(重要なやつだと特に)
      • text()とかで出来る限り入れない・表示非表示で切り替える。
    • formのバリデーションはブラウザのバリデーションも意識してやる(最低限required付けるとか)
    • WAI-ARIAについても考えておく必要はある
    • javascriptバリバリ使っているサイトだったら最低限の礼儀としてnoscriptタグをちゃんと使おう

結局のところマークアップなりの時点でHTMLの構造をしっかり作れという感じなのですが、デザインでもjavascript使えて当然なリッチなものも多いのでその辺意識しないと結構大変だなと思うようになってます。

まあ結局ケースバイケースでjavascriptやれる部分はjavascriptでやるという部分はやっておき、万一のことはnoscriptなりできっちり表示しといたほうがいいよなと感じます。

というか最近フロントエンド界隈でのフレームワークだのビルドツールだのどうだこうだの話もありますが、まずは根本の話をしませんか、という気持ちがあります。こちらからは以上です。

参考

website-usability.info www.webprofessional.jp

最近考えてる「使いまわせるCSS」について

色々設計思想がありますが

結局のところ、しっかりと定まった案件だったはずが、どこかで「アレがほしいコレがほしい」という継ぎ足しが発生して設計が崩れ去るみたいなことはザラにあるようなので、CSSに期待するということ自体もはや間違ってることなのかもしれない。なので自分はCSSを書く時に極力無駄に広げないようにしている。

個人的に考える使いまわせるやつ

自分の中で考えた方法としては、コンポーネント単位というよりもFLOCSSのUtilitiesみたいなものを用意しておいて必要なものを補填していく、というやり方。以下は例。

1. 要素間の空き・余白について

marginなりpaddingなりがあると思いますが、以下みたいなので調整すればいいんじゃないのかなと思ってる

.mt-10 { margin-top: 10px;}
.mt-100 { margin-top: 100px;}
.pt-10 { padding-top: 10px;}
.pt-100 { padding-top: 100px;}

空きとか余白がある要素にいちいちクラス付与させんのかよ頭おかしいんか?と思われそうだけど、逆にこうした方が急に要素の空きや余白に変動があったときにでも対応できるし、誰が見ても分かりやすいんじゃないかと思う。

2. Modifierについて

btnという要素があってそれの幅が狭い・普通・広いバージョンを作る際にsmallとかdefaultとかlargeとかつけると思うけど逆にその間をものを作る時、命名に困るなどはあると思う(small-x?large-s?とか)。そのくらいだったら以下みたいにいさぎよく設定したい。

.btn-w200 {
 max-width: 200px;
}

もし幅可変のbtnを作るんだったらdisplay: inline-blockみたいに作ってpaddingで横余白とかで調整するというのがあればいいんじゃないだろうか。

3. レイアウトに関しては大枠を作っておく

flexレイアウトにしろclearfixレイアウトにしろ、中にどれくらいの大きさが入っても安心できる外枠をつくるべきかな。clearfixはなんだかんだで愛用できるものだし、flexに関しては基本以下設定でいいんじゃないのかな。あとは中の子要素で調整。

.container {
  display: -webkit-flex;
  display: flex;
  -webkit-flex-wrap: nowrap;
  flex-wrap: nowrap;
  -webkit-align-items: stretch;
  align-items: stretch;
}

IE11のmin-heightバグ問題とかは各自なんとかしてください。

4.命名に困ったときに関して

たとえば似たような色があって機能もそこまで大した差異がないものを命名する時、ECSSのようにそのページのみにしか存在しないものとして作るのが良いかもしれない。黄色系統でも濃いのと薄いのが存在した場合はyellow-01とかyellow-02とかやらない。

.color--works { /* 制作ページでしか使わないカラー */ }
.color--mypage { /* マイページでしか使わないカラー */ }

こういう設計ってそもそもあるんかな

webnaut.jp と思ったらやりたいがほぼ一致しているのがここに書いてた。FLOU設計というそうです。

厳密に言えば僕のはclassの作り方・もたせ方をどうするかーみたいなことなんですけども。

結論

本当はこんなことしてないでスタイルガイドを確立させてそこにモノを落とし込むやり方が100倍良いと思う。お前らはもう少しスタイルガイドに対して意識した方がいい。

実例とか示せればいいかなとも思うのでネタがまとまったらまた何か更新します。こちらからは以上になります。

フロントエンドエンジニアってどんな生き物なのか

f:id:cardboarder:20170226213138j:plain

こないだ他業種(SE)の人と偶然呑む機会があって、自分の同僚が「MEをやってます」って伝えたんだけど「MEってなんですか?」と返されました。

弊社ではマークアップエンジニア=MarkupEngineerの頭文字からそれぞれとってMEと略されて「MEチームの皆さんは何か有りますか」などと聞かれている。この辺は独自文化っぽいので分からなくて当然かなとは思いました。

と「マークアップ」の話をしてみても結局何をやってるのかと聞かれてしまいフロントエンドとバックエンドという部類があって、前者から枝分かれしているのがマークアップエンジニアことMEです、みたいに説明しました。(以下引用)

  1. バックエンドエンジニアとは、単一の環境、つまりサーバ上で仕事をする人のことを指します。彼らは、新しいソフトウェアをインストールしたり、ハードウェアをアップグレードしたりするなど、環境を変更する権限を持ちます。
  2. フロントエンドエンジニアとは、全く異なる数えきれないほどの環境で仕事をする人のことを指します。最新のデスクトップコンピュータから3年落ちのものだったり、メモリが少なく処理に時間がかかるような古い電話だったりと様々です。彼らは、ユーザのブラウザに対して何もすることができないため、その環境を変更することができません。それでも、すべての環境で動作するコードを作る必要があります。

http://postd.cc/front-end-and-back-end

この辺は同じエンジニアという分類で括ってあげることでだいたい理解してくれましたが、たとえば親のような仕事でもパソコンに触れる機会が全くない人間にどう伝えるか、というのが最近悩ましいということがあります。(めんどくさいのでwebサイトを作る仕事やっていますと伝えてます。そんなもんじゃないでしょうか)

いわゆるフロントエンドエンジニアって範囲が広義すぎるから何をもってして従事できているのかが正直分からんのが実際のところで、明確な身分証明みたいなものも免許みたいなものもないので人に説明するのはなんか難しいねという感じです。

あと人によっては見栄などで大した技術もないのにプロのエンジニアですみたいに経歴詐称したりする世界らしいのでそのへんも厳しいです。

逆に言えば自分たちの業種からみたシステム、インフラ、バックエンド側って具体的にどういう仕事してるんだみたいに思う人間が多いんじゃないかとは思う(そもそもデザイナーの業務もあまり分かってないというのはあると思う)。歩み寄りをすることを怠ってはいけないなとは感じます。

久々の更新でしたが特にオチはないです。写真には特に意味はないと思います。

初心者にGit教える時に必要最低限のCUIコマンド

f:id:cardboarder:20170116221632p:plain

前提条件

ガチ初心者でgitの操作をCUIで学ぶため、基本1人でmasterで作業するという「いやお前それGit管理じゃないだろそれ」という前提でやってもらます。いいんだよ細かいのはこれから学んでいけば。

作業前にリポジトリとかはどこかで作って置いたほうがよい(Github、Bitbucket、backlogなど)。

必要なコマンド群

リポジトリのクローン ... gitを使う設定

git clone https://xxxxxxxx/xxxx.git

※この時もしかしたらログインIDやパスワード聞かれるかもだが、気にせず入力してください

作業ファイル全追加 ... 作業したファイルを保存

git add -A

コミットメッセージ ... 何の作業をしたかの記録

git commit -m "commit message"

プッシュ ... サーバーにアップする

git push

プル ... 人が作業した分を同期・ダウンロード

git pull

右のはあくまでもそうした意味ではなく、イメージ。だいたいこれで足りる。自分は足りた。

cloneした後に「作業 → add → commit → push」を基本ローテーションとして作業。

必要に応じて他の初心者を入れて同様に作業させて、pullを理解してもらう。コンフリクト起こしたら、その時は都度修正、コミットなどしてくれ。

基本の骨組みはこのイメージでいいのではないか

実際Gitは様々なコマンドがあったりフローが存在して、いわゆる「ちゃんと理解できたらちゃんと使える」代物とも言われてるので、使いこなすにはある程度知識や経験が伴う。

とはいえ自分がやってきた中では基本このイメージさえできていれば、後はそれに付随する肉付きをしていけばいいんじゃないかと思っている。

たとえば作業でpushまでしたけど実は違ったものが最新になっていたのでそれを直すというのがあった際に、上記コマンドであれば作業後に再びadd、commit、pushなどをする一連の流れがあるわけだが、そのままだと煩雑なコミットログになりかねない(別に慣れる間であれば気にしなくて良いのだが)

そのためにgit revertだったりresetだったりcheckoutというコマンドが調べて出てくるのだが、そうした時に学んでいけばいいんじゃないかとは思う。

それなりに親切なGit

あとGitは丁寧なので、たとえば新しくブランチを切って作業して何も考えずadd、commitしてpushすると「リモートにそんな追従ブランチねーよ」と教えてくれて以下のコマンドを提示してくれます。

git push --set-upstream origin branch

アメリカ語だけど頑張って訳せばそれなりにちゃんと教えてくれてるんだというのがわかる。なので極端に怖がらなくてよいのだ。

極端な言い方をさせてもらえば、やり方次第でなんとかなるのがGitである。

Git教育について知見が欲しい

ウチではこうやってるよ的なのを募集しています。

こちらからは以上です

wordpressの組込みをするときに思うセクショニングの話

みなさんセクショニングマークアップしてますか

f:id:cardboarder:20161226223136p:plain

してない人は正直に手をあげなさい。先生は怒らないので。

最近html5.1の勧告がありましたよねという話で

前置きはどうでもいいんですが、セクショニングでは個人的に気になっている点があります。

【HTML5.1勧告】セクション要素内見出しレベル仕様の変更について | とあるコーダーの備忘録

つまり、どうやら以下の様なことができなくなってしまうとのことです

<body>
<h1>見出し 1</h1>
<section>
<h1>見出し 1</h1>
<h2>見出し 2</h2>
</section>
<section>
<h1>見出し 1</h1>
<h2>見出し 2</h2>
</section>
</body>

いや、もとからそういう書き方はvalidationでエラー吐くよとはありましたが、MDNでは上記書き方が正しいよと載っているんですよ。

見出し要素の順位 (例では、最初のトップレベルセクションのためのh1、サブセクションのh2、および、セカンドトップレベルセクションのためのh3 ) は重要ではないことに注意してください。明確さを失いますし、推奨しませんが、どんな順位でも明確に定義されたセクションでの見出しとして用いることができます。

どっちやねん。

ところかわってwordpress組み込みの話

上記のことを引っ張った上で本題。

wordpressで組み込みがある際にページを作るときは固定ページを元にして作成するなどあるとは思いますが、ニュース記事などの記事作成時にみんなどういう風に捉えているのかということが気になってます。というのも…

記事作成時の「見出し」をどうしているのか

f:id:cardboarder:20161226082959p:plain

wordpressで新規投稿をするときにこのような画面に遷移します。この時に「段落」プルダウンを押すと段落。見出し、整形テキストが選択できるようになります。

この時に見出しを選んでそれぞれ入力してソースを見るとこんな感じで出力されます

f:id:cardboarder:20161226083336p:plain

これと上記HTML5.1のセクション要素の仕様変更と合わせるとまあまあややこしい話ですよねと思います。

つまり大見出しを書く時にh1が存在してしまい、他の部分でh1を使っていると(ロゴとか)セクショニングがややこしい判定になるんじゃないのかということ。

人はそうそうセクショニングを意識できない

今まではこの投稿記事自体にarticle要素なりsection要素で囲めば外とは関係なく使えてたのですが、それが今後効かなくなるとなると元々の組み方を変えねばならんよなーとなってくる。

一番僕が懸念しているのは、運用を非エンジニア職の人に渡してしまうとそこはもう魑魅魍魎と化したブログ記事が出来てしまうわけです(br改行が大量に挟まってたりとかね)。そんなん気にするなよってのはあると思いますが、僕は出来る限りゴミみたいな中身を増やしたくないとは思っている。

かといって人の書き方を制約してしまうというのもあってはならない話だし、この辺の話はブログサービスなりを作っている中の人にどうしているのかを聞くのが一番早いと思う。どっちかというとアメブロとか楽天ブログとかのよりエンジニアとはかけ離れたところの。

現状考えうる問題解決案

と書いてはみたものの現状でうまい回避策は見当たらないです。苦渋の選択として、

よい回避策を募集しております。こちらからは以上です

あと関係ないかもですが投稿画面でタグ自動生成しないやり方もあるようなのでシェア―です

webkikaku.co.jp