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

モノクロタイム

I'm from the future!

うちの情報学科におけるUIのはなし

結構前にこういう↓ツイートをしたところ,ボスにツイを拾われて超焦りました.

意図

私が所属しているゼミでは卒業研究としてWebサービスを作成します.私は機械学習と画像計測をやっていますが,同期も後輩も先輩も大体Webやってました.

先輩の時はわかりませんが,正直手を動かすのが遅すぎでは?と思っていました.もちろん,打ち合わせを行う事はとても大事です.しかし熟考するだけでは物は出来上がりません.いざ練りに練った要素を実装しようとしても,気づくと冬の初め.サービス内容を実装するのに手一杯です.そういった状況だと,UIを考える暇なんてありません.そして仕方なく卒業生の作ったUIをそのまま流用する,個人的に負の連鎖だと思っています.

先輩が作ったUIを流用するのが悪いこととは言いませんが,実装するサービス内容に全くマッチしないのに無理やりUIを使いまわしているという印象が余りにも強い為,これはどうにか流れを変えた方がよいのでは?と思った次第です.

というか,Webサービス構築の経験がない学生にUI・サービス内容の実装を丸投げするのは酷だなぁと思っています.

わからないこと,できないことが多く,進捗が出ないこともあります.成果物を求める教員とすれ違う事もあります.学生側の負担を減らしつつ,教員と学生のすれ違いを防ぐために以上のツイをツイしました.

なんとか学生も教員もハッピーになれる開発手法を探していきたいですね.あっ私は今年で卒業するけど.

UIを考える

これから述べることはWebサービスの開発においてとても初歩的な事です.たぶん.

前節でも少しだけ書きましたが,Webサービスはおろかプログラミング自体初心者の学生が多いです.

このような学生に対してはいきなりPCの前に座らせるより,「絵を描いてもらう」ことが大事だと思っています.

そうです,モックを考えてもらいます.

  1. 教員と話し合って練った要素をブラウザ上でどう見せるか,モック*1を描かせます.モックは「○○の機能をここに配置して,××のボタンを押したらあれが動いて…」と考えながら描くので,話し合いを長く続けるよりも頭の整理になります.

  2. 描けたら教員やゼミ生の前で発表してフィードバックを貰います.ボタンの配置場所や各要素の大きさなど.

3.モックを元に,必要な知識を洗い出します.ボタンの作り方,Ajaxの使い方,GoogleMapAPIの使い方,フレームの作り方などなど.

4.モックを参考にして要素を配置していきます.

超初歩的だと思いますが,これが出来ているのと出来ていないのとでは実装の進め易さが格段に違います.

これまでは中身を考えながら同時並行でUIも考えなければいけないという状況でしたが,モックという設計図を先に考えてしまうことで,次はボタン群を作ろう,この次は画像を切り替える機能を作ろう,などなど作るべき要素を明確化します.

これが教員(或いは指導できる先輩)にとって良い所は,学生が必要としている技術を把握できるということです.

何ができないのか,どこで躓いているのか,モックと進捗を対比させることで把握することができます.どういう技術が必要か,先回りして参考資料を示すことも可能になるでしょう.

誰が何をどうやって作っていたのか,そして現在のWebサービス開発における技術を把握することもまた研究室へのノウハウの蓄積に繋がることかと思っています.

まとめ

だらだら書きましたが,一言で言うと「作りたいサイトのイメージ図作ってそれに沿ってページ作ろうね」ということです.超初歩的ですね.

ボスが早速今年のB4の学生にモックを描かせてました.サービスのコアな要素を固めつつ,Webサイト開発のために手を動かし始めている学生もいるのでかなりいい感じに進んでいるのではないかと思います.これからの動向に期待ですね.

研究室もWebサービス開発が専門というわけではないので速攻スムーズに,とはいかないかもしれませんが,これを機に学生だけではなく研究室・大学全体の技術レベルが向上すればいいなぁと願っています.

ではでは~

おまけ

アイディアを実現させる最高のツール プログラミングをはじめよう

アイディアを実現させる最高のツール プログラミングをはじめよう

Ruby女子の池澤あやかさんの本です.技術系のゼミに入りたい(入った)けどついていけるか不安って感じてる学生に読んでほしい.

良書です,特にうちのゼミは必要だと思う

*1:パワポでも手描きでもなんでもいいです.重要なのはカラーで描いてもらうということ.