Hacker News Reader

Comment by Solvency | Hacker News Reader

I think the 3 absolute demons that will eventually seek to destroy you in any homebrewn GUI framework will eventually be:

- Rendering and dealing with text in all of its extreme permutation. Styling. Localization. Character sets. Etc.

- Modern accessibility standards. There are countless annoying yet de facto UX patterns that are just nightmarish to check off the list from scratch. Inputs/forms/etc. Even worse than accessibility, because you can decide to forgo that completely if you really wanted. The sheer volume of UX use cases and edge cases involved in even seemingly basic input components is also an exercise in rote dread. You've got input validation, error states, just so many ergonomics to deal with.

- Fluid layouts and scaffolding. This is where modern HTML/CSS finally starts to shine because making flexible layouts is actually quite painless. But it's a motherfucker to roll your own approach.

View on HN

I had no idea how deep the text rabbit hole goes until a couple of years ago when I got the bright idea to make my own UI rendering engine. Quickly realized that I was waaaay out of my depth, and I now have a profound appreciation for all the existing stuff we take for granted.

With a background in linguistics and a descent understanding of Unicode, I thought I had something of a grip on the complexities of text. But then I read Text rendering hates you[0] and realized I had no idea how hard rendering text really is. The most striking example for me is the Arabic example where allh (Allah) is styled with different colours on each of the four characters, because this particular character sequence is a mandatory ligature if memory serves, and how do you figure out the colour changes when you're layout out a single glyph from the font?

0: https://faultlore.com/blah/text-hates-you/

Ha, yep this article was actually one of the things I was thinking of when I made the comment. I remember reading it and thinking "...maybe I don't want to do this after all".

Love the pun/typo of descent there. Trying to learn about Unicode does feel like you are descending into the trenches of meaning. In ways you probably don't want to.

I wish more people on HN would be this adventurous and this humble about their adventures.

My career in tech has been one humbling experience after another. I don't know how anyone spends more than a few years in this industry and still feels intelligent.

For me, the top of these is accessibility. Obviously people can write code they like for fun and free, but governments are increasingly, and in my opinion rightly, saying that if you want to sell a product it must be accessible if that is reasonable.

People like Apple, Microsoft and browsers put lots of effort into this if you use their existing frameworks right.

It's been bugging me for years, but I don't really enjoy modern HTML/CSS for fluid layouts when it comes to forms.

To do really nice form layouts in a desktop application, alignment and sizing of labels across the entire form becomes really important to me. Products like Developer Express that have a dedicated form layout work so well for this. And some of the swing layout managers I've used (I can't recall the name, too long ago) make complicated form layouts much more sane than grid, flex and other css layouts.

I will say this about HTML+CSS: it's not the best layout system I've ever used, but it's certainly the best one I've used that runs on all the platforms I care about.

That might change with .NET MAUI, though. I'm not too deep into it yet, and it is significantly different enough from HTML+CSS to be a challenge to learn, but what I havelearned so far keeps making me question "why did the CSS version of this have to be so hard?"

Maui would be interesting, if it had Linux support.

and ready for prime time!

I'll mention two others I find very hard.

The compositor. Dealing with ancient Win32 API, with his semi intelligent windows where seemingly every window feature is in weird undocumented ways coupled. Also, the race condition when rendering, just resize any window and see it jiggle. We seem to have collectively given up on fixing it.

Text Input. While not terrible difficult, so many features. From drag and drop, copy / paste, page up / down, CTRL up down left right, Home / End, wrapping. Text is by far the most complex GUI.

It's not the whole story but part of what makes accessibility hard is toolkits not being designed with it in mind from the beginning. That's how you end up with things like accessibility "modes" that are really just skin deep themes instead of proper modes.

Good accessibility capabilities requires flexibility to be at the core of the UI toolkit. You basically can't make assumptions anywhere.

But you can't forgo accessibility. Anyone who would make software with your framework would be in violation of several laws.

EDIT: I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have? Surely it can't be "not a large enough market". There are more legally blind people in the world than Firefox users, yet web developers will happily test compatibility with that dying browser and eschew screen reader testing.

15+ years ago, I worked for an Australian university. We had a project to migrate to a new student email system – we were going from Novell NIMS (hosted on NetWare) to Sun/iPlanet/JES Messaging (on Solaris).

We asked our disability services office to review the webmail's accessibility. The manager of that office was a blind woman, who was both a staff member and a student, so she had her own personal student account. She told us she couldn't use Sun's webmail, it wouldn't work at all with her screen reader. We complained to Sun, their response was "we know, wait for the next major version".

What did we do? We offered her a shell account on a Solaris box with Pine, and told her that we'd offer the same to any vision-impaired students or staff members who requested it. And she was happy with that solution.

