こんにちは。福岡です。

Firefox Desktop Browser 69 （以下 Firefox69）が９月３日にリリースされていますので、その変更内容とWebClassへの影響についてピックアップして説明します。

2019/9/17 追記しました。

Firefox のリリーススケジュールについて

公式情報として以下のようなものがあります

Firefox release calendar
https://wiki.mozilla.org/Release_Management/Calendar

Firefox ESR のリリース周期は、以下に日本語で説明があります。
https://www.mozilla.jp/business/

Firefox 68 のリリースより、Firefox ESR も68ベースに切り替わっています。

Firefox69

公式の情報として、一般利用者向けのリリースノートと、開発者向けのリリースノートとが公開されています。

Firefox 69 release note
https://www.mozilla.org/en-US/firefox/69.0/releasenotes/

Firefox 69 release note for developers
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/69

開発者向け情報は、Web製作者およびプラグイン等の開発者にむけた、APIや開発環境の変更について情報があります。

これらの情報から、単純に WebClass の動きへの影響に加えて、教材への影響も確認することができます。

Pickup for webclass

WebClassおよび教材に関して、サービスおよび教材の提供側として注意しておいた方が良さそうなポイントをピックアップしました。

• Enhanced Tracking Protection 機能がデフォルトで有効になります。
  • https://blog.mozilla.org/blog/2019/09/03/todays-firefox-blocks-third-party-tracking-cookies-and-cryptomining-by-default/
  • このサイトでもGoogle Analytics によるアクセスの調査を行なっています。このように、Webサイトの意図で外部サイトクッキーを使った追跡があるとき、ユーザの意思で追跡をブロックすることができます。
  • WebClass は自サイトのクッキーで動作しており、外部の利用者追跡は組み込まれていません。ただし、教材や連携するシステムが外部リソースを利用するとき、ユーザの意図でブロックされると思ったように動かないことがあるかもしれません。
• Block Autoplay 機能が拡張されました。
  • https://support.mozilla.org/en-US/kb/block-autoplay
  • 動画等の音声を含んだ全てのメディアについて、デフォルトでは自動再生がブロックされます。設定変更することで自動再生できるようになります。
  • 教材などで動画を使用している場合に、利用者の利用環境の想定が変わる可能性があります。
• Flash コンテンツは、毎回必ずFlash有効化の確認をするようになります。
• 対象の要素でユーザーがテキストを選択できるかを指定する CSS の user-select プロパティの接頭辞を Firefox 69 で外しました
  • https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

Block Autoplay について(2019/9/17追記)

Firefox69になって、ユーザがページを開いたときに予期せず音が再生されてしまうのを防ぐようになりました。

具体的には、<video>タグと<audio>タグに autoplay 属性が設定されていても、自動再生されなくなります。例外として、muted 属性が付与されて音が出なくなっている場合と、一度ページを開いて自分で再生した後でリロード等により開き直したときは、自動再生されます。

WebClass では資料教材のページとテスト教材の設問・解説に動画または音声を取り込んでいる場合、上記の通りautoplay 属性をつけて自動再生させています。Firefox69以降では、これらページで自動再生されなくなり、ユーザが再生ボタンを押す必要があります。

こんにちは。福岡です。

この夏のアップデートパッチは７月３１日のリリースを予定していましたが、テストのやり直しが発生したため、少し送れて８月のお盆前を予定しています。

WebClassの年2回のリリースでは機能全体の検査をしています。だいたい１ヶ月くらいの期間をつかっていますが、その間に見つかったバグの修正などを反映したバージョンに差し替えるため、期間中には検査対象のバージョンや環境を変えて複数回テストをします。

今回はテストターゲットとして、拡張機能の開発途中のブランチで自動生成されたパッチを誤って選んでしまいました。そのままテストを開始してしまっていたため、テストターゲットを選び直してやり直しとなってしまいました。

