drivers/js: responsive, generic (customizable), design system?

[atdiar]

Preamble

Wondering if it wouldn't be better to have a generic and customizable responsive design system So that creating for the mobile-web can automatically translate on desktop and vice versa.

It would probably involve the consideration of:

Layout and Structure

• Grid System (Responsive): For creating flexible and responsive layouts.
• Container/Wrapper (Responsive): To limit content width and center content in the viewport.
• Sections (Responsive): To divide content into thematic groups.

Navigation

• Header/Navbar (Responsive): Typically needs to adapt for mobile screens, often with a collapsible menu (hamburger menu).
• Breadcrumb (Sometimes Responsive): To indicate the current page's location within a navigational hierarchy.
• Pagination (Responsive): To navigate a divided set of content, may need adaptation on small screens for better accessibility.
• Sidebar (Responsive): For secondary navigation, can convert to a slide-out or bottom navigation on mobile devices.
• Tabs (Responsive): For toggling between views within the same context, may require scrolling or dropdown on small screens.
• Footer (Responsive): Often requires layout adjustments for mobile.

Data Display

• Cards (Responsive): For displaying varied pieces of content; need to adjust layout and size on different screens.
• List Groups (Responsive): For displaying a series of content chunks, such as a list of links or textual content.
• Tables (Responsive): Complex tables may need to reflow, hide columns, or transform into a different layout on smaller screens.
• Accordions (Responsive): For collapsible content sections, useful for FAQs or for condensing information on mobile.
• Modals (Responsive): Overlays that display content on top of existing content; sizing and positioning need to be responsive.
• Tooltips (Sometimes Responsive): Small messages that appear on hover or click; might need adjustment or different interaction patterns on touch devices. (might want to show them on umreleased long touches)

Forms and Inputs

• Buttons (Responsive): May need size adjustments for touch targets on smaller screens.
• Form Controls (Responsive): Inputs, text areas, selects, checkboxes, and radios; sizing and spacing need to adapt to screen sizes.
• Input Groups (Responsive): For combining form controls with text or buttons.
• Toggles/Switches (Responsive): Custom UI controls that require touch-friendly sizes.
• Date/Time Pickers (Responsive): Complex components that often need a different UI on mobile.
• File Upload (Responsive): Needs clear feedback and easy interaction for mobile users.

Feedback and Notifications

• Alerts (Responsive): To convey important information or feedback; may need layout adjustments for smaller screens.
• Progress Bars (Responsive): Visual indicators of progress; need to maintain readability on all screen sizes.
• Spinners/Loaders (Responsive): Indicate loading states; sizing may be adjusted based on the device.

Media and Icons

• Image Galleries (Responsive): Collections of images that need to adapt to different screen sizes, possibly with modal or fullscreen views.
• Carousels (Responsive): Sliding components for multiple items, need swipe support and easily clickable controls on mobile.
• Icons (Responsive): Often scalable vector graphics (SVGs) that need to be clear at any size.
• Avatars (Responsive): User or entity representation, may change size based on screen real estate.

Miscellaneous

• Banners (Responsive): For announcements or promotions, needs to be attention-grabbing without disrupting the mobile experience.
• Badges (Sometimes Responsive): Small count indicators or status markers that accompany another element, like an icon or button.

Material 3 (aka Material You)

Implementing Material Design 3: Key Considerations

1. Theming and Customization

• Dynamic Color: Implement dynamic color systems adaptable to user preferences.
• Color Scheme: Support for light and dark themes with an accessible color scheme.
• Typography: Utilize recommended type scales for consistency.
• Shape: Apply shape theming for hierarchy and focus indications.

2. Responsive Layouts

• Adaptive Components: Ensure adaptability of components for various devices and screens.
• Grid System: Use a grid system for layout consistency.

3. Components

Essential components with responsive and adaptable considerations:

• App Bars: Top and bottom, with dynamic resizing.
• Buttons and FABs: With interaction feedback like ripple effects.
• Cards: Grouping related information.
• Dialogs: Modal windows for user interactions.
• Lists: Displaying related content series.
• Menus: Contextual choices related to primary content.
• Navigation Drawer: Side navigation for app content access.
• Sliders and Switches: For adjustments and settings.
• Tabs: Organizing content across different contexts.
• Text Fields: Including states like focused and error.
• Data Tables: Displaying data and actions.

4. Motion

• Responsive Motion: Natural animations and transitions.
• Touch Feedback: Clear interaction feedback, such as ripples.

5. Accessibility

• Contrast Ratios: Meeting minimum contrast ratios for readability.
• Focus Indicators: Showing keyboard focus for components.
• Semantic Markup: For web implementations, using appropriate elements and ARIA roles.

6. Performance and Optimization

• Efficient Loading: Fast component loading and rendering.
• Image and Asset Management: Optimized images and icons for resolutions and densities.

7. Development and Tooling