IANAL a lawyer, but from my understanding of disability discrimination law (which is different in different countries anyway), you are legally obliged to offer "reasonable accomodations" – which doesn't have to necessarily be by making the application accessible, it could be offering access to an alternative application instead.

Also, you are only obliged to provide accessibility if a disabled user asks for it, which assumes you have a user with a relevant disability – if your application is sufficiently niche, that might never happen. Suppose you build an internal GUI for SREs to use. Do you need to make that accessible for the vision impaired? Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation.

> Well, are any of your SREs vision impaired? If the answer is "no", then legally you don't. Maybe one day you'll employ a vision impaired SRE – at which point, then you will be obliged to make it work for them. But, maybe you never will, in which case you'll never have that legal obligation.

I don't completely disagree with you, I think accessibility is often a spectrum, and it's good to be thinking in terms of what your specific accessibility needs are, rather than just going for a scattergun approach.

That said, I have some problems with this example.

Firstly, a lot of features end up in the "accessibility" bin that are more broadly useful (the "cut curb effect"). Your SREs might be fully sighted and mobile, but they will probably still appreciate being able to drive the software fully by keyboard. And even from a development perspective, I've found having correct aria roles etc can often be useful for end-to-end testing because it allows you to be more semantic with the tests ("click on the thing with a button role with the text 'submit'" rather than "click on the element with the ID '...'").

Secondly, we often see accessibility in terms of the extreme cases ("you are blind, you have unlocked the accessibility treatment now"), but accessibility is more broad than that. If you're working late at night in a dark room, or trying to do something on a small laptop screen, or you were out climbing and now your wrists ache, you might still appreciate accessibility features - zooming, keyboard navigation, accessible themes etc. Getting this stuff right helps everyone.

Finally, retrofitting accessibility is often a nightmare to actually implement, because (a) it's hard to notice what's not working unless you go through everything with a fine-toothed comb, and (b) if you don't have at least some accessibility plans to start with, you might have dug yourself into a corner that you can't get out of. For example, if your gui framework has no accessibility support, and someone blind starts in a month's time, what are you going to do? Rewrite the whole application for them?

Yes, accessibility is all that too. But those things are what the vendors usually do not want to do. As in, actively, because that gives agency to the user, and would defeat whatever abusive business trickery they built the software to inflict on people in the first place.

We talk about accessibility in terms of extremes, because those extremes are where we have legal support that companies can't ignore. The vendors don't want to cut the curb, they want to replace it with a fence and a toll gate. Talking about wheelchairs and strollers lets us prevent the fences, and the toll gates. If they figure they'll skip the curb too, every user wins, but this won't happen without prioritizing wheelchairs, and won't happen if we emphasize regular people too much.

Or, in short, accessibility is the only weapon we have to fight dark patterns and maybe get some ergonomics for everyone.

Not a lawyer, but if this was true, wouldn't a bunch of developers and companies be facing fines? Especially smaller open-source stuff. And larger companies as well (for instance, Reddit's mobile app is infamously inaccessible).

Yes, they would. We're all only getting away with it because nobody has complained. It's a massive risk that companies are running. I don't know how Reddit has skirted it for so long, but there have been several high profile cases in recent years.

