$CommStep開発者のブログ

ホームページと言われる、Web上の画面を作り始めて
何年になるだろう。

約15年位前当時はまだ、HTMLエディターと言われる物も無く
Notepad等で文字入力していたのを思い出します。

当時の環境と言えば、ネットワークの速度も遅いため
画面表示ストレスをユーザーに感じさせない様に
なるべく一画面内の情報量を少なくし、タブ等で複数画面に
別けて作っていました。
また、ユーザー要望もあり、なるべくマウススクロール無く
一画面の中に収まる様に画面設計をしていました。

あれかれウン十年・・・
ネットワークの回線スピードも上がり、ネット人口も増え
HPやBlog、SNSとかなりの情報量が増えて来ています。
そんな中、HPの画面設計のトレンドも変化している気がします。

昔は表示はなるべく一画面、タブを使い複数画面に遷移

今は回線スピードも上がり、ユーザーも見る画面が増えたので
一つのページに画面遷移してまで留まらなくなっています。
むしろマウスでスクロールする機会が増えている感じがします。
そんな中で、最近のHPは画面遷移はせずに、
一画面の中に全て表示したスクロール画面的なページがトレンドに
なって来ています。

少し、考えて見て下さい。
Blogを流し読みする時に「次ヘ」を押すよりもマウスでクリクリ
した方がスムーズに読めませんか?
FacebookやTwitterなどでもそうですよね。

これからは企業HPも体裁的な画面遷移的HPから
見やすいスクロール的な一画面HPが増えて来ると思います。


$CommStep開発者のブログ

お仕事の一つに公共施設の予約状況を閲覧する仕組みを
提供させて頂いています。
これは施設の予約システムは工数も掛かり大掛かりなので
当面はアナログでも構わない とお客様の意向で
一日一回、事務員の方がファイルを更新しFTPにてアップロード
してWeb閲覧を行うと言うシンプルなものです。

サーバーはクラウドサーバーを使用してサポートは万全?
担当者にマニュアルも渡し何度かテストしてOK
公共のHP側からも予約確認画面にリンクを張って頂き準備OK

と思っていた矢先 「画面が表示されない」とHELPコール
お客様事務所を訪れ原因調査・・・
しかし、こちら側の設定その他は異常なし
奇しくも、同時期にクラウドサーバーがDDoS攻撃を受けて
大ダメージとかのニュースとも重なり、サーバーメーカーの
サポートページを確認した所、数回のDDos攻撃は受けていた模様

今回のトラブル原因はクラウドサーバー側の問題で
こちら側の過失では無い、
しばらくメーカーの対応を待ちましょう、とメールや
メーカーFacebookページ上で状況だけは報告して置き
状況改善のモニターだけはしておりました。

しかし、翌日になっても改善の兆しは見えない。
少しメーカーの対応に苛立ちを・・・

もう一度、初心に帰り、Webの更新手順を追って確認して見ると
サーバー側にあるはずの無いディレクトリが存在している。
???????
原因判明しました。
お客様の担当が誤ってFTP更新すべき階層の下に
もう一階層作ってしまいそちらにコピーしてました。

今回の反省
・サーバー管理を外部に任せなので、調査がブラックボックス
でありサーバー側の問題と思い込んでいた。(切り分けが困難)
・お客様はマニュアル通りに処理すると思い込んでいた。
・同じタイミングにてニュースで騒がすサーバーハッキング事件が有った。

全て思い込みが問題解決を遅くした原因でした。(汗・・・)
対策としては、ユーザー側の処理を自動化してボンミスを
なくす様にバッチ作業に修正致します。

トラブル対応の基本を忘れていたお粗末な内容でした。
$CommStep開発者のブログ

現在、モバイル機器用のWebアプリを作成中ですが
アプリケーションとモバイル機器の機能の限界?
に付いて整理します。

Facebookを例に取ります。
Facebook用のアプリケーションには
・通常のPC用Webアプリ
・モバイル用Webアプリ(スマホやタブレット用)
・iOS用専用アプリ(iPhone、iPad用)
・AndroidOS用専用アプリ
・携帯電話用アプリ(キャリア毎?)
今、分かるだけでもこれだけあります。 プラス世界言語対応分

