PDFレストランのウェブサイトのメニューのユーザーエクスペリエンス
私たちのほとんどは、メニューが注文フォームまたはアプリに統合されているテイクアウトまたはファーストフードの場所からオンラインで食品を注文することに慣れています。最近、非常にモダンなデザインのレストランのウェブサイトをいくつか訪れたとき、ウェブサイトにメニューのコンテンツを表示するのではなく、PDFドキュメントへのリンクを使用していることに驚かされました。
ビジネスの観点からは、それが人々がウェブサイトからデータをこすったり、価格を比較したりすることを防ぐ方法であり、いくつかの利点があるかもしれないと思います。ユーザーの観点からは、PDFファイルを用意し、Webサイトのコンテンツを用意しないことがユーザーの利益になるのではないかと思っていました。
Adobeは、2つの主な利点を維持しながら、PDF HTML + CSS（両方ともJSを含む可能性があります）の欠点のいくつかを克服しようとします。単一のファイルで可能な限り同じ静的設計です。両方とも時にはデメリットと考えられます。
Webサイトのユーザーの観点から見ると、HTML + CSS（+ JS）メニューにはいくつかの利点があります。それらの一部はPDFでも実行できますが、ほとんどのジェネレーターはそれらを（簡単に）サポートしていません。オンラインメニューは統合でサイトに組み込まれます。つまり、ユーザーはブラウザーからドキュメントビューアーアプリに切り替える必要がなく、シームレスなデザインでメニューはサイトの他の部分と同じように感じられるため、ナビゲーションエントリと半自動adaptでビューポートサイズに。オンラインメニューはインタラクティブにすることもできます。つまり、ユーザーは並べ替え（例：価格、肉、コース、サイズ）、フィルター（例：ベジタリアン、アルコール/乳製品/グルテン、特別オファー、子供用メニュー）、およびエントリを検索します。訪問者は、スクリーンリーダー、拡大鏡、翻訳機、通貨換算機などの支援技術も使用できます。紙とPDFは、ビデオまたは動的に拡大された写真を提供することに長けています。
Webサイトのメニューに注文フォームが既に含まれている場合、将来、紙のメニューに代わるタブレットアプリを簡単にコーディングできる可能性があります。データは電子掲示板にも再利用できます。現在、多くのファーストフード店では、カウンターリストメニューのオプションと価格の上に大きなテレビ画面があり、すばやく簡単に、気付かずに頻繁にエントリーや価格を変更できます（例：ランチタイムスペシャルや季節限定）オファリング）。
印刷メニューとウェブサイトが単一のソースから生成され、レストランのマネージャーが会計に使用するプログラムに接続する可能性がある場合、PDFをウェブに配置する理由はほとんどありません。少なくとも、デフォルトオプションとしてではなく、これは、同じ人物がWebサイトのバックエンドと印刷メニューを編集することを前提としています。
結論として、UXの観点から（フロントエンドとバックエンドの両方で）、レストランメニューは通常のデータベース駆動型のWebページである必要があります。
PS：レストランのゲストは、上記の利点のために、印刷されたものではなく、携帯電話を使用してオンラインメニューを見ているのを見ました。東南アジアでは、ウェイターがレストランのレストランを指すタブレットを手渡してくれました。なぜなら、印刷メニューはローカルスクリプトでのみ利用可能であり、写真は含まれていないためです。
オンラインメニューよりもPDFメニューを実装するのがeasierおよびcheaperだからです。
- ダウンロード、印刷、ズームなどの機能は、すでにWebブラウザーに組み込まれています。
- PDFメニューが印刷するメニューと同じである場合、1石で2羽の鳥を殺しています。
- コンテンツを更新するには、新しいファイルをアップロードするだけです。
- より安価な代替手段がある場合、クライアントはオンラインメニューを実装するために追加料金を支払うことを望まない場合があります。
ユーザーの知覚からPDFメニューは便利ではありません。
- PDFコンテンツの重さによっては、ロードに時間がかかります。
- 必要なアイテムを簡単に移動したり検索したりすることはできません（制御が不十分）。
個人的に私は彼らのサイトでメニューを見たいと思います：画像、価格、その他の有用な情報で分類されています。
しかし、インターネットがどこでも自由に利用できない国から来ている-それが頻繁に注文するレストランの場合-私はいつでも参照できるようにメニューもダウンロードして保存したいと考えています。好ましくは、任意のデバイスで開くことができる形式です。
主に、多くのレストランがPDFメニューを使用する主な理由は、彼らがすでに食事の常連客向けに印刷されたメニューを委託しているためです。この印刷メニューは、印刷用にPDFで作成されることが多いため、すでにPDFメニューが用意されています。レストランがレストランのウェブサイトを作成する方法を見つけ出したとき、それをHTMLメニューとして再作成するよりも、すでに持っているファイルをアップロードするのが最も簡単です。
これは主に費用便益分析です。はい、PDFメニューはWebサイトで少し不格好ですが、なぜ複数のメニューの開発と維持に余分なお金を費やすのですか？既に持っているPDFメニューをアップロードできる場合のフォーマット？
オンライン注文アプリの開発も安くはないので、多くのレストランは、オンラインメニューのあるWebサイトがあったとしても、電話で注文するか、単純な無料のテキスト連絡注文フォームを提供するだけです。
ほとんどのレストランが考えていた問題は、スクレイピングや価格の買い物を防ぐことではないと思います。大規模なファーストフードフランチャイズを除いて、レストランの食べ物は実際には商品ではありません。ある場所で同じメニューが次の店より50セント安いからといって、その場所で食べるかどうかについての私の決定にはあまり影響しません。
これを行うクライアントのカップルから今日まで：毎週または毎月誰かにお金を払ってメニューを実行したくないと言っており、必要に応じてすばやく変更したいので、メニューを作成するPDFオーサリングソフトウェア。クライアントの1つがOpenOffice WriterSave to PDFオプションを使用しています！
自動メニュー作成を作成する努力（実際には、私がシステムを作成したため、それらを使用します）は役に立たず、どちらも変更に消極的で満足していました彼らが物事を行っていた（そして行っている）方法。したがって、これは、合理的な考え方やテクノロジーの可用性に基づく決定よりも、 制御の軌跡 の問題のようです。
これに加えて、WPベースのシステムでレストランサイトを作成すると、クライアントの質問の1つはこれでした： "ボタンを追加できますかメニューをPDFにアップロードしますか？ "。この場合、メニュー作成システムは作成および承認されましたが、この人はこの機能だけを望んでいました場合によっては、特定の事業分野で広く普及しているようです
PS：ライアンの答えも考えられる理由の1つだと思います
私がデザイナーなら、両方のオプションを選択します。ユーザーにメニューを正しく表示することは重要ですが、PDFはデザインやレイアウトが優れている場合があります。一部の人々はメニューを印刷する必要があるかもしれません。なぜ使用するだけなのかわからないPDF。
私は、商人側にレストランを備えた市場モデルを持つスタートアップで働いていました。私が発見したのは、レストランにはさまざまなメニューとメニューオプションがあることです。一部のレストランは、ハーフアンドハーフのピザオプションを提供しますが、他のレストランはバンケットディールまたは同様のユニークなものを提供します。
Wordpressや他のテンプレート開発者は、この多様性が存在することを知っており、データベースに基づくソリューションの開発は簡単ではありません。そのため、それらの大部分は、PDFメニューのアップロードのみを提供しています。
これは、食品注文サイトが存在する理由の1つでもあります。彼らは様々なメニューオプションとバリエーションに対応し、食べ物を注文するための単一のインターフェースを提供します。
ほとんどのレストラン経営者は、ウェブサイトを広告媒体と見なしています。ウェブサイトの予算は限られているため、開発者はそこから最も簡単なソリューションを生み出すことができます。
経験から：Googleアナリティクスでは、ユーザーが料理の2ページで停止し、すべての料理をナビゲートできないことに気付きました。ユーザーは、レストランが提供する各料理よりも、レストランが提供するものの全体像を見たいと思ったという結論に達しました。そこで、個々の画像をレストランのメニューのような画像に変更しました。それはレストランにとってより良い結果をもたらしたと思います。
最高のユーザーエクスペリエンスは、ユーザーとビジネスにとって実際に機能するものに基づいていると思います。
それは簡単に言及されましたが、PDFファイルがメニューのHTMLバージョンではなくレストランのウェブサイトに普及している理由を詳しく説明していません。
いいえ、それはスクレイピングや何らかのビジネス上の理由によるものではありません（メニューは公的に投稿された場合は常に法律によりパブリックドメインです）。すでに述べたように、レストランのメニューを委託するとき、それはWeb以外の形式で行われるためです-ネイティブなので、Photoshop、Illustrator、Word、PowerPoint（はい、本当に）、またはその他の非Webネイティブ形式のソースファイルが作成されます。それをオンラインで投稿することはできません。
触れられていないのは、レストランのテーブルとWebサイトのメニューが必要な場合はどうするかです。そのため、次のことを可能にするWebネイティブ形式でメニューを用意することを検討する必要があります。
- メニューの設計のすべての複雑さ
- 高解像度印刷が可能
- ダウンロード機能PDFプラスWebサイトに埋め込む
現在、これを行うテクノロジーは1つだけです。これらの機能を備えた他のテクノロジーについて知りたいと思っていますが、執筆時点ではまだ見つかりません。埋め込まれたメニューがどのように見えるかの結果をここで見ることができます https://menugo.com/Shared
メニューはPDFとしてダウンロードするか、サイトにリンクして、次のようにJavaScriptを使用して自動的に同期できます。
<script id="menugo-share-script" src="https://menugo.com/js/embed.js?token=koLHB5cz"></script>
このように、1つの場所で管理できるメニューがあり、両方の場所で見栄えがよく、しかもWebフレンドリーです。