> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community should standardize namings and structures for common components.
It's so tempting to think of all the efficiency that could be gained if we'd stop replicating the same work and just all decide how to do things 'right', unfortunately though this isn't how the best results are achieved.
This is fundamentally a conversation about markets - in this case for ideas. Lots of parallel work is done in a distributed manner, much of it is wasted, but because of the competition between and combination of different ideas, you get emergent results that are really finely tuned to what people actually want in practice.
Top down planning won't get you this. You'll have less waste, to be sure, but you'll also have inferior results.
Some people can use pre-made UI components while others can have them tailor-made to better fit the case.
I, as a programmer, have a tough work to design UI components that fit well together, and of course I don't do as a good job as someone trained to do this.
So, I rather reuse components done by others if the project I am working on does not have a budget for UI specialists as can happen to a lot of projects.
Using premade components from big popular UI libraries like bootstrap, material UI, ant and so on is the market approach the parent mentions. All of those libraries are completing.
This project is not about reusable components. My understanding is that they want to standardize things across all of those projects so that a “switch” refers to the same kind of component in every project, for example.
I think this is an insufficient argument. There are lots of examples where standardization works and is effective, eg HTML, HTTP, SSL, FTP, CSS ...
The argument you posed is against standardization in general, but if the conclusion is “all standardization/regulation is bad” that holds no empirical water. You have to make the case that this specific standardization is bad, since standardization as a concept is not in question.
In my experience, SOAP has poor tooling compared to REST and nobody implements it properly. Given that, it's not really more powerful than REST in practice.
Well none the less, the standard doesn't help if nobody follows it. Since REST is less prescriptive, the tooling is generally more tolerant of all the funny implementations out there. At least, that's what I've found.
The web has traditionally followed a pattern where people are left to try out new things themselves, experiment with ideas, have a competitive marketplace of libraries and frameworks, and then once there's a consensus the selected approach gets enshrined and implemented as a browser standard that everyone can use. This happened with DOM selection and XHR fetching (jQuery), with promises, with list comprehensions, with modules syntax (ES Modules). It's time it happened with reactive DOM rendering.
I know what you mean, but I'd argue while that works for technical details with defined inputs->outputs, it doesn't really work for UI which is a much more open ended problem/solution space which the user directly interacts with. Beyond even the practical concerns with locking yourself down to certain modes of doing UI, there's also just evolving taste, trends of usage, device types etc. I just don't think UI is something you can ever call done.
I don't think what the GP is describing would restrict anyone from innovating in the UI space. What we need is a standard API for framework+component life cycles, tracing - i.e. a currentComponent api for tracking the relationship between JS scopes and DOM elements, and context/slot apis powerful enough to bridge between the parent-child semantics in React/Vue/etc and more complex implementations like Svelte's slots. A better abstraction between browsers and OS accessibility layers also wouldn't hurt.
Think aria attributes, window.requestAnimationFrame, source maps, and the JS debugger statement - not UI frameworks or new standard HTML elements.
Also even if browsers did implement standard UI elements no one would use them. Its the same situation we have today where everyone re implements the browser default inputs because they are too basic and not flexible enough and work different on every browser.
> once there's a consensus the selected approach gets enshrined and implemented as a browser standard that everyone can use
That's kind of a charitable way to put it I think, implying democracy has anything to do with it. The "consensus" really is "will enough browser makers care to implement this thing?" meaning the consensus of TC39 and other bodies doesn't really matter much, what matters is the will of a select few corporations.
Even if you do squint and look at the committees involved and try to take the charitable view, you'll see that the future direction isn't so much dictated by any kind of "invisible hand of the market" but rather by who has the tenacity to show up and stick with it. That's how we get half measures like the Promise API, and abominations like EME.
Truth of the matter is that the standard bodies have no stick, so they just kind of have to hope that the big three (Blink, WebKit, Gecko) play ball, and these days increasingly the smaller two have to play catch up to Blink.
I commend everyone involved in these standards processes – they're doing a thankless and difficult job – but they're mostly paving Google's cow paths rather than those of "the market."
Okay, maybe the technically precise term is "Node tree", which is a part of the DOM. But colloquially people today know what I meant. Even the term "Virtual DOM" implies my usage of the term.
open-ui is not proposing to make components look the same, it's proposing the exact opposite: to make the common components customizable enough that each design system / UI toolkit can use them rather than rolling their own.
> it's proposing the exact opposite: to make the common components customizable enough that each design system / UI toolkit can use them rather than rolling their own.
Honestly, that just sounds like re-implementation with extra steps and an extra layer of wrapper/bridge nonsense. If I am going to completely redesign and customize the provided controls, I might as well roll my own. It would be way quicker and easy to maintain than a mountain of hacks on top of each other.
There is also no need for a central standard. My company just took an existing CSS framework (it doesn't matter which framework) and then slapped their own customization on top of it and then reused it in dozens of applications. Not much time was actually wasted on the design itself.
Fair enough, but I'm having trouble understanding the point of the abstraction. Open-UI sounds like it wants to be an overarching standard that all design systems should work to. So they can inter-operate. Which in my opinion is a flawed idea.
I disagree, As an end user I want websites to all look and function the same - standards matter for usability so if half the web is using the same approach to me that is a very good thing.
> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community should standardize namings and structures for common components.
Yeah, they're called 'HTML forms'.
If you want a standards-compliant, accessible UI that works everywhere then just use them.
If you want some godawful 'SPA' with UI elements that 'communicate your corporate style', then no amount of standardization will help here.
Exactly, this is essentially a 'free market' vs 'command economy', the free market has inefficiency in lots of individual actors doing the same thing at varying levels of success. The command economy has inefficiency from a weaker link between product fit and success. In most of the cases we see that better results are seen in terms of product quality through the free market. There are cases where the commmand economy works better - well understood problems where success is easily measured, but I think UIs are about as far away from that as I can imagine.
Our core protocols would like a word about the value of standardization.
Are you sure you’re weighing where the demand is correctly? We’re talking the cognitive consumption layer which is trivial to generate desire for customization in.
Try writing your own TCP/IP stack.
The web UIs are taxonomy. Design. Easily customized for small tasks.
Work that needs to be done generically (protocols) is more abstract and becomes a de facto standard. We fought the protocol wars on the same grounds (ipx, netbui, tcp/ip, oh my!) and we stuck with the free ones.
The demand is for jobs. Having a lot of web developers is a matter of ideology for jobs, and is not an indicator we have so much demand for unique web UIs we need all these people making them.
That’s not real demand. That’s demand to keep our ideology about work alive.
Given all these UX libs, a desktop app could have tabs and in each tab a specific style (mail form, blog post) with a random design applied.
The user could punch in their data, click a button to deploy. But we atomized each task for jobs.
We have enough content and our consciousness only really seems to like certain styles generally.
Throwing more monkeys at typewriters isn’t due to demand for UI. It’s to meet demand of middle class Americans that don’t want to work at McDonalds.
I disagree that there's waste. People do not participate in winner-takes-all contests very often. When you have 10 competing approaches, you still try to have a plan B and a plan C for when you are not finding the best-for-everyone solution. Maybe you cover a smaller chunk of the demand, or find a way to make it cheaper. So while someone is taking up a longer-term, higher-risk project, others are trying shorter term solutions. And everyone wins: you have something done sooner rather than later, and long-term projects face less competition, so their chances of success are more tied to an actual fit than to a luck of outcompeting others.
Here is an example of what top down planning helped me to build something https://github.com/imvetri/ui-editor. There are doers and talkers. open-ui.org is a doer.
I think it might be a result of the massive propaganda against communism during the cold war, but the efficiency of central planning is too often overlooked in such comments. Of course it's not a silver bullet, but it doesn't produce inferior outcome by design.
Remember: most big coorp (think Walmart) are actually centrally-planned mini state and yet, their profitability is excellent compared to smaller actors.
As I see it, there are many factors at play:
- Network effects
- Economies of scale (usually not large in software development)
- Other barriers to entry?
How important each of these is, depends on each particular market. In some cases, some coordination between agents could achieve better results.
Regarding network effects, uncoordinated efforts or competition between a lot of agents could lead to an inefficient solution that is very hard to change without coordination of resources (perhaps the QUERYT keyboard layout, that was created for old mechanical keyboards?).
Anyway, I don't think this is the case for UIs, but perhaps in other cases, some coordination could be better for long term results without sacrificing innovation.
Besides that, in a capitalist economy, inside every company/organization, there is some sort of 'Top down planning' and coordination between resources (Example: Alphabet: Google Search, Youtube) to gain efficiency and efficacy.
The standard is the web platform itself. That's the only standard that will ever be followed to any meaningful degree.
Much of the needless splintering we see today can be traced back to having too many mutually-incompatible reactive rendering systems. If you make a button in React, even though I'd like the exact same button in my Vue app, I can't use it because it's rendered via a different API.
The core barrier here comes down to the different templated-rendering systems. What we need is a browser standard for templated/reactive rendering of DOM content (data + template = DOM). The <template> element doesn't count because it doesn't actually do anything. Web components are nearly useless without having a story for reactive rendering.
Beyond just compatibility this would give web apps a massive performance boost, in terms of both CPU cycles and initial payload size. It's long past due.
> The core barrier here comes down to the different templated-rendering systems.
This shouldn't be a barrier at all. The rendering system a component uses should be an entirely encapsulated implementation detail of the component. Components should absolutely not have to use the same template system to be used together.
This is something web components get very, very correct.
> Web components are nearly useless without having a story for reactive rendering
There are libraries that address just that specific need, like lit-html which I maintain. Again, it's an implementation detail of the component.
> What we need is a browser standard for templated/reactive rendering of DOM content (data + template = DOM)
While rendering should be an implementation detail, I still agree with you here, simply because templating is such a universal need that the platform should provide some primitives to help developers.
The main idea is that it lets you mark up a <template> with references that will be cloned along with the template contents. These references can then be used to dynamically update the cloned instance. You can accelerate most template systems with these primitives. It's critical because the DOM doesn't have any other way to clone a chunk of DOM along with references to specific nodes in that tree without manually walking the clone's tree.
'rendering should be an implementation detail', right so I need to download 3 overly complicated template engines for every website instead of one? Seems like modern UI dev is just nuts...
You can attempt to standardize all you want, the problem is that some companies wanted to put things on their rails and not share the controls...vs just enhancing html itself as was done in past. But SPAs are not documents, modern web is nothing but highly optimized UI delivery, not fast UI nor descriptive UI.
Seems... a bit misguided of an effort when the SPA makers are not clamoring for change and things largely 'work' from a dev perspective already.
About once every six months I’ll come across a problem, think of possible solutions, think it will be impossibly complicated, remember XForms exists, remember it wasn’t as easy as it needed to be last time (usually a mobile related issue), research the current state... and walk away full of disappointment.
XForms was a brilliant idea and a perfectly acceptable technology to solve extremely useful but mostly boring business type problems that never caught on... probably because of the boring / business type feel.
But there are glimmers of hope, https://enketo.org Enketo looks like it’s turning into a pretty good backend agnostic option for developing with XForms which is one of the usual issues... there are quite a few XForms options out there but many require the use of specific server side tool chains.
This division isn't unexpected. Compare the Mac OS toolbox and the Windows API for UI elements. UI's widget toolkits are built atop the graphics and input APIs below them and tend to end up tightly interwoven (and the projects that attempt to provide a spanning set of widgets across different graphics / input UIs seem to tend to end up looking like a lowest-common-denominator solution with the clock rolled all the way back to the late '80s / early '90s concept of what "good UI" looks like).
Projects like these are saying just because we figured out how chairs work, everyone should use the same chair.
It just completely misses the point, people like it when they build something themselves it looks how they like it. Want to spend years working on something that looks exactly like everything else?
I agree - this fear of "reinventing the wheel" needs to go away. People gravitate towards products that suit their needs, and if they don't they'll cook something up themselves. It's really not the end of the world if you're writing something that someone else somewhere wrote. Everything has its advantages and drawbacks.
That’s not what this is about at all. This is simply looking around at people using benches, stools, stumps, and piles of rocks and suggesting we come up with a word to describe something constructed that you sit on... then looking at the nicknames currently being used and highlighting the most common. It has nothing to do with prescribing any particular style of chair.
Has it become a mess though? I agree there are tons of frameworks out there but if you focus only on the main ones there are not more than for the trio of windows/linux/macOS. Heck, on windows only you can use half a dozen frameworks without even journeying to more esoteric ones.
Ultimately there are different frameworks precisely because different people have a different idea about how a UI framework should behave.
To many developers, what the software does is several orders of magnitude more important than how it looks.
There are certainly cases where visual design is much more critical to what you're building, but there are plenty where it's little more than an annoying distraction.
to many customers, there’s a handful of different software choices that more or less do the same thing. so interface and design plays a big role in experience
The point of frameworks is to provide a common operating pattern (familiarity). Frameworks often increase work at maintenance time due to being higher level abstractions that dictate conventions and practices that limit expressive independence.
Where do you think 'select' came from? Long ago we had many UI select boxes in many native frameworks...and decided that was too much work so we made tags...then browsers...most of the disconnect comes because UI controls have so many usages that ultimately you always want to bust out some code.
If OpenUI wants to enhance the default behavior of select, input, credit card, etc, cool, if they just want to build anothet framework then I'd rather use svelte or angular or vue. The large libraries already standardize, its just a matter of who 'wins' out, and there are already only a few SPA winners.
If it’s really about what the software does, then the conversation would be about exposing proper APIs that let me view the data, query it, schedule operations on it, etc.
But then offering a shinier/slightly more bespoke way of doing that becomes a competitive advantage for your product, and now you get why everyone wants to build their own custom UI.
The reason why the aforelinked to Open UI project will never be the One and Only way to build UIs on the web is because there’d too much economic value in being able to do precisely what it can’t do!
Distinguishing on/off state only by color is highly non-usable. Neither from a13y perspective nor for ordinary users. And to keep in mind LTR/RTL problems if someone rely on knob position.
What's wrong with classic check box for that purpose?
Check boxes don't imply immediate effects. They require 'saving' to take effect. Like when you're filling out a form, the checkbox doesn't do anything until the form is 'interpreted' by a human.
Switches(toggles) on the other hand, imply immediate effects. Like a light switch, we expect the change to occur immediately.
I have never heard of or expected this from my "binary choice components". To my knowledge, switches are used on iOS, while checkboxes are a macOS thing (though they just added support for iOS-style switches, but with a very specific purpose).
I have never heard of or expected this from my "binary choice components".
It's fairly standard in 'traditional' desktop UI where actions are supposed to be initiated by regular buttons and things like radio buttons and checkboxes are for setting the options of the action. "Radio buttons never initiate an action" says the classic MacOS HIG, for instance.
Right, but on macOS, checkboxes often apply immediately. Just look through System Preferences, which largely doesn't even have a "save" action: checkboxes have take effect instantaneously. (So do many radio buttons…)
Yep, that's why I said 'traditional', this has drifted a fair bit because there's a benefit to providing immediate feedback, especially if the action is some visual and reversible change like turning on dark mode. Windows ribbons are also full of such radio buttons and checkboxes.
I absolutely hate them. 80% of the time it's confusing as to which way is on/off either because of design or because of the wording for that setting/option.
I also prefer checkboxes to switches – at least on desktop.
Although anecdotally, I've helped a few older, technophobic people learn how to use websites/phones, and the majority of them know exactly what to do when presented with a switch, but they don't realize that they can click a checkbox. To them, it just looks like a square and they ignore it. (Take this with a grain of salt, my sample size is <10.)
> Distinguishing on/off state only by color is highly non-usable.
All of the examples use at least color and position, the majority also add an additional icon in the checked state (one of those also has a different icon on the unchecked state) and Material Design uses a relative contrast distinction (which, unlike a simple color distinction, is readily distinguishable for the colorblind.) There is exactly one (ANT design) that uses only color and position to distinguish between checked and unchecked states.
if you open iOS settings, you'll see them all over the place. They are not a usability disaster and any shortcoming in articulating intent should be attributed to the designer themselves. Switches can also be used when the binary state is not on/off and you don't want to imply a default state necessarily such as dark/light theme switches.
Project neglects UI paradigms/technical terms outside of the browser, that kind of wilful ignorance can only end in tears. Open up `designer-qt5` some time and marvel at the sheer number of UI widgets. https://duckduckgo.com/?iax=images&ia=images&q=qt+designer
Having cut my programming teeth on a Visual Basic analogue and later Cocoa/AppKit, both of which have a similarly rich roster of widgets, going into front end web development was somewhat shocking and frustrating. Where I would've been writing application logic, I was instead writing common widgets from scratch.
It's hard to believe that this has barely changed in the decade+ since then. The web has grown and matured immensely as a platform, yet it's still necessary to bring in (often heavy) third party libraries to not spend all our time writing basic widgets.
At minimum, browsers should provide basics like recycler views that can satisfy a majority of use cases with a little CSS and act as a foundation for libraries to build upon for the use cases they can't. One shouldn't need to pull in heavy third party code for such common functionality.
Negligence is a bliss. They may reach a different solution which others failed to see.
Open up `designer-qt5`
Ok. we had a disaster before and you witnessed it. Similar disaster is going to happen to this project, why cant you share what you learnt from `designer-qt5` and share it to this project?
Even on desktop their site isn't great. There are hardly any hints regarding what is a hyperlink. Only the mouse cursor changes. I've seen far more accessible designs.
To me, the most exciting aspect of this project is the common language. I would love to have a kind of dictionary of UI components where I can easily look up the correct (and widely accepted) name for a type of component.
No more carousels that are called sliders because they slide. No more wondering if it is a split button or button group...
Especially the Component Name Matrix[1] is great. Bookmarked.
Ambitious project! I hope there's some useful contributions to come for UI development. I was confused by the "concepts" sections—there's little meters with red and green, but it doesn't really express what those meters mean nor how they've been evaluated for each concept. It's surprising to me that something like a "basic" checkbox would get a 3/14 green: checkboxes are a pretty standard form element for both electronic and printed forms: what's so poor about the UI of this element? What's the better alternative?
> I was confused by the "concepts" sections—there's little meters with red and green, but it doesn't really express what those meters mean nor how they've been evaluated for each concept.
It isn't explained, but if I'm not mistaken it looks like they put a green box in the meter for each different UI system that they've recorded for it.
E.g. on https://open-ui.org/components/switch, the "basic" switch has 5 green boxes in the meter: Ant Design, Atlaskit, Evergreen, Lightning Design System, Material Components Web. The next example, "autofocus" only has 1: Ant Design
So it appears they are ranking the features (basic, autofocus, default, large, etc. of each component by how much support each feature has across design kits.
I was confused too because using the green/red meter makes it seem like they're giving it a score or rating. A better alternative would to say: "We found 5 frameworks that support this feature"
It also pollutes your browser history with a ton of navigation routes. Not the end of the world, but I feel a project with this ambition needs to have flawless standards to succeed.
Back when <insert-SQL-database-vendor's-name-here> "Forms" SDK's and tools where the way that data-centric applications were developed, do you think there was any consensus on naming and components?
You might have been able to leverage some conceptual knowledge from Oracle's tools to the ones associated with Postgres, but everything was different at the syntactic level.
When <insert-software-development-corp-here>'s GUI toolkit were the way that data-centric applications were developed,do you think there was any consensus on naming and components? Not all. People using MS GUI tools would flounder amidst Cocoa, and vice versa. Qt users would have to constantly read the GTK manual, and vice versa.
You might have been able to leverage some conceptual knowledge from one vendor's tools to the ones associated with another's, but everything was different at the syntactic level.
It might be a good idea to settle on some "global" definitions and components, but that hasn't happened before, and I can't see any particular reason it will happen for applications developed around the web platform.
> It might be a good idea to settle on some "global" definitions and components, but that hasn't happened before,
But it has. We all know what buttons, dropdowns, forms, windows, text boxes, etc. are. Windows and macOS gave us these concepts and the Web adopted them.
The vision of Open UI is "interoperability" but it doesn't explain what exactly is supposed to interoperate.
To support that vague vision, Open UI identifies four goals, and all of them are silly.
1) Document component names as they exist today
2) A common language for describing UIs and design systems
3) Eventual browser standards for web app components
4) Converging designer processes and developer workflows
#1 and #2 seem like two sides of the same coin, but they don't directly solve any "interoperability" problem. Agreeing to use the same name for "button" or "switch" would hardly solve this problem from the vision statement: "Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps."
#4 is so vague that I literally have no idea what it means.
As for #3, we already have have browser standards for web app components. What would Open UI deliver?
In that case, I think the vision statement should say:
"Open UI will develop new web components that we hope will one day become built-in standard browser features. To do that, we're going to scrutinize popular UI design systems, looking for cowpaths to pave."
Well the site is pretty broken on Android for Firefox.. that aside I sympathize with the mission but not sure preaching about wasted effort is going to help anything. Presentation should be completely up to the client, we need a UI that can understand what is being sent back from the server and dynamically visualize it in various ways based on user preference. We should not be stuck with whatever JS and mark up is sent back from the server. Ie we both are visiting hackernews but we should be able to configure our UI to view it in completely different ways based on preferences. And this can't be based on a standard per se because there won't be buy in. There just needs to be a UI client that is basically intelligent that you can tell it how you want your data visualized or presented and it will do it for you magically.
In this thread there seems to be no end of comments seeking to tear down the project under consideration.
In my opinion, this project is a good initiative and more folks should take a page from this project's book. Even if you think such a project is critically flawed, an effort to thread a needle and help the community deserves praise and constructive feedback. In this particular case, the author(s?) is apparently taking the time to study a broad selection of UI frameworks and synthesize what they are learning into something everyone can benefit from. That's awesome, and I hope they keep up the good work
> The purpose of AnyGui project was (development stopped in 2002) to create a generic access API to different types of GUI libraries found to work with Python. The name is inspired by the standard Python module anydbm, which provides generic access to DBM-style databases.
That's just one example of a meta-gui framework.
Without an extensive "related work" section this is just navel-gazing.
The whole vision is full of "shoulds" and "deserves" words. That's not how the world works, neither The Internet which has been built for decentralization. I don't think that will work, because unless there is a common interest no framework will be tempted to be compatible with a competing one, and ever in the cases they could be then each one would implement different UI designs, concepts, patterns etc so they won't match as it happens assets from different game studios.
Crudely speaking, something like this could allow components built for React to easily be used in Angular apps. Where's the harm in that? Any existing framework can adopt the standard, and new frameworks can be built upon it. A new one pops up every day, and honestly, I'd love the ability to use some of the thousands of React components from the shiny new framework I'm trying out. I don't get all the fuss.
Sort of related - it drives me up the wall when css frameworks change low level component class names. Bootstrap did it going from versions 2 to 3 and Foundation did it going from 5 to 6. Existing sites are either left to bit rot or or have to be given attention that would have better been spent elsewhere.
This site screams at me don’t reinvent the wheel. The premise is that frameworks aren’t enough and developers are wasting time working too hard on things they already know.
When I hear things like this it begs the question: Exactly how easy do you need it to be? Should UI developers not be required any greater effort than copy/paste?
The reality is that most of the components the site proposes are already copy paste if you aren’t locked into a giant framework like React. Like some other comments have said there already is a common platform for building reusable UI components: web standards. The world surely doesn’t need a framework for riding on top of your framework.
As far as I can tell, this is a collaboration between Microsoft Edge and the W3C for deciding what reusable UI components should be put in web standards, and what they should be named.
So it's already exactly what you want. What are you complaining about?
It’s an unnecessary artificial solution to a non-problem. If you need a reusable drop down you are fortunate because it already exists with full accessibility: the HTML select element. But but but it looks boring... CSS. But but but form elements are impossible to style and modify their behavior... probably because you are breaking accessibility for vanity.
My complaint is that this idea is an unnecessary work around to sole something that isn’t a real problem to supplement your unnecessary work around (your giant framework). I have reinvented this wheel enough to know that people frequently want nonstandard things for nonstandard reasons because vanity is more important than everything else, accessibility is an add on to worry about later, and they are hopeless without the world’s largest framework to do their jobs for them.
I already have to be saddened with framework nonsense spaghetti code by incompetent developers at work. The idea of taking mental laziness and bad ideas to another level for some senior surrogate dev to parent is horrific.
This looks interesting to me because I have dreamed of a mobile-first operating system where every app is using predefined UI components. Where every action is just an API call away (both web and non-web API) from a req/res. We could ship tiny apps (instead of multi-MBs), I think apps like twitter, instagram, etc that are mostly just interacting with a "feed" could literally become KBs worth of JSON/YML code...
Sure this would kill creativity but also make the web more accessible...sometimes it's a good tradeoff
This was Windows Phone. It was pretty great. Unfortunately we won't find out what would happen if it was a major OS (primarily: would the heavy constraints work well?).
Yeah, I used a windows phone for 18 months. There were some fantastic ideas in there and when it worked well it felt like the right way to do things BUT: in practice It was a mixed bag, where the back button would take you at any given moment was a mystery (last app? Last state within current app? Something in between?) and other components also had the feeling of being overloaded in terms of possible meanings. I get the impression that they lacked clear guidelines around usage, not an issue when components look different but when everything has the stamp of official OS look and feel divergent behaviour undermines trust in the whole system.
It would be neat for AB testing if you could make a one line code change and get a whole new style.
This project could just make a positioning component that's a parent to it's different child components and then also way to catch and translate all it's events to it's consumers.
It wouldn't be so bad if you just had to write a thin shim layer to do this for each new component framework you tried out.
Okay, but what does this project add that the current HTML5 components can't offer? Is the goal of the project to standardize the style? Or is the project's goal to get HTML5 UI elements extended to support more features? The website isn't very clear on that and doesn't mention already existing HTML5 UI components.
Design languages standardize control naming and structure, but while there is some borrowing between design languages, there is always going to be variation between them.
If someone failed, its an opportunity to learn from their mistakes.
Feel free to share what windows tried and what failed. It will help out other readers.
It's a nice thought, unfortunately the human ego factor will get in the way. We live in a world where we cannot standardize on which side of a car the gas tank opening is.
Does there? I don't mean to be flippant, but it seems to me there's an enormous number of companies that use UI as their competitive advantage. What exactly do we gain by standardising user interfaces?
If common UI elements are denoted the same, it means things like screen readers, alternative navigation options, custom styling (high-contrast) can work more reliably.
Everyone implementing their own UI means such things are often secondary.
Oh, I fully agree and would love for this to work. I just felt that this xkcd was going to get posted eventually so might as well be me. From the react world, being able to transition easily from MUI to Ant or something would be beautiful.
It's so tempting to think of all the efficiency that could be gained if we'd stop replicating the same work and just all decide how to do things 'right', unfortunately though this isn't how the best results are achieved.
This is fundamentally a conversation about markets - in this case for ideas. Lots of parallel work is done in a distributed manner, much of it is wasted, but because of the competition between and combination of different ideas, you get emergent results that are really finely tuned to what people actually want in practice.
Top down planning won't get you this. You'll have less waste, to be sure, but you'll also have inferior results.