読者です 読者をやめる 読者になる 読者になる

astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

デザイナーが「言葉」についてちょっと真面目に考えてみた

デザイン

f:id:astamuse:20170322211518p:plain

こんにちは。白木と申します。デザイナーです。

前回はデザイナー採用担当者の目線でポートフォリオについてお話をしました(下記)。多くの方にご覧いただけき、「参考になった」というフィードバックもいただきました。ありがとうございました。

lab.astamuse.co.jp

さて、今日はもう少し抽象的なデザインの話をしようと思います(時間ない方はブックマークしてお時間あるときにお読みください)。お題は「デザイナーが「言葉」について真面目に考えてみた」です。

デザイナーに求められる能力は多様?

本題ではありませんが、デザイナーに求められることは実に多様です。デザインがそもそも統合的・領域横断的な性格であるため、周辺領域からの知識要請がとかく多いと日々感じています。

例えば椅子一つ作る場合、デザイナーはただ美しい形状を追い求めるではなく、構造力学、材料工学、人間工学の側面も考慮せねばなりません。また、製造現場とのすり合わせや(「それ型で抜けるの?」的な)、コンセプト落とし込みの調整役もこなしますし、場合によっては何が売れるのかをマーケティング側とすり合わせるところにも関与します。簡単なマーケティングリサーチの知識も必要とすることもあります。

Webデザインも同様です。このご時世、企画、マーケティング、エンジニアリングと無関係でサイトやサービスを完成させることはあり得ません。いずれの隣接領域に対しても越境的にディスカッションできる程度には専門知識を備える必要があります。

しかし、実際には私たちの仕事はこれらの専門的知識・知見だけでなく、その土台をなす非専門的な能力によって支えられているように見えます。むしろ非専門的な部分の方が実は支配的なのではと思わせるほどです(仮説)。

デザインの専門領域外で重要な要素とは?

では、専門領域以外の重要な要素とは何なのでしょうか?先ほどの仮説から言えば、それはデザイナーの仕事を考えればおのずと出てくる答えですが、先に私なりの結論を示すと以下の3点です。

  1. 言葉・概念
  2. 思考・洞察力
  3. 多様な経験

1は私たちが作ったものに文脈やフィロソフィー、説明を与えるために必要な要素です。2の思考・洞察力は特段デザイナーに限定される話ではないですが、デザイナーらしい思考・洞察力はあると私は思っています。3についてはデザインを生み出す原体験の多様さです。

紙面と時間の関係上、本日は1のみ整理しますが、2,3についても日を改めて整理できればと考えています。ということで以下「言葉・概念」についての考えを整理します。

デザイナーの仕事の特徴と言葉・概念

デザイナーは「抽象的なもの・ことを形にすること」を仕事にします。クライアントや企画の想い・意図を解きほぐし整理し秩序を与えながら形に変えていく生業です。ほかの職種と比べて対象テーマが感覚的・感性的なことが多く、ここがデザイナーの難しさの一つでもあります

さて、この感覚的・感性的なテーマに向かっていく中で、言葉・概念という武器が少ないとクリアが難しくなるというわけです。

言葉・概念が対象テーマの的確に把握できない

f:id:astamuse:20170322225427p:plain

まず言葉・概念の扱いがうまくないと、対象テーマを正確・的確に把握しにくくなります

例えば「信頼感を醸成したい」というテーマがあったと仮定します。この場合、普通は「信頼感とは何か」を考え「誠実」「落ち着いた」などの言葉に至るのですが、本当に表現すべきことが「内省的な印象を備える信頼感」であった場合はどうでしょう。デザイナーが「内省的」という言葉・概念を知らなかった場合、どうなるのでしょうか。的確にテーマを捕捉しえるでしょうか。

サピア・ウォーフの仮説*1ではありませんが、適切な言葉を持ち合わせていない中で曖昧・複雑なことを的確にとらえることはおそらくは困難です。先ほどは「内省的」という発見されやすい例を出しましたが、実際の現場ではもっと面倒でわかりにくいケースがゴロゴロしています。これらを形にするのに、それを表現できる言葉が少なくては、落とし込みにに膨大な時間とコストがかかるか、結構な量の情報が落ちてデザインの精度が下がるかです。

