Is making PDF available in the mobile version harming the user experience?

Question

In a project in which I participate in developing the Front-End layers, I came across a possible problem about to finalize the mobile version of the same.

Such a proposal to be questioned, is in a certain part of the site, where there is a availability of the Menu in PDF to the visitor, providing the printing or the possibility to download the Document.

This PDF is not created via script (PHP or some LIB), it is a static document "uppado" by the user/client.

In the desktop version, the proposal may not hurt the experience so much, even considering that the file may have some Mega Bytes excessive (It was made by a Designer who exaggerated a little in the digital pen).

In the mobile/tablet version, it is obvious that these data-eating Mega Bytes in addition to possibly ending with the user’s "credits, animus, patience, (among other frustrating situations), a "lighter" version of this document becomes obligation "socioeconomic"(and why not?) of the project holders.

But here comes the question:

Even if a lighter version is the coherent solution for the Mobile user?

I believe that much of the target audience that the Site/ Project tries to meet has already had some experience with the use of PDF documents ever in life, so in a matter of use, the user would not "lose". But the person who enters the Smartphone/Cel/Tablet wants this type of situation?

Particularly I don’t like to come across PDF on Mobile, but what about "Povão", accepts this? It is conventionally a good idea to practice this?

Answer 1

First, let’s understand the user’s goal in this task context. From what I understand (you did not describe details of the application), the user is accessing the restaurant site and wants to simply access the menu. But you did not offer essential information such as: is the menu of the day? or would it be a fixed menu?

This information can completely change our perception (as designers) that something is easier or harder to harm the user experience. Want to see?

Scenario 1: Downloading PDF

Suppose the menu is fixed. That is, it is complete (has all the options offered by the restaurant) and does not change very often (and therefore probably does not include the values of the options offered). In this case, there is not so much harm in allowing the user to download the menu even though it is a large PDF. If the file size is clearly stated before download (an important criterion of usability is the clarity of information), the user can decide to download the PDF at home on his Wifi. If he also knows beforehand that the menu is complete, he can still decide to download the PDF using his mobile access (and paying the related cost) because he wants the menu and knows that once downloaded he will not need to do it again (because the PDF will already be on the device, easily accessible).

In this case, the usability of reading the menu is partly on account of the designer (and, let’s face it, a well-made menu is attractive and produces numerous other hedonic advantages for the business) and partly by the PDF reader used by the customer, which you simply have no control over.

If, on the other hand, the menu is not fixed or does not have everything that is offered (for example, it changes every day, every week), it is terribly bad for the user to have to download several different Pdfs. Not only for the transmission cost, but for the management it requires. In this case, this scenario is not even interesting (and I would say that it is also not interesting for a access via Desktop!).

Scenario 2: Dynamic Access

Suppose then that the menu is not fixed. In this scenario, the client opens the restaurant’s website and the system immediately presents the menu data of the day (or the moment desired by the client). Perhaps it is more difficult to allow the restaurant owner to easily change the information contained there (after all, using PDF the guy can simply go in Word, make a menu any and generate in PDF to put on the site)but on the other hand access is centralized and removes from the user (the client of the restaurant) any need to himself manage the possible menus that will be generated over time.

A nice and beautiful design remains equally important for the restaurant’s customer engagement. And if you think about it, the transmission/download costs involved won’t change that much, because the images, layout and color texts that would be downloaded into a PDF are now directly transmitted in HTML. But the content is essentially the same! That is, your designer may also have a heavy hand in the digital source pen making the CSS’s! rs

Thus, this scenario tends to be better for the experience because the user has the feeling that access is centralized and facilitated, and that the information is guaranteed to be updated. Plus he doesn’t need to have the cognitive effort to know where the hell he downloaded the last PDF from Monday’s menu.

Scenario 3: The Best of Both Worlds

Maybe the restaurant doesn’t really have a very variable menu. But that doesn’t mean that it doesn’t change, that occasional promotions don’t occur. And yet you wish (believe me, you wish! rs) that the restaurant customer has no job at remembering where to access the information he needs. So, one approach where you can get the best of the two previous scenarios is to build both a website and an app to be installed on the client’s mobile device.

It is true that the customer’s perception of the "need" to install another application is complex. But it stems exactly from the importance of content to him. If the user accesses the menu once, maybe it is because he is interested in knowing the restaurant. But if you visit often, it’s because you already like eating there and just want to know what’s for dinner tonight. Ideally your solution should rely on the site to facilitate casual access of the first type of user, and an application to facilitate access of the second.

The site would simply display the menu as it does on the Web. It could even be in a PDF, if it could be displayed directly in the browser without needing to be downloaded to any folder (that is, the user only sees the content - the operating system downloads it in a temporary folder). After all, remember: I am considering this mobile access as of initial, casual interest.

The application, installed by the less casual user and already frequent frequenter of the restaurant, also requires an Internet connection to download the data. But the fact that it’s a local app allows you to build a cache system, where you store the latest menu on your device and only update it when needed (by a push scheme, perhaps, since you can even display spot promotions that way).

To decision whether or not to build an app is controversial, mainly from the point of view of the restaurant owner (who will have to pay double). But my experience tells me that it makes sense to build something like this when there is actually some gain for the user, as seems to me to be the case with your scenario. In it there is gain in the menu cache and in the fact that the user does not need to know where such information is stored to have the parception that it is current.