CSS Nite公式サイト

CSS Nite LP48「ライティング特集」フォローアップ(3)森田 謙太郎さん(Twitter)

8 years 10ヶ月 ago

2016年10月22日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP48「ライティング特集」のフォローアップとして、森田 謙太郎さん(Twitter)の『インプレッション志向のTwitter活用ワークショップ』セッションのメッセージを公開します。

メッセージ

セッション3「インプレッション志向のTwitter活用ワークショップ」を担当しました森田です。

情報発信・収集のスタイルが大きくシフトし続けており、その受け皿の中心にソーシャルが存在しています。みなさんが今後していく商品・サービスのアピールが、数多ある情報から浮き上がって届いていくために、今回の講演が少しでもお役に立てたようでしたら大変幸いです。

社の都合で、スライドでの事後共有ができず大変申し訳ありませんが、お贈りした本にその内容が詰まっていますので、お時間あるときにぜひ目を通して頂ければ幸いです。また2時間バージョンで定期開催している無料セミナーもぜひご検討ください。出張講演もお気軽にご相談いただければと思います。

みなさんのツイートがTwitterバードに乗って飛んでいく姿は圧巻でした。お聴き頂きありがとうございました!

CSS Nite実行委員会

CSS Nite LP48「ライティング特集」のフォローアップを公開します

8 years 10ヶ月 ago
CSS Nite実行委員会

CSS Nite LP48「ライティング特集」フォローアップ(2)小田順子さん(ことのは本舗)

8 years 10ヶ月 ago

2016年10月22日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP48「ライティング特集」のフォローアップとして、小田順子さん(ことのは本舗)の『その文章、キケンです!』セッションのスライドなどを公開します。

メッセージ

セッション2「その文章、キケンです!」を担当した小田順子です。

私は「文章のモノサシ」というお話をしました。対象は、「事実を正確に伝え、書き手が意図した行動を読み手に起こしてもらうための文章」です。しかし、鷹野さんの質問への回答でもお話したように、言葉はコミュニケーションツールです。不特定多数の相手に伝えるときと、特定の相手に伝えるときとでは、表現の使い分けが必要ですよね。

