On 10/24/18 1:14 AM, Gary Willoughby wrote:
> On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
>> As a result I've done some fairly extensive research over the years on, not just the effort required to bring one to D, but also on what people are actually using.
> 
> How? I'm the author of a native UI toolkit and I've no idea how many people are using it. But I know a lot of people are though. Most people will never tell you they use your stuff.
> 
> https://github.com/nomad-software/tkd
> 

Asking is often a terrible way to discover things. For example, I can instantly tell if it's an Electron app (CPU spikes and memory usage is atrocious). WPF apps often have text rendering issues because they forgot to opt-in the improved text rendering modes, or the app has a non-native look and isn't obviously a UWP app (UWP apps are installed differently so they are ridiculously easy to differentiate). GTK apps often look non-native on KDE/Windows/macOS, where Qt apps often look non-native in GNOME/Windows/macOS. On the mobile world, just go to the apps store and look at the screenshots of the top 100. None of them use the native interface widgets. And I haven't visited a website that used native widgets since the early 2000's.

So in that respect, a simple passive survey can cover a statistically useful sample. Note that I cannot always pinpoint precisely which toolkit was used, but enough to know whether or not it is native or non-native and whether or not it is native to that OS/DE is trivial.

>> At this point in time HTML/CSS/JS is by far the most prevalent UX toolkit in use today and not a single modern website uses the native widget theme. The bare minimum is Bootstrap.
> 
> I disagree and this is impossible to measure. Don't confuse web with native both have use-cases.
> 
>> I've never used GTK or QT, but my understanding is that both have retrofitted some amount of theming into their toolkits but neither approach the capabilities of WPF or HTML/CSS.
> 
> I would have thought this would have been included in any 'research' you've done?
> 
>> There are other reasons that native toolkits died however.
> 
> What? Native toolkits haven't died.
> 

If by died you mean disappeared than I agree. But dead can also mean "no significant new work". In so far as no major new apps are being developed using native toolkits, and in the age of HTML and Mobile apps I think this is undeniably the case.

>> Native toolkits are a dead-end. The future of non-Web UX is non-native.
> 
> I think this is more of an opinion than concrete fact.
> 

How so? Show me a popular mobile app that uses the default widget set. Show me a new large scale desktop app that uses the native. I have done my best to provide examples, but since I can't post pictures to forum messages I am asking for a little bit of googling. :)

>> And that brings us to the final problem with UX in D. The amount of time it takes to bring any UX toolkit into D is...
> 
> It took me 6+ months (part-time) for the above linked toolkit. You just need dedicated hard work.
> 

Indeed. That was kind of my point. Especially the dedicated part. :)

>> I firmly believe that a non-native, cross-platform, UX library will open D up to a whole new market of users that are desperate for something better than what they have now.
> 
> I don't believe this at all. We just need better documentation for the native libraries we have available.
> 

Well, D has GtkD, DlangUI, and others. I imagine that the GTK docs are sufficient to working well enough, so I do seriously doubt that quality docs are the *only* thing holding back D GUI's, it certainly would not hurt to have better docs. But given that most of the available toolkits are bindings, pretty good docs already exist.

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

On Wed, 24 Oct 2018 16:55:05 -0700, Adam Wilson wrote:
> My team at MSFT did accessibility work and we had to follow all the ADA guidelines, EU rules, and internal policies when creating our HTML based UX. What you are describing here is not a problem with any individual toolkit, but the inability or unwillingness of the individual teams implementing the UX to use the accessibility tools of their respective toolkits. WPF has expansive Accessibility tooling, and indeed, all of the work on WPF in the .NET 4.7.x series has been on Accessibility to enable MSFT to meet all applicable policies for it's own WPF based apps.
>
> The problems you describe with accessibility are not related to the type of toolkit used. Native or Non-Native, if they don't utilize the accessibility features of the toolkit, it won't work right for those requiring accessible interfaces. I can build a completely inaccessible UX in any toolkit. And indeed, I've built inaccessible UX's in both WinForms and WPF.

It would be great if the toolkit made it simple to meet those guidelines. Maybe you're using a framework built on top of HTML+CSS and it helps out. Maybe you're using GTK+ and it does a fair bit for you. Maybe you're using WinForms and it falls far short, forcing you to write a lot of code.

> Specifically the goal is consistency between apps *on that platform*. KDE apps look like crap on GNOME and vice versa. VS Code looks exactly the same everywhere.

Consistency between platforms makes it a little easier to write documentation. Users get annoyed by applications that don't work like other applications on their platform.

> Not going to disagree with HTML having a garbage box-model. But that doesn't stop it from being the most widely used model out there.

Right, but if I'm choosing what tools to use, I'm going to prefer to use good ones instead of garbage ones.

> GTK works where you can accept the limitations that system comes with.

That's suggestive of abnormal limitations, but since you haven't used GTK+, you presumably haven't encountered them.

> Other than that I don't see why GtkD wouldn't work in D. Although on the preceeding thread there were a bunch of people who were unhappy with it. Specifically there were complaints about how well it worked on macOS and Windows. I've used GTK apps on Windows before, and it was immediately obvious to me that it was a GTK app, and it wasn't good. It functioned but suffered from font sizing and box model problems. GTK is great if you live in GNOME, outside of it, not so much.

There's an obvious solution there...

On 10/24/18 12:39 PM, drug wrote:
> On 24.10.2018 22:27, luckoverthere wrote:
>> On Wednesday, 24 October 2018 at 13:13:53 UTC, drug wrote:
>>> 24.10.2018 16:00, Guillaume Piolat пишет:
>>>> - OpenGL does not "work everywhere". It's deprecated on macOS. In general portable APIs don't make any giant any money: the trend is fragmentation hence why abstraction over specific APIs is a must: that's where Unity was better than anyone else.
>>>>
>>> So, nothing specific to OpenGL (it can be related to any other technology). But in general I am agree with again - renderer shouldn't be fixed. I recently started using `nuklear`, immediate gui c library. it's totally platform and renderer agnostic. We could use this way.
>>
>> I'd be against using those API for GUI. Something like ImGui and Nuklear are made specifically for games in mind. For rapid prototyping and debugging. The GUI can be constructed and manipulate the logic in-place. What it does not do well is efficiency. The GUI is reconstructed from scratch every frame. This is not needed for most GUIs, that is incredibly inefficient. It suites games as you are already rendering a new frame every 16ms or so. Qt uses OpenGL I think, but it doesn't render every frame. It'll optimize to try to reduce how many frames it has to create and it doesn't re-render anything it doesn't have to.
> 
> You are wrong about immediate mode a little bit. Yes, someone use it like you described above. But nothing prevent you from building efficient application. You can even build retained gui using immediate one. Moreover immediate mode is more efficient than retained in some cases.

You are both technically correct, but the word "efficiency" can be used in two different ways here. Immediate mode can be incredibly efficient from a rendering performance standpoint. But in general they are much less efficient than retained mode from a developer standpoint. So the question is, what kind of efficiency is more important?

My vote is for developer efficiency. Most UX's need a minor fraction of what even an Intel GMA 3000 can pump out, much less that of what a Vega64 or GeForce RTX 2080 Ti. I only have a Radeon Pro WX4100 because of the fact that it has four DP1.2 outputs in a half-height form factor. I certainly never get with a parsec of actually stressing the capacity of rendering silicon.

But if I can do something with 10 lines of code over 1000 lines of code I will take that option ever single time. My time is WAY more expensive than some GPU time.

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

On 10/24/18 5:22 PM, Neia Neutuladh wrote:
> On Wed, 24 Oct 2018 16:55:05 -0700, Adam Wilson wrote:
>> My team at MSFT did accessibility work and we had to follow all the ADA
>> guidelines, EU rules, and internal policies when creating our HTML based
>> UX. What you are describing here is not a problem with any individual
>> toolkit, but the inability or unwillingness of the individual teams
>> implementing the UX to use the accessibility tools of their respective
>> toolkits. WPF has expansive Accessibility tooling, and indeed, all of
>> the work on WPF in the .NET 4.7.x series has been on Accessibility to
>> enable MSFT to meet all applicable policies for it's own WPF based apps.
>>
>> The problems you describe with accessibility are not related to the type
>> of toolkit used. Native or Non-Native, if they don't utilize the
>> accessibility features of the toolkit, it won't work right for those
>> requiring accessible interfaces. I can build a completely inaccessible
>> UX in any toolkit. And indeed, I've built inaccessible UX's in both
>> WinForms and WPF.
> 
> It would be great if the toolkit made it simple to meet those guidelines.
> Maybe you're using a framework built on top of HTML+CSS and it helps out.
> Maybe you're using GTK+ and it does a fair bit for you. Maybe you're using
> WinForms and it falls far short, forcing you to write a lot of code.
> 
>> Specifically the goal is consistency between apps *on that platform*.
>> KDE apps look like crap on GNOME and vice versa. VS Code looks exactly
>> the same everywhere.
> 
> Consistency between platforms makes it a little easier to write
> documentation. Users get annoyed by applications that don't work like
> other applications on their platform.
> 