言葉・概念によるデザインの背景・哲学を形成が困難になる

f:id:astamuse:20170322230738p:plain

次にデザイン説明時にも問題に遭遇します。

何かしらのデザインができた時に、デザイナーはそのデザインに至った背景や理由の説明責任を負います。デザインの対象は感性的であることが多いため、そもそも説明コストは高いのは当然です。が、仮にデザインしたものが企業ロゴなどであったら、感性的な要素だけでなく企業のフィロソフィーすらもデザインに乗せることになりますから、それをどう言葉に落とし込むかは能力の求められることろです。

ただ、この点においては反論もあって、そもそも言葉を必要とするデザイン自体が問題なのではないかという指摘です。これは一理あります。言葉を必要としないように直感的なものを指向することも選択肢としてはあります。しかし、説明が不要かどうかを決めるのは提案するデザイナーではなく、それを受け取る側に依存しますから、依然説明ないし言葉は必要であると考えるのが自然です。

また直感的に理解し得るものであってもデザインに込められたフィロソフィーをどう伝播させるかという観点から言えば、伝達媒介としての言葉はやはり重要でおざなりにはできません

言葉をなくして観察ができるか

物事を観察するときにどこまで精緻に記憶・記録できるかは、観察の分解粒度と的確な言葉の利用が求められます。

昨今では「かっこいい」で表現できる幅が随分と広がりましたが、あらゆるものを「かっこいい」と評してしまうと、一体何が恰好よく足らしめているのかは解らないままです。色なのか構図なのかプロポーションなのか時代とのギャップなのか。観点は多様で、その観点を説明する言葉もまた様々です。日常の軽い会話であれば「すごい」「かっこいい」でもいいのかもしれませんがデザインを説明する時、またデザインを学習するときは、細かい部分にまで言及し的確に表現することが重要なのは自明のように思えます。

高尚な言葉・概念を使えばいいわけではない

さて、ここまで言うと「かっこいい言葉使わないといけないのかな」と思われるかもしれませんが、そんなことは全くありません。あくまで的確な言葉を探すこと・身につけるです。それもきちんと共感を得られる言葉、もしくは少しの学習で理解可能な言葉の中で、です。

かっこいい言葉を使うことは、排他的な面があります。専門家が専門用語で話している中に素人が入り込めないのと同じように。もしそういった高尚な言葉を使いたいのであればそれが通じる人との中でだけ使ってください。わからない人に対してひけらかし的に使わないよう心掛けてください。ひけらかしとして使うのは却って底の浅さを映すことになります。

説明くさくあれと言っているわけではない

また、ここまで言うと「随分と説明くさくしなければならないんだな」と思うかもしれませんが、それも意図しないところです。飽くまで問題の本質をとらえるために言葉が大事だとご理解いただければと思います。必要な時に必要な量の的確な言葉を出せるようになることと、物事をより正しく理解するために言葉が重要なのであって、説明的であることは重要ではありません。

最後に

デザインを的確に行い、その意図を理解してもらうことは、とりもなおさずデザインという世界そのものの理解を広げることと同義だと思っています。そのために私たちは言葉を身に付け伝え続けなければならないと改めて認識します。そこを怠り、デザイナーらが自身ら身内の言語に満足して外に向けての説明を放棄してしまうことは不信感を助長し、象牙の塔の印象をもたらすだけでしょう。そのような業界に未来はありません。

デザインとは相手とのインタラクティビティによって生まれてきます。そこでのコミュニケーションを語る前段として、まず良いコミュニケーションを行うための道具磨きが必要であり、それが豊かな言葉の獲得なのです。 日々の作業に追われているとWeb上のノウハウの収集ばかりに終始してしまいがちですが、たまには立ち止まって自分の言葉磨きなどもしてみるのはいかがでしょうか*2

*1:サピア=ウォーフの仮説

*2:ちなみに私は言葉磨きのために自分の考えていることを実際に紙に書いてます。それだけでも言葉がだいぶ使えるようになります。

KotlinでJVMのWebApplication開発は楽になるのだろうか。検証してみている。

Java Kotlin Web開発 Asta4D プログラミング

f:id:astamuse:20170314235457p:plain

どうも、えいやです。
またお鉢が回ってきたので、担当させていただきます。