• Component Library: Encapsulate Material Design principles in a library.
• Design Tokens: Use tokens for easily sharable themes.
• Prototyping and Design Tools: Support for Material Design guidelines.

8. Documentation and Guidelines

• Implementation Guides: Documentation for developers on component usage.
• Design Guidelines: Document design principles and best practices.

9. Testing and Validation

• Cross-Platform Consistency: Ensure design consistency across devices and platforms.
• Usability Testing: Validate design intuitiveness and user needs fulfillment.

Guidelines Not Obvious Before Reading Material Design Documentation:

1. Elevation and Shadow: Material Design uses elevation to imply hierarchy and focus. The use of shadows and elevation levels is more systematic and nuanced than merely adding drop shadows for aesthetic purposes.

2. Motion Provides Meaning: Animations and transitions aren't just for visual flair in Material Design; they are used to indicate relationships between elements, action outcomes, and spatial organization, guiding user attention in a meaningful way.

3. Adaptive Icons: Beyond the shape and size, adaptive icons in Material Design can dynamically change their appearance based on system settings or to better fit alongside other UI elements, enhancing visual harmony.

4. User-Generated Theming: Material Design 3, especially with Material You, emphasizes themes that adapt not just to device characteristics but also to user preferences, such as wallpaper colors, creating a personalized experience.

5. Component States: The detailed specification for how components should behave in different states (hover, focused, pressed, disabled) ensures a consistent and predictable user experience but might be more comprehensive than initially expected.

6. Layout Grids: The role of grids in Material Design extends beyond basic alignment; they establish consistent spacing and keylines, which are crucial for maintaining a harmonious layout across different screen sizes and orientations.

7. Dark Theme Considerations: Implementing a dark theme is not merely about inverting colors; Material Design provides specific guidance on color usage, elevation treatments, and component coloring to ensure readability and reduce eye strain in low-light conditions.

Understanding these nuanced guidelines can significantly enhance the usability and aesthetic of your applications, aligning them with Material Design principles for a cohesive and user-friendly experience.

(via chatgpt)

[atdiar]

Still wondering. TailwindCSS doesn't seem much different from applying CSS properties one by one which we can already do in a much more composable way in Go via the CSS Stylesheet API. In that case, reusable styles would simply be functions applied to ui elements.

Material is a no go as it requires preprocessing. Could use materialize although it might be a bit dated.

Would be perhaps relevant to build upon an implementation of classless CSS. Will require to create a component library. Once done for one platform, perhaps find ways to automatically translate layouts, etc. to other platform, turning everything into something 'responsive'.

[atdiar]

https://chat.openai.com/share/6f90d95e-b154-45ba-99f5-1107bf71de61

When/For What Element Do They Use em, rem, px, etc.?

The choice between em, rem, px, and other units in CSS depends on design goals, accessibility considerations, and specific behavior desired for various elements. Here’s a general guideline on when and for what elements each unit is commonly used:

px - Pixels

• Usage: Pixels are fixed-size units most useful for when you need precise control over the size of elements on the screen. They do not scale with user settings such as browser text size adjustments.
• Common Elements:
  • Borders, shadows, and spacing (margin, padding) where precise measurements are important and scaling with text size is not necessary.
  • Width and height for small, non-text elements that need to stay the same size, like icons.

em - Relative to the Font Size of the Element

• Usage: em is relative to the font size of its nearest parent. This makes em units ideal for scalable, typographic designs where elements need to scale in relation to the text size of their parent element.
• Common Elements:
  • Typographic elements (e.g., headings, lists, paragraph margins, and paddings) where scaling relative to the parent's font size maintains the visual hierarchy and proportional spacing.
  • Sizing that needs to scale with the text size, such as responsive text containers or buttons within a specific section that should scale according to the section's font size.

rem - Relative to the Font Size of the Root Element

• Usage: rem units are based on the font size of the root element (html). They are used to provide consistent scaling across the document, making them useful for building consistent, accessible interfaces.
• Common Elements:
  • Base font sizes for the document or components that should remain consistent regardless of parent size.
  • Spacing (margin and padding), border widths, and element sizes that need to be consistent across different sections of a page.
  • Layout dimensions for containers and sections to ensure consistent scaling.

% - Percentage

• Usage: Percentage units are relative to the same property of the parent element or another relative measurement, making them ideal for fluid layouts and responsive designs.
• Common Elements:
  • Width and height for fluid layouts where elements need to adjust to the size of their container or viewport.
  • Spacing for responsive designs that need to adapt to various screen sizes.

Viewport Units: vw, vh, vmin, vmax

• Usage: Viewport units are relative to the size of the viewport and are useful for creating layouts that respond to the size of the browser window.
• Common Elements:
  • Sections or elements that should take up a certain percentage of the viewport, such as full-screen sections or sticky headers.
  • Typography and elements that need to scale dynamically with the viewport size for visually impactful designs.

Choosing the right unit often involves balancing design consistency, accessibility needs, and the dynamic nature of web content across different devices and user settings.

