WordCamp Kyoto 2017 に参加

WordCamp Kyoto 2017 が京都大学で開催されたので行ってきました。(詳しくはこちらのリンクを参照)
https://2017.kyoto.wordcamp.org/

1日目だけですが、参加したセッションはこちら。

(1) WordPress の今とこれから
(2) wp-cli入門
(3) WP REST APIで実際なにが嬉しいの?
(4) WordPressユーザーのためのProgressive Web Appsの話
(5) WORDPRESSセキュリティ:攻撃対象になるのを避けよう
(6) ニュースアプリのAPIにWordPress.comを採用してよかった話
(7) 簡単!Webフォントクッキング ビギナーズ
(8) ライトニングトーク
その後 懇親会

それぞれの感想を書きたい気もしますが、大変なので、ひとまず私見を交えた雑感として・・・

ウェブサイトは、昔は「ページ」を中心とした概念で、サーバーにページを置いて、それそのものにブラウザでアクセスして見る、というような比較的単純な概念だったものが、
現在では「データ」という捉え方がされていて、それを作成する、保管する、表示する、などの役割を担っている処理や場所が分かれていて、いろいろな組み合わせが生じている、

という状況なのですが、今回のセッションを聴いていて、そのことを強く感じました。
(私自身がそういう目で参加するセッションを選んだせいかもしれませんが)

従来、サイトページを作っていた者として、それが仮にアプリケーション作りに変わってきたとして、
サーバーに何を任せるか、アプリケーションのデータ処理と管理はどうあるべきか、端末から入力したり、表示させたり(あるいは文字だけでなく音声入力であったり)するユーザーインターフェースをどう形成するか、
というように、自分(あるいは顧客)が必要とするものに如何に適切にフォーカスし、それ以外のいわば「煩わしいもの」をどのように手の中から安全に切り離して合理化していくか、という取捨選択が「非常に」求められているような気がしました。

というわけで、個人的にはとても興味深いセッションばかりでしたし、聴いていて「ふむふむ」と感心したり発見することが多く、楽しかったです。
と同時に、自分の仕事にも変革が迫られてるなというプレッシャーを感じました。

ちなみにお昼は、会場で用意されていたおにぎりとパンとお茶を頂きましたが、そのあと、キャンパス内にあるカフェテリアを見に行ってみました。それが上の写真です。

夜の懇親会は、お寿司でした。とても美味しかったです。
こういった食事を無料で頂けるなんて、素晴らしいですね。それも沢山のスポンサー様と、お世話して頂いているスタッフ皆様のおかげです。
WordCampの懇親会はたぶん初めて参加したと思いますが、何人かの方と有意義なお話ができて良かったです。

Webアプリケーション開発

一般に「アプリ」と呼ばれているものは「モバイルアプリ」つまりiPhone, iPad, Android 等にインストールして使うアプリケーションのことを指していると思います。

このアプリを使ってサーバーにアクセスして情報を受け取ったり送信したりするわけで、「アプリ開発(制作)」とはこのように端末にインストールして使うモバイルアプリを作ることを意味しています。

一方「Webアプリケーション」と言われるものは、一般的にサーバー側に設置されていて、端末からは「ブラウザ」を使ってアクセスして情報を受け取ったり送信したりするもので、「ウェブサイト」をシステム的な見方で表現したものと言えるかもしれません。それを開発することは「Webアプリケーション開発」(あるいはWebシステム開発)と呼ばれます。

当方はウェブサイトを制作しながら、Webアプリケーションの開発も行っています。願わくばモバイルアプリも開発したいところですが、今はまだそこまでは行きません。

Web制作で作られる「ウェブサイト」は、画像とテキストが入った文書(情報ページ)を表示して、ページを送って見ていくということと、問い合わせや注文フォームなどを設置して顧客との連絡が取れるようにしたものが一般的です。
これらは、例えば、WordPress のように CMS (Content Management System) と呼ばれるWebアプリケーションを使って制作されていて、改めて特別なアプリケーションを作らなくても良いような状況になっています。