そうなりますと、当然 マルチデバイスの機能の違いを
アプリケーションの方で吸収する必要が有りますが
機能にも限界があります。

Webアプリケーションからスマホ系の画像ファイルやカメラ
コントロールは厳しいです。
そうなると、画像ファイルやカメラコントロールは専用アプリに
任せるしか有りません。
チェックイン機能(GPS)もモバイル機器の機能なのでWebアプリ
からはコントロールが難しいです。

マルチデバイス対応となりますとWebアプリではデバイスの機能を
吸収し切れません、デバイス別の専用アプリが必要になります(現時点では)

そうなると体力の無い(弊社の様な)ソフト屋さんが
マルチデバイス対応のアプリを作るには限界があります。
(工数や規模において)

ここが課題です。

でも、方法論はモチロンあります
この部分は長くなるので次回に

$CommStep開発者のブログ

Facebookビジネス活用を模索する中
リアルなFacebookマーケティングを展開しています。
目的としては
北関東の地で何処まで、Facebookが浸透し
Facebookのビジネス活用が有用性を確認中です。

ページを開設後、約2ヶ月経過しましたので現状と
これまでの過程をレポートします。

仕掛けた事 【オ】オーナー実施項目、【シ】サポート実施項目

【オ】Facebookページとして、お店のオープン後から
Blogで応援して頂いたページをリンクしお礼の書き込みから開始。
【シ】Facebookページを作成後しばらく放置
何も仕掛けないで感度の高いアーリーアダプターが
発見してくれるか確認。
⇒数件のイイねはあるが、動きは無し。
【オ】オーナーBlogで告知
オーナーBlogも人気ページなのでそこからの流入を期待
⇒ここでも数件の動きしか確認出来ず。10名以下
【オ】お店のレジ横にPop(facebook始めました)告知
⇒FBを知らない方からも「何これ?」反応を期待しましたが
変化無し。

この頃から、オーナーも心配になって、少しこのFacebookのビジネス活用に疑心暗鬼になる。
しかし、ジックリ育てるのがSNSビジネスと言う持論からもう「少し辛抱を」とお話

一つ重要な落とし穴がありました。(私のミス)
レジ横ににPOPを置いたのでは、お客様が帰りモードで
話題になりません、食事やお茶中の会話話題にならないと意味が有りません。
そこで、ミニPOPをメニューの中にさりげなく挿入。

お店に来店して頂いたお客様Blogも半年経過すると
動きも鈍化して来て、FBへの掲載リンクBlogも減ってしばらくFB自体に動きなし。
動きの悪いページは人気ページになるはずが有りません。

【オ】毎日の一コマを画像と一言を掲載。
⇒この間約一ヶ月、動きが無かったFBページが急に活性化
イイねも増え、コメントも急に増えて来ました。
この頃からオーナーもFBの使い方にも慣れ、反応の早さに驚き
実務で忙しい中ではありますが、お客様とのFB繋がりを
楽しめる様になって来ました。

ここで、開設後2ヶ月間の総括をします。
・無駄な戦略は必要有りません、情報を発信し続ける事。
・しかし、注意すべきはビジネスモードを全面には出さない。


6月20日現在で
「47イイね」ファンの友達としては1500まで増えています
口コミ度も50%になって来ました。(インサイト情報より)

ここからがポイント
約50「イイね」は感度の高いアーリーアダプターの方と
お祝儀顧客(友人や知合いをこちらから誘った方)の人数です。
しばらくはこの人数で動かないでしょう。
「ここが第一の壁です」

この壁を打破するためには
・定期的なイベントをし掛ける。
・マジョリティ層に訴えかける仕組みを構築。


第一弾としての「楽しい場」は出来ました
その次を成熟させるのが正念場です。
これからの戦略が重要になります。



お店の応援共々、Facebookページ成長を見守って下さい。
大泉町 CafeひびきやFacebookページ
http://www.facebook.com/Hibikiyacafe
$CommStep開発者のブログ

最近、Facebookオフ会や事業主さんとの飲み会の席で
「社内でもFacebookのようなコミュニケーションが取りたい」
と言うお話や相談を受ける機会があります。

