Beware of Character Encoding during Cut & Paste of Websites

The issue is very simple;

Do not assume that a website written in “Shift-JIS” will only contain characters that can be represented in “Shift-JIS”.

If you copy any characters that cannot be represented in “Shift-JIS” and paste them to another web page also coded in “Shift-JIS”, it may generate garbled-text (Mojibake).

For example, you may copy text from a website coded in Shift-JIS which contains ™, © or ® to code , © or ®. These characters are not available in Shift-JIS. If you paste them in your webpage which is also in Shift-JIS, you will see garbled-text or a “?” sign (Mojibake).

Another example is if the page has an element that is loaded via Ajax. The Ajax payload will be handled by Javascript, which will handle the payload as Unicode. It is capable of inserting characters into the DOM that are not representable in Shift-JIS.

The thing to keep in mind is that the HTML character set is only a transfer protocol. It does not govern or limit in any way the text that can be displayed on the browser. Hence you cannot assume that all the text that you see on the browser is encodable in a particular encoding except Unicode.

CMSの役割について考える

最近ライフサイエンスの研究試薬・機器メーカーのウェブサイトを画期的に良くするサービスを準備していて、その関連でメーカーのウェブサイトを良く眺めています。

そうする中でCMSの存在が気になります。どういう風に気になるかというと、あまりクライアントの役に立っていなくて、むしろウェブサイトを悪化させているのではないかと感じているのです。

ポイントはメーカーのウェブサイトの特徴です;

  1. メーカーウェブサイトのボリュームの大半は製品ページであって、これはほとんど更新することがありません。更新するとしても印刷版のカタログと同期させることが(本来は)必要なので、どこかで更新履歴がまとまっていないと印刷版との同期がおかしくなります。
  2. メーカーウェブサイトの更新の大半はキャンペーンや新製品です。どれも新しいページの作成が必要です。特にキャンペーンページはデザインが重要なので、ウェブデザイナーに依頼します。製品担当が直接ページを作成することはありません。新製品の場合、注力製品であればイメージなども多いので、やはりウェブデザイナーに依頼するのが無難です。

CMSの最大の「売り」は、ウェブデザイナー以外の人がコンテンツを直接書き込めることですが、少なくともメーカーのウェブサイトの場合はそのニーズがそもそもないと感じています。

そうなるとCMSの欠点ばかりが見えてきます。CMSの欠点についてはYahoo知恵袋に良くまとまっていますが、一言で言えばCMS導入業者への依存度が凄く強くなることです。

総合すると

  1. CMSはメーカーにとってはメリットがない
  2. CMS導入業者にとっては継続的に管理費やカスタマイズ費がもらえるので、メリットだらけ

もちろんCMSには他にもメリットがありますが、そのほとんどはDreamWeaverのようにサイト管理機能が充実しているソフトウェアを使えば同等以上のことができます。

  1. CMSはテンプレートでデザインの統一性が保てます。DreamWeaverにもテンプレート機能が充実しています。そしてCMSのテンプレートとDreamWeaverのテンプレートの最大の違いは、CMSだとプログラマーが変更しなければならないのに対して、DreamWeaverのテンプレートはウェブデザイナーが変更できる点です。
  2. CMSに機能拡張をすれば、価格などの情報をデータベースから引っ張ったりできますので、常に最新の価格情報を保証することができます。しかしこれはまず非常に高価です。そしてカスタムなので業者依存がますます強くなります。このあたりは私たちが新しく用意しているサービスを利用すると、うんと安くできます。業者依存も生じません。

DreamWeaverの場合、一番のメリットはこれがデザイナーの標準ツールだということです。デザイン力が高い人材を探すとき、あるいはウェブサイト担当者を変更しればならないときにはこれは凄く重要です。確実に、簡単に、そして安価に引き継ぎが可能です。

