Thursday, April 15, 2021

Semantic Theming - indexed palette

There are many articles on palette categorizations online, I would skip to semantic relation of palettes to UX elements. 

Usually palette is selected from basic branded colors base. Usually 2 or 3 is sufficient, perhaps it relates to the heraldic symbols and colors. Remaining colors are chosen with keeping the base ones and emotional palette in mind. 

There is a catch on selection enterprise and government designs are facing: color set should be "accessible" for various cohorts of people: color blind, light sensitive, etc. Adobe has given a nice tool to help with accessible palette creation. In regards to color "accessible" means that close colors should be distinctive enough even for people with color challenges or in applicable conditions of low/bright light.

The palettes would have various colors but some of them have to be in straight color transition like bright to dim. Why you would need a color sequence? The answer resides in various states UX component are presented during interaction with UI. Those states are used in sequence: normal follows hovered, which followed "active"(pressed) , the disables should be least noticeable and resides in the end of color sequence. See Buttons and Actions states


How many color sequences you would need? It depends on how many color variations your application supports: light, dark, high contrast for each, grayscale for ePaper devices, etc. Another factor is munber of variations for UX components. As in Buttons and Actions there are 5 variations proposed, will be more for other types of UX components. Each need to have own entry in one of indexed palettes. 

While same palette could be reused for different UX components variations, it is better to choose a significantly distinctive different entry point in palette for inside of same color theme variation. 

For UX components single palette is not sufficient. The indexed palettes usually come in more than one color per row. You would need to make colors as for background as foreground/text, for outline, and for other sub-elements. For action it would be 3 colors: background, text, outline/border. The 4rth is assumed to come from theme variation background which is a basis for selecting proper entry within indexed palette. In this sample you could see the need to alter the text color due to background change:



Now to the meat of subject. The indexed palette become semantic when one of its entries is associated with one of semantic UX element variation. 




Semantic theming - buttons and actions states

 While W3C button attributes and CSS has given straight forward combination of possible appearance of actions/buttons, not all have a "semantic" meaning for the user. There is a proposal for state sequence in colors escalation order ( see indexed palette article ).

NORMAL  (default)

FOCUSED  :focus css selector

SELECTED attribute on some elements like OPTION 

HOVER  :hover

ACTIVE :active

DISABLED attribute, not available on A element

Not all states would affect background and not on all action variations: focused is usually leaves the current appearance with outline, in ghost variation the background by default would be transparent still for accessibility reasons keeping palette changes for other states.





Sunday, March 7, 2021

CDN deployment for JS modules - missing pieces

There are multiple CDNs which support mirroring the NPM and GitHub sourced modules. They support the semantic versioning of your modules and a bit of additional services for modules owner. The services for web developers at the moment are quite limited and need to be extended in order to support modern web application development and delivery stack. 

From security point we need assurance of content genuity  which is supported by resource integrity attribute , sufficient to replicate the binary build log, cross-reference to versioned source location. 

The security scan reports from one or several vendors is essential for keeping the publicly reused code safe. Publishing security scan reports along with binaries would enable transparent review across all modules used in the page without exceptions making 100% coverage as for own content as for dependencies from 3rd parties.

Test coverage is a significant criteria  of application reliability. In the world of Web 3.0 where apps from different vendors are met on same browser page the page owner does not have any assurance on quality of service overall unless able to review test coverage for all including 3rd party code. By deploying versioned binaries on CDN along with complimentary test coverage report the web application owner and consumer will acquire ability to check and if not satisfied to eliminate/substitute unreliable versions. 

Licensing transparency.  While legal reuse and re-distribution questions are  boring and complex, publishing the licensing info along with published on CDN binaries would give ability to check whole dependencies tree on subject of (in-) compatible licensing of whole dependencies tree. That would be important for applications vendors, corporate consumers and final users who do not want to support pirating.

Developers support. When dealing with binaries it is difficult to troubleshoot the internals of published in CDN module. The source map could be published on CDN next to binaries to help the development community and clients who are willing to troubleshoot themselves.  The original source version is also a subject to be mirrored on CDN.

Build stack with target of CDN publishing would eliminate the need for keeping dependencies in bundles making the build lighting fast as dependencies and own code which already published on CDN does not need to be recompiled/verified/published.

My goal is to support above features and make given stack available for applications developers.

Cross-posted on Patreon

Thursday, January 21, 2021

Data layer development via ORM and API Gateway

Not sure what pushed me to this direction but search "DB with graphql" lead to https://www.prisma.io/ - a tool for auto-generation GraphQL endpoints for DB schemas without programming. Open Surce, Apache 2 licence, MySQL/PostgreSQL capable.

Prisma is a next-generation ORM that can be used to build GraphQL servers, REST APIs, microservices & more. (222 kB)

For me DB-first approach is essential . The schema change is reflected in code just by re-generating code by CLI, no coding involved. Of course the discipline of migration for DB schema itself is still in place.


And last peace of back-end puzzle: ORM integration with API gateway( will serve security, authentication, licensing, analytics ) : Prisma + Apollo https://www.howtographql.com/graphql-js/5-connecting-s
erver-and-database/

The generated classes out of DB schema could(and should) be reused as on back-end as in front-end code via versioned (npm?) package.