前回はJava8で楽になったか試そうとしたけど、中途半端で完成しませんでしたという記事を書きました。
これはひどい、というご意見ですが、ごもっともですね。

今回も似た感じで、Kotlinで楽しようとした感じの中途半端な記事です。

kotlinlang.org

大体のことがそんな感じなので、大抵のことを誰か代わりにやってくれないかなぁと思っています。僕より役に立つ人が沢山いるといいな。

さて、今回は、WebアプリケーションにBetter JavaとしてKotlinを使う検討をやってみているという話です。
検討途中ですし、大して詳細に調べたわけでもないので、適当に聞き流してください。

弊社では、開発言語に特に縛りはないものの、Java、ScalaGroovyと言ったJVM言語で開発している事が多いです。
そういうわけで、しばらく前に1.0がリリースされ、やや安定期に入ってきた新しいJVM言語であるKotlinの評価を始めてみました。
ScalaもGroovyも15~12年前に開発されてから、最近はわりと安定、普及してきたのはそりゃいいんだけど、そろそろ新しめの言語にも触れておかないとね。

なお、Kotlinの開発元は、最近JVM向けの有償IDEで(たぶん)一番人気*1IntelliJ IDEAを作っているJet Brains社です。

まず、Kotlinという言語の特徴ですが、JVM上で動くバイトコードにコンパイル可能、静的型付け、オブジェクト指向という点ではJavaと同じです。
さらに、Kotlinには型推論、宣言側変性(ジェネクリスの変性を宣言可能)、高階関数、ラムダ式(最近のJavaにはあるけど)、移譲の宣言、Null安全、スマートキャストなどの便利機能がついています。

Kotlinの文法や詳細は、公式ページに任せます。また、いろいろな人が日本語で解説してくださっています*2*3ので、そちらを見てください。
この記事では、弊社が開発しているWebアプリケーションで、どの程度使えるのかを検証してみた内容について述べます。

なお、2017年03月現在で、世間様でのKotlinの利用状況としてはAndroidの開発でやや人気が出てきたというところのようです。

今回は、Kotlinの採用可能性について、以下の点で調べています。

1)KotlinおよびKotlin製のWebApplicationFWでシステム構築・運用が可能か
2)アプリケーションのコード全体をKotlinに置き換えることが可能か
3)2)のコードの一部をKotlinに置き換えることが可能か
4)既存のアプリケーションから利用するライブラリを作成可能か

1)KotlinおよびKotlin製のWebApplicationFWでシステム構築・運用が可能か

検証の対象として、Kotlin製のWebApplicationFWで一番安心できそうなJetBrain社製の「Ktor」を検証してみました。

結果としては、個人的には簡単なWebApplicationを作るだけならイケるんじゃないか、という感想なのですが、コレをチームメンバーに使えというのは酷という感じです。

Ktorは、最小の作業で素早くKtolinでWebアプリケーションを作るフレームワークと自身の紹介に書いてある通り、初見の印象としてはNode.jsのExpressに似たコンパクトなルーティングと処理を記述する、非常にコンパクトな機能を提供しているイメージです。

ドキュメントがほぼ整備されていないので、Ktor本体のソースコードとサンプルのソースコードを頼りに一通り試してみました。
公式のサンプルからそう離れたことはやっていませんし、この記事が出来上がる頃にはまた変わっていると思うので、試したコードは載せません。

なお、ドキュメントのGetting Startedで紹介してあるコードは僕が検証している段階では動かなかったのですが、今確認したところ動くコードに変わっているようです。

現時点でのバーションは0.3ですので、現時点ではかなり多くの不備があるため、採用するとなるとOSS開発に協力しつつシステム構築を進める事になります。
それはそれで面白いとは思いますが、すぐに導入を決めるのは難しそうです。

他のWebApplicationも一応検証してみたのですが、まともに動かすのに時間がかかるもの、更新止まっているものばかりでちょっと。。。

数年前に期待されていたKaraWasabi*4は開発が止まっている、か停滞しているみたいです。
なお、KtorはKaraやWasabiにインスパイアされているらしいので、それらの後継と言えるので、今一番安心できる開発体制なのではないでしょうか。