FacebookのGr登録して仕事とプライベートを分ける事も
可能性ですが、諸々煩わしい所もある様です。
・自分の部下に知られたく無い情報
・上司、社長に知られたく無い交友関係
・社内が接待ゴルフを投稿しただけで、
「イイね」では無い「イイよな」と社員にひがまれる。

こんな事もあり、Facebookでビジネス活用はしたいけれど
身内でのビジネス会話には一線を画したいと言うのが本音です。

以前、何処かでも発信しましたが
オススメの社内SNSツール(Facebookの企業版)とも言える
Salesforce社Catterと言う製品です。

これは完全企業向けで、前提条件が会社のメールアカウントで
同一ドメインの方しか共有出来ない仕組みです。

使い勝手はFacebookと同様で、FBユーザーであれば
何の違和感も無く使えます。
情報の共有や個別メールを使うよりは遥かに便利です。
・情報のカテゴリー分類も可能。
・小規模企業向けであれば承認回覧にも応用出来ます。
・開発力があればカスタマイズや他製品連携も可能

弊社(と言っても数人ですが)かなり使い倒しています。

製品自体は無償ですが、使う前には社内ルールや
運用コンセプトを決めてから評価導入をお勧めします。

是非導入したい又は導入サポートを依頼したいと思われる
太田市近郊の事業主の方はご相談頂ければサポートさせて頂きます。

システムコンサル費用詳細はここで書くといやらしいので
初回相談位は無償でのらせて頂きます。

その後は夜の街ワンタイム位の月額で年間契約と言う事で。
夜の蝶と同様いい仕事しますよ(苦笑)




CommStep開発者のブログ


会社だけでPCを使ってファイルを更新して
たまに家で加工する場合にはUSB等を使ってコピーする人も

多いと思います


会社のイントラネットを使っている場合は外部ネット環境の
制約は有るでしょうが

もし、制約が無くて会社でも家庭でも出先のモバイルPCでも
ファイル共有をしたい場合


ここまでの製品であれば色々な種類の製品が今までもありました。


しかし、これからが革新的ですひらめき電球

Windowsであればファイルエクスプローラーにて
普通のドライブとして使用出来る仕組みです

この興奮伝わりますかメラメラ


今までのC:ドライブの様に呼出更新書込みが普通に出来ます。

言うなれば、共有の大型ファイルサーバーにいつも繋いでいるイメージです。


凄いと思いません はてなマーク


これもクラウド技術とGoogleの成せる技です


今回は良いところだけしか書いていませんが必ず
負の要素も幾つかあります。(ここは次回)
それをも凌駕する革新的なシステムでだと思います