リリーススケジュールは社内のいくつかのスケジュールとも関係していたため、遅れが出るのは私たちとしても痛いのですが、その中でも幸いと思っているのは「STOP」ができたことです。

投入した何かがあると、どうしても取り返したくなります。そのために、続行したり、ちょっとした調整で済ませようとします。それで済むこともあるとは思いますが、「どうも進み方がおかしいぞ？」と思った時は、手を止めて仕切り直しをする勇気が必要と思います。スタッフも受け入れて、テストのやり直しも進めてくれています。

こんにちは。福岡です。

WebClass の画面は一昨年にデザインを改めましたが、まだまだ古いままの画面も残っています。利用者からは統一感のなさを指摘いただく機会も多々あり、至らなさを感じるところです。

ここでは画面の置き換え、もしくは機能の入れ替えについて、開発チームで共有しておきたい全体的な方向性についてまとめておきます。一番に想定している読者は開発チームです。また新機能の開発についてはここでは扱いません。

直すつもりはあるのか？

もちろんです。使いやすい・わかりやすい画面、もしくはより便利な機能に改めていきたいと考えています。

ただし、小さなチームでの開発ですのでリソースの問題は常に付きまといます。また、いざ取り掛かるにあたり、どう直したらいいのかというのが次にぶつかる問題です。

残念ながらやみくもに手当たり次第に取りかかれるわけではない中で、どう切り崩していこうかと常に考えたり、情報収集しています。

改善の方向性

WebClass の開発で常に意識している点は以下です。

1. できる限り多様な環境で利用できること
2. わかりやすく汎用性の高い、シンプルな画面・機能であること
3. 素早く変化し続けること
4. 安くあること
5. 連携

コース画面のデザインを改めた際に目指した、主に利用者目線の点は以下です。

1. スマホ・タブレット・PCといった現在の利用環境へ対応
2. あっさり使う利用者がすんなり使えるように単純化

画面を直すにあたり、コードの設計も改めていっています。開発目線の点は以下です。

1. 画面・機能とURLのマッピングの整理
2. パラメータチェックやセキュリティ対応の詳細化

2000年代のころは大学で LMS を使っていただく方は、eラーニングや LMS の活用に積極的な方が多くありました。このような利用者から多数のご意見・ご要望を頂きながら WebClass も様々な機能をそろえることができました。

2010年代にはいって大学での LMS 利用が浸透し、先生方に教育でのシステム利用に興味があるなしに関わらず、学校設備の1つとして広く授業で使われるようになってきています。また、学生の方もとりあえずスマホでアクセスするのが当たり前になってきています。また、普段から利用する先生が増えるに従い、システムの不具合があった時に与える影響も大きくなっています。こうした変化に伴い、WebClass が先に取り組んでいたのは学生のスマホ利用への対応、ソフトウェア開発工程とソフトウェアテストの改善、セキュリティ実装でした。

そこからさらに一歩進める改善が、一昨年からの新画面の取り組みです。今ではあまり高度な機能がありすぎても、普段ちょっと使うにはかえって扱いづらいと感じられるケースが増えています。また、利用端末もスマホだけでなくタブレットが加わり、学生が使うかと思いきや先生もタブレットで利用するケースがあり、とても多様化しています。セキュリティについても、ますます重大なテーマとなっています。

コードベースの改善

先月、松川さんが「ソフトウェア設計 勉強の手引き」という記事をちょうど書いてくれました。

例えばある機能の画面をきれいに直すにあたり、見た目だけ直せればいいやと考えて HTML と CSS ＋ Javascript だけの書き直しでうまくいくかというと、経験的にはそう簡単に行きません。見た目の整理は取り扱う情報の整理になるので、結果的にはプレゼンテーション以前のデータ構造やデータの受け渡し経路を見直す必要が出てきます。特に Ajax を使った SPA にしたい場合、JSONデータインタフェースの実装が必要になるので、当然ながらインタフェースの拡張が必要になります。これらはセキュリティ実装でも同じことが言えます。したがって多かれ少なかれリファクタリングをすることになります。

