Box2d: High screen resolution / frequency causes high friction?

I’m using Cocos Creator with (built-in) box2d for physics.

Recently our game behaves weirdly on our new device Galaxy S20 Ultra 5G – which has screen size = 1440 x 3200 – frequency = 120Hz.

After stop pushing, all our physical bodies almost stop immediately like they has very high friction. No other device react that way.

Anyone experienced this issue can give me an advice?

How to Detect Cognitive Friction on a Mobile Application?

I’m researching Cognitive Friction on my thesis and found out there’re only 2 works academically studying the topic.

1.The Fiction of No Friction: a User Skills Approach to Cognitive Lock-In

2.Irritating CAT Tool Features that Matter to Translators

Even I’m mostly interested in detecting the subject in an academical manner, I’d also love to learn all the ways practically applicable and you’ve tried to figure out.

Note: There is no proper scale has been studied for this topic.

Since I have to study the topic on an existing mobile application which does not belong to me, I’m framed with the idea of creating scenarios for users and apply it in a lab to observe them where eyetracking possible.

I’m either doubtful about eye tracking because it would not provide any direct details about user’s exact state of determination or failure in this situation.


  1. I’m planning to make users rate the overall User Experience of 3 randomly choosen mobile applications with a pre-defined UX scale
  2. Then make them use and rate the same scenarios for each application to score more accurately.
  3. And last, making further survey with the lower-graded-scenarios to detect for any cognitive friction.

Besides commenting what to do avoid, I’ll appreciate if any other ways you use to detect it in your products and in your case provided.

Data table entry: creation vs editing – how to design workflows for least friction and effort

I am designing a new feature and workflow in our business application, which allows administrators to create export configurations, which can later be selected by users, to quickly export projects with a certain configuration. The goal is to let users more quickly and conveniently export their data, so they can use it in other applications.

These configurations contain vital information such as:

  • Which parts of the project to export
  • Which file format to export
  • Whether to download the file or store it on a (pre-configured) server
  • Should the file be compressed or pretty-printed
  • etc.

Currently, when exporting data, the dialog that’s presented to the user, might look something like this:

enter image description here

Administrators are able to see a table of all available configurations, which looks somewhat like this:

enter image description here

Admins can Add Configurations (as indicated by the top right corner button), which opens the dialog (first image, but replaced export button with save) and lets them save this configuration, which gets added to the table. Subsequent editing could take place in the data table itself, by means of expanding the respective row and changing values in place, without the need of a dialog.

My question is this:
In order to cause the least amount of distraction and cognitive load, I opted for the in-table-editing, while still leaving the creation process in a dialog.
My reasoning for this is that the process of creation is mentally relatively separated from the context you start out and warrants the use of a dialog. Yet, editing (possibly multiple) configurations later on, while maybe even comparing them, would be severely interrupted by having to open a dialog for every configuration – which would also severely impede the ability to scan and compare while editing.

One of my colleagues argues that, to the contrary, the creation and the editing process should take place in the same “established” environment – namely the UI of the dialog – in order to remain consistent and not have two different interfaces displaying the same information.

Which procedure is more recommended in order to keep the administrator’s effort (both cognitive and manual) the lowest possible and aim for the least friction in the workflow?


How to design intentional friction in app?

I am designing an app for iOS where I need to prevent user to unintentionally trigger an alarm (the action of calling for emergency should be easily accessible but at the same time should prevent any accidental initiation).

I don’t want to use confirm dialog since it requires user to read and looking for a button in different position. (seems like too much friction on the other side)

What occurred to me initially as an good idea was to use ‘slide to’ action button, similar to what was/is used to unlock iPhone screen, but then I run to this topic: basically saying that Apple discourage usage of these kinds of components refuse to publish such an app in the store.

Do you have any experience with this kind of user scenarios? Or do you have experience with apple refusing to publish your app for such reasons?