オット、興奮して製品名を言ってませんでした(苦笑あせる
「Google Drive」と言う機能です。

Googleのメールアカウント(@Gmail.com)が必要です
まだ、いじり倒していないので評価までは出来ませんが
こちらも追い追いレポートして見ます。




CommStep開発者のブログ

本来のFacebook機能的にはPCの方が設定や参照も
し易く出来ています。


しかし、内容がプライベートになっていますので
これは家庭内でも起こり得る事です。

さすがにPCが家庭に浸透したからと言っても
一人一台の家庭はまだまだ少数派だと思います。

家庭内共有PCではプライバシーが難しいです。

家庭内でも、Facebook内のプライバシーは覗かれたく
無いのが本音でしょう。

そうなるとプライバシーを守ってFacebookに接続・・・
この手段がスマホに移行して行く事は間違いないです。


リンクFacebook、スマホからの利用時間がPC上回る

今後のFacebookユーザー増加の鍵はスマホになります。

特に現在はスマホ&Facebook未経験ユーザー層
おばさま層はかなりのBigマーケットになるでしょう。

そうなりますと気になるのが「らくらくスマホ」です。

おしゃべり好きで、有閑マダムで口コミ力絶大のおばさま層が
夏にかけては台風の目になる気がします。


CommStep開発者のブログ

今回のテーマは、少額決済の救世主になるか
「Google In-App Payments API」について考えます。


モバイル系ソフト開発は言語選択が難しい。

でも書きましたが、モバイル系ソフト開発&販売は


・ネイティブアプリ:iPhoneやAndroid専用アプリ
・Webアプリ:HTML5/jQuery Mobile等

が大きな所ですが、薄利多売のモバイル系アプリで
ネイティブアプリの選択もありますが、


デバイス毎に開発する必要があり、決済のための
iPhone系であればApp store
Android系であればAndroid Market
を使用する必要があり、審査&認証がネックになります。


もう一つの選択肢 Webアプリでは少額決済の機能が
ネック(代行手数料高い)でしたが、Googleがやってくれました。


昨年、12月より日本でもサービスを開始した
「Google In-App Payments API」と言う少額決済用API

特徴は
・決済手数料が5%、残りの95%がデベロッパーの取り分となります。

・JavaScript使用のサービスなのでWebブラウザに依存しない。
・ 利用者はクレジットカードで決済可能。


手軽かつ簡単に決済や導入が出来る「Google In-App Payments API」は、

まだ未成熟な日本の少額決済市場を席巻するのではと思います。


しかし、日本でもサービスを開始してから半年
あまりニュースにならないのが不思議です。


気になるので今後は評判や導入状況を少し追って見ます。



CommStep開発者のブログ


電子メールの設定をした事のある方なら一度位は
目にした事が有るかと思います。

「POP」、「IMAP」って何だろう、どの様に使うの?何が?
こんな質問を受けたので、改めて整理して見ます。


電子メールの仕組みは、メールサーバに送受信したメールを
クライアント(PC、スマホ)にて見るのが一般的です。


この時のサーバとクライアントの関係を示すのがこの言葉です。


POP(Post Office Protocol): メールをクライアントにダウンロードする方式。
IMAP(Internet Message Access Protocol):クライアント側にメールを

ダウンロードせずに必要に応じ参照に行く方式


で?結局何が違うの

お互いにメリットデメリットもあり、もっと言うと時代背景もあります。


今ほど、通信速度も早く無く、サーバも高額で保存容量も少ない時代は、

POP方式がメインで メールをクライアント側にダウンロードして参照する事で、

都度の通信負荷軽減とサーバ保存量軽減が出来ました。


しかし、クライアントにダウンロードしてしまうと、違うPCや出先でのメール確認が

出来ない状況が発生します。


そこでIMAP方式が登場です。

メールを全てサーバ上で保管管理するので、クライアントはどこからでも、

何台でもメールを確認する事が可能になります。


この方が便利ですよね。これらを可能にしたのが、

通信速度向上、クライアントの多様化、クラウドサーバの技術向上
等様々な恩恵です。


複雑な技術も、時代背景から確認すると技術の進歩が確認出来て面白いですね。



CommStep開発者のブログ

開発者ブログと銘打っている割に、情報系の話題ばかりなので
たまには開発系の情報更新もして見ます。


モバイル系開発アプリの方向性です。

事業の柱の中でモバイル系アプリ開発は外せません。
しかし、デバイスが多様化し言語も氾濫し選択肢が多い昨今
選択判断を整理しながら考えて見ます。


言語選択の前に、進むべき方向性を決める必要があります。
方向性と言うと、大きく分けると以下の2点になります。

・ネイティブアプリ:iPhoneやAndroid専用アプリ
・Webアプリ:HTML5/jQuery Mobile等


どちらを選ぶかは、一長一短があり、ここが難しいと言えるゆえんです。


メリット
ネイティブアプリは課金システムと開発環境の充実です。
課金システムとはソフト料金の回収に仕組みが出来ています。
Webアプリは「互換性」「インストール不要」この辺になります。


デメリット
ネイティブアプリはデバイス毎に開発する必要があり
体力の無い、中小ソフト屋ではサポートも含め冒険です。
Webアプリはメリットは大きいですが課金の仕組みがプアー
開発環境もまだまだこれからと言う感じです。


この判断は今後の経営方針に匹敵する位難しい課題です。
しかし、今の実力と規模(体力)を考慮すると必然的な
答えが見えて来ます。


基本方針としては、「Webアプリ」を柱に、
開発アプリの有用性が見込める様であれば、ネイティブアプリ
外注委託開発(オフショア開発含む)を検討して行きます。


今回はここまで。
次に、開発環境の標準化を考えて、まとまり次第UPします。