自分で作れるホームページサービスや、すぐ開設できるネットショップなど、特定のサービスプロバイダと契約して使うシステムでは、それらの業者のサーバーに専用のWebアプリケーションが構築されており、それらを一般のユーザーが使って目的を実現できるようになっています。

それ以外で、何か自分たちでWebサービスのようなものを作って機能を提供したいとか、普通のウェブサイトではやらないような主宰者・ユーザー間の情報のやり取りをしたいとか、何か特定の情報を管理するためのサイトを作りたいとか、そういった目的がある場合に、Webアプリケーションを開発することになります。

この場合、やりたいことを整理して、仕様を作り、システムの構成を設計して、プログラミングを行い、サーバーに載せて動かす、という一連の作業が必要になります。
当方では、通常のWeb制作のかたわら、このようなWebアプリケーション開発も行っています。
ただ、やはりチームでの開発を行っていないため、規模は限定的になります。納期も余裕をみさせて頂いています。

現在は、1件、Webサービスのためのアプリケーションを開発中ですが、その他の制作案件も二、三、並行して実施していますので、ありがたいことですが、5月ぐらいまでは手一杯の状況です。

以上、今回は、Webアプリケーション開発について書いてみました。

サイト来訪者のモバイル率 その2

おかげさまで忙し過ぎまして、新年のご挨拶以降、日記書けてませんでした。
クライアントさんには「ブログ書いてください」とか言ってるのに自分が一番、書いてないです。(汗)Twitter, Facebookはしょっちゅう書いているのに、ブログとなるとプライベートブログでも最近はなかなか書けなくなりました。

それはさておき、2年前に自分が直接管理しているサイト4つのモバイル率について、Google Analyticsで調べた結果、次のような数値になっていました。
(今回は順番変えて mobile を先に持ってきてます)

サイト: mobile | tablet | desktop | モバイル対応有無
(モバイル率が高いもの順)
サイトA: 59% | 7% | 34% | ◯
サイトB: 48% | 9% | 43% | ◯
サイトC: 39% | 6% | 55% | ×
サイトD: 33% | 6% | 61% | ×

今回は、8サイトほど、2017年1月1日〜3月17日までの概ね3ヶ月の平均を取って比較してみました。前回のサイトも含まれていますが、どれと対応するのか、記録してないので、そのままずらずらと並べます。

サイト: mobile | tablet | desktop | モバイル対応有無
(モバイル率が高いもの順)
サイト1: 74% | 4% | 22% | ◯
サイト2: 72% | 4% | 24% | ◯
サイト3: 55% | 8% | 37% | ◯
サイト4: 47% | 6% | 47% | ◯
サイト5: 45% | 3% | 52% | ◯
サイト6: 39% | 6% | 55% | ×
サイト7: 38% | 3% | 59% | ◯
サイト8: 30% | 4% | 66% | ◯

全体的に、モバイル(スマホ)での訪問者は増えてきている印象ですが、うちのクライアントの業種がインテリア業界が多いので、パソコン(desktop)で見ている方もまだまだ多い方だと思います。

サイトのデザインとしてのモバイル対応は、今は必須となっているので、対応するしないでどのくらい違うとか、あまり言える材料がありません。非対応サイトを対応させるとどのくらいアクセスが上がるのかとかも、うちはデータが少ないので判断できないのが正直なところです。

ただ、やはりスマホで見ている人はかなり多くなったという認識だけは持っています。

PS. 去年、今年辺りは、軽くてかっこいいノートパソコンが各社から出てきていて、カフェでノートを開くというスタイルも定着してきているので、PCユーザーはもしかして持ち直すのでは?と思ったりしています。

謹賀新年

2017年となりました。
新年あけましておめでとうございます。

昨年も、ネットショップの更新、制作会社様のサポート、新規サイト構築など、いろいろな種類のお仕事を無理のないペースでご提供することができました。お声がけくださいました皆様には厚く御礼申し上げます。

