docs: Enhance documentation with design patterns and features from other competitors

Author: manudev0004

docs/DaisyUI (with Tailwind CSS).md

@@ -34,16 +34,45 @@ It also provides excellent styling for form controls, which is super helpful.
 
 DaisyUI, especially when paired with Tailwind CSS, is an **excellent choice** and highly reusable for this UI-WoT project. Here's why:
 
-*   **Foundational UI Building Blocks:** It gives a full set of all basic UI components that can be directly mapped to the fundamental data types and interaction patterns found in Thing Descriptions. For example, we can use DaisyUI's toggle for booleans, range for numbers, select for enums, and input for strings.
-*   **Rapid Development:** Pre-styled components and Tailwind's utility-first approach help to build UI quickly, allowing us to focus more on the core logic of TD parsing and dynamic generation.
-*   **Customization and Theming:** DaisyUI comes with some default settings, but almost everything about it can be changed with Tailwind. Thus anyone can easily change the look and feel of the dashboard to match any style.
-*   **Clean and Minimal:** It encourages a clean and modern aesthetic, which is great for a functional minimal yet catchy dashboard.
+- **Foundational UI Building Blocks:** It gives a full set of all basic UI components that can be directly mapped to the fundamental data types and interaction patterns found in Thing Descriptions. For example, we can use DaisyUI's toggle for booleans, range for numbers, select for enums, and input for strings.
+- **Rapid Development:** Pre-styled components and Tailwind's utility-first approach help to build UI quickly, allowing us to focus more on the core logic of TD parsing and dynamic generation.
+- **Customization and Theming:** DaisyUI comes with some default settings, but almost everything about it can be changed with Tailwind. Thus anyone can easily change the look and feel of the dashboard to match any style.
+- **Clean and Minimal:** It encourages a clean and modern aesthetic, which is great for a functional minimal yet catchy dashboard.
 
 ## Identified Gaps (and Our Opportunity!)
 
 When seen as a styling framework and a component library it is perfect. But for UI-WoT, DaisyUI does lack in dynamic UI generation from TDs. These are not the limitations of DaisyUI but places where UI-WoT has to extend from it, so currently it lacks:
 
-*   **No Schema-Based UI Generation:** DaisyUI doesn't automatically interpret a JSON Schema to generate a form or best component. DataSchema to the appropriate DaisyUI component.
-*   **No Semantic Enrichment:**  It does not understand that a boolean property with `@type` `saref:LightSwitch` should be rendered as a lightbulb icon toggle.
-*   **No Dynamic Layout Management:** DaisyUI provides components, but not a system for drag-and-drop layouts or persistence. 
+- **No Schema-Based UI Generation:** DaisyUI doesn't automatically interpret a JSON Schema to generate a form or best component. DataSchema to the appropriate DaisyUI component.
+- **No Semantic Enrichment:** It does not understand that a boolean property with `@type` `saref:LightSwitch` should be rendered as a lightbulb icon toggle.
+- **No Dynamic Layout Management:** DaisyUI provides components, but not a system for drag-and-drop layouts or persistence.
 
