717 Add a recommended set of user channels to the Standard #727
Conversation
kriswest
added
enhancement
kriswest
requested review from
mattjamieson,
nkolba,
rikoe,
mistryvinay,
donbasuno,
hughtroeger,
ggeorgievx and
a team
✅ Deploy Preview for lambent-kulfi-cf51a7 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
There was a problem hiding this comment.
Not sure what a recommended set of user channels will achieve. A "SHOULD" won't guarantee consistent experience for end users and a "MUST" would be a non-starter. Also, while this is a brave stab at coming up with a standard set of channels (and I appreciate the move away from colors only), the proposal tempts a synethesiac rabbit hole of which color should be associated with what letter. I'd be in favor of tabling this and taking up again in the context of the desktop bridging discussion. A more flexible mechanism that allowed for a federated approach across bridges would make more sense and provide end users with much greater consistency and determinism.
|
You can find minutes for the 3 previous occasions that this has been discussed in the Desktop Agent bridging group meetings (added as references on the issue) at:
We did discuss other mechanisms for doing this. Providing a mapping system in the bridge was not a popular solution as its very hard to expose to the user what the mappings are. Likewise mapping on each end (which might prove inconsistent and more complex to administer). It will always result in a poor UX where messages on a channel with one name/appearance pop out on one with different details.
True, but it will at least encourage one - which no other solution proposed actually does (mapping channels to each other doesn't do that). If a MUST is a non-starter, then this appears to be the best option on the table currently.
For colourblind users, a purely colour-based channel set is not usable - I would assume that's why I hope the community is mature enough to avoid getting bogged down in a 'synethesiac rabbit hole' and to forgo accessibility for the sake of debate. To help with that, it was requested by a participant in one of the discussions that we are vague on the exact hue of each colour so teams can select their ideal red for example (hence named colours rather than hex - although in CSS those do imply a specific hex, here they are more of a guide) - however we did acknowledge that colours do need to be tied to the channel names/glyphs for consistency for sighted users. Finally, the group discussed it being advantageous to introduce this in a major version and as soon as possible. The later we do it, the harder it will be to migrate to/agree on... |
|
P.S. I just took a stab at the colours / glyphs and used the set of 6 in electron-fdc3 for inspiration (I think the colours there go through a similar progression of the hue) but expanded to 8. Happy to adjust/have it adjusted via review! Really not sure whether letters on numbers make better Glyphs, but do think channel names should match them (for sanities sake). |
There was a problem hiding this comment.
I actually think this is a reasonable mapping of colors and letters, since the colors are ordered by decreasing wavelength (visible spectrum red to purple/violet). Of course brown is an outlier, I'd almost rather use black or white or just cap it at 7 and leave additional ones up to the desktop agent implementation.
|
Another thought, maybe Arabic numerals are more internationally recognized than Latin alphabet characters? |
|
Both good points @greyseer256, I've switched to Arabic numerals and tweaked the back half of the range to: cyan, blue, magenta, purple (in the correct order in the spectrum I think), which (to my eyes at least) is easier to differentiate than before. Heres a preview: preview code |
|
As mentioned on #717 I think we must add some form of "fdc3" part to the id to ensure there's no mismatch with any existing or other channels. I think we had comments about namespacing before so not sure if |
I'm not sure the namespacing discussion was related to channel names specifically - but I suggested this (with periods) for the sake of consistency with context types and intent names. However, I don't think it matters a whole lot - we can even have spaces (e.g. "fdc3 user channel 1"). I'll update the PR with the version with periods - but give me a shout if there's a strong argument for underscores or something else. |
|
@openfin-johans you can see the revised list of channels here: |
resolves #717
Adds a set of recommended channel definitions to the API to encourage desktop agents to use a consistent set to aid a future Desktop Agent Bridging addition.