Reddit can be used on a website (which is how I've always used it, old.reddit.com even better) and I assume it's "accessible" on the browser. As another commenter said, as long as disabled users have options for using your application, there's no ground for litigation.

The time isn’t right. They haven’t IPO’d yet. Should file the lawsuit at the end of the second day post-IPO.

> I see that there are people down voting several comments in this thread in support of accessibility. I wonder what disagreement that you have?

Didn't downvote but I want to share a couple thoughts I've had about accessibility:

- I assume that browser/electron accessibility is not really optimal for users. It's sort-of free if you're building web/browser stuff, which is nice because it's available by default, but I can imagine most applications could be tailored for accessibility and be much more productive and enjoyable for end-users. For instance a "blind mode" for a text editor would probably be a lot different than what you get out of the box from a screen reader + VS Code. (I would love to get feedback on this from someone using a screen reader or accessibility features.)

- I worry you're providing a bit of a moat if you regulate/require accessible software, since for most applications that equates to using a native GUI toolkit or browser-based solution.

AIUI that law only apply to businesses who make their employees use the software without accommodating their disablities, and customers that are required to use inaccessible platforms (e.g. only permitting refunds through a website and not in person/by mail, but the website isn't accessible). It doesn't actually require all programmers to exclusively ship their apps with frameworks with accessibility features.

(IANAL)

What are those laws?

https://www.legislation.gov.uk/ukpga/2010/15/contents

Section 20

I'm not used to reading law in English, so this is all a bit hard for me to parse, but I'm having trouble finding the section that prescribes the addition of accessibility features to all software written for any purpose.

Say I am a British person who decides to make a some common piece of software, like a spreadsheet, and offer it for download on the internet. Am I required by law to make it accessible? And if, for instance, the provision of accessibility features would require thousands of hours of redevelopment, does that fall under "reasonable adjustments"?

I understand that the moment my software becomes required for someone's job, for instance, there might be a problem, but a few posts up it was implied that making software without accessibility features was in itself illegal in some way, and that just sounds doesn't sound right to me.

(Not a lawyer)

Section 20: https://www.legislation.gov.uk/ukpga/2010/15/section/20

That does not call out in its table any reference to software. I can't see anything in it which would effect a binding to software products. Section 22 refers to regulations being able to define what are "auxiliary aids", so in theory an SI may have done so.

Scanning the whole Act, the closest thing I can spot is Schedule 25: https://www.legislation.gov.uk/ukpga/2010/15/schedule/25, however even that defines it as “any service normally provided for remuneration, [...]". Note that is for an online Service, not a Good (which software would generally be). I've also not found what references it.

So that may cover a web site, but only if it was a paid for thing (e.g. online newspaper sites accessed via subscription). I wonder if and how it applies to the likes of Amazon, where the site itself is not paid for, but goods available through it are.

So unless someone can find specific references, I see no reason to believe there is such a statutory requirement in existence for software, certainly not for free software.

The EQA says that your website must provide reasonable access as any other user would have. It focuses on equality of usage, not specification of how software or supporting software should meet it (a la WCAG)

You said

>Anyone who would make software with your framework would be in violation of several laws.

Which just isn't true as there are ways you can comply with EQA without every underpinning library being accessibility-compliant.

Rule of thumb: a UI toolkit is equivalent to a game engine like Unity.

Approach it like that and you have a slight fighting chance because you know what you are getting into.

> UI toolkit is equivalent to a game engine like Unity

Funny that you mention Unity because they first had an immediate mode UI that was very difficult to work with, then they got a more flexible UI but decided to go the HTML way of having separate documents for elements and styles, making the whole design process way more complex.

Unity in recent years has a tendency to overengineer things and have little regard for ease of use for some features.

The new input system is powerful and flexible but is slower to learn and makes lots of things that used to be easy much harder.

Same for the new UI Toolkit and several other recent additions. I think it's a company culture thing - nobody internal is rooting for casual devs or noobs.

The problem is - everyone is a noob on something. You might be an incredibly experienced Unity dev who rarely touches input or UI. You want to quickly implement something and you're going to feel the pain.

"Make the easy things easy, and the hard things possible."

For me it was the text issues that dulled my desire to keep working it. I was updating a Nim based immediate mode GUI called Fidget (https://github.com/treeform/fidget) and fixed a number of issues. It was fun getting 9-patch rectangles with corners working, etc.

I even implemented a fair subset of CSS grid:

    parseGridTemplateRows gt, ["row1-start"] 25'pp \
        ["row1-end"] 100'ux \
        ["third-line"] auto ["last-line"]

( https://github.com/elcritch/cssgrid )

However, text input is hard and tedious! Then you ideally would need to handle the different keybindings for each OS. You also loose any plugins the OS'es provide. Not to mention the lack of accessibility.

I recall reading that browsers shim out to native OS text fields and wonder how that's done. It really seems like the best approach for small GUI libraries to enabled first class text input.

> Fluid layouts and scaffolding.

Short of doing a whole CSS rule engine (best) you can also implement a Flutter-like layout system. It is described well by Flutter documentation and is quite flexible.

For the text rendering part, is there no off-the-shelf library that provides that functionality?

There might be a few, but the complexity of the task reduces the number of options (the most popular choice is probably FreeType+HarfBuzz). But even then there's the problem that FreeType's text rendering might look slightly different than the underlying system's text renderer (so your application stands out like a sore thumb), and text rendering also affects UI layout (just take right-to-left languages for instance) - so it's often not an isolated drop-in solution.

Ideally the underlying system would offer a low level text rendering API that's independent from the system's UI framework and can be combined with your own rendering efficiently (haven't used it, so don't know how good it actually is, but for instance on Windows there's DirectWrite). The problem with this approach is that not all platforms provide such a modular text renderer (for instance web browsers), and you need different code paths on different platforms (maybe even still have to integrate FreeType because one of the target platforms doesn't expose a text rendering API).

I believe Harfbuzz is used almost universally by every major application from Chrome to Firefox.

Harfbuzz only provides 'text shaping' (very important for UNICODE support, especially for languages like Arabic), but the actual text rendering needs to be done elsewhere.

Their rendering engines choose the OS native one. They have abstractions over that. For example they'll use DirectWrite on Windows. Implementing a partial GUI toolkit is just another thing in the list of extremely hard problems in browser engine development.

Reply on news.ycombinator.com