+## Design Patterns and Features that can be considered for UI-WoT
+
+Since UI-WoT aims to become a more advanced competitor, we can analyze and adopt some of the existing features to strengthen our own system. Below are the features we should consider to add or enhance in our UI-WoT project:
+
+- **Fixed Size Scaling:**
+  Looking through DaisyUI's examples it uses consistent sizing tokens (xs, sm, md, lg, xl) across buttons, inputs, and cards. This creates a clear visual hierarchy in dashboards.
+  We should apply this same scaling system to affordance cards in UI-WoT. Small cards would be perfect for simple boolean properties like switches, medium cards for standard properties with single values, and larger cards for complex objects or actions that require multiple input parameters.
+- **Interactive State Feedback:**
+  DaisyUI's interactive components, especially buttons, support multiple visual states: normal, hover, active, disabled, loading. Each state has distinct visual feedback that communicates what's happening to the user.
+  For UI-WoT, we need to extend this pattern and have clear visual feedback for execution, value changing and connection loss. These additional states are crucial for WoT because network interactions can be slow or fail, and users need to understand what's happening with their devices.
+
+- **Cards as a Core:**
+  DaisyUI's Card component is versatile and well-designed, making it an ideal foundation for our affordance representation. We should standardize on using Cards as the primary container for properties, actions, and events.
+  Each affordance card should include consistent elements: a title (from the TD affordance name), a description (from the TD description field), an icon (mapped from semantic annotations), and affordance badges that surface important metadata. This consistent card structure would make dashboards intuitive and scannable, regardless of how many different Things are displayed.
+
+- **Accessibility and Keyboard Support:**
+  DaisyUI builds on Tailwind's excellent accessibility features, including focus-visible utilities and proper ARIA attributes. Their components are keyboard-operable by default, which is essential for inclusive design.
+  We must leverage these accessible patterns throughout UI-WoT. All interactive elements like toggles, sliders, and others should be fully keyboard operable with visible focus rings. We can tie ARIA labels directly to TD titles and descriptions so that screen readers can announce meaningful information about each affordance.
+
+- **State Styling System:**
+  DaisyUI has a pattern of using state classes for different component states (disabled, loading, error, success). These classes apply consistent visual styling across the entire component library.
+  We can adopt and extend this pattern for WoT-specific states like offline, readonly, observable, secure. By applying a consistent visual language (e.g., greyed-out for readonly, pulsing for observable), users will immediately understand the nature of each affordance.
+
+- **Animation and Interactions:**
+  DaisyUI includes various transitions and hover states that make interfaces smooth and responsive. These micro-interactions provide important feedback without being distracting.
+  For UI-WoT, we should leverage these existing animations like a “pulse” or spinner while an action is executing. Connection loss warnings with fade-in/out alerts etc.
+
+- **Icons:**
+  While DaisyUI doesn't prescribe a specific icon library, their design language works well with popular icon sets like Heroicons, Lucide, or FontAwesome. Icons improve readability and quick recognition of widgets. For UI-WoT, we need a similar icon mapping strategy. For example, a temperature sensor could automatically get a thermometer icon, a light bulb gets a lamp icon, if not clear then there may be icons based on the type of TD.

docs/Home Assistant Dashboards.md

@@ -37,7 +37,7 @@ These components are interactive and provide immediate feedback to the user.
 
 Home Assistant's UI strategy is very relevant and reusable for UI-WoT project because of too much similiarity. Here's why:
 
-- **Card-Based Structure:** The concept of representing each device entities as a distinct, self-contained card aligns perfectly with UI-WoT aims.  In a similar way UI-WoT should generate each property, action, or event from a TD as its own interactive card in the dashboard.
+- **Card-Based Structure:** The concept of representing each device entities as a distinct, self-contained card aligns perfectly with UI-WoT aims. In a similar way UI-WoT should generate each property, action, or event from a TD as its own interactive card in the dashboard.
 - **Entity-Centric Design:** Home Assistant's focus on entities (which are analogous to TD affordances) gives a great idea of how to organize UI components and how they turn specific device details into generic but useful UI elements.
 - **Dynamic Data Binding:** Their approach to binding UI elements to real-time data is exactly what is needed for the live interaction with WoT devices in UI-WoT.
 - **Customization:** Home Assistant gives so much to customize their dashboards, which is the core feature to replicate with UI-WOT drag-and-drop layout. Their success in user-customizable UIs is a good benchmark.
@@ -48,4 +48,43 @@ While Home Assistant is fantastic, there are areas where it lacks, like:
 
 - **Limited Schema-Based Adaptation:** Most of Home Assistant's cards are made for certain types of entities. While they are customizable and users can configure them, they still can't inherently generate their UI based on a generic JSON Schema (like DataSchema in TDs) in the way UI-WoT aim to.
 - **Semantic Enrichment Beyond Hardcoding:** Home Assistant uses semantic information (e.g., a light entity gets a light card), this is based on predefined integrations. UI-WoT aims for a more generalized semantic interpretation from the TD using `@type` annotations to suggest richer UI components without needing specific integrations.
