SEO対策への対策をするのはえらい

インターネットエクスペリエンスを劇的に向上させたのは、疑いもなく検索エンジンです。
キーワードを入力してボタンを押すだけで、何兆ページとあるwebページの中から、自分に必要(そう)なページを見つけてくれるのです。
信じ難い文明の利器ですよね。びっくり


そんな中、SEOという考え方、そしてビジネスが生まれてきました。
当然といえば当然です。
便利になればなるほど人が楽するようになるというのがまさにこのことだとは思いますが、
webブラウジングにある程度のリテラシーがある人にとって、ページ離脱率は半端なく高くなります。
検索した場合は、ふつう最初の1ページ目にある上位10件の見出しくらいしか目を通しませんし、ページにアクセスしたら瞬時にそのページに必要そうな情報があるかどうかを判断します。
仮にそのページに必要な情報があっても、ちょっとスクロールしないと見つけられなかったり、鬱陶しいデザインがあったりするだけでページからは離脱します。

webデザイナーは、訴求力を高めるために、見栄えだけでなく情報の見せ方といった内容にまで踏み込んでページを作ります。
でも、どんなに有意義なページを作成しても、SEO対策ページが出てくるとそれらには負けてしまいます。

本来SEOはwebデザインの1つと言えたでしょう。
でも、これがビジネスになると、非常に阿漕なつくりになっていくわけです。
検索エンジンさえだましてしまえば、とりあえず検索上位にくいこむという考え方。

先に、ある程度のリテラシーのある人なら、SEO対策で検索上位にくいこんできたページでも、アクセスしたところで実を伴っていなければすぐ離脱するのですが、ストレスになります。リテラシーがついてない人にとってみれば、CMと同じくらいやはり商売に貢献することでしょう。
これはwebの理想の姿ではありません。

せっかくのユーザーエクスペリエンスを損なう方向なのですから。

ところが、GoogleなどはこのSEO対策に対策をしてきています。
ブラックボックスとなっている検索エンジンのアルゴリズムは分からないことだらけですが、実を伴わないページはちゃんとはじくように常に改良をしています。

こういった努力は、ありがたいことです。


さて、最近テレビのCMでよく目にするのは
スマホアプリのCMなどで、最後に「○○でけんさく♪」みたいの。

上述のような思いがあったものですから、試しに検索してみて本当に上位に入ってくるのか確認してみました。
いや、検索結果はノーヒットでした。
それはそれでおそるべし(笑)^^;