なお、WebApplicationというとサーバサイドって感じですが、KotlinはJavaScriptにトランスパイルする事ができるのでそういうFWもあるみたい*5です。検証してませんが。

2)アプリケーションのコード全体をKotlinに置き換えることが可能か

今のJava製のアプリケーションFWをそのまま使ってということですね。

まず、前提としてKotlinのコードはバイトコードにビルドされますし、Javaのライブラリもそのまま使うことが出来ます。なので、可能性ということであれば絶対に可能です。
あとはそれで開発が楽になったり、いいことがあるかということです。あと、既存コードからKotlinへの一挙置換となると現状のテストコードだけでは検証が難しそう、とかは一旦考えません。

弊社でJavaのプロジェクトと一部のScalaのプロジェクトでは、自社製のJavaWebApplicatrionFWを使用していますので、その仕様に則って、WebApplicationを作ったとしましょう。
検証のポイントは、FWの仕様が、Kotlinとミスマッチだったりしないか、ということです。
さらに、既存コードからの置き換えということで、KotlinのJava->Kotlin変換機能でどの程度楽にできるか、ということも検証してみます。

検証

次のプロジェクトを変換してみます。

github.com

このプロジェクトは、弊社製のWebApplicationFrameworkのAsta4Dで作成されており、簡単なHandlerとSnippetで構成されています。

本当はDB周りも試したかったのですが、この記事のためには時間切れです。

もし実行してみたかったら、次のコマンドで実行可能です。

git clone https://github.com/aya-eiya/java2kt1
cd java2kt1
git checkout JavaSmaple 
./gradlew clean appRun

起動にはGrettyを使っています。

localhost:8080で以下の画面を見ることが出来ます。

f:id:astamuse:20170314224025p:plain

上から、path/helloに対して引数なしGet、引数(name)ありGet、Postを行います。
path/helloからの返りはJsonで、Getに対しては{“message”:“hello ○○”}を返し、Postに対しては{“name”:“○○”}を返します。

Postで送ったNameはSessionに保存され、引数なしGetの返却値の一部およびPath/の一番下の入力フォームの初期値として使用されます。

さて、Kotlinに変換をしていきます。

まず、InteliJのJava->Kotlin変換機能を使ってみます。メニューからは Code -> Convert Java File to Kotlin Fileで選べます。

f:id:astamuse:20170314225034p:plain

変換後のソースはビルドが通りません。

どうやらNull許容のところで型違反と、valで初期化するように変換した値に代入をしているようです。

単純な方法でコンパイルが通るように修正したコードではアプリが起動しません。

どうやらNull安全の機能が問題で、Null許容型とNull不可型で型が違うため、Springの設定ファイルに書いてあるBeanの作成に失敗しているようです。
型を合わせてみるとこのエラーはなくなりました。

次はFactoryとして作っていたクラスで、staticなinstance()メソッドが実装されています。
このクラスのBeanの設定でfactory-methodにinstanceを指定していましたが、Kotlinではクラスにstaticなメンバを持つことが出来ないため、JavaからはCompanionオブジェクトを通じて呼ばなければなりません。
なのでFactory.CompanionをBeanに登録して、factory-beanにそのIDを指定します。

次は、UrlRuleがInitialize出来ない、というエラー。。。

その後、30分ほど色々試してみるものの、どこかしらでエラーとなって起動できませんでした。

結論として、大きなプロジェクトを変換するのはちょっと辛そう。ということになってしました。。。

しかしながら、時間さえかければ変換はそんなに苦労はしないんじゃないかなという感想も持ちました。
作業の慣れの問題でどうにかなるんじゃないかと。

3)2)のコードの一部をKotlinに置き換えることが可能か

1)の途中の状態から一部をJavaに戻したりしながら検証してみました。
Beanに登録するようなものでなければ違和感なくKotlinに変換して利用が出来ます。

ただ、この境界をどうするのか、というのが難しく、混ぜて使うのはちょっとつらいんじゃないかな。
という感想です。

4)既存のアプリケーションから利用するライブラリを作成可能か

これは検証前は一番大丈夫なパターンだと思ったのですが、ライブラリの対象によってはBeanに登録するだの、利用シーンを限定できないこともあってかなりつらいです。
一番つらいパターンかもしれません。