本年も引き続き、様々なご要望に対し、それぞれのクライアント様、案件に応じた解決策を考えご提案しながら、Webサイトの活用、発展に寄与して参りたいと考えております。
どうぞよろしくお願い申し上げます。

SNSのブームも落ち着き、スマートフォン対応も定着し、検索・SEO関連もウェブサイトの実質が問われるような時世となってきている今日この頃、内容や存在意義、効果、といったものにきちんとフォーカスしたサイトづくりを地道に継続していくことが大切です。

PS.
本日、初詣に出かけた近所の廣田神社での一コマを添えておきます。

初詣

Web制作特有の工数

わりとよく耳にするような話で、「チラシのデザイン5,000円ぐらいなのにWebページ1ページがなんで何万円もするのか?」というのがあります。
私自身はそういうことを直接、クライアント様から言われたことはありませんが、「なんとなくそう思われているんじゃないかな」と感じるときはたまにあります。(^^)

印刷とWebは全然違うものなので、そもそも比較することは出来ないのですが・・・
たしかに、ショップなどでも実店舗を作るよりWebサイトを作った方がよっぽど安いとか、印刷だったら部数分の印刷代が掛かるからWebの方が安上がりだ、というのはその通りかもしれなくて、だからこそコストメリットの点でWeb制作は優れているということにもなるわけですが、
Web制作にもそれなりの世界があって、それ相応の工数(手間)がいろいろと掛かりますので、簡単な事例で説明したいと思います。
(コンピュータなので、なんでもワンタッチでできてしまえば、我々ももっと楽に商売が出来るというものですが・・・)

 

例えば「すでにサイトにアップされている画像を差し替えたい」という場合、
(ブログやCMSなどのようにユーザー自ら、今ある画像を削除して新しい画像をアップしなおすという場合ではなく、あくまで制作者がCMS管理画面を使わずにファイルを更新する場合)

(1) 新しい画像を作って用意する。
もしPC表示用とスマホ表示用の2種類の画像がある場合は2種類用意する。

(2) HTMLファイル上(またはCSSファイル上)に書かれたファイル名を新しいファイル名に変更する。
ファイル名を変えない場合は、キャッシュ防止のため(後述)ファイル名の後ろに日付などの文字列(クエリー文字列)を書き加える。

(2-1) CSSファイルに画像のURLを記述している場合は、キャッシュ防止のため(後述)HTMLファイル上のCSSファイル名の後ろに日付などの文字列(クエリー文字列)を書き加える。

※PC表示用とスマホ表示用の2種類のHTMLやCSSがある場合は、それぞれに同じ対応を行う。

(3) 画像ファイルとHTMLとCSSをサイトにアップする。

(4) 正しく表示されているか、それぞれの端末で確認する。

※いきなりサイトを修正・確認するのが問題がある場合は、テストサイトで一回、上記の作業をしてから、本番サイトで同じ作業を実施する。

※キャッシュ防止とは?
ウェブサイトを閲覧するソフト(ブラウザ)には、前に見たページをパソコンに記憶して、次回アクセスしたときにページが変更されていない場合は記憶されたページを見せるという「キャッシュ」の機能があります。
ですので、ファイル名が同じ画像ファイルをアップすると、以前のファイルと同じだと判断されて、記憶された古い画像を表示してしまいます。
それを防止するために、HTML等に書かれたファイル名を変更する必要があるのです。

 

というわけで、たった1枚の画像を差し替えるだけでも、担当者はこれだけの作業をすることになります。
個人の趣味のサイトでしたら、単に同じファイル名の画像を作ってアップするだけでも良いですが、商用のサイトではやはりきちんと作業したほうが、更新した内容がより確実に訪問者に届きます。

上記はあくまで
Web制作には「いろいろ細かくてシビアな工程がある」
ということをお伝えするための例です。

実際にはクライアント様のワークフローや制作側の環境、サイトの作り方等によって更新や確認作業の手順も異なりますので、参考としてご理解頂けましたら幸いです。

ページトップにもどる