-- **No Direct TD-to-UI Mapping:** Home Assistant does not support direct TD parsing, reading, or writing. It requires manual integrations and customizition.
+- **No Direct TD-to-UI Mapping:** Home Assistant does not support direct TD parsing, reading, or writing. It requires manual integrations and customizition.
+
+## Design Patterns and Features that can be considered for UI-WoT
+
+Since UI-WoT aims to become a more advanced competitor, we can analyze and adopt some of the existing features to strengthen our own system. Below are the features we should consider to add or enhance in our UI-WoT project:
+
+- **Entity-Card Model**
+  Home Assistant treats every device capability as an "entity" with standard attributes (state, attributes, and last_changed timestamp). This creates a unified model where everything follows the same interaction pattern, regardless of the underlying device complexity.
+  For UI-WoT, we should adopt this approach by treating each affordance (property, action, or event) as an entity-like abstraction. Each affordance card should display: the current value or state, last updated timestamp and semantic type (derived from @type annotations).
+- Card Specialization\*\*
+  While Home Assistant has generic entity cards that work for any entity type, they also provide specialized cards for common domains. A light card includes a color picker and brightness slider. A thermostat card has heating/cooling mode selectors and temperature set points. These specialized cards provide much better user experience than generic ones for common use cases.
+  We can provide a similar hierarchy in UI-WoT. Start with generic affordance cards that work for any property, action, or event. Then create specialized cards for common WoT patterns. For example, a coffee machine might have a specialized card template that shows bean levels, water levels, and brewing controls in an intuitive layout, rather than just showing three separate generic properties.
+
+- **Layout Flexibility**
+  Home Assistant supports multiple view types including Masonry (automatic card flow), Sections (organized groups), and Panel (full-width single card). Despite this layout flexibility, all cards maintain consistent interaction patterns. You can move a light card between different view types and it still works the same way.
+  Our layout system should follow this principle. Allow users to choose different layouts with drag-and-drop flexibility, while keeping affordance interactions standardized.
+
+- **Template and Sharing**
+  Home Assistant allows users to export their dashboard configurations as YAML files and import configurations from others. This has created a vibrant community where people share dashboard templates for common scenarios and device combinations.
+  UI-WoT can export dashboard configurations (including card layouts, customizations, and connections) in a standard format either JSON or YAML.
+
+- **Conditional Rendering**
+  Home Assistant provides Conditional cards that show or hide based on entity states or other conditions. You can create a card that only appears when motion is detected, or when temperature exceeds a threshold.
+  UI-WoT should implement similar conditional rendering. Show an error card only when a Thing goes offline. Display a notification card when a sensor value exceeds limits. This makes dashboards more dynamic and focused on what's currently relevant.
+
+- **History and Visualization**
+  Home Assistant includes history graphs, gauges, and statistic cards that visualize data over time. They show quick historical sparklines on individual cards for numeric properties, and provide detailed history views when needed.
+  We should borrow these visualization patterns for WoT. Not every affordance needs full history, but for those that do, it adds tremendous value.
+
+- **Dashboard Editing**
+  In view mode, you interact with devices normally. Click the edit button (three dots), and you enter edit mode where you can add, remove, rearrange, and configure cards. This clear separation between viewing and editing prevents accidental changes while making editing accessible.
+  UI-WoT should implement the same pattern. View mode is for normal interaction with WoT devices. Edit mode enables layout changes, card customization, and dashboard configuration. This will make dashboard management much more robust and user-friendly.
+
+- **Badge and Status Indicators**
+  Home Assistant uses a badge system to show important status information consistently. Badges appear in the top-right corner of cards with semantic colors: blue for updates available, red for low battery, yellow for warnings. Hovering over badges reveals detailed tooltips.
+  We can adopt adopt badges for affordances (e.g., observable, readonly, secure) with semantic color codes and tooltips
+
+- **Notification and Alert Management**
+  Home Assistant has a persistent notification system that categorizes messages by severity (info, warning, error), allows dismissal and grouping, and provides action buttons for quick resolution. Notifications appear in a dedicated panel rather than cluttering the main dashboard.
+  UI-WoT systems need robust notification handling because devices can have errors, lose connectivity, or require attention. Categorize notifications by severity, allow users to dismiss or snooze them.