利用者から見えないリファクタリングに時間を食われるのをもどかしく思うこともありますが、私は画面の改善でリファクタリングが必要になるのは好機と見ています。素早く確実にソフトウェアを改善し続けるためには、コードの保守性は重要です。これまで画面を変えられなかったのは、その様なコードの体制がなかったのも原因の1つです。ですがコードの問題は画面の改善だけでなく、テスト可能性やテストのコストにも反映されます。

幸いなことに、コードの設計は手本になる本やオープンソースのライブラリやプロダクトが多数あります。したがって、何を実現するかがはっきりしていれば解は比較的見つけやすいです。また、基本的には良いパターンを使いまわしていきます。なので、一か所で何とかすれば、同じような個所を一気に片付けることができます。そして、その後は維持しやすくなると期待できます。

見た目・機能の改善

コードベースの問題を乗り越えて実質的な機能修正に取り組むにあたり、一番問題になるのは「本当に使いやすいのか？」という点です。

コードの良さは計測しやすく、開発チーム内でコンセンサスが得られればOKという意味で、評価しやすいです。一方、画面や機能について利用者がどう思うかは計測・確認がしにくく、いろんな利用者がいてコメントの方向性が定まらないケースもあります。また、仮にいい画面になったとしても、慣れの問題が付きまといます。この点について個人的に印象深いのは Microsoft Office 2007 のリボンUIです。出た当時はいろいろ言われていましたし、私も「なんで？」と思いました。従来のメニューでは一通りの機能を本当に扱いきれなかったのかどうか私には評価できませんが、今では慣れて特に問題なく使っていますし、スタイルの適用などはUI表示域の広さと表示される情報とが程よく、便利だなと思っています。

真似しやすいコード設計に対して、UIや機能の設計は基本は考えてひねり出すのが良いと思います。利用者のコメントはありがたい参考資料になりますが、そのまま受け入れるだけだとブレます。特定の利用シナリオにぴたりと寄り添うほど汎用性を失って、オプションを必要としてしまいます。オプションも加えれば加えるほど動きがわかりにくくなり、テストやマニュアルの周辺作業が積みあがってしまい、機能を洗練させる時間を取れなくなります。

ではどうしたら良い機能や画面をひねり出せるか、これは私もいつも悩む問題です。やはりここは、いろいろ聞いたり試したりするしかないと思っています。特に、先生がどんな状況でどんなことをしようとしているか、というあたりでしょうか。WebClass のあるなしに関わらない、もう少し根本的なシーンやシナリオが見えてくると、考えやすいです。でも、特定のケースに固執しすぎては汎用性を失います。ここが難しいといつも思います。

取り組み続ける

利用者がいてくれる限り、WebClass の開発は終わりません。その時ごとにテーマや課題があり、常に変化・対応し続けていきます。今いいものも、2年後には利用環境と乖離して使い物にならなくなっている可能性もあります。それどころか、後になって昔の機能の価値を再発見してしまうこともあります。そういう意味で、コードベースの改善も画面・機能の改善も果てがなく、あまり考えすぎてしまってもしょうがないところがあります。

なので私たちはアジャイルなソフトウェア開発の仕方を取り入れています。小さく手堅い修正を素早く重ねて行く作戦です。画面の置き換えも、表には見えないリファクタリングだけ先に進めたところもあります。その中で、試したけど捨てたコードも多数あります。いいと思って採用したけど、思ったようには行かなかったコードも多数あります。ですが、これらは「うまくいかない」ことがわかった成果として無駄ではなかったと思っています。

いずれにせよ、多くの利用者が使うシステムでは「パパッと作って何とかなる」とは行きにくくなります。タイムリーに新機能や改善を提供し続けるためにも、普段からリファクタリングや試行錯誤を常にやり続け、そして学び続け、堅実なコミットを積み重ねていきます。