会社の決算期なので書類掻き集めている。
こまめにやっとけばいいのに、っていう至極もっともな突っ込みはこの際おいとく。
そのうえで書くと、電話料金のような「月々の利用明細」が結構問題だ。
今時、利用明細を郵送で送ってくる、という会社は少ない。
別料金払えば送ってくれるのだけど、うちみたいな零細企業だとそのわずかな金を惜しみたい。
WEB で見られるから見てね、となっているのが普通だから、それを印刷することになる。
この明細書の扱いが、会社によって激しく違う。
Biglobe の SIM を使っているのだけど、明細書ページの使いやすさに感心した。
ある月の明細を見ていて、「前の月」「後の月」が簡単な操作で移動できるし、離れた月へもプルダウンメニューから移動できる。
事務作業している時には、まとまった期間の明細を全部出力したいので、この「次の月」への移動がとても便利。
使う人のことを良くわかっている。
そして、これが一番大事なのだけど、印刷すると全く見た目の違う、保存する経理書類として適切な形式の「利用明細」が得られる。
そこには、「次の月」とかプルダウンメニューなどの、操作インターフェイスは一切入っていない。
技術詳細としては、CSS のメディアタイプで振り分けているだけだ。
この説明でわかる人は、以下２５行ほど読み飛ばしていい。
…改めて説明しよう。
WEB のページは HTML で記述されている。
HTML は、表示する文章などに「データの意味」を与えるものだ。
たとえば、ある部分は見出しで、ある部分は本文の段落。
そしてこの部分は引用、などと指定していく。
一応、そのままの HTML でも、それなりの表示はしてくれる。
見出しは大きな文字を使うし、引用部分は段落を下げる。
でも、もっと見た目を整えたいのであれば、この「意味」に対して、どういう「見た目」にしたいのか、という指示を、Cascading Style Sheet (CSS) で行う。
この CSS なのだけど、普通に指定しておけば、画面上も印刷時も同じ見た目になる。
でも、CSS の指定時に「画面用」「印刷用」とか、さらには「PC用」「スマホ用」とか分けられる。
メディアごとに異なる見た目を用意できることから、「メディアタイプ」と呼ぶ。
そして…やっと最初の話に戻れた。
Biglobe では、1つのページに、画面用の見た目と印刷用の見た目を用意している。
画面用の見た目では「前の月」「次の月」などの機能ボタンが配置されているが、印刷時はこれらのボタンは消えうせる。
そして、明細書として適切な見た目で印刷され、そのまま経理書類として保存しやすいようになっている。
アサヒネットは、Biglobe のように「１つのページの見た目を CSSで制御する」のではなく、印刷用の別ページを用意してあった。
しかし、インターフェイスとしては使いやすいし、悪くない。
一方、楽天カードは、印刷用の仕組みはなかった。
画面用の見た目をそのまま印刷すると、最初の1ページには丸ごと、どうでもいい情報が入る。
（画面遷移のインターフェイスとか、過去の明細の保存期間のお知らせなど）
でも、これが「ちょうど1ページ」なのは都合がよく、2ページ目から印刷すると大体残しておきたい情報がみっちり入る。
残念なのは、最初の1ページに入る情報が「ちょうど1ページ」になるように計算されているわけではなく、偶然だということだ。
実は、直近３カ月とそれ以前で、ページの体裁が少し異なる。
そのため、最近のページを見ると、必要な情報が1ページ目途中から始まってしまう。
また、Javascript を使い、ページのスクロールに合わせて動的に CSS を書き換えるようになっていた。
具体的には、ページ一番上の表示は「ヘッダ」として、スクロールに合わせてついてくるようになっている。
ページを開いたときは何も設定されていないのだけど、スクロールして初めて fixed になるようだ。
この結果、印刷を開始するスクロール位置によって、印刷結果が変わってしまう。
fixed だと印刷時も紙の一番上に表示してくれるのだけど、経理上重要な「明細書」の一部が、この表示で隠されてしまう。
これは経理上全く許し難いことで、多数のページを印刷してから気づき、隠されてしまったページの再印刷となった。
見た中で最悪だったのが、DMM の明細ページ。
DMM の sim は安くて便利なので使っているのだけど、明細を印刷して保存することは全く考えられていない。
Biglobe と同じように、画面用の CSS と印刷用の CSS を分ける作りになっているんだ。
でも、印刷用の CSS というものは存在していない。
「画面用」の指定を印刷時に使うわけにはいかないので、印刷時は「素の HTML」になる。
先に書いたように、素の HTML でもそれなりの表示にはなる…ようにできる。
ところが、DMM のページは、CSS で成形することを前提に作られていて、素の HTML では見た目が非常に崩れるのだった。
結果として、保存したい情報をまともに印刷できない、ということになる。
ところで、google chrome の印刷機能は独特で、プリンタドライバを介さないで印刷しようとする。
そして、WEB を印刷するときに、「おそらくここが本文」という場所を経験則的に探し当てて、不要な部分をカットして印刷するモードがある。
これを試してみたところ、DMM のページでは利用明細以外の部分を綺麗にカットすることができた。
表組などは崩れているのだけど、必要な情報は保全できるので、この機能を利用して明細を印刷した。
僕のページは人のことを言えるほどインターフェイスについて考えられてはいない。
考えられてはいないのだけど、この際、心に棚をつくって、自分のことは棚上げして言わせてもらおう。
課金明細を WEB 化するのであれば、単に WEB で「見られる」だけではなく、印刷して保存することを考慮してほしい、と思う。
Biglobe の作り方は最善だし、アサヒネットのやり方も悪くない。
（多分、アサヒネットは CSS がまだ今ほど使い物にならなかった頃に作られたシステム）
楽天のは結構ダメなのだけど、少なくとも画面の見た目のまま印刷できるので、表組を使うことが多い明細としては悪くない。
でも、印刷時に表組すら崩れてしまう DMM のやり方はダメだ。
CSS に「画面用」の指定を入れるのであれば、「印刷用」も作っておかないと意味がない。
安い sim を便利に使わせてもらっているし、こういう細かな部分はコストに跳ね返るので仕方がないとも思うのだけど、改善してほしい部分だ。
そして、実は一番困ったのは NTT 東日本だった。
明細ページに入るためのインターフェイスがややこしすぎ。
自分で決められないのでとても覚えていられない「ユーザー ID」と、パスワード、それと「お客様番号」の3つが揃わないと認証できない。
しばらくアクセスしないと ID は失効して、再発行を依頼すると郵送で送られてくる、というシステムだ。
実は、失効していてアクセスできないので、再発行依頼したところ。
印刷以前の問題なので、是非改善してほしい。
さらにいえば、「明細」と「請求」は別の関連企業によって管理されていて、両方見るには２つのIDが必要になる。
別々に管理しているので、明細と請求が異なる場合もある、と説明されているけど、それじゃ何のための明細かわからない。
「セキュリティのため」なんて言わせない。
セキュリティに敏感な銀行だってこんなに意味の分からない認証方法は使っていないのだから。
＃現在、ＮＴＴ東日本は「インフラ会社」になりつつあり、「顧客管理」を別会社に任せる戦略を打ち出している。
先に書いたように、「明細」と「請求」が別会社になっているのもその一環。
この請求会社は自由に選ぶことができて、うちの場合、アサヒネットを窓口にするように切り替えれば、ＮＴＴ東日本のサービスはほぼそのままで、請求がアサヒネットから来るようになる。
ひと段落したら切り替えてやろう、と画策している。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |