On Wed, 24 Oct 2018 18:39:20 -0700, Adam Wilson wrote:

> On 10/24/18 5:22 PM, Neia Neutuladh wrote:
>> 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.
> 
...
>
> One thing I can say with confidence is that the average user wants each app to behave consistently regardless of where they using them. [snip...]
> 
...
> 
> 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.

Yes and no. These design elements are most important for people that use an app on multiple devices - which is often less common that we tend to think (at least for the next 2-3 years). But there are UI adjustments that need to be system-specific.

I'm sysadmin/helpdesk; I'm the one that helps people save their email attachments, extract files from a zip archive, explains why they didn't actually save that document because the OK and Cancel buttons are in the wrong order...

Whenever people struggle to understand how something works, I ask them to describe what they expect. People tend to have pretty reasonable expectations -- the way people want the software to work often makes more sense than the actual design. I've come to see non-technical people that just want to get some task done as more reliable designers than those of us to can fall into the habit of making the tech itself the important thing.

For major elements, like descriptions, menu order, button color, yes, the application on every platform needs to be consistent *if* it's a multi- platform application; otherwise it should definitely follow system guidelines (on macOS, the OK button should be blue). In other areas, design elements need to be adjusted by that platform. Windows places OK on the left, Cancel on the right; macOS is the reverse - and if you're application gets it wrong, your end-user will not be happy with you.

--Ryan

On Wed, 24 Oct 2018 03:29:58 -0400, Nick Sabalausky (Abscissa) wrote:

> 3. Transitively, I would caution against conflating "current direction of trends" with "what we, the creators, should be doing." [snip...]
> 
> 4. I would caution against taking myopic, self-absorbed corporate-interest motivators (such as "our branding before the platform's branding") as higher-priority than *THE USER'S BEST INTEREST* when creating a product *FOR THE USERS TO USE*.
> 
> 5. In any endevour of creation, at some point, you have to ask yourself: "Who is this being creating for? For myself/ourselves, or for the people who we HOPE will actually CHOOSE to use it?" [snip...]
> 
> 6. I've noticed that your entire several-page post and you're entire argument regarding user-interface decisions makes absolutely ZERO mention whatsoever of THE USER

I agree with what you're saying, but could you elaborate as to what you see that is being ignored? Other than performance considerations (which is why I'll never even consider Electron), I don't see much in that post that would have a direct and major impact on end-users -- though there would be many followup conversations that would need to.

I guess I think of a UI toolkit's primary audience being the developers, and the developer's audience is the end-user; there are things the UI toolkit needs to do for the end-user, but ultimately UX is up to the application developer.

-Ryan

On 26/10/2018 12:09 AM, rjframe wrote:
> I guess I think of a UI toolkit's primary audience being the developers,
> and the developer's audience is the end-user; there are things the UI
> toolkit needs to do for the end-user, but ultimately UX is up to the
> application developer.

If a GUI toolkit does not interact with the system's accessibility API's it isn't the developers which suffer its the end-users.

But I agree with you that the GUI toolkit developers are ultimately not responsible for the UX of a GUI. But they can certainly do a lot to make it more likely to be correct for the end user.

On Thursday, 25 October 2018 at 09:14:08 UTC, Basile B. wrote:
> On Thursday, 25 October 2018 at 08:13:38 UTC, rikki cattermole wrote:
>> On 25/10/2018 9:06 PM, Adam Wilson wrote:
>>> There is absolutely no reason that a D based non-native toolkit could not be used to mimic the native theme at a pixel level. WPF does it, so we *know* it can be done. Easy, no. Possible, absolutely. :)
>>
>> We can do better than just the visual attributes. Hook in the accessibility API's of the platform and we'd be significantly better off than libraries like nuklear or imgui. But first, we have to decide to actually engineer a solution and not just hack one together like dlangui.
>
> People needs to work together, forget their little person, make concessions.
> "Cool kids" have begun to build desktop apps using web technologies, that's imo impossible to accept. We need to stop being some stupid / classic asocial system programmers.
>
> I'm part of the many who tried to build his own little GUI framework and finally gave up because a GUI framework requires many knowledge in many domain (i.e you want to to work on a GUI but you have to loose your time on learning how clipboard works on X...). It's time to move on. When you'll have finished the core (windowing, message loop) it will be time to build something serious on top. I think that something like the Lazarus widgetset system may work.
>
> People just need to start working together. Talents are here but fragmented.

I also have homemade UI widgets and windowing and now need a CSS equivalent! This story is familiar it sounds. I don't think it will be easy to serve many use cases but it's probably worth it to try.

I'll gladly participate in such a work-group (wherever it is on Github) and can provide some native Cocoa backend help (amongst other), preferably if led with a top-down vision by Adam Wilson (yup). I think enough people around here can deal with the bottom-up aspects of such an endeavour.

Btw I agree with the assessment that CSS+HTML is where it's at currently. It's not that it's best but browsers are about the only thing that can display multi-lingual text correctly.

On Thursday, 25 October 2018 at 11:23:27 UTC, Guillaume Piolat wrote:
> Btw I agree with the assessment that CSS+HTML is where it's at currently. It's not that it's best but browsers are about the only thing that can display multi-lingual text correctly.

Why would you say that bo toolkits (HTML is no toolkit!) can render multilingual text? Some of them most definitely can. If programs fail to support it, it is mostly because some of the required international work cannot be abstracted away and has to be performed in a domain-specific way by the application developer. And that is hard.

And I have to put my foot down hard and tell you that HTML for desktop UIs is just inadequate and wrong. D as a language is strongest when performance matters. That includes applications that need very involved GPU accelerated rendering and visualizations. Webkit or Blink would imply that WebGL is required for rendering. And that is a toy API compared to what is available in DirectX, OpenGL or Vulkan and comes with severe limitations.

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> I was reading the hijacked JAXLondon thread about GUI's and started replying but decided against hijacking the already hijacked thread again.
>
> I've been working with UX toolkits since the earliest days of my career and it was one of the first things I looked for when I started using D in 2011. Needless to say I wasn't impressed. 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.

I think I can contribute something useful to this too. I've worked with MFC, Visual Basic from 1.0, Paradox, Delphi (1,2,3, I actually paid for this with my own money, and it was worth it), SQLWindows, Oracle*Forms, ActiveX/COM/OLE2, Swing, Qt Widgets (not QML) (C++ and Python), wxWidgets, JavaFX, DHTML/Javascript/CSS, Android UI and probably others I've forgotten.

>
> 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.

Yes, because the web is close to a universally available platform, running everywhere. No one who knows Qt or JavaFX would choose the dogs breakfast of accidental software DHTML/Javascript/CSS/Ajax etc. if Qt or JavaFX was equally universally available/distributable on all platforms.

>
> I think this is a key point. The theme itself is now part of a brand and using the native toolkit would be a branding disaster. American Express, Facebook, or Google aren't in the business of showcasing Microsoft's, GNOME's, or Apple's branding, they want their apps to showcase their own brands.
>

What has a companies brand got to do with a widget theme? Anyway, it doesn't matter. BTW JavaFX has excellent CSS based widget/scene graph node themeing.

> Somewhat unusually for Microsoft they recognized this shift in industry early and starting with WPF in 2006 they have allowed you to completely customize the look of widgets. WPF actually began as an (however misguided) attempt to improve on the UX capabilities of HTML/CSS. They continued this direction with Silverlight and most recently, UWP. UWP is intended as the long-term replacement for the Win32 UX API's and Microsoft is no longer developing the Win32 API's, it's
> just bug fixes now.

Many many years of MS chopping and changing their recommended UI development platform (Silverlight is a great example) have taught me not to build on MS's latest and greatest UI platform - whatever that is this month.

>
> 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.

>
> So why doesn't D have ANY useful bindings UX library bindings?
>
> The answer, I think, is that almost every case, the UX toolkit in question was designed for a specific language, Qt->C++, GTK/MacOS/Win32->C, SWT->Java, WPF->.NET, etc. and these toolkits are often deeply integrated with the languages they are implemented in.


Qt works brilliantly from python too, not just C++. It could easily be used from D and other languages too, if there was a binding. How come no one has mentioned Calypso in these two GUI threads? The Qt binding is just about complete with Calypso, as far as I can tell.

Russel also suggested creating a binding a la sip/PyQt. I started something based on the same architecture as PyQt in 2014, it's probably crap, but it's not that far off providing something that works. I stopped because Calypso looked so good.


>
> The way I see it. We either pull together around a unified vision for a UX toolkit written in D from the ground-up or we wait (im)patiently for a benevolent corporate benefactor to appear. It's that simple.
>

No, Phil Thompson wrote PyQt on his own. Something similar for D/Qt is not impossible, I have (had) a working core to prove it. Calypso is much better, but frankly, no one seems interested. It's more fun to bikeshed about writing an entire UI toolkit from scratch.

> I do have a vision for a non-native, WPF-like, UX toolkit written entirely in D. I estimate that it will take a minimum of three extremely dedicated, multi-disciplinary, individuals about three to five years to complete with the help of a constellation of secondary contributors. I have a rough design sketched out and I'd be happy to post it here but this message is already getting to long.

>
> 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.

If you seriously want a good UI toolkit for D then write a wrapper for Qt. It's very feasible. it would be tremendously useful. Writing something even half as good as Qt? I admire your ambition but there is simply no chance of it happening. None.

BTW, an aside, I was very surprised that for a large family of applications, JavaFX is even better than Qt. Just an aside for those who have C++/Python/Java as potential options for their next masterpiece.

Abdulhaq

On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
> How come no one has mentioned Calypso in these two GUI threads? The Qt binding is just about complete with Calypso, as far as I can tell.

I would have mentioned it if I had known about it. It never showed up in my searches for some reason. I will go and check it out.

On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
> Qt works brilliantly from python too, not just C++. It could easily be used from D and other languages too, if there was a binding. How come no one has mentioned Calypso in these two GUI threads? The Qt binding is just about complete with Calypso, as far as I can tell.

Calypso is one specific compiler AFAIK. Something like a GUI library shouldn't be tied to using a specific compiler.

On Friday, 26 October 2018 at 07:44:03 UTC, Laurent Tréguier wrote:
> On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
>> Qt works brilliantly from python too, not just C++. It could easily be used from D and other languages too, if there was a binding. How come no one has mentioned Calypso in these two GUI threads? The Qt binding is just about complete with Calypso, as far as I can tell.
>
> Calypso is one specific compiler AFAIK. Something like a GUI library shouldn't be tied to using a specific compiler.

Yes, you are right. But if you really want to write a fast, rich GUI application using D, then LDC/LLVM/Calypso is probably the closest you can currently get. I'm very curious if anyone here has actually tried to use it in the last couple of years, and if they were successful or not.

On 10/23/2018 11:20 PM, Adam Wilson wrote:
> [...]

I must say, that was a well-written and enjoyable article. Thanks!