簡単な機能のライブラリでは問題はでてこないのかもしれませんが、これも何をKotlinで作って良くて、何がダメなのかの境界を設定するのが辛いと思いました。

一旦の結論

  • Kotlinで書くのはそんなに辛くないが、FWなどエコシステムがまだ発展途上。
  • 現行のWebApplicationのコードをKotlinに変換するのは辛い。
  • 一部をKotlinで書き始める場合も、落とし穴だらけの可能性が高い。

今回とは逆に、Javaで作ったものをKotlinで使うのは、Null安全などの対応は別にすれば問題は少ないです。
なので、業務で使う場合、WebApplicationよりもバッチとか、それこそ今流行り始めているAndroidで使うのが、まだ安全かな、という結論です。

今回、検証とは別に習熟のためにKotlinで色々書いてみたのですが、Scalaと同じく、言語の持つ機能が多いので覚えることが多い印象です。JVM言語ではないのですが、シンプルなGo言語なんかと比べると習得に要する時間が長いかも。

Javaもそれなりに多いんだけど、経験年数長い人やドキュメントが多いので。同じ理由でだいぶ長くなってきたScalaもその辺をクリアしてきた感じありますね。

良い言語だと思うんだけど、普及率や自分たちの領域を考えると、まだチームメンバーに強要はできないかなー。

という感じで、今回も中途半端な感じで終わります。

なお、既にKotlinマスターで強烈にKotlinをプッシュしてくれる方が来ていただけると事情も変わると思います。
Javaを全部Kotlin化するって言っても、僕はことさら止めはしないので。

今回の記事は以上となります。
お疲れ様でした。

BootstrapとVueでタブを作ってみる、の巻

Bootstrap フロントエンドエンジニア Vue.js

2016/09/30に2.0がリリースされてから、現在2017/03/05まででダウンロード数約3倍の増加をみせるVue.js。 f:id:astamuse:20170308132520p:plain

npmtrends(2016/09/25 32,043 → 2017/03/05 109,774)

そろそろ無視出来ない勢いなので、とりあえず触ってみることにしました。 ドキュメントもしっかり日本語化されてるので英検4級の私にはありがたい。←ここ重要

1. 下準備

