[HN Gopher] Open UI
___________________________________________________________________
Open UI
Author : twapi
Score : 87 points
Date : 2020-03-30 20:21 UTC (2 hours ago)
(HTM) web link (open-ui.org)
(TXT) w3m dump (open-ui.org)
| c-smile wrote:
| Am I the only one who think that <switch> https://open-
| ui.org/components/switch is a usability disaster?
|
| 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?
| hanniabu wrote:
| 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.
| dragonwriter wrote:
| > 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.
| superhuzza wrote:
| 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.
|
| https://www.nngroup.com/articles/toggle-switch-guidelines/
| saagarjha wrote:
| 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).
| pvg wrote:
| _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.
| saagarjha wrote:
| 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...)
| pvg wrote:
| 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
| checkmarks.
| aliveupstairs wrote:
| 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.
| sdfhbdf wrote:
| This website has really messed up mobile view (Safari on iPhone)
| for a UI project.
| ricardobeat wrote:
| 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.
| memco wrote:
| 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?
| chiefofgxbxl wrote:
| > 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"
| maxcan wrote:
| Ok, I'll post the obligatory XKCD reference https://xkcd.com/927/
| jimhefferon wrote:
| Fair enough, but there _does_ need to be a standard, or at
| least a convention.
| maxcan wrote:
| 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.
| interactivecode wrote:
| 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?
| PaulDavisThe1st wrote:
| 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.
| nexuist wrote:
| > 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.
| [deleted]
| stevenpetryk wrote:
| Not seeing much in the way of accessibility here.
| grizzles wrote:
| 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.
| davnicwil wrote:
| > 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.
| brundolf wrote:
| 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.
| davnicwil wrote:
| 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.
| akiselev wrote:
| 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.
| goblin89 wrote:
| I wonder whether UI component patterns have, in fact, stabilized,
| and whether an attempt to standardize them could result in
| stagnation.
| brundolf wrote:
| 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.
| spankalee wrote:
| > 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 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.
| shadowgovt wrote:
| 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).
| bmn__ wrote:
| 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
| kitsunesoba wrote:
| 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.
___________________________________________________________________
(page generated 2020-03-30 23:00 UTC)