もしもそれでもCMSを利用するのであれば、業者依存を生じさせないために、広く普及しているオープンソースのCMSを利用するべきだと考えます。世の中で圧倒的に普及しているCMSはWordPressですので、原則としてWordPressが第一候補です。明確な理由(Wordpressで実現できない機能)がない限り、それ以外のCMSを使うべきではないでしょう。

もちろん「CMSを使うべきかどうか」はケースバイケースで変わります。例えばこのブログはWordPressで動いていますし、Castle104のホームページもWordPressです。

気をつけなければならないのは、「業者は業者依存を増やしたい。なので彼らはCMSを導入したがる」という点です。

ウェブデザインからサイドバーをなくしていこう

2013年1月に[iPad専用にデザインするということはどういうことか](https://naofumi.castle104.com/?p=1925)というブログを書き、その中でPC用のウェブデザインが実は無駄だらけだと述べました。そしてその無駄を省いていくことで、iPadに適したウェブサイトが自然にできてくると議論しました。

先日、[Squarespace](http://www.squarespace.com/)でテンプレートを開発しているEric Anderson氏が、やはり[サイドバー不要論](https://medium.com/design-ux/167ae2fae1fb)を展開していました。

解決策として;

1. 関連リンクはブログポストの後に付ければ良い。
2. 検索窓はヘッダーかフッターに付ければ良い。
3. アーカイブは専用ページに用意すれば良い。

このブログはまだサイドバーなしにしていませんが、Eric Anderson氏の述べていることは全くその通りだと思います。近々、サイドバーをなくしていきたいと思います。

デスクトップウェブサイトがモバイルウェブサイトから学ぶべきこと

スマートフォン、タブレット、そしてデスクトップからもアクセス可能なウェブサイトをここ1年ぐらい構築していますが、その中でウェブサイトのあるべき姿についてだいぶん考えさせられます。

特にスマートフォン用のウェブサイトを作る時に非常に考えさせられます。スマートフォンは画面のサイズがデスクトップよりも圧倒的に小さく、がらりとデザインを変えないとウェブサイトの目的が果たせません。サイズが小さいので、不要なコンテンツを容赦なく切り捨てていくことになります。

そうやって重要なコンテンツとそうでないコンテンツを厳しい目で見分けるのになれると、デスクトップのウェブサイトが非常に無駄だらけに見えてきます。

今回は“10 Ways Mobile Sites Are Different from Desktop Web Sites”というUXmattersの記事を見ながら、デスクトップウェブサイトのあるべき姿について考えてみたいと思います。

モバイルウェブサイトで重要なこと

UXmattersの記事では、モバイルウェブサイトで重要なこととして以下のことを列挙しています。

1. Content Prioritization (コンテンツの優先順位の明確化)

Mobile site designs should give priority to the features and content users are most likely to need when viewing a site using a mobile device.

要するにウェブサイトのコンテンツや機能に優先順位を付けなさいということです。

デスクトップのウェブサイトは画面のサイズが大きいので、デスクトップウェブサイトは幅広いコンテンツを入れがちです。わかりやすさの観点から、デスクトップもモバイルに習ってコンテンツの減量をするべきではないでしょうか?

2. Vertical Instead of Horizontal Navigation

vertical navigation has replaced horizontal navigation on more than 90% of the mobile sites I analyzed

デスクトップのウェブサイトでは水平なナビゲーションがよく使われます。その一方で横幅の制約のため、モバイルウェブサイトでは垂直のナビゲーションが圧倒的に多く使われいます。

ただUXmattersの記事にもリンクがありますが、実はデスクトップであっても水平なナビゲーションは垂直なナビゲーションよりも制限が多く、簡潔な言葉遣いとナビゲーション項目の優先順位の明確化が必要だとしています。

モバイルウェブサイトで垂直のナビゲーションを使ったとしても、やはり項目の簡潔さと優先順位は重要です。

3. Bars, Tabs, and Hypertext

Hypertextというのはクリック可能な文字列(ボタンではない)のことです。

We see much less hypertext on mobile pages. … Links instead appear in the form of bars, tabs, and buttons.

モバイルの場合はタッチインタフェースを使わなければならず、指は太いので、小さいhypertextはうまくクリックできません。その代わり、大きめのボタンなどが多く使われます。

こうすると必然的にリンクの数を減らさないといけなくなります。リンクの数を減らすというのは、重要なリンクとそうでは無いリンクの間の優先順位を明確化することです。

デスクトップでもリンクの数が減れば、利用者は迷うことが少なくなるはずです。

4. Text and Graphics

Designers often remove promotional or marketing graphics from the designs of mobile sites.

モバイルのウェブサイトは広告やマーケティングを目的としたグラフィックを減らしているということですが、デスクトップでも同様にすれば利用者は助かります。

5. Contextual and Global Navigation

While global navigation is common on mobile sites, contextual navigation is not.

場所の制約により、モバイルサイトではコンテキストに応じて変化するナビゲーションが付けられないとしています。

対処方法として以下のように述べています。

Therefore, it’s essential to reduce hierarchy when organizing the content on mobile sites, so users don’t have to dig too deeply to get things done. They should be able to achieve what they want to accomplish before becoming lost.

つまりサイト全体の構造を単純化しろということです。それができれば、デスクトップの利用者も大変助かります。

6. Footers

Mobile sites employ footers that provide access to content users often look for on a home page, keeping its links to a minimum, but they do not use footers containing quick links.

モバイルのサイトもフッターを使うけれども、quick link (ウェブサイトのコンテンツへのショートカット)を載せられないということです。

ショートカントを載せられないということに対処するためには、そもそものウェブサイトの構造を単純化し、階層を減らすべきです。それができれば、デスクトップでもショートカットが不要になるはずです。

7. Breadcrumbs

Breadcrumbs rarely appear on mobiles sites, and there is usually no necessity for them.

Limited space is one reason breadcrumbs are uncommon on mobile sites. But the main factor is that the design of mobile sites prevents users from having to go too deep into a hierarchy to find what they are looking for.

モバイルウェブサイトではサイト構造を単純にすることが非常に重要なため、そもそもパンくずが必要にならないということです。

デスクトップもパンくずがいらないぐらいに単純なサイト構造にすれば良いはずです。

8. Progress Indicator

Such progress indicators do not appear on mobile sites. Again, limited space is the main reason.

ユーザが複数ステップの作業をしているとき、どこまで進んだかをはっきりさせるために進捗インジケータが使われます。しかしモバイルでは出てこないそうです。

Use alternative approaches to make users aware of their progress without a progress indicator. For example, instead of using buttons with implicit actions such as Next or Continue, use buttons with explicit labels that inform users exactly what the next step is.

対処方法として、ボタンの名前を明確で具体的にすることを紹介しています。「次に」というボタンではなく、「支払いする」とか「届け先を指定する」とかを使いなさいと述べています。

これもデスクトップのウェブサイトでできることです。操作が分かりやすくなります。

その他

9番は電話機能との融合、10番は場所によってカスタマイズしたサーチということで、デスクトップには当てはまりません。

まとめ

モバイルウェブサイトとデスクトップのウェブサイトは大きく違います。画面サイズが小さいため、モバイルウェブサイトを作る上では、デザインだけではなく、サイト構造の単純化、コンテンツの優先順位の明確化が必要になります。

そしてそのどれもがモバイルサイトだけではなく、デスクトップサイトにも役立ちます。

モバイルサイトを作るときに考えるべきことは、モバイルサイトのことだけではありません。サイトの土台となるコンテンツと構造を見直すことです。そのとき、当然デスクトップサイトも変わります。

私が最近模索しているのは、まずモバイルサイトを考えることです。そしてデスクトップに移したときに余裕が生まれるのであれば、そこにどのようなコンテンツを持って行くかと考えるのです。

実はこうやっていくと、意外と何を載せるべきか悩みます。それこそモバイルサイトがうまくできている何よりの証拠ではないでしょうか。