インタラクティブなデジタル作品をつくる — 企画から公開まで

クリック一つで反応が変わる、ごく小さなインタラクティブ作品を作って公開するところまでを実際にやってみます。派手な機能は入れず、体験できる状態にして公開することを最優先にしました。ここでは企画・構築・発表それぞれの段階で何を決めたか、なぜその範囲で止めたかを記録します。

小さく完成させることを最初に決める

今回作ったのは、画面をクリックすると背景の模様が少しずつ変化していく、それだけの作品です。当初は音や複数シーンも検討しましたが、制作ワークフローの設計の記事で書いたBuild段階の教訓どおり、機能を足すたびに完成の基準があいまいになると判断し、最初の案から機能を削りました。

企画 — 何を体験させたいかを一文にする

「クリックするたびに画面の印象が変わる」という一文だけを企画の軸にしました。この一文に当てはまらない要素(効果音、複数ページ、ユーザー登録など)は、今回のスコープからすべて外しています。

企画書ではなく制約リストを作る

やることのリストではなく、やらないことのリストを先に作りました。「音は入れない」「画面遷移は作らない」「対応環境はスマートフォンのブラウザ一つに絞る」といった制約です。制約を先に決めておくと、構築中に「あれも入れたい」という判断が入り込む余地が減ります。

構築 — 使う技術を絞り込む

Webブラウザで動く形式を選びました。特別な実行環境を用意させずに人に見せられるためです。クリックイベントで見た目を変える処理自体は、Web標準の基本的な仕組みで実現でき、複雑なフレームワークは今回の規模では必要ありませんでした。仕様や実装方法はWeb標準の変化に合わせて更新されるため、実装時は最新のリファレンスを確認するのが安全です。

動くものを最短で作ってから足す

最初にクリックで色が変わるだけの状態を作り、そこから模様の変化を足していきました。完成形を先に設計してから作るのではなく、動く最小の状態を早い段階で確認したことで、想定と違う挙動に気づくのも早くなりました。UIデザイン入門の記事で扱った、小さな画面から状態を積み上げる考え方と同じ進め方です。

発表 — 公開先を先に決めておく

公開先は個人のインタラクティブ作品を扱う配布サイトを利用しました。構築を始める前に公開先を決めておいたことで、必要なファイル形式や画面サイズの制約を先に把握でき、構築の途中で書き出し方法を変える手戻りが発生しませんでした。

公開後に直せる部分と直せない部分

公開後もファイルの差し替えは可能ですが、公開URLや紹介文は後から変えると見に来た人を混乱させます。公開直前にタイトルと説明文だけは固定する、というルールを設けました。

ただし、今回のように機能を絞り込む進め方が常に正解とは限りません。作品の目的が技術の検証そのものであれば、あえて範囲を広げて試す価値があります。もっとも、初めて公開まで通す場合は、小さく完成させて一度最後まで通す経験を優先したほうが、次の作品に活かせる学びが多いというのが今回の実感です。

作品に他者の画像や音源を使う場合は、素材のライセンス条件を確認し、表示が必要なクレジット表記を省略しないでください。自分の作品を公開する際も、利用したツールの規約に商用利用や再配布の制限がないか事前に確認します。

企画から公開までを一通り伴走してほしい場合は、講座ページで実践形式のプログラムを案内しています。

参考文献

1. MDN Web Docs, "Getting started with the web," https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Your_first_website
2. itch.io Creator Docs, "Quick launch guide," https://itch.io/docs/creators/quick-launch-guide
3. Creative Commons, "About CC Licenses," https://creativecommons.org/share-your-work/cclicenses/