2

I am currently doing some research on how data is sometimes distorted during visualization on progress bars (showing 70% instead of 50% etc). The research is focused on expanding the thesis of Chris Harrison and team (chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf) that distorting the data shown on progress bars can lead to affecting the user's perception (either in good or bad way).

I would like to ask if you know about products (either web / desktop or mobile) where such distortions are being used to manipulate user's perception? The question that I asked is more about whether someone has already seen usage of any type of such distortions in real app or is it just a theoretical concept.

Many thanks for your help!

  • 1
    Please see best practices on how to form questions (ux.meta.stackexchange.com/questions/1266/…), and how to present your question in a meaningful way, with your own research. Your current question can be essentially boiled down to asking people to do research for you. As an example, you can ask "How often are misleading graphs used?", and present your findings. This opens doors to discussion and actual examples in a more natural way. – mrcharlie Oct 9 '18 at 21:20
1

Occam is your friend. I have seen plenty of seemingly distorted progress bars, and I am pretty well convinced that the vast majority are not deliberately distorted, but rather distorted due to either lack of information or laziness.

There are two different types of progress bars that I typically see, with different problems:

Upload/Download/Display

  • File Upload - Upload speeds are often much lower than download speeds due to the speed of the user's internet connection (e.g., DSL is typically asymmetric with upload 4 (or sometimes more) x as fast as downloads) and/or due to the speed of the server. It tends to be easier to spread out the download process to multiple servers (mirrors, CDN, etc.) than uploads (which are often limited to one server for security reasons). These bars are generally quite reliable except: (a) at the beginning they may have an arbitrary (and therefore inaccurate) chunk (5%? 10%?) for "getting things started, (b) the actual upload process may slow down at various points due to factors beyond server control but the progress will continue based on a simple calculation of the file size and (c) there may be an extra delay at the end (e.g., "stuck" at 99% or 100%) as the server does post-upload processing (virus checking, database operations, etc.) of the file.

  • File Download Most file downloads are small enough (even up to several megabytes) that the server will simply let the browser handle the details, in which case any progress bar will be based purely on file size and any abnormalities due to internet access speed/problems, generally beyond server control. However, some systems will provide a progress bar similar to the typical Upload progress bar and with the same 3 caveats as listed above, though in this case the last issue at 99%/100% is dependent on the user's computer instead of the server.

  • File Display This includes charts and complex reports/pages. The progress here is typically due to server-side processing, which is under control of the server. However, that processing may be very "chunky" or subject to delays from other processes (e.g., request from other users). Often the progress will be broken up in a reasonable but arbitrary manner which may match the average report but not exactly match any actual report.

For example, the programmer might measure 100 reports and find that, on average, 15% is used for an initial big database query, 40% is used for looping through the data and analyzing it and 35% is used for another process that takes the processed data and generates a chart image.

The first problem is that the numbers may vary considerably depending on the particulars of the user's data selection.

The second problem is that some sections may not be easily divided. For example, the database query might be an atomic process from the perspective of the main program which makes one single huge complex SQL query and waits for the results. So the progress will go from 0% to 1% and then pause for a relatively long time before jumping to 16%.

The third problem is that some sections may be easily divisible but not consistently divisible. This report that takes 40% for the main processing loop might have 1,000 primary records - which would equal 25 records per % of total progress bar. However, it might turn out that some of those records take 1 millisecond and some take 1 second, and the result is a "jumpy" progress bar.

User-Driven Function "Progress"

This is my terminology for progress bars that are based primarily on user events rather than server processing. Two typical examples are surveys and complex forms:

  • Surveys In order to encourage completion, a survey will often show a progress bar with it incrementing a little bit on every page. These are actually fairly reliable, in my experience. The exceptions are branches. A survey might have 20 pages, with 5% progress per page. But if there is a point in the middle where based on one answer either the survey is cut short or the survey is extended then the progress bar will either "jump" a large chunk or seem to "slow down" - i.e., all of a sudden instead of 5% per page it is 2% per page because more questions have been added. This is not deliberate messing with the user's minds, it is simply inability to predict the exact progress speed in advance.

  • Complex Forms A complex form might have 8 pages - 12.5% per page. However, some pages may be really easy (e.g., name/address/etc.) and some quite complex (e.g., medical details or descriptive note fields). The progress, thanks to lazy programmers (like me) may be based on the number of pages without adjusting for the complexity - and therefore the time - that each page requires to complete.

0

I think it would be a problem if standard commercial products were designed to deliberately distort the way data is presented, at least in the way that you have described it.

Not only that, I am sure that developers would have a headache trying to work out how to program this into the software application in a consistent or meaningful way because of the variation in the way data can be displayed programmatically.

So I think what you will see is that most data-manipulation occurs after the initial chart or graphic has been produced. This is where the distortion of axis can be manipulated by changing the labels, or changing the style or size of the visual elements and whatever else people can think of (e.g. turn the whole thing into an infographic that is detached from the actual raw data).

However, if anyone else knows examples it would be interesting to look into such products that are commercially available.

  • I have actually heard rumors that Microsoft uses some kind of distortion in Windows, but I can't find any article or study about that. Is there anybody who knows more? – Mara Augustin Oct 10 '18 at 13:05

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.