*** Ram-Z_ is now known as Ram-Z | 05:55 | |
*** geheimni1` is now known as geheimnis` | 05:55 | |
*** Mirv__ is now known as Mirv | 06:11 | |
*** FireFly is now known as FaerieFly | 06:11 | |
*** Amu is now known as Smar | 06:18 | |
kid | pa: Yay! | 06:35 |
---|---|---|
pa | i guess i could wait sfos3 , then i could try to swallow the uglyness of the UI and give it a shot as main device for a few weeks | 06:38 |
pa | android is currently unbearable | 06:38 |
pa | iOS still the usual limiting shit | 06:38 |
pa | if only these arrogant finns would listen that their brainfucked UI is actually brainfucked.. | 06:39 |
chriadam | ooi which parts? | 06:39 |
pa | sfos ui? | 06:39 |
pa | like all of it? | 06:39 |
chriadam | don't you like, I mean. I'm not a Finn, but I'm always interested in hearing feedback about the UI, and can pass feedback onto the designers etc | 06:40 |
pa | from the home to the silica/pulley menu to the lo-res resembling theme | 06:40 |
pa | i was actually forced to reset the device yesterday | 06:40 |
chriadam | that's not very concrete. are there specific things you don't like, which you think could be improved via incremental change, or is it that you don't liek the entire paradigm (of swipe gesture based ui)? | 06:40 |
pa | and it was very enlightening to get reminded how sfos was in 1.0 | 06:40 |
pa | in other words to see almost side by side Harmattan - SFOS 1.0 - SFOS 2.2 | 06:41 |
pa | chriadam: i loved the harmattan /Swype ui | 06:42 |
pa | and i actually in some way liked even more the BB10 ui | 06:42 |
pa | based on similar concepts | 06:42 |
pa | but SF just managed to worsen it in almost every aspect | 06:43 |
pa | failing to see it is blindness | 06:43 |
chriadam | ok, so are you saying that some specific UI elements in SFOS 2.x are unintuitive (not discoverable) or are difficult to perform (e.g. without stretching long distance with thumb, etc)? | 06:43 |
pa | i find it always very confusing to get the app drawer from the bottom | 06:43 |
pa | with this L-shape virtual thing | 06:43 |
pa | this is one thing | 06:44 |
chriadam | by confusing, do you mean "sometimes it shows when it shouldn't" or do you mean "it's difficult to access when I want to"? | 06:44 |
pa | i mean "i always get somewhat lost in the navigation" | 06:44 |
pa | (after 2 years i mean) | 06:44 |
pa | other specific feedbacks: | 06:44 |
chriadam | swipe up from bottom = app drawer | 06:45 |
pa | the quick menu from the notification screen: a mess, and why isnt there a settings shortcut? there are only sub-settings shortcuts | 06:45 |
chriadam | after the app drawer is open, swipe down = close app drawer | 06:45 |
pa | chriadam: i told you what i felt | 06:45 |
pa | i suppose there was a reason for doing it differently in harmattan and bb10.. | 06:45 |
Smar | I guess there is also reasons why HTC ended up to pretty similar workflow than SF has... | 06:46 |
pa | chriadam: then one thing i never understood is if the theme where the fonts looked soo lo-res was done to cover the crappy screen quality, or was just some ingenious idea of some designer | 06:46 |
chriadam | the quick menu in the events view page is greatly changed now in SFOS 3.x. I don't know how much of that is public yet, but I think you'll be pleased with the SFOS 3.x changes | 06:47 |
pa | chriadam: at some point i even thought of writing down a long list of all things i really couldnt swallow | 06:47 |
pa | then i didnt, coz i thought "whos gonna listen?" | 06:47 |
chriadam | pa: fonts looking bad is just a bug if it happens. specifically, it's "we should tweak the distance field rendering parameters to ensure appropriate font weight under different ambience conditions" | 06:47 |
chriadam | pa: it's not so much "we don't listen" and more "we don't have enough developers to fix lots of the things we want to fix" so while we appreciate all feedback, we have to be very selective about prioritising high-value tasks and roadmapping them for fix/release | 06:48 |
chriadam | I recently forwarded a list of such feebdack from ApBBB to MartinS and I know that some of those feedback points influenced decisions in SFOS3 design work | 06:49 |
chriadam | but in general, from the outside I understand why it seems like the rate of progress is slow | 06:50 |
chriadam | (because, in many ways: it is slow. we have limited resources, and only a small amoutn of that can be spent on the UI polish, even though that's very "visible" to end users, because we have high priority tasks from business customers, etc, also) | 06:50 |
pa | chriadam: while i understand that, i somewhat have little trust in a company coming from a very appreciated product and managing to screw the design from the beginning only to incrementally fix it, and "maybe with sfos3 we will like it" (6 years later?) | 06:50 |
chriadam | pa: sure, that's a partially valid criticism. but SFOS was never intended to be a clone of Harmattan. it was able to build upon its base, but the UI was never intended to be exactly that. it has its own direction and flavour (which I think is a good thing, personally). | 06:51 |
pa | i mean, one could have been "chinese", just copy harmattan/bb10/whatever worked back then, use much less resources and yet have a much more intuitive product | 06:52 |
Nicd- | pa: you could try a more polite tone and maybe your feedback would be received better :P | 06:54 |
pa | what i also always wondered is: releasing silica as closed source <-- how could you guys expected to motivate developers tailoring the apps for your ecosystem? | 06:55 |
pa | i mean it's available only for sfos | 06:56 |
pa | and, at least some releases back (not sure about now) sfos didnt have controls1/2 | 06:56 |
chriadam_ | sorry dc'd | 06:56 |
chriadam_ | missed whatever was said for the last 3 mins I think | 06:57 |
pa | chriadam_: pa: what i also always wondered is: releasing silica as closed source <-- how could you guys expected to motivate developers tailoring the apps for your ecosystem? | 06:58 |
chriadam_ | well, many or most developers always wanted to open source silica and the components etc | 06:59 |
chriadam_ | but there are a variety of complexities related to the developer ecosystem which maybe aren't immediately apparent to outsiders (e.g. promising source or binary compatibility, migrating older apps, application lifecycle management, etc) | 07:00 |
pa | chriadam_: then why not providing qt quick controls out of the box? | 07:00 |
chriadam_ | lots of things which need careful thought (and unfortunately lots of resources) to get right. I personally think that the platform is lacking in a variety of areas there. there are steps we know we need to take to get there, but that will take time | 07:01 |
pa | you sort of give your developers only one option: "use silica, and only for sailfish." | 07:01 |
chriadam_ | pa: I can't speak for that one specifically, I assume it's because the Qt Quick Controls doesn't match in any way the platform look and feel, i.e. Silica | 07:01 |
chriadam_ | pa: not quite. you can bundle whatever you like with your app. but promising to support it at the platform level is different. | 07:01 |
pa | exactly | 07:02 |
chriadam_ | i.e. once a platform commits to supporting something, well, that's a long term commitment. | 07:02 |
pa | chriadam_: i can speak for myself, and say that i haven't even consider porting anything to sfos, because of this. | 07:02 |
pa | i already ported 3 apps to android, otoh... | 07:02 |
chriadam_ | my personal mantra is: reduce external dependencies, reduce platform surface. | 07:02 |
pa | which is kind of ironic | 07:02 |
chriadam_ | pa: what do you mean? are you worried that your app bundle will be too large? | 07:03 |
chriadam_ | (if you include qtquick controls in your app bundle, I mean) | 07:03 |
pa | no, i don't wnat to redo the UI with silica | 07:03 |
pa | i had them in qtquick1 | 07:03 |
pa | i just ported it to qtquick 2 | 07:03 |
chriadam_ | right, but you don't have to, right? if you bundle qtquick2.controls with your app, I mean | 07:03 |
chriadam_ | maybe I'm misunderstanding | 07:03 |
pa | chriadam_: yes, but that's more work (builidng the qt module for sailfish etc etc) | 07:04 |
pa | if it was there already | 07:04 |
chriadam_ | true | 07:04 |
pa | both in the device and sdk | 07:04 |
pa | i wouldnt have to do this | 07:04 |
chriadam_ | I agree. but remember: this is true of literally every library (and heck programming environment / language runtime) in the universe | 07:05 |
chriadam_ | should we therefore commit to supporting everything in SFOS because apps might want to use those? my personal opinion is: no, we should only support those ones which add the most value and make the most sense. perhaps qtquick.controls2 is one such, I don't know. | 07:05 |
chriadam_ | but my mantra, personally, is: minimise external dependencies, and minimise platform surface. we have too few development resources to do otherwise, IMO. | 07:06 |
pa | if you expect developers to use the Qt5 to develop native mobile apps for silica, i dont see how thats gonna happen without either a) having controls2 or b) releasing silica for using it on different platforms (i agree b is difficult) | 07:07 |
pa | if you just expect android apps, well then it doesnt matter | 07:08 |
pa | and just use silica for the UI itself and done. | 07:08 |
pa | not a pretty product, in that case, tho | 07:08 |
chriadam_ | pa: long term, we want developers to explicitly target SFOS because of its (in the future) large installed customer base. and at that point, we'd like developers to develop native, Silica applications. | 07:08 |
pa | :-) | 07:09 |
chriadam_ | as of right this moment, my personal opinion is that there isn't much (financial) incentive for developers to do so, outside of personal interest. but my opinion is that that also gives us some opportunity to improve some of the platform architecture... | 07:10 |
chriadam_ | in the future, I believe that financial incentive will indeed exist, when the installed base is large. | 07:11 |
pa | chriadam_: maybe i should write down that list. maybe not. in any case, hoping to not hurt anyone's feeling, i just want to conclude the discussion saying what your last sentences reads like: "In the future we want to be like Apple, forcing the developer to create apps adhering to our UI design. Just with our funky UI paradigm instead, which is largely not validated" (have you conducted user-studies for it, btw? if so, any public results?) | 07:15 |
chriadam_ | pa: not hurting feelings. as I said, we appreciate feedback and discussion! we know it comes from the right place (i.e. wanting to improve SFOS) | 07:15 |
chriadam_ | pa: it's not about forcing. as said, you can bundle whatever you like. but of course we'd like apps to use Silica as we believe that Silica looks nice. | 07:16 |
Nicd- | pa: if you don't want to hurt anyone's feelings, you should really reconsider how you make your points | 07:17 |
*** Blizzzek is now known as Blizzz | 09:48 | |
pa | btw | 09:51 |
pa | im 99% sure this has been reported already | 09:51 |
pa | with Telegram on Jolla1 it's possible to unveil an input bug, hopefully caused by integration with Alien Dalvik | 09:52 |
pa | basically: open a chat, then try to switch to short video message | 09:53 |
pa | it just won't do it | 09:53 |
pa | (with the short press) | 09:53 |
pa | not sure if sailfish X or jolla c has the same issue | 09:53 |
*** leinir_ is now known as leinir | 11:13 | |
*** Renault_ is now known as Renault | 11:52 | |
r0kk3rz | https://arstechnica.com/gadgets/2018/10/xiaomis-mi-mix-3-is-an-all-screen-magnetic-slider-phone-with-10gb-of-ram/ | 12:31 |
r0kk3rz | dirk's magnet slider design gone mainstream | 12:32 |
mornfall | only in this case, the pieces are not held together by magnets | 12:38 |
*** leinir_ is now known as leinir | 16:10 | |
*** Renault_ is now known as Renault | 16:42 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!