今は、検索結果よりも上に、関連広告というものが出るのです。
そちらに載せているのですね。
SEO対策でwebを荒らすより、お金を払って関連広告という形で表示させるというのは、とても全うなやり方で評価できます。
ですが、テレビCMやって、さらにweb広告って、、、。広告費が二重にかかるわけですよね。膨大だあ。
それを回収できるほど儲かるのでしょうか。
似たり寄ったりなアプリばかりに見えますが、不思議だなあと感じるのでありました。
0

    WordPressデビュー

    WordPressをインストールしてみました。

    テンプレを一から作るのは時間がないから、テーマ選択ができるのはとてもいいです。
    だけど、テーマをインストールするとかゆいところには手が届きません。
    (google analyticsをどう埋め込めるのかは今度調べることにします)

    無料のブログサービスは、ソーシャルボタンなどあったらいいものが一通りそろっているので、気軽にという点ではやはり素晴らしいものです。

    もちろんWordPressでもソーシャルボタンや、facebookへの更新通知など送れるけれど、

    • 一手間かかる
    • テーマとデザインがマッチするとは限らない
    • プラグインの信頼性は自己判断

    というデメリットがあると感じます。

    まあ、それでもユーザー管理しながら拡張も可能な状態で運用できるCMSって本当にありがたいものですね。


    作ったサイトは、まあ探してみてください楽しい

    0

      フラットデザインは定着するか

      windows8などで取り入れられ、iOS7のアイコンに採用されることですっかり一般的に知れ渡った「フラットデザイン」。
      これまでのリッチさを追求したデザインからの一新で賛否が分かれています。

      私は、フラットデザインが「反リッチ」=「貧相」という視点とは別で、定着しないのではないかと考えています。

      定着しないと考える一番の理由は
      フラットデザインは、1つのコンセプトのもとに機能するものである
      と考えていることによります。


      このことに言及していきたいわけですが、他の定着しないと考える理由も先に挙げておきます。

      ・フラットデザインができるのは、専門的な知識のあるプロのデザイナーだけ。
      ・フラットデザインと、ユニバーサルデザインはちがう。


      さて、フラットデザインとは何でしょう。
      上述したリッチデザインの反義語というだけでなく、
      余計な装飾を省き、実物を2次元化して、ユーザーに機能を判別しやすくしたデザイン
      などと表現することができるのかもしれません。
      フラットデザインは、そのどちらにも該当しているものが望ましいのでしょうが、単に平べったくなったものを指していることもあります。実物の2次元化ではなくテキストを使うこともありますね。

      私がデザインした横浜市立本郷台小学校のHPも、まあフラットデザインに分類できるかもしれませんね。
      挙動はAjax制御ですが、見た目は判別しやすいように、無駄な装飾がありません。
      横浜市立本郷台小学校HP


      プロにしかできないと言っておきながら、素人の私がデザインしているわけですが、それは1つのコンセプト上でのみ制作されているからです。台小HPのデザインは私しかしないからです。
      (もちろん、素人の私がデザインしてますから、貧相なフラットデザインとも言えるでしょうが^^;)


      このように、もともとフラットデザインは、至る所にありました。
      ガラケーなどの多くもフラットデザインと言えます。
      クリエイターが、ユーザビリティーを考え抜いて、デザインしたものです。
      しかもそれが、排他的な空間であるからうまく機能しているのです。


      iOSにしてもAndroidにしても、アプリ制作者が何万人といます。
      カメラアプリを例にとってみましょう。
      極限まで無駄な装飾をなくし、カメラの形をデザインにとりいれたとして、他のカメラアプリとどう差別化できるでしょうか。
      これは、本当にプロのデザイナーでなくては、「意味があり、自身のアプリであることをユーザーに判別しやすくする」ということをやってのけるのは困難です。
      また、ユーザーにとってみれば、似たようなアイコンがいくつもあることになり、リッチデザインよりもむしろ判別がしにくくなります。
      緑の三角形が再生ボタン、赤の丸が録画ボタンのように、誰もが分かるユニーバーサルデザインとは違います。
      クリエイターにしてみれば、どうしても差別化が必要であり、共通化だけでは実現しないのです。
      フラットデザイン例

      ユーザビリティを意識してデザインされるフラットデザインと、類似のアプリが乱立するスマホのアプリアイコンは、あまり相性がよろしくない、そう考える次第です。
      0

        jsonブログ

        久しぶりにJavascriptのコーディングをしました。

        webデザインの話ですが、リアルでの私の知人の方は、おそらく興味ないあるいは意味不明な記事になると思います。

        今回の記事の材となるのは、このページです。
        ソースコードはこちらです。(テキストエンコーディングはutf-8)

        私はExcelのデータをブログ様式にする疑似ブログシステムを作り、学校HPにて導入していますが、他にトピックスはjson形式で疑似ブログシステムを組んでいます。

        トピックスは基本、作成に私しかかかわらないので、直接json形式のテキストデータを編集できますし、データ容量がコンパクトになるからです。


        すでにブログ様式に仕立ててあったので、今日は何をしたかというと、見た目的にはほんとうにちょっとの変更です。
        月の表示を日本語表記にしたのと、年度ごとのjsonデータの切り替えのバグフィックス。
        それとソースコードの整理です。

        ちなみにトピックスのjsonデータは
        	{
        		title:"タイトル",
        		day:"日付",
        		photo:"画像",
        		morephoto:"(今後の拡張用で未使用)",
        		download:"ダウンロードファイル提供がある場合はurl",
        		description:"記事本文",
        		category:"投稿主体",
        		PageTitle:"実質のカテゴリ",
        		uri:"詳細ページのurl(実質未使用)"
        	}
        を1記事分として記述しています。


        アーカイブリストの月表記の日本語化
        jsonデータは、トップページにも読み込ませています。
        カレンダー風にデザインしたので、記事作成の月は「見た目がいい」というだけの理由で、小学校HPにもかかわらず英語表記にしていました。
        それゆえ、8月17日ならば、jsonには「AUG.17」と記述してあります。

        アーカイブリストの生成には、dayの始めの3文字分を抽出し、リスト項目の配列に格納。
        indexOfを利用し、同じものが既に格納されているかをチェックし、新しいものを順次登録するようにしてあります。

        リストにする際、例えばAUGを抽出したら「8月」に変換して登録すればいいだけに思えますが、実はこのリストにはイベントが設定されており、クリックしたリスト項目の文字列と同一の記事をdayの中からソートするようにしてあったので、表記を「8月」にしてしまうと「AUG」の記事を抽出できなくなってしまいます。
        8月をクリックしたらまた今度はAUGに変換して・・・というのはあまりにスマートでないので、それは避けたかったのです。
        そこで、クリックしたリスト項目の文字列でなくて、クリックしたリスト項目のID属性でソートするようにしました。
        <li id="AUG">8月</li>
        みたいな感じですね。
        リスト生成の際に、idにはそのままdayの3文字を代入し、テキストには変換したものを代入するようにしました。

        	var n = tagName[i].substring(0,3);
        	whatMonth(n);
        	check = a.indexOf(m);
        	if(check < 0){
        		a[i] = m;
        		gList += "<li><a href='#' id='m" + n + "'>" + a[i] +"</a></li>";
        	}
        
        tagNameとしてあるのは、リスト生成機能をアーカイブリストとカテゴリリスト併用しているからです。この場合のtagNameはdayです。(実際はdayを一度、配列daysに格納してあるのでdaysですが)
        whatMonth(n)の中身はスイッチ文があります。AUGなら8月というやつです。
        変数mに入れられて戻ってきます。
        a.indexOf(m)で、配列にすでに8月が登録されているかを調べています。
        次のif文で、登録されていない場合は登録するようにしています。
        idにはAUGを(エラーが起きないよう、便宜上頭に文字を一つつけています)、
        リスト項目となるテキストには8月が入ります。


        年度データの切り替え
        これまでは、年度ごとに新しくデータを流し込む雛形となるhtmlファイルを設けていましたが、年度のリストをクリックしたら、その年度に対応するjsonデータを呼び出し、再表示させるようにしました。
        これは以前に実装してあったのですが、実はバグがあったことが判明。
        切り替えた後も、切り替える前のデータが残ってしまうというもの。
        配列を初期化していなかったために起きていました。
        ちょっと煩雑ですが、配列を初期化するよう記述しました。

        	titles.length = 0;
        みたいな感じ。
        titlesは、タイトルを格納した配列です。
        この記述で配列を初期化できることは、今日知りました。


        ソースコードの整理
        私がwebクリエイターとして、素人であるゆえなのですが、
        実際これだけのJavascriptをコーディングできるだけでも、我ながらたいしたものだと思うレベルです。
        コードをシンプルにしていくのは、永遠の課題です^^

        疑似ブログの仕組みを簡単に説明すると
        初期表示では、まず記事数が10に満たない場合は全て表示する。そうでなければ最新のものから10個を表示するようにしています。
        リストをクリックした場合は、それに対応した記事を抽出して表示するようになっています。
        for文でぐるぐるするのはいいのですが、1記事分を生成するコードをどうしたら1つにまとめられるかずっと分かりませんでした。
        今回は、「今年度の記事を全て表示する」という機能をつけようかと思い、その機能のためにまた同様のコードを書くのは煩雑だったので再挑戦したのでした。

        		for (i=0; i<titles.length; i++){
        			generateArticle(i);
        			resultData += article;
        		}
        
        のように記述することで、1記事分の生成する機能へ渡して記事データを戻せることが理解できました。めでたしめでたし。
        これは普段使っているAjax × Excel × Blogにも適用できると思います。
        わーい。



        あきらかな自己満足記事ですが、所詮ブログなのでご容赦ください。
        そんなロジックよりもコンテンツを充実させろというおしかりもいただきそうですが、
        サーバーサイドスクリプトを使えない横浜市では、HP1回ごとの更新の手間を極力小さくすると同時にユーザビリティを確保するのは死活問題なのです。。。


        JUGEMテーマ:WEB作成のテクニック 
        0

          トップページのデザイン

           私がこの5年間、学校HPのトップページデザインで貫いているのは
          「シンプル」
          ということ。

          単純なつくりの中に、見応えがあるように。
          ごちゃごちゃして、どこを探したらいいかわからないサイトにならないように。

          こういった思いから、サイトマップ上の上位カテゴリ以外へのリンクしか貼らず、トピックスに目がいくようにしていました。

          indexというのは「目次」のことですから、本当はアクセスしたいページへ一発リンクがベストなのですけど、そこらへんは私もプロではありませんから、限界を感じながらやっていました。

          もちろん、個人的好みもあるんですね。
          プルダウンメニューは好きじゃないとか、アニメーションGIFが嫌いとか^^;

          そういったコンセプトを保ちつつ、今年度4月に3回目のリニューアルをして、今の形になっています。
          担当者がかわっていないのに、5年でリニューアル3回は多いと思いますが、周囲の方からはいずれも「改善」であって、歓迎していただけました。
          また、今回のリニューアルは、私の一存ではなく、HPPメンバーで話し合ってできあがったものです(たたき台はもちろん私が出しましたが)。みんなで決めた形なので、しばらくはこれで続けていき、これで引き継いでいこうと思っています。


          その上で、私が今悩んでいること。
          それはトップページコンテンツを拡充するか否かということ。
          HPPから特集ページへの誘導に課題を指摘されているのですね。
          今はお知らせ欄に特に見てもらいたい特集ページのお知らせとリンクを貼っていますが、もう少し訴求したいとかなんとか・・・。
          でも、仮に特集ページのバナーを作って貼付けるとすると、それだけトップページでいじくらなくちゃいけない部分が増えてしまい、引き継ぎが心配になるのですね。

          例えば、特集ページのサムネイルを自動作成してトップページに流し込んでくれるようなAPIがあったとしてそれを利用するというのも1つの手・・・とは考えにくいのです。
          さほど変更するものでもないのに、クライアントがトップページをリクエストする度にAPIに接続していたら読み込みにも時間かかって不便です。(現時点でも3つのAPIを利用してますし・・・)

          引き継ぎとしては、トピックスを読み込むjsonデータ、お知らせ欄、お便り欄の3つが限界だと思っています。特集ページ紹介をランダムに読み込ませる用のxmlなりjsonデータを増やすのは、う〜ん・・・。厳しいと思うなあ。
          0

            Ajax × Excel × Blog

            「Ajax × Excel × Blog」
            というブログシステムを開発しております。

            すごいことができるわけではないのですが、ある特殊な環境において力を発揮します。

            Ajax × Excel × Blog の一番のウリは、

            “非CGI環境で稼働する”

            という点です。

            学校など自治体のネットワークに依存している場合、セキュリティの問題からCGIが利用できないことはすくなくありません。
            さらに、これも情報管理の問題から、外部サーバーに学校ホームページコンテンツ(オフィシャルなもの)を設けることも規制されています。
            横浜市もこれに当たります。

            こういった自治体では、「ホームページを更新しなさい」と言われても、スタティックなページを地道に作るほか無いのですね。
            ご存知のことかとは思いますが、スタティックなページを作成するには多少なりともHTMLの知識が必要であったりして、技術的な敷居がぐっと上がっているのです。
            こうなってくると、本来の「学校ホームページを更新する」ことの意味さえ考えることはなくなり、現場では無理難題としてまいってしまうわけです。

            この問題をなんとか解決できはしまいかと考え、開発したのが、Ajax × Excel × Blogなわけです。


            システムの概要は、

            あらかじめ用意されたテンプレートに、記事データとなるエクセルのデータを、JavaScriptで流し込む

            というもので、
            エディタにとっては、エクセルを開いて、一行記事を入力するだけですみ、
            管理者にとっては、差分ファイルをアップロードするだけですみます。

            簡便かつ、分業を実現しているので、システムとしては一般のプロダクツよりはるかにしょぼいものだとしても
            導入にはかなりのメリットがあります。

            おかげさまで、全国でもあちらこちらで使っていただいております。
            開発者としては、嬉しい限りです
            ということで、
            Ajax × Excel × Blog
            関連のヘルプもこのブログから受け付けます。どうぞご利用ください。
            0

              | 1/1PAGES |

              小学生発!Pray for Japan

              search this site.

              profile

              selected entries

              categories

              archives

              recent comment

              recent trackback

              Twitter

              ブクログ

              facebook

              links

              recommend

              教育×破壊的イノベーション 教育現場を抜本的に変革する
              教育×破壊的イノベーション 教育現場を抜本的に変革する (JUGEMレビュー »)
              クレイトン・クリステンセン,マイケル・ホーン,カーティス・ジョンソン

              others

              mobile

              qrcode