I've see this assertion made many times usually by developers who've never worked on a UX for non-technical people and always without any corroborating evidence.

The following is my credentials in the UX space. I took a UX design class from Billy Hollis, a well known (in the Microsoft space) UX designer. And I've study the psychology of UX design ever since then by reading a number of books on the subject. I've also designed a UX for use by non-technical people that is still in use today.

One thing I can say with confidence is that the average user wants each app to behave consistently regardless of where they using them. The human mind is an excellent pattern matching system. It turns out that as long as certain affordances (UX designer speak for something that signals deeper, possibly hidden, meaning) follow the same conventions, how they look (theme) on a given platform is irrelevant. An example of an affordance is a blinking cursor, which signals that you can type here. Or a drop-shadow on a button. Or a menu across the top, or the ubiquitous "hamburger icon" in mobile apps. As long as these affordances function the way their look suggests they do (by convention) then the specifics of how they are colored or drawn (themes, drop-shadows, etc) is functionally irrelevant to the human brain. This is because the brain creates mental "shortcuts" that map to these affordances and once the brain has perceived the affordance, it stops processing the particulars of how it is drawn.

(The exception to this rule is those who have more aggressive forms of Autism Spectrum Disorder. The reason is that those individuals have difficulty, or are even incapable of not processing. They see *everything*. The trouble here is that apps that an ASD person can use are nearly unusable to non-ASD people who are relying on the affordance shortcuts. So we don't do that.)

However, if I design an app that looks the same and functions the same across platforms (mobile, web, desktop) then the brain develops shortcuts for things like button color, menu ordering, etc. But the most important shortcut the brain can take is that of learning. For example, my American Express app is just a limited version of the website. I can't do everything the website can but what I can do works the same way on both, same affordances, same scheme, same layouts (within reason). I only have to learn the UX once.

In the UX class I took one of the first lessons was the order in how the  the human brain perceives the elements an image.

Colors
Shapes
Text

The first thing that registers in our brains is color. So for example, if we did an American Express app using the native widgets with default colors. Samsung's Android would be white-on-black, but Googles Pixel would be black-on-white. Now our brains have work harder to recognize the app we are using because the colors changed. So then we start looking at the shape on the screen, but those too have changed, Samsung uses different sized buttons for example, so the layout got pushed around. And they use different default fonts, so now the font shapes are different. So our brain slows down even more and starts processing the text on the screen and then we start to slide into our routines.

Each one of these increases the total cognitive load, and even if you switch between platforms many times a day, such that you get used to it, your brain still has to do this "context switch". It is simply unavoidable. You might get faster at it the more you do it, but the cognitive load is *always* higher. The cool psychology part of this is that this increased cognitive loading  produces an increase in stress level (cortisol). (So do square corners)

Again the exception is folks on the Autism Spectrum, they never stop processing, so that don't really benefit from the shortcuts. And I'd even agree that having an environment consistent UX for ASD folks would be better than a task specific UX. Based on my understanding of how ASD people process information.

And that is why UX teams are developling apps that look the same across devices, it literally de-stresses their users, which is a good thing if you're trying to sell something. Corporations do things that benefit their bottom-lines sure, but that's doesn't mean that those things are inherently at odds with what users want. A corporation can only make money from happy people. So they tend to do what makes the largest number of people happy.

>> Not going to disagree with HTML having a garbage box-model. But that
>> doesn't stop it from being the most widely used model out there.
> 
> Right, but if I'm choosing what tools to use, I'm going to prefer to use
> good ones instead of garbage ones.
> 

"Good" is often a matter of preference. I don't like WinForms, GTK, or HTML, but I do like WPF. Does that bias me, I'm sure it does, but it doesn't change the direction that the industry at large is headed.

>> GTK works where you can accept the limitations that system comes with.
> 
> That's suggestive of abnormal limitations, but since you haven't used
> GTK+, you presumably haven't encountered them.
> 

I'll admit that I haven't used GTK, but I've used apps that use it, and the thing is, what I consider a limitation you might not. Since that's subjective it's probably best that we table further discussion on it since it comes down a matter preference.

>> Other than that I don't see why GtkD wouldn't work in D. Although on the
>> preceeding thread there were a bunch of people who were unhappy with it.
>> Specifically there were complaints about how well it worked on macOS and
>> Windows. I've used GTK apps on Windows before, and it was immediately
>> obvious to me that it was a GTK app, and it wasn't good. It functioned
>> but suffered from font sizing and box model problems. GTK is great if
>> you live in GNOME, outside of it, not so much.
> 
> There's an obvious solution there...
> 

... if I'm thinking what you're thinking, that is a pipe dream. I use GNOME too but sometimes we just have to accept that even if we're technically correct, it doesn't matter. :D

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

On 10/24/18 6:39 PM, Adam Wilson wrote:

> human mind is an excellent pattern matching system. It turns out that as long as certain affordances (UX designer speak for something that signals deeper, possibly hidden, meaning) follow the same conventions, how they look (theme) on a given platform is irrelevant.

Meant to say that whether or not they match the given platforms theme is irrelevant.

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;

On 10/24/18 7:33 PM, Adam Wilson wrote:
> 
> UX is used here as an overarching term, many of those libraries go beyond the traditional UI capabilites with things like Audio/Video. Device integration (cameras, etc). So yes, I am listing libraries that have UX capabilities.
> 

That's all still UI. UX means "User Experience". Ie, quite literally, the experience from the user's perspective. It's an abstract concept. The concrete details of the UX are what we call UI.

On Wed, 24 Oct 2018 18:39:20 -0700, Adam Wilson wrote:
> (The exception to this rule is those who have more aggressive forms of Autism Spectrum Disorder. The reason is that those individuals have difficulty, or are even incapable of not processing. They see *everything*. The trouble here is that apps that an ASD person can use are nearly unusable to non-ASD people who are relying on the affordance shortcuts. So we don't do that.)

Oh. Well, there's my problem.

(My case isn't particularly aggressive and I've made full accommodations, but it still affects me.)

On 10/24/18 9:39 PM, Adam Wilson wrote:
> 
> The following is my credentials in the UX space. I took a UX design class from Billy Hollis, a well known (in the Microsoft space) UX designer.

Well there's your problem. It's been a long time since MS was known for UIs that *aren't* a complete clusterf*ck, so it's difficult to assume anything they're relying on is necessarily reputable.

Besides, "I took a class" hardly counts as credentials.

On Thursday, 25 October 2018 at 01:39:20 UTC, Adam Wilson wrote:

> However, if I design an app that looks the same and functions the same across platforms (mobile, web, desktop) then the brain develops shortcuts for things like button color, menu ordering, etc.

What if someone makes an application only for one platform, or only for desktop or mobile? Or someone needs to quickly create a simple utility and assumes that there is a good default theme - native, which looks and behaves similarly as in that whole platform, utilizing "mental shortcuts" of that environment.

25.10.2018 03:24, Adam Wilson пишет:
> You are both technically correct, but the word "efficiency" can be used in two different ways here. Immediate mode can be incredibly efficient from a rendering performance standpoint. But in general they are much less efficient than retained mode from a developer standpoint. So the question is, what kind of efficiency is more important?
> 
> My vote is for developer efficiency. Most UX's need a minor fraction of what even an Intel GMA 3000 can pump out, much less that of what a Vega64 or GeForce RTX 2080 Ti. I only have a Radeon Pro WX4100 because of the fact that it has four DP1.2 outputs in a half-height form factor. I certainly never get with a parsec of actually stressing the capacity of rendering silicon.
> 
> But if I can do something with 10 lines of code over 1000 lines of code I will take that option ever single time. My time is WAY more expensive than some GPU time.
> 

Combining power of D metaprogramming and immediate gui I have both developer efficiency and rendering performance efficiency. For example I failed to implement custom tree view using Gtk and Qt/Qml and it was really simple to do it using immediate gui. But I see drawbacks of immediate gui too.