敬語については、さわりの部分だけをご紹介しました。補足説明として、敬語の解説動画「バカにされない敬語の使い方」をご覧ください。また、『その文章、キケンです!』(http://goo.gl/0Vnidj)をはじめ、私の書いた本にはすべて、敬語の解説がありますので、あわせてご覧いただければ幸いです。

以下、補足説明とご質問・ご意見への回答です。

漢字についての補足 常用外漢字と常用外音訓

たとえば「適宜」など、「宜」を「ギ」と音読みする使い方は常用漢字として認められています。しかし、「宜しく」を「よろしく」と訓読みする使い方は常用外です。つまり、漢字で書かず、ひらがなで書くほうがよいわけです。
このように、「ある読み方のときは使ってよいけれど、その読み方で使うのはNG」という「常用外音訓」というものもあります。これについては、ネット上にあるチェッカーは判断できないようです。
Wordなどの文章作成ソフトでは、ほとんどがチェック可能です。文章作成ソフトは、益子さんのセッションで紹介されていたサジェスト機能のような、校正機能もあります。文章作成には欠かせない便利な機能が満載。ぜひ、活用してください。そんなの、知らなかった! という方は、『その文章、キケンです!』(http://goo.gl/0Vnidj)の第4章「文章の組み立て方と校正方法」を読んでみてくださいね。

参考サイト

常用漢字表(平成22年内閣告示第2号) (文化庁のサイト)
http://kokugo.bunka.go.jp/kokugo_nihongo/joho/kijun/naikaku/kanji/

質問・意見への回答

士業や役所のサイトを作っているが、文章が難解で、硬い。
それをどう伝えたらよいか困っている。

士業の方も、お客様のためにサイトを作っていると思います。お客様に伝わることは大切ですよね。役所も当然、伝わるように努力することが責務です。
士業や役所のサイトを作っている方は、ぜひ、私の書いた以下の本を「これ、役に立ちますよ!」とお勧めするか、プレゼントしてあげてください。

  • 『お客様が集まる!士業のための文章術』(翔泳社)(http://amzn.to/1gMCQal
  • 『これで怖くない!公務員のクレーム対応術』(学陽書房)(http://amzn.to/LSHVzw
  • 『誰も教えてくれなかった 公務員の文章・メール術』(学陽書房)(http://amzn.to/j5bDZB

常用漢字は政府資料だけ守ればいいと思う。一般人は状況により使うべき。

確かに、状況や目的に合わせて使うべきだと思います。

たとえば「薔薇」と書くのか、「バラ」なのか。「薔薇」が読める人だけをターゲットとして、商品やサービスを売りたいときは、常用外漢字であっても使う必要があるでしょう。逆に、「薔薇」が読めない人にも正確に、効率的に理解してもらいたいときは、「バラ」と書いたほうがよいわけです。

ちなみに、報道機関や出版社などは、各社に独自の表記のルールがありますが、基本的には常用漢字を使うようルール化しています。

ワークの文章で、商品券を終了することに対して、店舗側のお詫びや説明は不要か?
「え? 終わっちゃうの?」といったお客様の心情に配慮が必要では。

鋭いご指摘!
今回のセッションではお話しできませんでしたが、お客様とのコミュニケーションという意味では、ご指摘のような配慮が必要な場面もあります。

もし、急にサービスを終了することになったのであれば、「3月31日(土)です」の後に、「これは、○○のためです」と理由を書きます。さらにおわびの言葉を添えたほうが良いですね。理由やおわびを書くと文章が長くなりますが、不特定多数に向けた文章の場合、やはり1文を短くするよう心がけると伝わりやすくなります。

お知らせというよりおわびをすべきケースは、『その文章、キケンです!』(http://goo.gl/0Vnidj)の第2章「クレーム・不祥事への対応」でご紹介しています。ご興味があればご覧ください。

ちなみに、「詫び」は常用外の漢字です。

「致します」「宜しく」など漢字率が異常に高いメールをもらうことが多く、気になる。
相手にやわらかく伝えるのに、良い方法はあるか。

「相手にやわらかく伝える」というのは、「あなたは漢字を使いすぎですよ、ということを伝える」という理解でよろしいでしょうか。

そうであれば、なかなか難しいですね。相手との関係性次第ですが、たとえば私の話した内容を、以下のような方法で紹介するのはどうでしょうか。

  • 私のセッション動画が一般公開されたら、「このセミナー、役に立ったので、お時間のあるときにご覧ください」とお勧めする
  • 「この本、とても役に立ったので」と、『その文章、キケンです!』(http://goo.gl/0Vnidj)や『言いたいことが確実に伝わる メールの書き方』(http://amzn.to/gktG2C)をプレゼントする

つまり、私のせいにして、私に語らせるという方法です。この手を使っている方は、結構いらっしゃいますよ(笑)

「頂く」を文中に2回以上使うような場合の表現や書き換えを聞きたい

確かに、「いただく」が2回以上続く場合、文章も長くなり、回りくどい印象になりますね。
一番多いのは、次のような「させていただく」ではないでしょうか。

  • お送りいただいた書類を拝見させていただきましたが、
  • お送りいただいた書類を拝見しましたが、
  • ご指摘いただいた部分を修正させていただきました
  • ご指摘の部分を修正いたしました

このように、「させていただく」は、ほとんどの場合、削除してしまって問題ありません。
また、相手の動作が複数回続くときに、それぞれ「いただく」をつけると、次の例のようになりますね。

  • 必要事項をご記入いただき、署名・捺印していただき、ご返送いただけますでしょうか
  • 必要事項を記入して、署名・押印の上、ご返送いただけますでしょうか

このように、「いただく」は最後の動作だけにつけると繰り返さずに済みます。あとは短く書き、「、」や「て、」でつなぐと、すべての動作が「していただく」に係(かか)ることが伝わります。
また、箇条書きにするという方法もあります。

  • 以下のご対応をお願いできますでしょうか。
    • 必要事項の記入
    • 署名
    • 押印
    • 返送

ちなみに、「捺印」の「捺」は常用外漢字なので、「押印」と書き換えました。

以上、少しでもお役に立つことができればうれしく思います。
また、いつかどこかでお会いしましょう!

CSS Nite実行委員会

CSS Nite LP48「ライティング特集」フォローアップ(4)小川晶子さん(さむらいコピーライティング)

8 years 10ヶ月 ago

2016年10月22日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP48「ライティング特集」のフォローアップとして、小川晶子さん(さむらいコピーライティング)の『選ばれる、ファンを増やす プロフィールの書き方』セッションのスライドなどを公開します。

メッセージ

セッション4「選ばれる、ファンを増やすプロフィールの書き方」を担当した小川です。
ビジネスでいい効果が生まれるプロフィールを書くため、自分自身・お客様・競合について知ろうというお話をしました。ワークショップはその本当にさわりの部分でしたが、ぜひあらためて時間をとってやってみてくださいね。

自分自身に対して客観的になるのは本当に難しいものです。いきなり文章を書き始めると、どうしても主観的に書きたいことを書いてしまいます。最初の森田哲生さんのセッションの中にも、「いったん要素を書き出して並べてみることが大切」というお話がありました。わかっている、当たり前に感じていることであっても、一度外に出して目で見てみると発見がありますし、客観的になることができます。

以下、いただいたご質問に回答します。

Q. ワークショップでやったインタビューは、プロフィールにどう活かせばいい?

まず、自分自身についての要素をいったん洗い出し、客観的に見つめるために使うということ。それから、過去から未来に向かっての方向性を感じられるストーリー作りにとくに役立てることができます。

強みが見つかりやすい質問ということで50個にまとめたものは『ファン倍増!単価アップ!プロフィール作成術』(Kindle)の中でご紹介していますので、ご興味があればぜひご覧ください。

Q. 商品に置き換えて考える場合、インタビューできないがどうすればいい?

商品を知るステップとしては、特徴・スペック・商品に込められた想い(開発背景)等をいったんすべて洗い出し、書き出します。商品に想いがあるほど、その想いばかりを打ち出しそうになりますが、お客様と競合についてもしっかり調べたり考えたりすることでいい表現ができるようになります。

Q. 実績の部分で鼻につくような書き方をしているものを多く見るが、共感を得るには?

なるべく具体的な数字や固有名詞を使って、客観的に事実を伝える表現をすれば鼻につくような感じにはならないかと思います。

たとえば、お客様の数を実績として伝えるときに

  • 多くの→1,000名以上の
  • あらゆる職業の→(具体的に考えてみると)→経営者、士業、コーチ、カウンセラー、コンサルタント等

というように具体化します。

そして、方向性を感じるストーリーや夢・ビジョン・ミッション等で共感を得るようにします。プライベートを表す一文で親しみを感じさせるのもおすすめです。

またいつか、どこかでお会いできるのを楽しみにしております!

CSS Nite実行委員会

CSS Nite LP48「ライティング特集」フォローアップ(1)森田 哲生さん(Rockaku)

8 years 10ヶ月 ago

2016年10月22日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP48「ライティング特集」のフォローアップとして、森田 哲生さん(Rockaku)の『特講!書かなきゃいけない人のための「見出し」教室』セッションのスライドなどを公開します。

メッセージ

LP48セッション1『特講!書かなきゃいけない人のための「見出し」教室』を担当させていただいた森田哲生です。

ライティングだけのセッションに、これだけ多くの方が、こんなにも積極的にご参加されているということに正直驚きました。正に「書かなきゃいけない人」の時代がやってきているのだなと再認識した次第です。

セッションでも触れましたが、「上手く書けない」「書くことが苦手」とおっしゃる人の中には、「とりあえず書いてしまう人」が多いように感じています。
「書く前に並べる」「書く前に置く」という視点から、下準備を整える習慣をつけていただけると、この実態がつかみにくい苦手意識を克服していく鍵がつかめるのではないかと思っています。

書くことは本来とても楽しいことです。また、あらゆるコミュニケーションを根本から強くする、エッセンシャルなスキルだと思います。今回の僕のセッションや、他の講師のみなさんのセッションもしっかり吸収して、「書かなきゃいけない人」であることを、より実りあるものへと変えていっていただければ幸いです。

今回のセッションをさらに深く理解したいという方には、ASCII WEB PROFESSIONAL連載時の記事や、書籍『書かなきゃいけない人のためのWebコピーライティング教室』もおすすめです。ぜひご一読ください。

CSS Nite実行委員会

CSS Nite LP48「ライティング特集」フォローアップ(5)益子 貴寛さん(まぼろし)

8 years 10ヶ月 ago

2016年10月22日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP48「ライティング特集」のフォローアップとして、益子 貴寛さん(まぼろし)の『Google Driveを使った原稿の共有とリアルタイム赤入れ』セッションのスライドなどを公開します。

メッセージ

セッション5「Google Driveを使った原稿の共有とリアルタイム赤入れ」を担当した、益子貴寛です。

すべてのセッションにワークが用意されていたのは、CSS Nite LP史上はじめてだったかもと思いつつ、みなさんがどのワークにも熱心に取り組む姿、近くの方と楽しそうに話す姿が、とても印象に残っています。

アンケートで、Microsoft Officeの機能についていくつか質問をいただきましたが、Office 365 Businessを年間契約で使っているものの、クライアント企業からのWord、Excel、PowerPointファイルを開く目的でしか使っていないため、詳しいことはまったく知らないということで、ご容赦いただければ幸いです。

みなさんと一緒に、ライターとしても、プロジェクトマネージャーとしても、もっともっと成長できればと願っています。

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」のフォローアップを公開します

9 years ago
CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(1)サトウ ハルミさん(FLAT)、酒井 優さん(WEBCRE8)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、サトウ ハルミさん(FLAT)、酒井 優さん(WEBCRE8)の『コーダー白書 2016』セッションのスライドなどを公開します。

セッション1「コーダー白書」を担当しました、FLATサトウ・WEBCRE8酒井です。

土曜日は長時間お疲れ様でした。各セッションとも充実して刺激的な一日でした。

LP47お申込みの際にいただいたアンケートでは、ほぼ100%の方が答えてくださり、

皆様のご協力があって、実現できたコーダー白書でした。改めて御礼申し上げます!

アンケートの集計中にリアルな数字が見えてきて、私達も楽しみながら企画を作っていきました。

以下、アンケートでいただいた質問への回答です。

マークアップエンジニアの給与の安さ

全アンケートデータに職業別の平均年収をまとめました。

男女の平均は職業の平均が大きく反映されています。

  • マークアップエンジニア平均年収 385.2万円
  • デザイナ平均年収 492.5万円
  • フロントエンドエンジニア平均年収 500.8万円
  • プログラマー平均年収 721.4万円

マークアップエンジニアとフロントエンドエンジニアとはなんなのか

個人的な知識と分析に基づく見解になってしまいますが、これは要は求人用語です。そもそもマークアップエンジニアとは現在多くの人が思っているであろう「HTMLとCSSができる人」というような職業ではなく、もっと幅広い職域を想定して考えられた職種でした。

マークアップ・エンジニアのTips - 第1回 マークアップ・エンジニアって何?:ITpro - http://itpro.nikkeibp.co.jp/article/COLUMN/20080529/304737/

しかし業界が成長するに従ってこの職種を募集する会社は増え、求められる役割は細分化されてきました。このためマークアップエンジニアという募集で集まる人のスキルと企業のニーズが必ずしも一致しなくなってきたのではないかと推測できます。そのうち、JSを中心としたスキルを持つ人材に焦点を絞った職種としてフロントエンドエンジニアというものが生まれたのではないでしょうか。

年収に開きがあることや実際に多めの給料をもらっている方たちがフロントエンドと名乗っているのも、そういうスキルを求めて採用された方たちがそういう職種を与えられているからであると考えられるでしょう。

もう一歩踏み込んでほしかった、原因理由をもっと知りたかった

発表時間が時間が短いということもあったのですが、このセッションは他のセッションへのイントロダクションという位置づけでもあったため、アンケートでは情報としては浅くてもなるべく広めの情報を拾っているということをお知らせしたかったというのが私達の狙いです。とはいえ、各項目についてもう少し軸を増やして深掘りできればよかったというのは反省点でもあります。

今回、技術に関する質問で特に示唆が得られたと感じられたところは、各ツールの普及状況です。全体としては意外と普及していないような数字の出たツールも、コーダー、デザイナーに分けてみるとコーダーには浸透していて、それ以外の人にはそうでもないという結果が目立ちました。また、フロントエンドエンジニアを名乗る人のほうが全体的に高度なツールを使いこなしていたりしています。さらに言えば、「マークアップ」という領分にあるWAI-ARIAのようなものですら、使用者はフロントエンドエンジニアに偏り気味でありました。せっかくマークアップを名乗っているのならマークアップのスペシャリストを目指したいなと私自身感じました。

Sass、レスポンシブデザイン、SVGといった技術はコーダーの中では当たり前になっているため今まだ触ったことがないという人は少し焦るかもしれません。反対に、コーダーではない人で経験をしている人は今後さらに求められる人材になるかもしれないでしょう。こういった数値を自身の学習の火付けに使うのも有用であると考えます。

その他データはある程度揃っているので、皆さんで仮説を立ててデータを読むのも面白いはずです。

ペルソナがわかりやすい

ありがとうございます!今回は男女のペルソナを作りましたが、
コーダー・エンジニア・デザイナーと職業別のペルソナというのも作ってみたい…と構想が膨らみます。

引き続き毎回やってほしいです。

毎年技術や検証環境など比較したら、興味深いデータが出そうですね。

1-2年後のWeb制作はどうなっているか予想をまとめて、実際そのようになったか検証もしてみたいです。

コーダー白書について、ご要望があればTwitterで是非お知らせください!

サトウハルミ @uzu / 酒井優 @glatyou

#登壇スライド、全アンケートデータ

#コーダー白書 参考リンク

EditorConfig参考URL

http://editorconfig.org/

Popular Coding Convention on Github

http://sideeffect.kr/popularconvention#javascript

The W3C Markup Validation Service

https://validator.w3.org/

Web Content Accessibility Guidelines (WCAG) 2.0

http://waic.jp/docs/WCAG20/Overview.html

実装チェックリストの例 2012年11月版

http://waic.jp/docs/jis2010/test-guidelines/201211/icl-index.html

Top 5 Desktop, Tablet & Console Browsers in Japan from Aug 2015 to Aug 2016 | StatCounter Global Stats

http://gs.statcounter.com/#browser-JP-monthly-201508-201608

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(8)高津戸 壮さん(ピクセルグリッド)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、高津戸 壮さん(ピクセルグリッド)の『Enduring CSS』セッションのスライドなどを公開します。

セッション8「Enduring CSS」を担当したピクセルグリッドの高津戸です。長時間のイベントでしたが、ご清聴くださり、ありがとうございました。

アンケートにて頂いた質問にご回答いたします。

サイト全体でデザインを統一したい時向かなそう

これについてはその通りだと思います。私も、コーポレートサイトを作る場合、サイト全体で共通のモジュールをデザインし、そのモジュールを使いまわして多くのページを量産するというような方法を採用してきたことがほとんどでした。このような場合、サイト全体で共通のモジュールが多くなるため、名前空間で明確に分けるというのは難しいように思えます。

一応、ECSS書籍の中では、サイト全体で横断して使われるようなモジュールには、sw-(SiteWide)という名前空間を用意し、この名前空間に属させるというような例が紹介されています。しかし同時に、この名前空間に属するモジュールが多すぎると、やはり後でモジュールを変更したり、消したりするのは難しくなるため、ECSSのやりたいことを実現できなくなってしまう故、塩梅を考えよとのアドバイスも同時に書かれています。

結局のところ、サイトをどのように運用していくかという点について考えた時、長い運用に耐えられるという点に最も重きを置いて考えられたのがECSSであり、どのような場合においても、常にベストな答えというわけでは無いでしょう。全てECSSのとおりにする必要は全くありませんので、自分のプロジェクトには向いているのか向いていないのかを判断し、良さそうであれば、部分的にでも、採用してみると良いのではないでしょうか。

ECSSにぴったりマッチさせるには、Webサイトのデザイン自体も、それとなくECSSの思想に寄せて作られているような状態にする必要があるかもしれません。

メンテナンスのときに漏れが発生しそう

同じようなモジュールでも、別のCSSで書かれているという考えが基本となるため、例えば「このデザイン見出しの文字サイズを変えたい」と思った時、何箇所もCSSを編集する必要が出てくるというケースはあるでしょう。これについては、分けて考えるというECSSが取った選択のデメリットと言って良いかと思います。前述したように、そういったモジュールを、全体で共通のモジュールとして考えるのも一つの答えです。

bodyにidを振っていたけれどそれをクラスの頭につける感じでしょうか?

セッション内で挙げたのは、テンプレートごとに別の名前空間を用意するという例でした。この例においては、そのようなイメージと近いものと考えて良いかと思います。

ただ、名前空間の切り方は自由なので、ページ毎という縛りにとらわれる必要は無く、そこはサイトに合わせて自分で設計して問題無い部分です。

CSSを分けるとリクエストが増えて高速化の観点からすると心配

分けて考えるとお伝えしましたが、最終的にブラウザが読むCSSのファイルを、名前空間の数だけ用意するというわけではありません。ECSSでは、CSSの管理は何らかのビルドツールを使って行うことを推奨しており、書籍の中では、postCSSを使ったgulpのセットアップ例が紹介されています。

あえて分けたいという箇所については、そのように名前空間でまとめたCSSファイルを用意しても良いかと思います。ですが、基本的には、gulpなりでCSSはいくつかのファイルにまとめてしまい、gzipするというのが推奨される方法のようです。

ベース部分の設定についてはSMACSSなどの分け方と共存するかんじでしょうか

この点については、とりたててECSS内では触れられていませんが、必要に応じてnormalize.cssや最小限のreset.cssを読み込むと良いであろうと書かれています。

http://ecss.io/chapter5.html

ビルドを頑張らねばならないというのはどういうことか?

ECSSでは名前空間でモジュールをグルーピングし、名前空間ごとにCSSや画像、JSをまとめることとなります。HTMLではこれらを全て個別に読み込むわけではなく、一つのファイルにまとめてしまい、それを読み込ませるのが、前述した高速化の視点からは望ましいでしょう。

これを行うには、gulp等のビルドツールを用いる必要が出てきます。つまるところ、全体で一つのCSSに全部かいてしまうという方法をやめ、名前空間ごとに分けて管理しようというやり方を選んだのがECSSなので、この分けたファイルらをまとめたり何なりしたい場合、ビルドするという工程は必要になってきます。

CodeGrid、記事単位で売ってくれると嬉しいかも

これは宣伝となりますが、本セッションで紹介した内容をもうちょっと深掘りした記事が、弊社サービス、CodeGridでお読みいただけます。

https://app.codegrid.net/series/2016-ecss

CodeGridは今のところ月額制の支払い方法を基本としており、記事単位での販売は行っておりません。すみません!しかしながら、ご要望は開発の方にフィードバックさせていただきます。初月は無料ですので、気になる方はご購読頂けると幸いです。

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(9)西畑 一馬さん(トゥーアール)、小林信次さん(まぼろし)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、西畑 一馬さん(トゥーアール)、小林信次さん(まぼろし)の『フロントエンドからのテクニカルディレクション』セッションのスライドなどを公開します。

セッション9「フロントエンドからのテクニカルディレクション」を担当したまぼろしの小林です。
長丁場のイベントでセッション数も多く、頭の切り替えなど大変だったと思います。
お疲れさまでした。

以下、いただいたご質問への回答です。

クライアントなど、プロジェクトに関わる全ての人がハイレベルでないと実現不可能なのではないか?

確かにクライアントにまでGitの利用方法や、正しいタスク管理ツールの使い方を理解いただくのは難しい場合もあります。
いきなりパーエフェクトな進行を実現するのではなく、まずはメールの利用を禁止にしてみる、制作現場内だけでもタスクランナーを使ってみるなど、小さなことからはじめてみるのはいかがでしょうか。
実際、弊社においても理想通りの体制を整えられるプロジェクトは希少です。

見積もりで迷ったらどうした良いのか?

まず、正確に見積もることが困難であるということを(よくある追加要件などの具体例をまじえて)事前にクライアントに伝えるようにしています。
ひとまずザックリとこのくらいですが詳細が見えてきた段階で調整しましょう、と伝えれば、その段階でそんな曖昧な回答ではダメだと言われたことはありません。

会社のディレクターに聞かせたい、動画撮影してませんよね?

スライド/動画ともに後日共有されますので、是非皆さんで見てください!

同じく、セッション9を担当したトゥーアールの西畑です。最後のセッションまで清聴いただきありがとうございました。

弊社もまぼろしと同じく受託制作をメインで行っている制作会社のため、大手や中小のさまざまなクライアントさんとお仕事をします。セッションでお話したような理想的な進め方の案件もあれば、理想とはかけ離れた案件も多くあります。

クライアントさんにもよりますが、理想に近づけるため最初のタイミングで以下のような質問ベースで誘導していくなどを行なってます。「ファイルのバージョン管理は普段どうされていますか?Gitを使われているようでしたらリポジトリを教えてください。リポジトリの準備が難しいようでしたらこちらでも用意できますのでー」

お見積に関しては、仕様が曖昧な場合はお見積から溢れた場合にどうするかの会話をお見積を行う前にしていますが、お見積にバッファを詰んでおきバッファ分が余ったら減額して請求、バッファが足らなくなりそうな場合は早めにアラートというのが多い感じです。仕様が確定している場合でも仕様変更がどれくらいありそうか、変更時には追加見積もりができるかをなどを確認しております。

セッションで伝えた内容を全部実現するのは難しいですが、まずはクライアントさんとの距離を縮めることを目標にがんばってみてはいかがでしょうか?

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(7)山田 敬美さん(ピクセルグリッド)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、山田 敬美さん(ピクセルグリッド)の『モダン日本語フォント指定』セッションのスライドなどを公開します。

CSS Nite LP47に参加いただきましたみなさまありがとうございました。
「モダン日本語フォント指定」でお話させていただきました、ピクセルグリッドの山田(@tacamy)です。

游ゴシックのウエイト問題については、ブログ記事で様々な情報が飛び交い、何が正解なのか混乱していた方も多かったのではないでしょうか。いろんな記事を目にするたびに、うーん?と思うことが何度かあり、さらにそういった記事が拡散されてたりしてモヤモヤしていたので、今回お話しさせていただこうと思いました。

セッションの内容を理解していただくことで、「この指定だとここで問題が出るな、この説明はちょっと違うかな」など、ご自身で判断ができるようになったのではないでしょうか。

最初に「脱コピペ」と言ったのは、オチのためのフリというわけでなく、原理を知ることで、様々な情報に振り回されずに、自分で判断できるようになってもらうことを目的としたかったためです。

このフォローアップを書いていて、この感覚は料理と少し似ているような気がしてきました。初心者はWeb上のレシピが正しいのかどうかが判断できませんが、普段から料理をしている人は、自分のこれまでの経験をもとに、これはおいしくないレシピだと判断できたり、元のレシピに変更を加えておいしくできたり……と脱線してきたので、アンケートの質問にお答えしたいと思います。

明朝はどうすればいいのか

「漢はだまってserif」としたいところですが、游明朝を使いたいということでしたら、游ゴシックと同様にウエイトの問題の差はありますが、游ゴシックと違ってWindowsの場合、10でもMediumはありません。

  • Windows
    - YuMincho-Regular
    - YuMincho-Demibold
    - YuMincho-Light
  • OS X
    - YuMin-Demibold
    - YuMin-Medium

そのため、もしRegularウエイトでは細いとなった場合は、Windowsにおいては別のフォントを使うしか選択肢はなさそうです。

sans-serifについての説明がもう少し欲しかった

sans-serifを指定すると、ブラウザのデフォルトのフォント(ゴシック体)が使われます。それがOSやブラウザによって異なるので、制作者はフォントを指定してコントロールしようとします。
ただ、ユーザーからすると普段使っているブラウザの標準フォントが一番馴染みのある読みやすいフォントだと思いますし、もしそのデフォルトフォントが気に入らなければ、ブラウザの設定で自分好みのフォントに変更しているかもしれません。
サイト側でフォント指定をするということは、そのユーザーの好みのフォントを否定し、こちらの意図するフォントを押し付けることにもなります。
そういう理由もあって、個人的にはsans-serifが一番よいのではと考えています。
ただ、フォントも含めてサイトの印象の一部となるので、難しいところですね。
WindowsのFirefoxとChromeの日本語のデフォルトフォントがMS Pゴシックで、デザイン的にあまりにも残念な見た目になってしまうのが問題なのでしょうね。Windowsさえどうにかなれば……。

各OSが違うフォントしか持ってない以上、ムリに同じものにしなくてもいいかなと

私も同意見です。サイト側でフォントが指定されているとちょっとイラっとします。
ただ、仕事でマークアップをする以上、個人の思想とクライアントやデザイナーの要望が一致するとは限らず、どうしても游ゴシックにしてほしいと言われる場面もあるでしょう。そして細すぎるのでどうにかしてほしいとも。
マークアップ・エンジニアとして、そういった要望を実現する方法を知識として持っておくことと、個人の思想はまた別なのかなと割り切っています。

レスポンシブの際のフォントファミリー指定で注意しておくことはありますか?

レスポンシブだから、というわけではないですが、ある程度の主要なOSやブラウザを考慮して、どの環境から見ても違和感のないフォント指定をしておくべきかなと思います。
それよりもレスポンシブの場合は、フォントサイズの指定の方に気を配る必要がありそうです。
remやemを使った指定の他にも、vwという画面幅を基準としたサイズ指定をfont-sizeに指定するなどの方法も場合によっては必要になるかもしれません。
CodeGridにも「レスポンシブデザインにおけるテキストのコントロール」というシリーズがありますので、気になる方は読んでみてください。
https://app.codegrid.net/entry/responsive-text-1

英名のみでOKなブラウザは明確にどこから?

すみませんが具体的なバージョンについては把握できていないのですが、現在主流なサポートブラウザであるIE11、Edge、Chrome、Safari、Firefoxの最新版であれば問題ありません。

@font-faceは全ブラウザ、環境で使用可能?

IEは9+で使用可能で、その他のブラウザもほぼ対応しています。
http://caniuse.com/#feat=fontface

OS Xでメイリオが入っている場合、Winでヒラギノが入っている場合はどうなるのか気になりました

OS Xでメイリオというのは、Officeを入れているケースを考えるとそこそこありそうなので考慮の優先度は高めですが、Windowsでヒラギノが入っているケースは限定的だと思うので、優先度は低めかなと考えました。
そこまで対応するとなるとすれば、JSでOS別にクラス名を振って、それぞれ個別のfont-family指定をするしかないのかなと思いますが、そこまでするかどうかは判断の迷うところですね。

ちなみに、今回紹介したサンプルではそれぞれ次のようになります。

「最新のシステムフォントに寄せる」

html {
font-family:
-apple-system, /* OS X, iOS San Francisco */
BlinkMacSystemFont, /* OS X, iOS Chrome San Francisco */
"Hiragino Kaku Gothic ProN", /* OS X, iOS ヒラギノ */
MyYuGothicM, /* Windows 游ゴシック */
Meiryo, /* Windows メイリオ */
sans-serif;
}
  • OS Xでメイリオが入っている場合 : ヒラギノが優先されるので影響なし
  • Winでヒラギノが入っている場合 : ヒラギノが適用される(かもしれない※)

「游ゴシックメインの指定」

html {
font-family:
MyYuGothicM, /* Windows 游ゴシック */
YuGothic, /* OS X 游ゴシック */
-apple-system, /* iOS San Francisco */
BlinkMacSystemFont, /* iOS Chrome San Francisco */
"Hiragino Kaku Gothic ProN", /* OS X, iOS ヒラギノ */
Meiryo, /* Windows メイリオ */
sans-serif;
}
  • OS Xでメイリオが入っている場合 : 游ゴシックかヒラギノが優先されるので影響な
  • Winでヒラギノが入っている場合 : 游ゴシックが入っていない環境であればヒラギノが適用される(かもしれない※)

※Windowsにヒラギノをインストールするには、ライセンス的にヒラギノフォントを購入しなければならず、Windows用のヒラギノを持っていないので正確にはわかりませんが、もしそのヒラギノのフォントファミリー名がOS Xと同じ名前であればヒラギノが適用されます。なお、OS Xからヒラギノを抜いてWindowsに入れるのはライセンス違反のようです。

「フォントのメタデータの中のnameテーブルを確認する」と言われていたと思うのですが、どうやってここまで深く勉強されたのかすごく気になりました(たとえば仕様書とか参考資料とか)

正直に言うと、私自身、そんなにフォントについての知識がなく、この結論が出るまでに悪戦苦闘しました。
フォントにnameテーブルがあるということは、同僚に教えてもらったのですが、@font-faceでnameテーブルのどの値が使われるなどは色々と試してみたりして、かなりの時間を費やしました。
最終的に仕様書を読んだらPostscript名が使われるということが書いてあり、最初から仕様書を読めばよかったと思いました。

メイリオで斜体が表現されないので困っている

日本語の斜体が読みやすいかどうかはさておき、斜体にしたい部分だけ別のフォントを指定するなどしか方法がなさそうです。
なお、@font-faceではfont-weightだけでなく、font-styleも指定できるので、font-style: italic;のときのみ別フォントを適用するオリジナルのMyMeiryoのようなフォントファミリーをつくってみてもいいかもしれませんね。

海外だとどういう指定が流行ってるのか知りたい

私も詳しくはないのですが、海外の場合は、文字数も少ないのでWebフォントも気軽に使われていそうな印象です。

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(6)小山田 晃浩さん(ピクセルグリッド)、坂巻 翔大郎さん(ピクセルグリッド)、赤塚妙子さん(esa)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、小山田 晃浩さん(ピクセルグリッド)、坂巻 翔大郎さん(ピクセルグリッド)、赤塚妙子さん(esa)の『esa.ioのBootstrap利用とCSSリファクタリング』セッションのスライドなどを公開します。

「esa.ioのBootstrap利用とCSSリファクタリング」で共有した内容、いかがでしたでしょうか?

Webサービスでの例ということで、少し特殊だったかもしれませんが、皆さんのお仕事に活かせるであろう内容も色々あったと考えています。

  • 共通言語としてのBootstrapが解決したこと
  • 必要以上なツールは不要
  • CSSリファクタリングで解決した内容
  • リファクタリングの進め方の参考例

特に、「CSSリファクタリングで解決した内容」でご紹介した

  • 詳細度のを低く一定にする
  • コンポーネントの粒度

は、普段CSSを書く際に注意するポイントであり、
リファクタリングのタイミングでなく、最初からCSSを書く場合においても大切で、
これらがいいCSSを書くためのポイントとも考えています。

ぜひ、ツールを活かし、いいCSSを書いてみてください。
私達のセッション内容が少しでも皆さんの日々のお仕事への参考になれば幸いです。

以下は、アンケートにあった質問への回答です。

見積もり方法について教えてください

CSSコンサルティングを行う際の見積もりですが、今回が初めての試みだったため、まず最初に打ち合わせをしました。その中で、ピクセルグリッドは「コードレビューや相談が主で、実装はしない」という取り決めを行いました。基本的には、週に半日分ぐらいの稼働目安で始めて見る事となりました。

Bootstrapとの競合はあったのか、またその解決方法は?

競合がないように、共存をすることを選ぶのがよいと考えています。
そのためにコードを見直し(リファクタリング)クラス名などBootstrapと同じにならないように
しっかり再検討することが解決方法です。

高津戸がお話したESCSSの考え方も、競合しないCSSを書くためには有効です。

リファクタリングが生む価値はなんでしょうか?

CSSは、書き方が決まっておらず、とても難しいといえます。
その為、書き方ばバラバラになったり、時には表示速度に影響することもあります。

リファクタリングをすることで、CSSはもちろん、HTML(テンプレート)の管理のしやすさ、
つまりメンテナンスのしやすさに影響すると考えています。

リファクタリングをすることは、メンテナンスのしやすさ、パフォーマンス(速度)などを改善することができ、Webサイト、アプリケーションの寿命を延ばすために価値があるといえます。

また、esaの場合の考え方ですが、UIや機能を自分たちで試行錯誤しながら作っていったWebアプリケーションということもあり、普段からCSSも何度も書き直しつつ開発を進めています。
最初からベストなUIデザインやCSSを書くことを目標とせず、より良い方法を発見するたびに日々少しずつ改善していけるのが良いと考えています。

身軽にいつでもCSSを書き直せる状態を保つには、土台となる部分がある程度整理されていることが必要になりますが、Webアプリケーションが大きくなってきて年月が経ってくると、長い紐同士が絡まり合ってほどきにくくなるように、CSSも複雑化してきてしまい《いじりにくい》状態になってきてしまいます。
今回esaが行った大きなCSSリファクタリングは、その CSSを《いじりにくい》状態を解消して、絡まりあった紐がほどけた状態にし、いつでもCSSやUIを身軽に改善しやすい状態を保つということを目標としました。

リファクタリングの際に注意したポイントは?

実際に多くのユーザーが既に使って下さっているWebアプリケーションなので、リファクタリングで崩れる箇所がないかどうかの動作確認は、サーバサイドのエンジニアにも協力してもらい慎重に行っています。
この確認作業が結構大変で負担がかかり、また開発中の部分とのコンフリクトも起きやすいので、開発を比較的活発に進めているような時期にCSSリファクタリングをするのは避けるようにしています。

カスタマイズのコツは?

コード面では、なるべく _variables.scss 内の変数を上書きしていくという方法で進めていくのがおすすめです。
私(赤塚)の場合ですが、https://github.com/twbs/bootstrap-sass/blob/master/assets/stylesheets/bootstrap/¥variables.scss の中身をまず全部コピーした _variables.scss というファイルをimportし、そのファイルの中身を最初全てコメントアウトして、カスタマイズする部分のみ行コメントを外して上書きして使っています。このやり方だと、_variables.scss の中身をテキスト検索すれば目標の変数を探すことができ、またBootstrap関連の上書きが1ファイルにまとまるので便利です。

また、Sassファイルのimport順ですが、少し注意が必要になります。

@import variables;@import bootstrap;

上記のように、_variables.scss の方を、Bootstrap本体よりも先にimportします。そのようにすることで、こちらで上書きした変数を使用した状態でBootstrapのCSSがコンパイルされます。(逆の読み込み順にするとvariablesは使われない状態でBootstrapが実行されてしまいます)
変数を先に読むのになぜ上書きされるのか?と疑問に思われる方もいるかもしれませんが、Bootstrap本体のSassの変数には下記のように末尾に全て !defaultがついている点がポイントです。

$brand-success: #5cb85c !default;

このように、末尾に!defaultがついた状態で定義された変数は、同じ変数を定義している箇所が他にあれば、読み込み順の前後に関わらず、!default がついたもの以外 を優先するようになります。なので、上に書いても変数の上書きができるのです。

デザイン面でのカスタマイズのコツですが、まずはBootstrapのデザインにとらわれないで、そのサイトやアプリケーションにとって最適なデザインをした上で、使えるところにはBootstrapを使うくらいの感じで行うと良いでしょう。

見た目が Bootstrapっぽくならないようにするにはいくつかポイントがあります。
例えば、Bootstrapには色んな色のボタンが用意されており、つい色んな色を無意味に使いたくなってしまうのですが、ボタンの色の使い方に基本的なルールをきちんと定めておくというのもコツの1つです。

私(赤塚)は、下記のような基本ルールでやっています。

.btn-primary: そのページでの通常、メインの動作系に使うボタン.btn-default:  .btn-primary よりも相対的に弱いボタン.btn-warning: 少しイレギュラーな動作に使うボタン(新規作成系が多い).btn-danger:

削除等の危険な動作に使うボタン(赤くて目立つので設定画面等の奥まった場所でしか利用しない)
1つのページ内に.btn-primary は原則1個以内
単純なページ遷移はなるべくボタンではなくリンクにする
杓子定規に全てルールを守るのが必ずしもベストではなく、その時々でバランスを見てベストなデザインにしていくのが良いと思いますが、基本的なルールが決まっているとデザイナー自身も、協業するエンジニア等もその後の展開がしやすく楽になり、統一感のある使いやすいサービスに育ってくると思います。

Aigis(スタイルガイドジェネレーター)について気になります

プロジェクト専用にコンポーネント集(フレームワーク)を作ることがあります。
その際、ピクセルグリッドでは、Aigisというスタイルガイドジェネレーターを利用します。

スタイルガイドジェネレータとしては、KSS、hologram、styledoccoなどが有名ですが
それよりも使い勝手をよく、ピクセルグリッドの一部のメンバーにより開発されています。

日本語での説明書もありますので、気概があれば試してみてください。
https://pxgrid.github.io/aigis/docs/jp/

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(5)阿部 正幸さん(KDDIウェブコミュニケーションズ)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、阿部 正幸さん(KDDIウェブコミュニケーションズ) の『「Good bye~~ floats and “clearfix” hacks」これからはFlexboxの時代』セッションのスライドなどを公開します。

CSS Nite LP47に参加いただきました皆様ありがとうございました。
「Good bye~~ floats and “clearfix” hacks」これからはFlexboxの時代に登壇したKDDIウェブコミュニケーションズの阿部です。

セミナー当日のアンケートでFlexboxを使ったことがある方が8割を超えていて、Flexboxが普及していることを実感したのと共に、本当にセッションを止めて帰ろうかと悩んだ次第です^^;

------Flexboxを学習するために-------

さて、Flexboxを触ったことが無い方もおりましたので、これから学ぶという方は以下を参考にしていただければと思います。

Flexboxのプロパティは12種類あります。今回配布するスライドに全てのプロパティとデモコードを添付していますので、どのような動作をするか試してみてください。

全てのプロパティがどのような動作をするか理解した上で、サンプルプログラムや、下記であげます、Flexboxのサンプルサイトを見てどのようなことに活用ができるか確認をしてください。12種類のプロパティがどうのような動作をするか、Flexboxの活用例を知ることで、格段にレベルがあがるかと思います。

------デモ中のCMSの環境について-------

デモの途中でFlexboxのコードをCMSのWYSIWYGに反映をしました。その環境は以下で構築をしております、興味のある方は参照してみてください。

CMS Core:
 Drupal7

Drupal Module:
CKEditor - WYSIWYG HTML editor
 https://www.drupal.org/project/ckeditor

 Wysiwyg API template plugin
 https://www.drupal.org/project/wysiwyg_template

 Ckeditorの設定変更(エディターの設定を一部変更する必要があります)
 http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.removeDialogTabs
 (例)
 // リプレイスのデフォルト上書きOFF
 config.templates_replaceContent = false;
 // class、IDなどのAttributesを全て許可
 config.allowedContent = true;

------Flexbox参考サイト-------

○ 当日使用したスライド
  http://shared-blog.kddi-web.com/sandbox/lp47

○ Flexboxサンプルサイト

 Flexbox Patterns
 http://www.flexboxpatterns.com/home

 Masonry Layout(参考にはなるが実運用ではちょっと微妙かも)
 http://codepen.io/lucprincen/pen/PZPEby

 Pure CSS Radios with Flexbox
 (クリック判定にJSを使っていません)
 http://codepen.io/oknoblich/pen/mnlKi

○Flexbox CSSフレームワーク

 BULMA
 http://bulma.io/

 Bootstrap4 (現在Alpha版です)
 https://v4-alpha.getbootstrap.com/

○Flexboxのバグ

 https://github.com/philipwalton/flexbugs

------最後に-------

長くなりましたがセミナーに参加いただきました皆様、フォローアップメッセージを最後まで読んでいただきありがとうございました。またみなさまにお会いできることを楽しみにしております。

下記は私のソーシャルアカウントです。LINE@ではセミナーの無料招待チケットなどもお配りしておりますので、ぜひお気軽にフォローいただけると幸いです。

Facebook
https://www.facebook.com/chiyo.abe

LINE@
http://line.me/ti/p/@gkv8736o

CPIスタッフブログ
http://shared-blog.kddi-web.com/

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(4)長谷川 広武さん(HAMWORKS)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、長谷川 広武さん(HAMWORKS)の『本当に利用は必要か? デザイナーにとっての jQueryとJavaScript フレームワーク』セッションのスライドなどを公開します。

セッション4「本当に利用は必要か? デザイナーにとっての jQueryとJavaScript フレームワーク」を担当したHAMWORKSの長谷川です(´°ム°`)

デザイナーやマークアップ担当にとって JavaScript の内容は苦手意識の大きい部分だった人も中にはいると思います。しかし、jQuery やその他のライブラリ・フレームワークを含め JavaScript を覚えることで、仕事の幅も大きくかわってきます。今後も JavaScript が必要になることは多く出てきますので、紹介したようなライブラリやフレームワークも、簡易なところからでいいので、まずは一度チャレンジしてください。

以下、アンケートでいただいた質問への回答です。

結局 jQuery 使ってて OK?

小規模のときは使っててOKです。規模が大きめになる場合は jQuery だけだと対応が難しい場合も増えるため、そのときは jQuery 以外の選択も検討してください。

便利なプラグイン、フレームワークがあって自分に合ったものを探すのって大変

プラグインにしても、ライブラリやフレームワークにしても、自分に合うかどうかは触ってみないとわからないことが多いので、とても大変です。私もよく悩みますが、合うかどうかやカスタマイズしやすいかを判断するために、導入前に一度触れてチェックするようにしています。

JavaScript Framework って SEO 的にはどうなんでしょう?

私もこの点についての知識が乏しいため明確な回答を出せないのですが、検索エンジンはJavaScriptでの表示もクロールされるといわれているので、検索にヒットしないということはないようです。もしも気になってしまうようであれば、検索に影響の少ないところ、例えばサイドバーの読み込みや一覧の読み込みなどの簡易部分から利用してみることをおすすめしています。

JavaScript / jQuery どっちを勉強したらいいのか?

個人的には jQuery から勉強を始めても問題ないと思っています。jQuery なしでも出来ることでも、利用前提でいることで作る時間の短縮にもなるためです。JavaScript で抑えなければならない基礎部分もありますが(forループや変数など)それほど多くないため、jQuery の勉強とともに JavaScript の基礎も勉強してみてはいかがでしょうか?

jQueryのアニメーションはやっぱり便利

アニメーションはとても便利な機能の一つですが、CSS のアニメーションで代替できることが増えてきています。CSS で出来ることであれば jQuery のアニメーションを使わずに、transform や opacity などで動作を構成する方が動きが滑らかです。動的に値が変わる場合も、animation を使うのではなく、CSS の値を書き換えるくらいにとどめ、動き自体は transition や transform で構成するほうが滑らかです。アニメーションが必要な場合は、最初は CSS でできるか考え、難しい場合のみ jQuery の animation を利用するようにしましょう。

スライドで紹介した参考サイト

jQuery

ライブラリ・フレームワーク

簡易サンプル(リスト表示)

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(3)松田直樹さん(まぼろし)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、松田直樹さん(まぼろし)の『ハマるSVG』セッションのスライドなどを公開します。

セッション3「ハマるSVG」を担当いたしましたまぼろしの松田です。

ご参加いただきました皆様、誠にありがとうございました。そして、お疲れ様でした。

SVG実装時における罠として、10のトラブルシューティング例をお話しいたしました。

「Coder's High」なイベントにおいてみなさんのテンションを Low にしてしまったのではないかと懸念しておりましたが、アンケートではご評価いただけたようで安心いたしました。

実装の面倒な点ばかり紹介しましたが、SVGはやはり「キレイ」「無劣化」「再利用性」「アクセシブル」といったメリットを多く保持している画像形式です。面倒な点は一旦置いておいて、まずは使ってみてください。使えば使うほどハマる(夢中になる)かと思います。

次のバージョンであるSVG2の仕様についても、9月15日に勧告候補となりました。もっと可能性を持った画像に進化しようとしています。我々コーダーがSVGを使ってどんどん普及させてまいりましょう。

以下、アンケートでいただいた質問への回答です。

「background-image の SVGの色を変える方法はないですか?」

SVGはその表示のさせ方によってセキュリティレベルが定められており、background-image や img要素で表示させた場合は、HTML側からSVGの中身にまったくアクセスできないようになっています。なので、一般的には色を変えられません。
ただ、SVGファイルの中にCSSを記述し、Media Queriesなどを利用して図形の色(fill)を変えることは可能です。

当日のスライドにて紹介した参考サイト

アニメーション &インタラクション

ビジュアライゼーション

ロゴ

アイコン

パスの隙間を解決するFilter

React + SVG

SVG最適化

SVGの罠のDEMO

CSS Nite実行委員会

CSS Nite LP47「Coder's High 2016」フォローアップ(2)森田 壮さん(Gaji-Labo)

9 years ago

2016年9月24日(土)TKPガーデンシティPREMIUM神保町で開催したCSS Nite LP47「Coder's High 2016」のフォローアップとして、森田 壮さん(Gaji-Labo)の『イマドキのコーダー環境構築』セッションのスライドなどを公開します。

セッション2「イマドキのコーダー環境構築」を担当した森田です。
長丁場、お疲れ様でした。

30分という短い時間の中で、環境の話を詰め込んだので、詳細まで説明しきれないところもありましたが、コーダーのイマドキの環境を知っていただけたら幸いです。
やること多くて大変ですよね。

ご質問

アンケートにいただきました、ご質問について回答します。

gulp-sassってLibSassなの?node-sassと同じもの?

gulp-sassは、node-sass を gulp で動かすものなので、中身は同じものです。LibSassです。
gulp では gulp-sass、単体や npm-script などで使う場合は node-sass を使います。
また、RubySass を動かしたい場合は、gulp-ruby-sass というパッケージがあります。

PostCSSを使う利点は結局何でしょうか?gulpでベンダープリフィックスとか出来るし…

CSS を処理するタスクランナーと思ってください。
gulp で使う場合、gulp の中で PostCSS を使います。
なので、gulp プラグインの一つとして特に意識する必要はありません。

ベンダープリフィックスとは Autoprefixer のことを指していると思いますが、gulp で Autoprefixer を使う場合、実はすでに PostCSS を使っています。
https://github.com/postcss/autoprefixer#usage

PostCSS は Sass のような事もできますが、現状は記述については Sass を使い、小山田さんが言われていた「Sassの補助ツール」として使うのが一番ベターかなと考えます。

SassがCSSのスタンダート(!?)とのことであせりました
Sassも使っていないので難しかった

ピュア CSS より Sass の方が多く使われているのは驚きですよね。
スライドは煽り気味に書いてしまいましたが、無理に使う必要はありません。可能なところから始めてみてください。

ブラウザで簡単にSassを試せるオンラインツールもあります。
SassMeister - http://www.sassmeister.com/

まだ実案件で使ったことがないので、最初に実案件で使うオススメありますか?

全てを使ったことがないという意味であれば、まずはSassを使ってみてください。そして、せっかくなのでgulpも一緒にどうでしょう?

セッションでも最後に紹介したサンプルファイルは、gulpでSassのコンパイルと、Autoprefixer(ベンダープリフィックス付与)ができます。
こちらを雛形に、gulpのプラグインを追加してみてはいかがでしょうか。

https://github.com/sou-lab/cssnite-lp47

オススメのgulpパッケージを紹介します

スライドで紹介したサイト

イントロ

Sass

PostCSS

gulp

Node.js

サンプルファイル

CSS Nite実行委員会

CSS Nite LP49【再演版】「ワークショップで学ぶユーザーと検索エンジンから評価されるためのwebライティングの極意」が終了しました

9 years ago
CSS Nite実行委員会

CSS Nite LP49「【ワークショップで学ぶ】ユーザーと検索エンジンから評価されるためのwebライティングの極意」が終了しました

9 years 1ヶ月 ago
CSS Nite実行委員会

CSS Nite in SAPPPORO, Vol.19「秋のスキルアップ特集」が終了しました

9 years 2ヶ月 ago

2016年10月16日(日)、わくわくホリデーホール第1会議室でCSS Nite in SAPPPORO, Vol.19「秋のスキルアップ特集」を開催し、50名を超える方にご参加いただきました。

「ベーコンさんの世界ブログ」のベーコンさんも出演されました。

CSS Nite実行委員会
確認済み
1 時間 30 分 ago
「CSS」だけでなく、Web制作全般に関するトピックを取り上げるセミナーイベント。都内のほか、大阪、名古屋、青森、福岡、沖縄、秋田、札幌、福井、仙台、福島、広島、新潟、京都でも開催。 Movable Type Pro 4.23-ja
CSS Nite公式サイト フィード を購読

人気記事トップ10

人気記事ランキングをもっと見る