vue-cliを使ったほうがかなり楽そうなんですが、めんど(ry

ファーストステップなのでVue.jsのみでやってみたいと思います。

またCSS書くのもめんど(ry

久しぶりにbootstrap触りたくなったのでそれ使います。

ということでCodePenだけで準備完了です。すばらしい。pugも使える。CodePenありがとう。

2. とりあえずhtmlを組んでいく

元テンプレートはこちら

div.container
  h1 vue tab sample
  ul(class="nav nav-tabs" role="tablist")
    li(class="nav-item" role="presentation")
      a(href="#home" class="nav-link active" role="tab") ホーム
    li(class="nav-item" role="presentation")
      a(href="#test" class="nav-link" role="tab") テスト
  
  div.tab-content
    div(id="home" role="tabpanel")
      h2 HOME
      p ホームタブコンテンツ
    div(id="test" role="tabpanel")
      h2 TEST
      p テストタブコンテンツ




まず <slot>を使ってhtml側で管理する内容と、vue側で管理する内容を分離していきましょう。ここでは、テキスト内容をhtml、そのほかのものはvue側で管理させるようにしました。 (サンプルではわかりやすいようにnameをつけてますが、なくてokです)

div#v-root.container
  h1 vue tab sample
  tabs
    div(slot="tabContents")
      tab(name="home" text="ホーム" v-bind:selected="true")
        div(slot="tabinner")
          h2 HOME
          p ホームタブコンテンツ
        
      tab(name="test" text="テスト")
        div(slot="tabinner")
          h2 TEST
          p テストタブコンテンツ


Vue.component('tabs', {
  template: `
    <div>
      <ul class="nav nav-tabs" role="tablist">
        <li class="nav-item" role="presentation">
          <a href="#home" class="nav-link" role="tab">ホーム</a>
        </li>
        <li class="nav-item" role="presentation">
          <a href="#test" class="nav-link" role="tab">テスト</a>
        </li>
      </ul>
      <div class="tab-contents">
        <slot name="tabContents"></slot>
      </div>
    </div>
  `
});
Vue.component('tab', {
    template: `
    <div :id="'#' + this.name" role="tabpanel"><slot name="tabinner"></slot></div>
    `,
    props: {
        name: { required: true },
    },
});
new Vue({
    el: '#v-root'
});



See the Pen Vue tab sample 03 by 35n139e (@35n139e) on CodePen.

3. Vue実装開始

tab実装

タブコンテンツを軸にタブリストを生成する方法で実装していきます。 html側でid名やタブのテキストを管理するので、propsにtext(テキスト)とname(id名)、selectedでデフォルトで開くタブを選べるようにしました。

tab(name="home" text="ホーム" v-bind:selected="true")
  div(slot="tabinner")
    h2 HOME
    p ホームタブコンテンツ
  
tab(name="test" text="テスト")
  div(slot="tabinner")
    h2 TEST
    p テストタブコンテンツ


Vue.component('tab', {
  template: `
    <div :id="'#' + this.name" role="tabpanel" v-if="isActive">
      <slot name="tabinner"></slot>
    </div>
  `,
  data() {
    return {
      isActive: false
    };
  },
  props: {
    text: { required: true },
    name: { required: true },
    selected: { default: false }
  },
  mounted() {
    if(location.hash != ""){
      const url = location.hash;
      this.isActive = (url == '#' + this.name);
    }else{
      this.isActive = this.selected;
    }
  }
});

tabs実装

つぎにタブリストの生成です。

Vue.component('tabs', {
  template: `
    <div>
      <ul class="nav nav-tabs" role="tablist">
        <li v-for="tab in tabs" class="nav-item" role="presentation">
          <a :href="'#' + tab.name" @click.prevent="selectTab(tab)" role="tab" class="nav-link" :class="{ 'active': tab.isActive }">{{ tab.text }}</a>
        </li>
      </ul>
      <div class="tab-content">
        <slot name="tabwrap"></slot>
      </div>
    </div>

    `,
    data() {
        return { tabs: [] };
    },
    created() {
        this.tabs = this.$children;
    },
    methods: {
      selectTab(selectedTab) {
        this.tabs.forEach(function(tab){
          tab.isActive = (tab.name == selectedTab.name);
        });
      }
    }
});

v-forでタブコンテンツの中を見に行かせます。

<li v-for="tab in tabs" class="nav-item" role="presentation">

タブリストの中身はそれぞれtabのpropsを参照させます。タブのアクティブ化は'v-bind:class'で行います。

<a :href="'#' + tab.name" @click.prevent="selectTab(tab)" role="tab" class="nav-link" :class="{ 'active': tab.isActive }">{{ tab.text }}</a>


タブリストをクリックしたときの関数をmethodsに記述。 それぞれのtab.nameとクリックしたtab.name(selectedTab.name)にアクティブフラグを立てさせます。

methods: {
  selectTab(selectedTab) {
    this.tabs.forEach(function(tab){
      tab.isActive = (tab.name == selectedTab.name);
    });
  }
}

完成

tabsとtabを合わせるとあら不思議。タブの完成です。

See the Pen Vue tab sample 04 by 35n139e (@35n139e) on CodePen.

4. <transition>で味付け

最後に<transition>を使って味付けしていきます。

animationのcssはAnimate.cssを利用させてもらいます。

下記のようにカスタムすれば<transition>でAnimate.cssを直接使うことができます。

<transition
  name="animateCSS"
  enter-active-class="animated fadeIn"
  leave-active-class="hide"
>
  <div :id="'#' + this.name" role="tabpanel" v-if="isActive">
    <slot name="tabinner"></slot>
  </div>
</transition>

これでアニメーションさせたいコンテンツをラッピングして終了です。簡単!キレイ!

See the Pen Vue tab sample 3 by 35n139e (@35n139e) on CodePen.

5. 最後に

Vue.jsはガイドもしっかりしてるし、学習コストも低めなので「Jqueryしか書いたことないよ」って方もぜひ触ってみていただきたいフレームワークです。

私もお試しで触ってみてハマった口で、今週の月曜日に弊社の採用サイトをVue.jsで作り直しました。ぜひそちらのほうも見ていただければと思います。

参照・参考元

Copyright © astamuse company, ltd. all rights reserved.