Perceived responsiveness of the UI

Yea, I mean, why not make it user-configurable (as in extra “feeling” / delays on OR off)
But I must say, sometimes the UI feels a bit “fuzzy” in that I am not sure what happens - everything moves in some kind of direction, at least for a while, at which point I have to raise my fingers to let it “come back into place”. It doesnt happen often, but mostly when unexpected movements occour and I accidentally activate the pulley (and I have to stop the interaction abruptly).
I think one thing iOS definitely does better than SFOS is the transitions; they are clear, solid and direct (like from left to right, or top to bottom; its only one direction always; SFOS homescreen is a good example, but other places are not that “clean”, if you pass me the meaning) SFOS feels “smoother” / less rigid in that sense. The floating buttons / texts at the top to “confirm” somehow feel really old school (material design maybe?), and especially in the browser a bit out of place theme-wise.

I would assume the guidelines and framework for the design, including the delays, have been set early on in the life of Sailfish, when the project was riding the hype train.

Just remember the design of the original Jolla phone, the work put into making the other half control the ambiance, even the word “ambience”, are all part of the original overall look and feel of Sailfish.
Jolla spent a significant amount of time developing and refining the design language of the user interface.

That is why I liked it so much from the beginning. There was a cohesive overall design for both hardware and software.

That is why I hate the Jolla C2 phone, a soulless thing with the most hideous type of notch on the market that breaks the consistency of the previously clean design of the user interface at the top of the screen.

Of course, those delays might just be random workarounds and hacks forgotten in the code…

1 Like

That’s a good idea and to develop this idea: In Settings/Display, there could be a slider or numerical setting named e.g. “UI Response Speed” and a range from “relaxed” in 4 steps to “snappy”.
present values in the qml files could be all divided by 4 but multiplied by the number from speed settings.

For example: Some delay or duration may be hardcoded to 400 ms now. Then it could be in future 100 * UIR where UIR is a integer variable containing the number from the UI Response setting.

So user could choose between having 100, 200, 300 and 400 ms delay.

4 Likes

Hmm what is different on the C2 from say the Sony’s? Is there any difference in terms of UX?
I guess not; so rather between different SF versions?

1 Like

There was again some change in Launcher.qml

I uploaded new version and I hope it will work, I can’t test it because I am still on 5.0.0.55.

To state the obvious:

The C2 is the first (only?) official device with

a) camera notch
b) very curved corners

which warranted some changes in the UI.

It is also much less performant than “current” Sonys.

3 Likes

It appears to be working as intended. Awesome! Thank you so much.

Can I read these guidelines anywhere? Where are they?

Is this a rhetorical question?

3 Likes

No, not rhetorical. I want to read them and - please forgive me - was too lazy to search for it. Therefore I asked.

@nephros thanks for the links, reading now.

edit: found nothing about delays or a wanted/intended slow speed UI interaction in the guidelines.

I thought it might be rhetorical because I don’t understand why you would ask me such a thing. I don’t work for Jolla, I don’t have inside information and I thought it was clear that not all design elements are public.
It does not really concern the public what delays are used by what control to give the specific feeling, so I don’t see why anyone would expect them to be public.
That is if there are any documents at all even inside Jolla.

1 Like

Aaah the good old “senior” documentation policy…

Glåda Vappu!

Came to mind now; having used iOS for dev purposes; the main difference perceived when comparing sfos ui to ios ui, is definitely the “snappyness” of the transitions. On iOS, things “fall” into place fast and straightforward; with smooth and slick animations; whereas on sfos, is a bit slower and smoother…personally i prefer the snappiness, so a ui mode for that / ptch would be nice!

Are you sure it’s just that and not the fundamentally different philosophy of the user interface gestures?
In fact, are you talking about gestures? Or are you talking about something else?
Do you have some examples that we can analyze?

Im sure its not the gestures (which btw are available on iphone nowadays as well, except the pulley); and yes, the “fastness” of the transitions is better on iphone; and it makes things “snap in” at the end of a transition, which gives it the feeling of stuff “falling into place”, increasing the user engagement

It’s simply because there are a huge amount of delays implemented in the qml files in e.g. /usr/share/lipstick-jolla-home-qt5/ and subfolders, and some others.

Have a look into these .qml files and you will see.

Maybe someone can bring this topic up for the next irc meeting, C2 having a bigger screen seemed really slow originally, but sailors sped up the animations and it no longer feels this way, it’s back to og jc in terms of transitions speed, adding a speed toggle like font size toggle should be easy enough? Just one more item in settings and people who prefer quicker transitions would be happy. Having to use patches for basic functionality like this seems backwards

1 Like

Old Xperia 10 with my tweaks also now runs like a Ferrari. Therefore I claim that slowliness comes only from intentionally implemented delays in the qml files of UI.

4 Likes