[atdiar]

Breakpoint Strategy in Responsive Design

Breakpoint strategy in responsive design is crucial for adapting layouts to various screen sizes, ensuring both usability and accessibility. Here's a comprehensive strategy for utilizing breakpoints:

1. Defining Breakpoints Based on Content

• Instead of adhering strictly to device dimensions, define breakpoints where your content naturally demands a layout change.

2. Adjusting Layout and Grid

• As screen size changes, adjust the number of columns in your grid to ensure content remains legible and accessible.

3. Typography and Readability

• Increase or decrease font sizes at certain breakpoints to ensure text remains legible across devices.

4. Navigational Elements

• Navigation menus might need to change form between desktop and mobile views to save space and maintain usability.

5. Images and Media

• Use different image sizes for different breakpoints to ensure fast loading times and avoid layout shifts.

6. Testing and Iteration

• Regularly test your design on actual devices and through emulators to identify any usability issues.

Implementation Example

/* Base styles */
body {
  font-size: 16px;
}

.container {
  max-width: 1200px;
  margin: auto;
}

nav ul {
  display: flex;
}

/* Breakpoint for tablets */
@media (max-width: 768px) {
  body {
    font-size: 14px;
  }

  .container {
    max-width: 600px;
  }

  nav ul {
    display: block;
  }
}

/* Breakpoint for mobile */
@media (max-width: 480px) {
  body {
    font-size: 12

[atdiar]

As usual, we are going to reconsider everything from first principles in order to find out what the best course of action should be.

What is "responsive" in responsive design?

After having thouhgt a little about it, turns out that responsive design is synonymous with reactive style properties of the elements of a UI tree, where the reaction is triggered by a change in the viewport dimensions or the user-agent (interaction capabilities change depending on whether we are on mobile web or desktop web for instance). Could even be triggered by a viewport orientation change (on mobile for instance).

responsive design is synonymous with *reactive style properties

Given how the framework allows to have namespaced stylesheets, we can simply activate the relevant stylesheet that corresponds to a given breakpoint.

Example: a reactive grid

A grid is characterized by a number of columns and a number of rows. For a reactive grid, these numbers are functions of the viewport dimensions that are recomputed when the size of the viewport changes.

user-agent: mobile web vs desktop web

Some elements that might be fitting for a desktop environment might not be adequate for a mobile environment and vice versa. In which case, we need to be able to swap them depending on the user-agent.

Implementation

func On(uiprop string, condval Value, children  ....*Element) func(*Element) *Element{
    return func(e *Element) *Element {
        e.Watch("ui", uiprop, e, NewMutationHandler(func(evt MutationEvent)bool{
            evt.Origin().SetChildren(children....)
            return false
        }).RunASAP())
        return e
    }
}

We can implement a wrapper round the above that will watch a property that holds a value describing the type of responsive environment the document is in (for instance, could be ("ui", "display") ( and include the user-agent and/or information such as mobile, desktop, smalldisplay, medium display, large display, length, width, ...)

// Switch is an *Element modifier that applies to an element and allows to conditionally set its children
// based on the value of a property:
// 
//  Switch("ui","display").
//      Case(String("small"), A).
//      Case(String("large"), B).
//      Case(String("medium"), C).
//  Default(nil),
//
// In the above example, the children of the element will be set to A if the value of the property "display" is "small",
// to B if it is "large", to C if it is "medium" and to nothing if it is anything else.
// The Default method is used to set the children of the element when the property value does not match any of the cases.

// Example of a reactive datepicker Element implemented using the Switch modifier:

var smallDatepicker *Element // Reference to the small datepicker element, here just to provide a more realistic example

    E(document.Div.WithID("uuid-datepicker"),
        Switch("ui","display").
            Case(String("small"), DatePickerSmall("uuid-dp-s", Ref(&smallDatepicker))).
            Case(String("large"), DatePickerLarge("uuid-dp-xl"))).
            Case(String("medium"), DatePickerMedium("uuid-dp-m")).
            WithSharedData("date").
        Default(nil),
    )

/*
    Important to note that the the value of "ui,display" is observed on the parent div of id "uuid-datepicker".
    This is potentially the same value that is being set by the EnableResponsiveUI constructor option, i.e. the value
    for the document "ui" property "display"
    That should allow for the tree to be reactive to display changes.

*/

TODO

• [ ] grid attributes should depend on the ui.Display value (number of columns and rows) to be considered responsive
• [ ] touch events should be set for different user-agent (mobile)
• [ ] tooltips should be displayed on long sustained touch events
• [ ] implement stylesheet reset, classless css as a base, and then add the rest of the design system (components, display breakpoints,...)
• [ ] WYSIWYG editor for quick design system creation (theming, layouting, design)

[atdiar]

Re. Touch event handling https://chatgpt.com/share/b9669aaf-7857-4a83-9e4a-24237c1b4b95