Open UI
open-ui.org
open-ui.org
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.
Think aria attributes, window.requestAnimationFrame, source maps, and the JS debugger statement - not UI frameworks or new standard HTML elements.
This is framework nonsense. Rendering isn’t related to the DOM.
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."
A single unifying framework can never dominate, because everyone wants a unique looking website
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.
It's not a great thing.
Really? That would be really terrible wouldn't it? Did you imagine that world? (Maybe I misunderstand you.)
Which currently existing website would you most want all websites to look and function like, if you had to choose?
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.
[1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_(abando...
People dislike having to make efforts.
Don't understand what I ask - look here http://greglturnquist.com/2016/05/03/rest-soap-corba-e-got/
How apropos. A behind-the-times punishment for being so behind-the-times? [1]
[1] https://en.wikipedia.org/wiki/Washing_out_the_mouth_with_soa...
For me, I've been a pretty big proponent of Material Design, and in particular the material-ui component library implementation.
In the end, nobody is going to fall into a "standard" set of components, if for nothing else, because designers want variance and customization.
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.
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.
Remember: most big coorp (think Walmart) are actually centrally-planned mini state and yet, their profitability is excellent compared to smaller actors.
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.
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.
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.
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.
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 current best proposal in this area is Template Instantiation: https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
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.
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.
They already created that a long time ago and nobody used it.
https://en.m.wikipedia.org/wiki/XForms
Before anybody starts crying about it being XML please remember that SVG is XML. Everybody loves SVG and it integrates into HTML just fine.
I really don’t see the practical difference between your idea and the idea proposed by this site.
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.
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?
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.
A select is a select using a native widget
An input is a standard OS input widget
And so on
It also looks and feels better.
That boils down to which technologies you are familiar with.
> It also looks and feels better.
And this is highly subjective too. Of course looks are very independent from system to system but the feels depend on the tech stack quite a bit.
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.
> To many developers, what the software does is several orders of magnitude more important than how it looks.
Native widgets are still the easier way to produce an UI that looks good enough to work with
This link[1] explains how they work on different OS, if they work for desktop apps, why shouldn't they work for web based ones?
[1] https://developer.mozilla.org/en-US/docs/Learn/Forms/Basic_n...
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!
we figured out how chairs work, everyone should use the same chair.
Want to spend years working on something that looks exactly like everything else?
Ultimately there are different frameworks precisely because different people have a different idea about how a UI framework should behave.
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?
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.
Switches(toggles) on the other hand, imply immediate effects. Like a light switch, we expect the change to occur immediately.
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.
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.)
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.
Open up `designer-qt5`
It's an open project. Feel free to provide a fix.
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.
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"
I’m like, oh please tell me how to build a UI for the web...
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.
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 issue seems to be that the way they work, and the way to work with them, differs from toolkit to toolkit.
I.e. just like ye olde SQL forms tools and ye not so olde desktop-native toolkits.
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?
My best guess is that Open UI is laying the groundwork for built-in standardized web components like std-switch https://github.com/tkent-google/std-switch and std-toast. https://github.com/jackbsteinberg/std-toast
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."
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
https://wiki.python.org/moin/AnyGui
> 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.
I'm actually in favor of the general idea. And these folks seem like they might know a thing or two: https://www.w3.org/community/wicg/participants
I would be way more impressed though if there was a nice "related work" section.
Good luck with the project.
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.
So it's already exactly what you want. What are you complaining about?
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 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.
The day it results in stagnation is where we will find the true pattern. Patience.
Windows tried, and failed (unfortunately).
"We need one universal standard that covers everyone's use cases!"
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.