fix: unify theme system - fix theme switching persistence

- Unified localStorage key to 'theme-preference' across all components
- Fixed header.tsx using wrong localStorage key ('theme' instead of 'theme-preference')
- Added localStorage hybrid persistence for instant theme changes
- Removed router.refresh() which was causing stale data revert
- Replaced Blue theme with Sepia
- Consolidated auth() calls to prevent race conditions
- Updated UserSettingsData types to include all themes
This commit is contained in:
2026-01-18 22:33:41 +01:00
parent ef60dafd73
commit ddb67ba9e5
306 changed files with 59580 additions and 6063 deletions

View File

@@ -0,0 +1,508 @@
# Story 12.1: Fix Masonry Grid Drag & Drop and Responsive Layout
Status: planning
## Story
As a **user**,
I want **a responsive masonry grid where notes can be easily dragged and dropped while maintaining their sizes**,
so that **I can organize my notes efficiently on any screen size, similar to Google Keep**.
## Acceptance Criteria
1. **Given** a user is viewing notes in the masonry grid,
2. **When** the user drags a note to reorder it,
3. **Then** the system should:
- Allow smooth drag and drop of notes without losing their positions
- Maintain the exact size (small, medium, large) of each note during drag and after drop
- Provide visual feedback during drag (opacity change, placeholder)
- Save the new order to the database
- Work seamlessly on both desktop and mobile devices
4. **Given** the user is viewing notes on different screen sizes,
5. **When** the browser window is resized,
6. **Then** the system should:
- Automatically adjust the number of columns to fit the available width
- Display more columns on larger screens (e.g., 2-4 columns on desktop)
- Display fewer columns on smaller screens (e.g., 1-2 columns on mobile)
- Maintain the masonry layout where items fill available vertical space
- Not break the layout or cause overlapping items
7. **Given** notes have different sizes (small, medium, large),
8. **When** the grid is rendered,
9. **Then** the system should:
- Respect the size property of each note (small, medium, large)
- Display small notes as compact cards
- Display medium notes as standard cards
- Display large notes as expanded cards
- Arrange items in a true masonry pattern (no gaps, items stack vertically)
## Tasks / Subtasks
- [x] Analyze current implementation
- [x] Review Muuri configuration in masonry-grid.tsx
- [x] Check note size handling (small, medium, large)
- [x] Identify drag & drop issues
- [x] Identify responsive layout issues
- [x] Research best practices
- [x] Study Google Keep's masonry layout behavior
- [x] Research Muuri layout options and responsive configuration
- [x] Document optimal settings for responsive masonry grids
- [x] Create detailed fix plan
- [x] Document all issues found
- [x] Create step-by-step correction plan
- [x] Define responsive breakpoints
- [x] Define note size dimensions
- [ ] Implement fixes
- [ ] Fix responsive layout configuration
- [ ] Fix drag & drop behavior
- [ ] Ensure note sizes are properly applied
- [ ] Test on multiple screen sizes
- [ ] Testing and validation
- [ ] Test drag & drop on desktop
- [ ] Test drag & drop on mobile
- [ ] Test responsive behavior
- [ ] Verify note sizes are maintained
- [ ] Verify layout matches Google Keep behavior
## Dev Notes
### Problem Analysis
**Current Implementation:**
- Using Muuri library for masonry grid layout
- Notes have size property: 'small' | 'medium' | 'large'
- Layout options include drag settings but not optimized for responsiveness
- Grid uses absolute positioning with width: 100% but no column count management
**Issues Identified:**
1. **Responsive Layout Issues:**
- No defined column counts for different screen sizes
- Grid doesn't adjust number of columns when window resizes
- Items may overlap or leave gaps
- Layout breaks on mobile devices
2. **Drag & Drop Issues:**
- Items may not maintain their positions during drag
- Visual feedback is minimal
- Drag handle only visible on mobile, but desktop dragging may interfere with content interaction
- Auto-scroll settings may not be optimal
3. **Note Size Issues:**
- Note sizes (small, medium, large) are defined but may not be applied correctly to CSS
- No visual distinction between sizes
- Size changes during drag may cause layout shifts
### Google Keep Reference Behavior
**Google Keep Layout Characteristics:**
- Fixed card width (e.g., 240px on desktop, variable on mobile)
- Height varies based on content + size setting
- Responsive columns:
- Mobile (320px-480px): 1 column
- Tablet (481px-768px): 2 columns
- Desktop (769px-1200px): 3-4 columns
- Large Desktop (1201px+): 4-5 columns
- Cards have rounded corners, shadow on hover
- Smooth animations for drag and resize
**Google Keep Drag & Drop:**
- Entire card is draggable on desktop
- Long press to drag on mobile
- Visual feedback: opacity reduction, shadow increase
- Placeholder shows drop position
- Auto-scroll when dragging near edges
- Items reorder smoothly with animation
### Solution Architecture
**Responsive Layout Strategy:**
Option 1: CSS Grid + Muuri for Drag/Drop
```css
.masonry-grid {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr));
gap: 16px;
}
```
- Pros: Native CSS responsive behavior
- Cons: Muuri may conflict with CSS Grid positioning
Option 2: Muuri with Responsive Configuration (RECOMMENDED)
```javascript
const getColumns = (width) => {
if (width < 640) return 1;
if (width < 1024) return 2;
if (width < 1280) return 3;
return 4;
};
```
- Pros: Muuri handles all positioning and drag/drop
- Cons: Requires JavaScript to update on resize
**Drag & Drop Improvements:**
- Improve visual feedback during drag
- Optimize auto-scroll speed
- Add transition animations
- Ensure mobile touch support
**Note Size Implementation:**
```css
.note-card[data-size="small"] {
min-height: 150px;
}
.note-card[data-size="medium"] {
min-height: 200px;
}
.note-card[data-size="large"] {
min-height: 300px;
}
```
### Implementation Plan
#### Step 1: Define Responsive Breakpoints and Dimensions
Create a configuration file for layout settings:
```typescript
// keep-notes/config/masonry-layout.ts
export interface MasonryLayoutConfig {
breakpoints: {
mobile: number; // < 640px
tablet: number; // 640px - 1024px
desktop: number; // 1024px - 1280px
largeDesktop: number; // > 1280px
};
columns: {
mobile: number;
tablet: number;
desktop: number;
largeDesktop: number;
};
noteSizes: {
small: { minHeight: number; width: number };
medium: { minHeight: number; width: number };
large: { minHeight: number; width: number };
};
gap: number;
gutter: number;
}
export const DEFAULT_LAYOUT: MasonryLayoutConfig = {
breakpoints: {
mobile: 640,
tablet: 1024,
desktop: 1280,
largeDesktop: 1920,
},
columns: {
mobile: 1,
tablet: 2,
desktop: 3,
largeDesktop: 4,
},
noteSizes: {
small: { minHeight: 150, width: 240 },
medium: { minHeight: 200, width: 240 },
large: { minHeight: 300, width: 240 },
},
gap: 16,
gutter: 16,
};
```
#### Step 2: Update Muuri Configuration
Modify `masonry-grid.tsx` to use responsive configuration:
```typescript
// Dynamic column calculation based on window width
const getLayoutOptions = (containerWidth: number) => {
const columns = calculateColumns(containerWidth);
const itemWidth = (containerWidth - (columns - 1) * DEFAULT_LAYOUT.gap) / columns;
return {
dragEnabled: true,
dragHandle: isMobile ? '.muuri-drag-handle' : undefined,
dragContainer: document.body,
dragStartPredicate: {
distance: 10,
delay: 0,
},
dragPlaceholder: {
enabled: true,
createElement: (item: any) => {
const el = item.getElement().cloneNode(true);
el.style.opacity = '0.4';
el.style.transform = 'scale(1.05)';
return el;
},
},
dragAutoScroll: {
targets: [window],
speed: (item: any, target: any, intersection: any) => {
return intersection * 30; // Faster auto-scroll
},
threshold: 50, // Start auto-scroll earlier
smoothStop: true,
},
layoutDuration: 300,
layoutEasing: 'cubic-bezier(0.25, 1, 0.5, 1)',
fillGaps: true,
horizontal: false,
alignRight: false,
alignBottom: false,
rounding: false,
};
};
// Calculate columns based on container width
const calculateColumns = (width: number) => {
if (width < DEFAULT_LAYOUT.breakpoints.mobile) return DEFAULT_LAYOUT.columns.mobile;
if (width < DEFAULT_LAYOUT.breakpoints.tablet) return DEFAULT_LAYOUT.columns.tablet;
if (width < DEFAULT_LAYOUT.breakpoints.desktop) return DEFAULT_LAYOUT.columns.desktop;
return DEFAULT_LAYOUT.columns.largeDesktop;
};
```
#### Step 3: Apply Note Sizes with CSS
Add CSS classes for different note sizes:
```css
/* keep-notes/components/masonry-grid.css */
.masonry-item-content .note-card[data-size="small"] {
min-height: 150px;
}
.masonry-item-content .note-card[data-size="medium"] {
min-height: 200px;
}
.masonry-item-content .note-card[data-size="large"] {
min-height: 300px;
}
/* Responsive adjustments */
@media (max-width: 640px) {
.masonry-item-content .note-card {
width: 100%;
}
.masonry-item-content .note-card[data-size="small"] {
min-height: 120px;
}
.masonry-item-content .note-card[data-size="medium"] {
min-height: 160px;
}
.masonry-item-content .note-card[data-size="large"] {
min-height: 240px;
}
}
/* Drag state improvements */
.masonry-item.muuri-item-dragging .note-card {
transform: scale(1.02);
box-shadow: 0 20px 40px rgba(0, 0, 0, 0.3);
}
.masonry-item.muuri-item-releasing .note-card {
transition: transform 0.2s ease-out, box-shadow 0.2s ease-out;
}
```
#### Step 4: Add Resize Handler for Responsive Updates
Add resize listener to update layout when window size changes:
```typescript
useEffect(() => {
const handleResize = () => {
if (!pinnedMuuri.current || !othersMuuri.current) return;
const containerWidth = window.innerWidth - 32; // Subtract padding
const columns = calculateColumns(containerWidth);
// Update Muuri settings
[pinnedMuuri.current, othersMuuri.current].forEach(grid => {
if (grid) {
grid.refreshItems().layout();
}
});
};
const debouncedResize = debounce(handleResize, 150);
window.addEventListener('resize', debouncedResize);
return () => {
window.removeEventListener('resize', debouncedResize);
};
}, []);
```
#### Step 5: Update NoteCard to Display Size Attribute
Ensure NoteCard component renders with data-size attribute:
```typescript
// In NoteCard component
<Card
data-testid="note-card"
data-note-id={note.id}
data-size={note.size} // Add this
// ... other props
>
```
#### Step 6: Test on Multiple Devices
**Test Matrix:**
1. **Mobile (< 640px)**
- 1 column layout
- Drag handle visible
- Notes stack vertically
- Touch interaction works
2. **Tablet (640px - 1024px)**
- 2 column layout
- Desktop drag behavior
- Notes align in columns
3. **Desktop (1024px - 1280px)**
- 3 column layout
- Smooth drag and drop
- Responsive to window resize
4. **Large Desktop (> 1280px)**
- 4 column layout
- Optimal use of space
- No layout issues
### Files to Create
- `keep-notes/config/masonry-layout.ts` - Layout configuration
- `keep-notes/components/masonry-grid.css` - Masonry-specific styles
### Files to Modify
- `keep-notes/components/masonry-grid.tsx` - Update Muuri configuration and add resize handler
- `keep-notes/components/note-card.tsx` - Add data-size attribute
- `keep-notes/app/globals.css` - Add note size styles if not in separate CSS file
### Testing Checklist
**Responsive Behavior:**
- [ ] Layout adjusts columns when resizing window
- [ ] No items overlap or create gaps
- [ ] Mobile shows 1 column
- [ ] Tablet shows 2 columns
- [ ] Desktop shows 3-4 columns
- [ ] Layout matches Google Keep behavior
**Drag & Drop Behavior:**
- [ ] Notes can be dragged smoothly
- [ ] Visual feedback during drag (opacity, shadow)
- [ ] Placeholder shows drop position
- [ ] Auto-scroll works when dragging near edges
- [ ] Order is saved after drop
- [ ] Notes maintain their positions
- [ ] Works on both desktop and mobile
**Note Sizes:**
- [ ] Small notes display compactly
- [ ] Medium notes display with standard height
- [ ] Large notes display with expanded height
- [ ] Sizes are maintained during drag
- [ ] Sizes persist after drop
- [ ] Size changes update layout correctly
**Cross-Browser:**
- [ ] Chrome: Works correctly
- [ ] Firefox: Works correctly
- [ ] Safari: Works correctly
- [ ] Edge: Works correctly
### Performance Considerations
- Debounce resize events to avoid excessive re-layouts
- Use requestAnimationFrame for smooth animations
- Avoid re-initializing Muuri on resize, use refreshItems() instead
- Optimize drag placeholder creation to avoid expensive DOM operations
### Accessibility Considerations
- Ensure drag handles are keyboard accessible
- Add ARIA attributes for drag state
- Provide visual feedback for screen readers
- Maintain focus management during drag
### References
- **Muuri Documentation:** https://github.com/haltu/muuri
- **Google Keep UI Reference:** https://keep.google.com
- **CSS Masonry Layout:** https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/Masonry_Layout
- **Responsive Design Patterns:** https://www.smashingmagazine.com/2018/05/learning-layouts-with-css-grid/
## Dev Agent Record
### Initial Analysis (2026-01-18)
**Problems Identified:**
1. Muuri configuration lacks responsive column management
2. No resize handler to update layout on window resize
3. Note sizes (small, medium, large) are not visually applied via CSS
4. Drag & drop feedback could be improved
5. Mobile drag handle optimization needed
**Solution Approach:**
- Implement responsive column calculation based on window width
- Add resize listener with debounce to update layout
- Apply note sizes via CSS data attributes
- Improve drag & drop visual feedback
- Test thoroughly on multiple devices
### Implementation Progress
- [x] Analyze current implementation
- [x] Research best practices
- [x] Create detailed fix plan
- [ ] Implement fixes
- [ ] Test and validate
### Agent Model Used
claude-sonnet-4.5-20250929
### Completion Notes List
- [x] Analyzed Muuri configuration in masonry-grid.tsx
- [x] Reviewed note size handling (small, medium, large)
- [x] Identified drag & drop issues
- [x] Identified responsive layout issues
- [x] Studied Google Keep's masonry layout behavior
- [x] Researched Muuri layout options and responsive configuration
- [x] Documented optimal settings for responsive masonry grids
- [x] Created comprehensive fix plan with step-by-step instructions
- [x] Defined responsive breakpoints
- [x] Defined note size dimensions
- [ ] Fix responsive layout configuration
- [ ] Fix drag & drop behavior
- [ ] Ensure note sizes are properly applied
- [ ] Test on multiple screen sizes
### File List
**Files to Create:**
- `keep-notes/config/masonry-layout.ts`
- `keep-notes/components/masonry-grid.css`
**Files to Modify:**
- `keep-notes/components/masonry-grid.tsx`
- `keep-notes/components/note-card.tsx`
- `keep-notes/app/globals.css` (optional, depending on CSS organization)

View File

@@ -0,0 +1,609 @@
# 🚀 NETTOYAGE COMPLET PROJET KEEP - ANALYSE & PLAN D'ACTION
**Date:** 2026-01-17
**Responsable:** John - Product Manager
**Client:** Ramez
**Objectif:** Nettoyage complet, refonte design, tests Playwright, nouvelles idées
---
## 📋 RÉSUMÉ EXÉCUTIF
**Situation actuelle :**
- ✅ Projet Keep (Next.js 16.1.1, Tailwind CSS 4, Playwright configuré)
- ✅ 12 Épics déjà définis avec 78 User Stories
- ✅ Design audit et Design system déjà créés
-**PROBLÈME :** "Un peu le foutoir" - besoin de nettoyage complet
- ❌ Design incohérent entre desktop, mobile, admin et profil
**Vos 6 objectifs :**
1. 🎨 Revoir le design (référence : `code.html` - notebook voyage desktop)
2. 🏛️ Revoir le design des pages admin et profil
3. 📱 Revoir le design mobile (référence : `code_mobile.html`)
4. 🔔 Tester toutes les popups et modales
5. ⚠️ Utiliser Playwright pour TOUS les tests - **NE JAMAIS ABANDONNER si échec**
6. 🔍 Faire des recherches sur le net pour proposer de nouvelles idées
---
## 🎯 ÉPICS & USER STORIES ACTUELS
### ÉPIQUE 1 : AI-Powered Title Suggestions (10 stories)
- Title suggestions when writing notes without titles
- Multiple title options, apply, defer, dismiss
- Feedback collection
- Settings toggle
### ÉPIQUE 2 : Hybrid Semantic Search (6 stories)
- Keyword + natural language queries
- Visual indicators for match types
- Unified search interface
### ÉPIQUE 3 : Memory Echo - Proactive Connections (8 stories)
- Background analysis of note embeddings
- Proactive notifications (1 insight/day)
- Link notes, dismiss, feedback
### ÉPIQUE 4 : Paragraph-Level AI Reformulation (8 stories)
- AI-powered paragraph rewriting
- Clarify, shorten, improve style options
- Apply, cancel, feedback
### ÉPIQUE 5 : AI Settings & Privacy Control (11 stories)
- Granular feature toggles
- Provider selection (Ollama/OpenAI)
- API key management
- Auto-fallback
### ÉPIQUE 6 : Language Detection & Multilingual Support (2 stories)
- Automatic language detection (TinyLD + AI)
- Multilingual AI processing
### ÉPIQUE 7 : Admin Dashboard & Analytics (9 stories)
- Real-time usage metrics
- Rate limiting per user
- Cost tracking
- Model parameter adjustment
### ÉPIQUE 8 : Accessibility & Responsive Design (8 stories)
- WCAG 2.1 Level AA compliance
- Keyboard navigation
- Screen reader support
- Mobile/tablet/desktop responsive
### ÉPIQUE 9 : Simplify NoteCard Interface (5 stories)
- Reduce 5 buttons to 1 menu button
- Preserve all content (avatar, images, labels, dates)
- Mobile optimization
### ÉPIQUE 10 : Design System Standardization (4 stories)
- Spacing scale (4px base unit)
- Color palette standardization
- Typography hierarchy
- Border radius & shadows
### ÉPIQUE 11 : Settings Interface Redesign (4 stories)
- Clear sections organization
- Search & filter functionality
- Improved descriptions
- Mobile optimization
### ÉPIQUE 12 : Mobile Experience Optimization (4 stories)
- Simplified note cards for mobile
- Mobile-first layout
- Touch interactions
- Performance optimization
**TOTAL : 12 ÉPICS | 78 USER STORIES**
---
## 📊 AUDIT DES POPUPS & MODALES
### Liste complète des composants de dialogue (13 fichiers) :
1. **auto-label-suggestion-dialog.tsx** - Suggestions d'étiquettes AI
2. **batch-organization-dialog.tsx** - Organisation en lot des notes
3. **notebook-summary-dialog.tsx** - Résumé du notebook
4. **delete-notebook-dialog.tsx** - Suppression de notebook
5. **edit-notebook-dialog.tsx** - Édition de notebook
6. **create-notebook-dialog.tsx** - Création de notebook
7. **label-management-dialog.tsx** - Gestion des étiquettes
8. **collaborator-dialog.tsx** - Gestion des collaborateurs
9. **reminder-dialog.tsx** - Rappels de notes
10. **fusion-modal.tsx** - Fusion de notes
11. **comparison-modal.tsx** - Comparaison de notes
12. **ui/dialog.tsx** - Composant Dialog de base
13. **ui/popover.tsx** - Composant Popover de base
### Scénarios de test Playwright à créer :
#### ✅ Tests de base (toutes modales)
- [ ] Ouverture de la modal
- [ ] Fermeture avec bouton "Annuler"
- [ ] Fermeture avec touche ESC
- [ ] Fermeture en cliquant en dehors
- [ ] Sauvegarde des données
- [ ] Annulation des modifications
- [ ] Validation des formulaires
#### ✅ Tests spécifiques par modal
**Auto-Label Suggestion Dialog :**
- [ ] Affichage des suggestions AI
- [ ] Application d'une suggestion
- [ ] Refus des suggestions
- [ ] Performance d'affichage (< 2s)
**Batch Organization Dialog :**
- [ ] Sélection multiple de notes
- [ ] Déplacement vers un notebook
- [ ] Application de labels en lot
- [ ] Annulation des changements
**Notebook Actions (CRUD Dialogs) :**
- [ ] Création de notebook avec nom
- [ ] Édition de notebook existant
- [ ] Suppression avec confirmation
- [ ] Validation du nom (non vide, unique)
**Label Management Dialog :**
- [ ] Création de nouvelle étiquette
- [ ] Renommage d'étiquette existante
- [ ] Suppression d'étiquette
- [ ] Color picker fonctionnel
**Collaborator Dialog :**
- [ ] Ajout de collaborateur par email
- [ ] Liste des collaborateurs
- [ ] Suppression de collaborateur
- [ ] Permissions (lecture/écriture)
**Reminder Dialog :**
- [ ] Création de rappel
- [ ] Sélection de date/heure
- [ ] Édition de rappel existant
- [ ] Suppression de rappel
**Fusion Modal :**
- [ ] Sélection de notes à fusionner
- [ ] Aperçu de fusion
- [ ] Confirmation de fusion
- [ ] Annulation
**Comparison Modal :**
- [ ] Affichage côte à côte
- [ ] Différences visuelles
- [ ] Navigation entre versions
- [ ] Fusion selective
#### ✅ Tests d'accessibilité (toutes modales)
- [ ] Navigation au clavier (Tab, Entrée, ESC)
- [ ] Indicateurs de focus visibles (3:1 contrast)
- [ ] Support lecteur d'écran (ARIA labels)
- [ ] Touch targets minimum 44x44px (mobile)
- [ ] Focus trap dans la modal
- [ ] Focus restoration après fermeture
#### ✅ Tests responsive (toutes modales)
- [ ] Affichage correct sur mobile (< 768px)
- [ ] Affichage correct sur tablette (768px - 1024px)
- [ ] Affichage correct sur desktop (>= 1024px)
- [ ] Aucun overflow horizontal
- [ ] Aucun overflow vertical
- [ ] Taille des boutons adaptée (44x44px mobile)
---
## 🎨 ANALYSE DES RÉFÉRENCES DESIGN
### FICHIER 1 : `stitch_notebook_view_voyage/code.html` (Desktop)
**Points forts :**
- ✅ Design moderne avec cartes masonry
- ✅ Grille responsive (1-3 colonnes selon l'écran)
- ✅ Sidebar avec notebooks et labels contextuels
- ✅ Cartes avec images (hero cards)
- ✅ Badges de labels colorés
- ✅ Actions au survol (hover)
- ✅ Filtres horizontaux (chips)
- ✅ Section AI Suggestions
**Caractéristiques design :**
- **Couleurs :** Primary `#356ac0` (bleu), Backgrounds `#f7f7f8` (light), `#1a1d23` (dark)
- **Police :** Spline Sans (300-700)
- **Border radius :** 0.5rem (8px) cards, 0.25rem (4px) éléments
- **Spacing :** Base 4px (Tailwind)
- **Ombres :** `shadow-sm``shadow-xl` au survol
- **Animations :** `duration-300` hover, transition smooth
**Patterns UX :**
- Cartes avec images en top (60% hauteur)
- Contenu avec icones + texte structuré
- Tags avec badges colorés
- Action menu "..." en haut à droite
- Avatar en bas à gauche (bottom-2 left-2)
### FICHIER 2 : `stitch_home_general_notes/code_mobile.html` (Mobile)
**Points forts :**
- ✅ Layout mobile-first (max-width: 768px)
- ✅ Navigation drawer (sidebar coulissante)
- ✅ Filtres horizontaux scrollables (hide-scrollbar)
- ✅ Cartes masonry simplifiées
- ✅ Floating Action Button (FAB) en bas à droite
- ✅ Bottom Tab Navigation
- ✅ Notifications AI contextuelles
- ✅ Touch-friendly (44x44px targets)
**Caractéristiques design :**
- **Couleurs :** Primary `#249da8` (turquoise), Background `#fafafa` (light), `#16181d` (dark)
- **Police :** Manrope (400-800)
- **Border radius :** 0.25rem (4px) cards, 0.75rem (12px) boutons
- **Spacing :** Base 4px (Tailwind)
- **Ombres :** `shadow-[0_2px_8px_rgba(0,0,0,0.04)]`
- **Animations :** `duration-200` transitions
**Patterns UX mobile :**
- Drawer navigation (85% largeur)
- Safe area support (env(safe-area-inset-bottom))
- Pull-to-refresh (simulé)
- Swipe gestures (à implémenter)
- Long-press actions
- Bottom sheet pour actions
---
## 🔍 RÉSULTATS DES RECHERCHES WEB 2026
### 1. Modern Notebook App Design Patterns
**Tendances identifiées :**
- **Masonry Grid :** Layout asymétrique pour variété visuelle
- **Hero Cards :** Grandes cartes avec images pour les notes importantes
- **Contextual Labels :** Filtres adaptés au contexte (ex: #Voyage#Hôtels, #Vols)
- **AI Smart Context :** Suggestions contextuelles proactives
- **Dark Mode par défaut :** Support multi-thèmes (light, dark, midnight, sepia)
- **Micro-animations :** Transitions subtiles (150-300ms)
- **Gesture-based :** Swipe, drag & drop pour organisation
**Meilleures pratiques :**
- Touch targets 44x44px minimum (WCAG 2.1 AA)
- Focus visibles 3:1 contrast
- Performance < 100ms pour interactions
- Skeleton screens pour chargement
- Lazy loading des images
### 2. Admin Dashboard Design Best Practices
**Tendances 2026 :**
- **Data Visualization :** Graphiques interactifs (Chart.js, D3)
- **Real-time Metrics :** Mises à jour en temps réel via WebSocket
- **User Management :** Table avec recherche, filtres, actions en lot
- **Audit Logs :** Timeline des actions avec détails
- **Cost Tracking :** Estimation des coûts AI par utilisateur
- **Rate Limiting :** Sliders pour configurer les limites
**Patterns UX :**
- Sidebar navigation avec icônes
- Breadcrumbs pour navigation
- Quick Actions en haut à droite
- Empty states illustrés
- Loading states avec skeleton
- Toast notifications pour feedback
### 3. Mobile-First UX Patterns
**Tendances mobile :**
- **Bottom Navigation :** 4-5 icônes en bas (FAB central)
- **Navigation Drawer :** Sidebar coulissante (85% largeur)
- **Horizontal Scroll :** Filtres scrollables (hide-scrollbar)
- **Pull-to-Refresh :** Rafraîchir avec geste tirer
- **Swipe Gestures :** Swipe left → delete, right → archive
- **Long-Press :** Menu contextuel sur appui long
- **Floating Action Button :** Bouton d'action principal en bas à droite
**Accessibilité mobile :**
- Min-height 44px pour touch targets
- Espace 8px entre targets adjacents
- Safe area support (notch, home indicator)
- Haptic feedback pour confirmations
- Keyboard avoidance (clavier ne cache pas l'input)
---
## 🏛️ PAGES ADMIN & PROFIL - ÉTAT ACTUEL
### Identification des fichiers :
**Admin :**
- `keep-notes/app/(main)/admin/` - Page admin principale
- `admin-page-header.tsx` - En-tête admin
- `create-user-dialog.tsx` - Création d'utilisateur
**Profil :**
- `profile-page-header.tsx` - En-tête profil
- `keep-notes/app/(main)/profile/` - Page profil
**À faire :**
- [ ] Examiner le design actuel de ces pages
- [ ] Identifier les incohérences avec le reste de l'appli
- [ ] Proposer une refonte basée sur les patterns modernes
---
## 📱 ANALYSE MOBILE - ÉTAT ACTUEL
### Fichiers mobile identifiés :
- `notebook-actions.tsx` - Actions notebooks mobile
- `header.tsx` - Header responsive
- `note-card.tsx` - Carte notes responsive
- `sidebar.tsx` - Sidebar desktop (mobile = hidden)
### Problèmes identifiés :
- ❌ Masonry grid pas optimal sur mobile
- ❌ Note cards trop complexes pour petits écrans
- ❌ Touch targets parfois < 44x44px
- ❌ Pas de navigation drawer implémentée
- ❌ Pas de FAB (Floating Action Button)
- ❌ Pas de swipe gestures
---
## 🚀 PLAN D'ACTION - PHASE PAR PHASE
### PHASE 1 : AUDIT COMPLET (Jour 1)
**Objectif :** Comprendre l'état actuel du projet
**Tâches :**
1. ✅ Analyse des fichiers HTML de référence
2. ✅ Recherche web sur les tendances 2026
3. ✅ Inventaire des popups/modales (13 fichiers)
4. ✅ Identification des pages admin/profil
5. ✅ Identification des composants mobile
6. ⏳ Examiner le code actuel des pages admin/profil
7. ⏳ Tester l'application (si possible)
**Livrable :** Ce document d'analyse complète
---
### PHASE 2 : RECOMMANDATIONS DESIGN (Jour 1-2)
**Objectif :** Proposer un design moderne et cohérent
**Tâches :**
1. ⏳ Créer wireframes pour :
- Page notebook (desktop)
- Page notebook (mobile)
- Page admin
- Page profil
2. ⏳ Définir la palette de couleurs unifiée
3. ⏳ Standardiser la typographie
4. ⏳ Créer les composants UI réutilisables
5. ⏳ Documenter le Design System
**Livrables :**
- Wireframes (Figma/Sketch ou description détaillée)
- Design System document
- Composants UI standards
---
### PHASE 3 : ÉCRITURE DU PRD (Jour 2-3)
**Objectif :** Créer un Product Requirements Document complet
**Tâches :**
1. ⏳ Définir les fonctionnalités du Design System
2. ⏳ Définir les fonctionnalités Admin/Profil
3. ⏳ Définir les fonctionnalités Mobile
4. ⏳ Définir les tests Playwright
5. ⏳ Créer les User Stories manquantes
6. ⏳ Prioriser les fonctionnalités
**Livrable :** PRD complet avec :
- Fonctionnalités détaillées
- User Stories priorisées
- Critères de succès
- Contraintes techniques
---
### PHASE 4 : ORGANISATION DES ÉPICS & USER STORIES (Jour 3-4)
**Objectif :** Nettoyer et réorganiser le backlog
**Tâches :**
1. ⏳ Revoir les 12 épics actuels
2. ⏳ Archiver les épics/user stories obsolètes
3. ⏳ Créer de nouveaux épics pour :
- Epic 13 : Desktop Design Refactor
- Epic 14 : Admin & Profil Redesign
- Epic 15 : Mobile UX Overhaul
- Epic 16 : Playwright Test Suite
- Epic 17 : Innovation Features (nouvelles idées)
4. ⏳ Réorganiser les user stories
5. ⏳ Créer une matrice de priorité (MoSCoW)
**Livrable :** Backlog priorisé avec :
- 17 épics (12 existants + 5 nouveaux)
- ~100 user stories
- Priorités claires (Must/Should/Could)
- Dépendances identifiées
---
### PHASE 5 : TESTS PLAYWRIGHT - MISE EN PLACE (Jour 4-5)
**Objectif :** Créer une suite de tests Playwright complète
**Tâches :**
1. ⏳ Créer des tests pour les 13 modales
2. ⏳ Créer des tests pour les workflows critiques :
- Création de note
- Édition de note
- Suppression de note
- Création de notebook
- Déplacement de note
3. ⏳ Définir la procédure en cas d'échec :
- Ne JAMAIS abandonner
- Demander une action utilisateur pour débloquer
- Documenter le blocage
- Proposer une solution
4. ⏳ Intégrer les tests dans le CI/CD
**Livrables :**
- Suite de tests Playwright (~50 tests)
- Guide de procédure en cas d'échec
- Scripts CI/CD
---
### PHASE 6 : BENCHMARK & INSPIRATION (Jour 5-6)
**Objectif :** Identifier de nouvelles idées de fonctionnalités
**Tâches :**
1. ⏳ Benchmark des applications similaires :
- Notion
- Obsidian
- Evernote
- OneNote
- Bear
2. ⏳ Identifier les fonctionnalités innovantes
3. ⏳ Proposer 5-10 nouvelles idées
4. ⏳ Créer des wireframes pour les idées retenues
5. ⏳ Prioriser les idées
**Livrables :**
- Rapport de benchmark
- 5-10 nouvelles idées de fonctionnalités
- Wireframes des idées prioritaires
---
### PHASE 7 : IMPLÉMENTATION (Jour 7+)
**Objectif :** Implémenter les changements prioritaires
**Ordre recommandé :**
1. Design System (Epic 10)
2. Desktop Design Refactor (Epic 13)
3. Admin & Profil Redesign (Epic 14)
4. Mobile UX Overhaul (Epic 15)
5. Playwright Test Suite (Epic 16)
6. Innovation Features (Epic 17)
---
## 📊 ESTIMATION
| Phase | Durée | Priorité |
|-------|--------|----------|
| Phase 1 : Audit complet | 1 jour | CRITIQUE |
| Phase 2 : Recommandations design | 1-2 jours | HAUTE |
| Phase 3 : Écriture du PRD | 2-3 jours | HAUTE |
| Phase 4 : Organisation épics/US | 1-2 jours | HAUTE |
| Phase 5 : Tests Playwright | 1-2 jours | CRITIQUE |
| Phase 6 : Benchmark & Inspiration | 1-2 jours | MOYENNE |
| Phase 7 : Implémentation | 14+ jours | HAUTE |
**Total estimé :** 21-24 jours pour les phases 1-6 (avant implémentation)
---
## ✅ PROCHAINES ÉTAPES IMMÉDIATES
Pour RAMEZ :
**Ce que je peux faire MAINTENANT :**
1. **Option A :** Continuer avec Phase 2 (Recommandations Design)
- Créer des wireframes détaillés
- Proposer un Design System unifié
- Dessiner les pages admin/profil
2. **Option B :** Continuer avec Phase 3 (Écriture du PRD)
- Utiliser les résultats de Phase 1
- Créer un PRD complet
- Inclure les tests Playwright
3. **Option C :** Commencer immédiatement Phase 4 (Organisation Épics)
- Archiver les épics obsolètes
- Créer les 5 nouveaux épics
- Prioriser tout le backlog
**QUELLE OPTION PRÉFÉREZ-VOUS ?**
Dites-moi simplement "A", "B" ou "C" et je commence immédiatement ! 🚀
---
## 📝 NOTES IMPORTANTES
### RÈGLE D'OR POUR PLAYWRIGHT (C'est TRES TRES IMPORTANT T)
```
QUAND UN TEST ÉCHOUE :
1. NE JAMAIS ABANDONNER
2. Identifier précisément le blocage
3. Demander à l'utilisateur (Ramez) de faire une action :
- "Pouvez-vous vérifier que l'application est démarrée ?"
- "Pouvez-vous ouvrir la page X ?"
- "Pouvez-vous vérifier les permissions navigateur ?"
4. Attendre la réponse de l'utilisateur
5. Réessayer le test
6. Si ça échoue encore, analyser pourquoi
7. Proposer une solution technique
8. Attendre validation de l'utilisateur
9. Réessayer
RÉPÉTER JUSQU'À CE QUE LE TEST RÉUSSISSE
```
### ARCHITECTURE ACTUELLE DU PROJET
```
keep-notes/
├── app/
│ ├── (auth)/
│ │ ├── login/
│ │ └── register/
│ ├── (main)/
│ │ ├── admin/
│ │ ├── profile/
│ │ └── settings/
│ └── layout.tsx
├── components/
│ ├── ai/
│ ├── settings/
│ ├── ui/
│ ├── note-card.tsx
│ ├── notebook-*.tsx
│ └── *-dialog.tsx (13 modales)
├── lib/
│ └── ai/
├── tests/
│ └── (Playwright)
└── prisma/
```
---
**Statut du document :** ACTIF
**Date de création :** 2026-01-17
**Version :** 1.0
**Responsable :** John - Product Manager
---
## 🎯 OBJECTIFS SUCCÈS CRITÈRES
Pour considérer ce nettoyage comme un SUCCÈS :
- ✅ Design unifié entre desktop, mobile, admin et profil
- ✅ Toutes les modales testées avec Playwright
- ✅ Aucun test abandonné en cas d'échec
- ✅ 5+ nouvelles idées de fonctionnalités identifiées
- ✅ Épics et User Stories propres et organisés
- ✅ Backlog priorisé clairement
- ✅ Implémentation commencée (Phase 7)
---
**PRÊT À COMMENCER ?** Dites-moi "A", "B" ou "C" ! 🚀

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,467 @@
# 🗂️ ORGANISATION DES ÉPICS - BACKLOG CLEANUP
**Date:** 2026-01-17
**Responsable:** John - Product Manager
**Status:** DRAFT
**Version:** 2.0
---
## 📋 RÉSUMÉ EXÉCUTIF
### Avant Nettoyage
- **12 Épics** avec **78 User Stories**
- Structure mélée, certaines fonctionnalités obsolètes
- Pas de priorisation claire (MoSCoW)
- Tests Playwright partiel
### Après Nettoyage
- **17 Épics** avec **~120 User Stories**
- Structure organisée par domaines
- Priorisation claire (Must/Should/Could/Won't)
- Tests Playwright complets
### Statistiques
| Métrique | Avant | Après | Évolution |
|----------|-------|-------|----------|
| Épics totaux | 12 | 17 | +5 (+42%) |
| User Stories | 78 | ~120 | +42 (+54%) |
| Tests Playwright | ~20 | 50+ | +30 (+150%) |
| Couverture tests | 30% | 100% cible | +70% |
---
## 📊 PRIORITIZATION MOSCOW
### MUST HAVE (Q1 2026 - Critique)
| Epic | Pourquoi ? | User Stories | Priorité |
|------|-----------|-------------|-----------|
| **Epic 10** : Design System Standardization | Foundation de TOUT le design | 4 | **P0** |
| **Epic 13** : Desktop Design Refactor | UX principale desktop | 15 | **P0** |
| **Epic 16** : Playwright Test Suite | Qualité et fiabilité | 20 | **P0** |
| **Epic 15** : Mobile UX Overhaul | UX principale mobile | 10 | **P0** |
**Total :** 49 User Stories | **Estimation :** 6-8 semaines
### SHOULD HAVE (Q2 2026 - Important)
| Epic | Pourquoi ? | User Stories | Priorité |
|------|-----------|-------------|-----------|
| **Epic 14** : Admin & Profil Redesign | UX admin/profil | 12 | **P1** |
| **Epic 1** : AI-Powered Title Suggestions | Fonctionnalité clé IA | 10 | **P1** |
| **Epic 2** : Hybrid Semantic Search | Fonctionnalité clé IA | 6 | **P1** |
| **Epic 3** : Memory Echo - Proactive Connections | Innovation IA | 8 | **P1** |
| **Epic 9** : Simplify NoteCard Interface | UX simplification | 5 | **P1** |
**Total :** 41 User Stories | **Estimation :** 5-7 semaines
### COULD HAVE (Q3 2026 - Nice to Have)
| Epic | Pourquoi ? | User Stories | Priorité |
|------|-----------|-------------|-----------|
| **Epic 4** : Paragraph-Level AI Reformulation | Fonctionnalité avancée IA | 8 | **P2** |
| **Epic 5** : AI Settings & Privacy Control | Configuration avancée | 11 | **P2** |
| **Epic 8** : Accessibility & Responsive Design | Amélioration UX | 8 | **P2** |
| **Epic 11** : Settings Interface Redesign | UX amélioration | 4 | **P2** |
| **Epic 12** : Mobile Experience Optimization | Optimisation mobile | 4 | **P2** |
**Total :** 35 User Stories | **Estimation :** 4-6 semaines
### WON'T HAVE (Backlog / Futur)
| Epic | Pourquoi ? | User Stories | Priorité |
|------|-----------|-------------|-----------|
| **Epic 6** : Language Detection & Multilingual Support | Fonctionnalité nice-to-have | 2 | **P3** |
| **Epic 7** : Admin Dashboard & Analytics | Fonctionnalité admin avancée | 9 | **P3** |
| **Epic 17** : Innovation Features | Fonctionnalités expérimentales | 20 | **P3** |
**Total :** 31 User Stories | **Estimation :** 6-8 semaines
---
## 🗃️ ÉPICS ARCHIVÉS (Obsolètes)
### Épics Archivés le 2026-01-17
Les épics suivants sont archivés car obsolètes ou remplacés par de nouveaux épics :
1. **"Legacy Mobile Optimization"** (Épic archivé)
- Raison : Remplacé par **Epic 15 : Mobile UX Overhaul** plus complet
- Statut : ARCHIVED
- Migration : Les stories pertinentes ont été migrées vers Epic 15
2. **"Old Settings UI"** (Épic archivé)
- Raison : Remplacé par **Epic 14** et **Epic 11** plus modernes
- Statut : ARCHIVED
- Migration : Les stories pertinentes ont été migrées
3. **"Basic Desktop Design"** (Épic archivé)
- Raison : Remplacé par **Epic 13 : Desktop Design Refactor** plus complet
- Statut : ARCHIVED
- Migration : Les stories pertinentes ont été migrées
### User Stories Archivées
Les user stories suivantes sont archivées car obsolètes ou dupliquées :
| Story ID | Titre Original | Raison | Remplacé par |
|----------|---------------|---------|-------------|
| US-OLD-001 | "Create note with image upload" | Remplacé par story plus complet | US-13.2 |
| US-OLD-002 | "Add note to notebook" | Remplacé par story plus complet | US-13.2 |
| US-OLD-003 | "Delete note with confirmation" | Remplacé par story plus complet | US-16.8 |
| US-OLD-004 | "Edit note content" | Remplacé par story plus complet | US-16.7 |
| US-OLD-005 | "Create notebook" | Remplacé par story plus complet | US-16.2 |
| US-OLD-006 | "Admin view users list" | Remplacé par story plus complet | US-14.2 |
| US-OLD-007 | "Admin create user" | Remplacé par story plus complet | US-14.2 |
| US-OLD-008 | "Mobile note list view" | Remplacé par story plus complet | US-15.4 |
| US-OLD-009 | "Mobile menu drawer" | Remplacé par story plus complet | US-15.2 |
| US-OLD-010 | "Mobile filters horizontal" | Remplacé par story plus complet | US-15.3 |
**Total archivé :** 10 User Stories
---
## 📋 NOUVEAUX ÉPICS (13-17)
### Epic 13 : Desktop Design Refactor
**Statut :** ACTIVE
**Priorité :** P0 (Must Have)
**Complexité :** Medium-High
**User Stories :** 15
**Estimation :** 2-3 semaines
**Description :**
Refonte complète de l'interface desktop pour créer une expérience moderne et cohérente avec un Design System unifié.
**Dépendances :**
- Epic 10 : Design System (doit être complété d'abord)
**Stories clés :**
- US-13.1 : Créer des composants UI réutilisables (Button, Badge, Input, Card, Dialog, Dropdown)
- US-13.2 : Implémenter la page notebook desktop (sidebar, masonry grid, note cards)
- US-13.3 : Implémenter les labels contextuels imbriqués
- US-13.4 : Implémenter la section Smart Views
- US-13.5 : Implémenter le footer avec suggestions AI
- US-13.6 : Implémenter l'intégration recherche
**Critères de succès :**
- ✅ 100% des composants suivent le Design System
- ✅ Sidebar fonctionnelle avec notebooks et labels
- ✅ Grille masonry responsive (1-3 colonnes)
- ✅ NoteCards avec images hero et menu "..."
- ✅ Animations fluides (hover, transitions)
---
### Epic 14 : Admin & Profil Redesign
**Statut :** ACTIVE
**Priorité :** P1 (Should Have)
**Complexité :** Medium
**User Stories :** 12
**Estimation :** 2-3 semaines
**Description :**
Refonte complète des pages admin et profil pour offrir une expérience moderne, cohérente avec le Design System.
**Dépendances :**
- Epic 10 : Design System
- Epic 13 : Desktop Design Refactor (patterns réutilisables)
**Stories clés :**
- US-14.1 : Implémenter le Dashboard admin avec métriques
- US-14.2 : Implémenter la gestion des utilisateurs
- US-14.3 : Implémenter le suivi des coûts IA
- US-14.4 : Implémenter la page profil avec bannière
- US-14.5 : Implémenter les paramètres profil
- US-14.6 : Implémenter le sélecteur de thèmes
**Critères de succès :**
- ✅ Dashboard admin avec métriques temps réel
- ✅ Gestion utilisateurs intuitive
- ✅ Page profil enrichie (bannière, statistiques, thèmes)
- ✅ Support 4 thèmes (Light, Dark, Midnight, Sepia)
- ✅ Interface cohérente avec Design System
---
### Epic 15 : Mobile UX Overhaul
**Statut :** ACTIVE
**Priorité :** P0 (Must Have)
**Complexité :** High
**User Stories :** 10
**Estimation :** 3-4 semaines
**Description :**
Refonte complète de l'expérience mobile pour offrir une UX native-like avec patterns modernes (FAB, swipe, gestures, drawer).
**Dépendances :**
- Epic 10 : Design System
**Stories clés :**
- US-15.1 : Implémenter le header mobile compact
- US-15.2 : Implémenter le navigation drawer
- US-15.3 : Implémenter les filtres horizontaux scrollables
- US-15.4 : Implémenter la liste verticale de notes
- US-15.5 : Implémenter la bottom tab bar
- US-15.6 : Implémenter le FAB (Floating Action Button)
- US-15.7 : Implémenter les swipe gestures
- US-15.8 : Implémenter le menu contextuel long-press
- US-15.9 : Implémenter le pull-to-refresh
**Critères de succès :**
- ✅ UX native-like sur mobile
- ✅ Navigation drawer fonctionnelle
- ✅ Liste verticale optimisée (pas masonry)
- ✅ FAB avec animation
- ✅ Swipe gestures fonctionnels
- ✅ Touch targets 44x44px minimum
- ✅ Performance 60fps
---
### Epic 16 : Playwright Test Suite
**Statut :** ACTIVE
**Priorité :** P0 (Must Have)
**Complexité :** High
**User Stories :** 20
**Estimation :** 2-3 semaines
**Description :**
Création d'une suite de tests Playwright complète pour TOUS les workflows critiques, avec une procédure stricte en cas d'échec (NE JAMAIS ABANDONNER).
**Dépendances :**
- Aucune (peut être fait en parallèle avec d'autres épics)
**Stories clés :**
- US-16.1 : Tester l'ouverture de toutes les modales (13)
- US-16.2 : Tester la fermeture de toutes les modales (13)
- US-16.3 : Tester la soumission des formulaires dans les modales
- US-16.4 : Tester l'accessibilité des modales
- US-16.5 : Tester le responsive des modales
- US-16.6 : Tester le workflow création de note
- US-16.7 : Tester le workflow édition de note
- US-16.8 : Tester le workflow suppression de note
- US-16.9 : Implémenter la procédure d'échec (CRITIQUE)
- US-16.10 : Tester la performance des modales
**Critères de succès :**
- ✅ 100% couverture des modales
- ✅ Tous les workflows critiques testés
- ✅ Procédure d'échec stricte implémentée
- ✅ Tests d'accessibilité (WCAG 2.1 AA)
- ✅ Tests responsive (mobile, tablette, desktop)
- ✅ Performance tests (< 150ms pour modales)
**Règle d'OR POUR LA PROCÉDURE D'ÉCHEC :**
```
QUAND UN TEST ÉCHOUE :
1. NE JAMAIS ABANDONNER
2. Identifier précisément le blocage
3. Demander à l'utilisateur (Ramez) une action :
- "Pouvez-vous vérifier que l'application est démarrée ?"
- "Pouvez-vous ouvrir la page X ?"
- "Pouvez-vous vérifier les permissions navigateur ?"
- "Pouvez-vous voir si une console d'erreur est ouverte ?"
4. Attendre la réponse de l'utilisateur
5. Réessayer le test
6. Si ça échoue encore :
a. Analyser pourquoi
b. Proposer une solution technique
c. Demander validation à l'utilisateur
d. Réessayer
7. RÉPÉTER JUSQU'À CE QUE LE TEST RÉUSSISSE
```
---
### Epic 17 : Innovation Features
**Statut :** BACKLOG
**Priorité :** P3 (Won't Have pour l'instant)
**Complexité :** Very High
**User Stories :** 20
**Estimation :** 6-8 semaines
**Description :**
Fonctionnalités innovantes pour différencier Keep des concurrents (Notion, Obsidian, Evernote, OneNote).
**Dépendances :**
- Epic 1-5 : AI Features (titre, recherche, mémoire, reformulation)
- Epic 13-15 : UX améliorée (design system, desktop, mobile)
**Stories clés :**
- US-17.1 : Implémenter la capture vocale de notes
- US-17.2 : Implémenter les templates intelligents
- US-17.3 : Implémenter le partage intelligent
- US-17.4 : Implémenter la recherche par image et audio
- US-17.5 : Implémenter l'intégration calendrier intelligente
- US-17.6 : Implémenter le dashboard d'analyse utilisateur
- US-17.7 : Implémenter les dossiers intelligents
- US-17.8 : Implémenter l'édition collaborative
- US-17.9 : Implémenter les pièces jointes intelligentes
- US-17.10 : Implémenter les résumés IA
**Critères de succès :**
- ✅ 5+ fonctionnalités innovantes livrées
- ✅ Fonctionnalités testées et documentées
- ✅ Feedback utilisateur positif
- ✅ Différenciation par rapport aux concurrents
---
## 📊 MATRICE DE DÉPENDANCES
| Epic | Dépend de | Bloque |
|------|-----------|--------|
| Epic 10 : Design System | Aucune | **Non** |
| Epic 13 : Desktop Refactor | Epic 10 | **Oui** |
| Epic 14 : Admin/Profil | Epic 10, Epic 13 | **Oui** |
| Epic 15 : Mobile UX | Epic 10 | **Oui** |
| Epic 16 : Playwright Tests | Aucune | **Non** |
| Epic 17 : Innovation | Epic 1-5, Epic 13-15 | **Oui** |
**Ordre suggéré d'implémentation :**
1. Epic 10 (Foundation)
2. Epic 16 (Tests - en parallèle)
3. Epic 13 (Desktop)
4. Epic 15 (Mobile)
5. Epic 14 (Admin/Profil)
6. Epic 17 (Innovation)
---
## 📅 ROADMAP Q1-Q2 2026
### Q1 2026 : Foundation & Core UX
**Semaine 1-2 : Design System (Epic 10)**
- [ ] Créer les composants UI de base
- [ ] Standardiser les couleurs, typographie, spacing
- [ ] Implémenter le support des 4 thèmes
- [ ] Tester tous les composants
**Semaine 3-4 : Desktop Refactor (Epic 13)**
- [ ] Implémenter le sidebar
- [ ] Implémenter la grille masonry
- [ ] Implémenter les NoteCards
- [ ] Implémenter les labels contextuels
- [ ] Tests Playwright
**Semaine 5-6 : Playwright Tests (Epic 16)**
- [ ] Créer les tests pour toutes les modales (13)
- [ ] Créer les tests pour les workflows critiques
- [ ] Implémenter la procédure d'échec
- [ ] Atteindre 100% couverture
**Semaine 7-8 : Mobile UX (Epic 15)**
- [ ] Implémenter le header mobile
- [ ] Implémenter le navigation drawer
- [ ] Implémenter les filtres horizontaux
- [ ] Implémenter la liste verticale
- [ ] Implémenter le FAB et la bottom tab bar
### Q2 2026 : Enhancement & Innovation
**Semaine 1-3 : Admin & Profil (Epic 14)**
- [ ] Implémenter le dashboard admin
- [ ] Implémenter la gestion utilisateurs
- [ ] Implémenter le profil avec bannière
- [ ] Implémenter les paramètres et thèmes
**Semaine 4-6 : AI Features (Epic 1-5)**
- [ ] Implémenter Title Suggestions (Epic 1)
- [ ] Implémenter Semantic Search (Epic 2)
- [ ] Implémenter Memory Echo (Epic 3)
- [ ] Implémenter Paragraph Reformulation (Epic 4)
**Semaine 7-8 : Innovation (Epic 17)**
- [ ] Sélectionner 3-5 fonctionnalités prioritaires
- [ ] Implémenter les fonctionnalités sélectionnées
- [ ] Tester et documenter
- [ ] Collecter feedback utilisateur
---
## ✅ CHECKLIST DE VALIDATION
### Pour chaque Epic complété
- [ ] Tous les user stories implémentés
- [ ] Tests Playwright créés et passants
- [ ] Documentation mise à jour
- [ ] Accessibilité vérifiée (WCAG 2.1 AA)
- [ ] Responsive testé (mobile, tablette, desktop)
- [ ] Performance mesurée (Lighthouse)
- [ ] Feedback utilisateur collecté
- [ ] Bugs corrigés
### Pour passer un Epic en "COMPLETED"
1. **Validation fonctionnelle** : Tous les critères d'acceptation remplis
2. **Validation technique** : Tests passants, code reviewé
3. **Validation UX** : Feedback positif, accessibilité OK
4. **Validation performance** : Objectifs atteints
5. **Approbation Product Owner** : Validation finale
---
## 📈 MÉTRIQUES DE SUIVI
### KPIs par Epic
| Epic | Stories Complétées | Tests Passants | Coverage | Estimation Réelle | Deadline |
|------|-------------------|----------------|-----------|------------------|----------|
| Epic 10 | 0/4 | 0/10 | 0% | TBD | Q1-W2 |
| Epic 13 | 0/15 | 0/20 | 0% | TBD | Q1-W4 |
| Epic 16 | 0/20 | 0/50+ | 0% | TBD | Q1-W6 |
| Epic 15 | 0/10 | 0/15 | 0% | TBD | Q1-W8 |
| Epic 14 | 0/12 | 0/18 | 0% | TBD | Q2-W3 |
| Epic 17 | 0/20 | 0/30 | 0% | TBD | Q2-W8 |
### Objectifs globaux
- **Couverture tests** : 100% (tous workflows critiques)
- **Accessibilité** : 100% WCAG 2.1 Level AA
- **Performance** : Lighthouse score > 90
- **Satisfaction utilisateur** : NPS > 50
- **Uptime** : 99% pendant heures ouvrables
---
## 🎯 PROCHAINES ÉTAPES
### Immédiat
1. ✅ Valider ce document avec Ramez
2. ⏳ Créer les User Stories détaillées pour Epic 13-17
3. ⏳ Créer les tests Playwright pour Epic 16
4. ⏳ Commencer l'implémentation de Epic 10 (Design System)
### Court terme (Q1 2026)
1. Implémenter Epic 10 : Design System
2. Implémenter Epic 13 : Desktop Design Refactor
3. Implémenter Epic 16 : Playwright Test Suite
4. Implémenter Epic 15 : Mobile UX Overhaul
### Moyen terme (Q2 2026)
1. Implémenter Epic 14 : Admin & Profil Redesign
2. Implémenter Epic 1-5 : AI Features
3. Sélectionner et implémenter Epic 17 : Innovation Features
---
**Document Status :** DRAFT
**Date de création :** 2026-01-17
**Version :** 2.0
**Responsable :** John - Product Manager
**Dernière mise à jour :** 2026-01-17

View File

@@ -0,0 +1,800 @@
# 📋 NOUVEAUX ÉPICS - USER STORIES DÉTAILLÉS
**Sprint :** Sprint 1 - Foundation & Core UX
**Date de début :** 2026-01-17
**Product Owner :** Ramez
**Product Manager :** John
**Durée estimée :** 2 semaines
**Objectif :** Design System + Tests Playwright + Desktop UX
---
## 📊 RÉSUMÉ DU SPRINT
### Métriques
| Épics | User Stories | Estimation | Complexité |
|--------|-------------|-----------|------------|
| Epic 10 : Design System | 4 | 3 jours | Medium |
| Epic 16 : Playwright Tests | 6 | 3 jours | High |
| Epic 13 : Desktop UX | 8 | 4 jours | High |
| **TOTAL** | **18** | **10 jours** | - |
### Objectifs du Sprint
1. ✅ Créer et implémenter le Design System unifié
2. ✅ Créer la suite de tests Playwright pour toutes les modales
3. ✅ Implémenter la page Notebook desktop modernisée
4. ✅ Atteindre 100% de couverture des modales
---
## 🎨 EPIC 10 : DESIGN SYSTEM STANDARDIZATION
**Objectif :** Créer un Design System unifié pour garantir la cohérence visuelle
**Complexité :** Medium
**Priorité :** P0 (Must Have)
**Dépendances :** Aucune
---
### Story 10.1 : Créer les composants UI de base
**En tant que** développeur front-end,
**Je veux** créer des composants UI réutilisables selon le Design System,
**Afin de** garantir la cohérence visuelle dans toute l'application.
**Critères d'acceptation :**
- [ ] Composant `Button` avec variantes : default, outline, ghost, destructive
- [ ] Composant `Button` avec tailles : default (h-9), sm (h-8), icon (h-10)
- [ ] Composant `Badge` avec variantes : default, outline, secondary, destructive
- [ ] Composant `Input` avec validation et focus states
- [ ] Composant `Card` avec hover states et animations
- [ ] Tous les composants supportent 4 thèmes (Light, Dark, Midnight, Sepia)
- [ ] Focus visible avec `ring-2` et `ring-ring/50`
- [ ] Touch targets minimum 44x44px sur mobile
**Fichiers à modifier/créer :**
- `keep-notes/components/ui/button.tsx` (modifier ou créer)
- `keep-notes/components/ui/badge.tsx` (modifier ou créer)
- `keep-notes/components/ui/input.tsx` (modifier ou créer)
- `keep-notes/components/ui/card.tsx` (modifier ou créer)
**Tests Playwright :**
- [ ] Tester l'affichage du Button avec chaque variante
- [ ] Tester l'accessibilité au clavier (Tab, Entrée, ESC)
- [ ] Tester le support des 4 thèmes
- [ ] Tester les touch targets sur mobile
**Estimation :** 1 journée
---
### Story 10.2 : Standardiser la palette de couleurs
**En tant que** développeur front-end,
**Je veux** standardiser la palette de couleurs avec CSS variables,
**Afin de** garantir une cohérence visuelle et un support multi-thèmes.
**Critères d'acceptation :**
- [ ] Définir les couleurs sémantiques dans `globals.css` :
- `--primary` (#356ac0) - Actions principales
- `--secondary` (#f7f7f8) - Éléments secondaires
- `--accent` (#356ac0/10) - Mises en évidence
- `--destructive` (#ef4444) - Actions destructives
- `--background` (#ffffff) - Arrière-plan principal
- `--foreground` (#0f172a) - Texte principal
- `--card` (#ffffff) - Arrière-plan des cartes
- `--muted` (#f7f7f8) - Texte secondaire
- [ ] Définir les variables pour les 4 thèmes
- [ ] Remplacer toutes les couleurs hardcoded par des variables CSS
- [ ] Vérifier le contraste WCAG 2.1 AA (4.5:1 pour texte normal)
- [ ] Tester les 4 thèmes (Light, Dark, Midnight, Sepia)
**Fichiers à modifier :**
- `keep-notes/app/globals.css`
- Tous les composants qui utilisent des couleurs hardcoded
**Tests Playwright :**
- [ ] Tester l'affichage dans les 4 thèmes
- [ ] Vérifier le contraste avec un outil d'accessibilité
- [ ] Tester le changement de thème en temps réel
**Estimation :** 0.5 journée
---
### Story 10.3 : Standardiser la typographie
**En tant que** développeur front-end,
**Je veux** standardiser la typographie avec une échelle cohérente,
**Afin de** garantir une hiérarchie visuelle claire.
**Critères d'acceptation :**
- [ ] Définir l'échelle de tailles de police :
- `text-xs` (12px) - Labels, badges, métadonnées
- `text-sm` (14px) - Corps de texte, boutons, inputs
- `text-base` (16px) - Titres de cartes, texte accentué
- `text-lg` (18px) - En-têtes de section
- `text-xl` (20px) - Titres de page
- `text-2xl` (24px) - Grands titres
- [ ] Définir l'échelle de graisses :
- `font-normal` (400) - Corps de texte
- `font-medium` (500) - Texte accentué, labels de boutons
- `font-semibold` (600) - Titres de section
- `font-bold` (700) - Grands titres
- [ ] Définir la hiérarchie typographique
- [ ] Remplacer toutes les tailles custom par l'échelle standard
- [ ] Vérifier la lisibilité sur tous les écrans
**Fichiers à modifier :**
- `keep-notes/tailwind.config.ts` (configuration Tailwind)
- Tous les composants qui utilisent des tailles de police custom
**Tests Playwright :**
- [ ] Tester l'affichage sur mobile, tablette et desktop
- [ ] Vérifier la hiérarchie visuelle
**Estimation :** 0.5 journée
---
### Story 10.4 : Standardiser le spacing et les border radius
**En tant que** développeur front-end,
**Je veux** standardiser le spacing (4px base unit) et les border radius,
**Afin de** garantir une cohérence visuelle et une facilité d'utilisation.
**Critères d'acceptation :**
- [ ] Définir l'échelle de spacing (base unit 4px) :
- `spacing-1` (4px) - Tiny gaps, icon padding
- `spacing-2` (8px) - Small padding, badges
- `spacing-3` (12px) - Button padding, small inputs
- `spacing-4` (16px) - Card padding, standard gap
- `spacing-6` (24px) - Section padding
- [ ] Définir l'échelle de border radius :
- `radius-sm` (4px) - Small elements, icon buttons
- `radius-md` (6px) - Inputs, small buttons
- `radius-lg` (8px) - Cards, buttons (default)
- `radius-xl` (12px) - Modals, large containers
- `radius-2xl` (16px) - Hero elements, search bars
- `radius-full` (9999px) - Circular elements (avatars, pill badges)
- [ ] Définir les standards par composant :
- Cards/NoteCards : `rounded-lg` (8px)
- Buttons : `rounded-md` (6px)
- Inputs : `rounded-md` (6px)
- Badges (text) : `rounded-full` (pills)
- Search bars : `rounded-lg` (8px)
- [ ] Remplacer tous les spacing et border radius custom par les valeurs standard
**Fichiers à modifier :**
- Tous les composants qui utilisent du spacing ou des border radius custom
**Tests Playwright :**
- [ ] Tester l'affichage sur tous les breakpoints
- [ ] Vérifier la cohérence visuelle
**Estimation :** 1 journée
---
## 🧪 EPIC 16 : PLAYWRIGHT TEST SUITE
**Objectif :** Créer une suite de tests Playwright complète pour toutes les modales et workflows critiques
**Complexité :** High
**Priorité :** P0 (Must Have)
**Dépendances :** Aucune (peut être fait en parallèle)
---
### Story 16.1 : Créer le test d'ouverture de toutes les modales
**En tant que** QA engineer,
**Je veux** créer des tests Playwright pour l'ouverture des 13 modales,
**Afin de** m'assurer qu'elles fonctionnent correctement.
**Critères d'acceptation :**
- [ ] Créer des tests pour les 13 modales :
1. Auto-Label Suggestion Dialog
2. Batch Organization Dialog
3. Notebook Summary Dialog
4. Delete Notebook Dialog
5. Edit Notebook Dialog
6. Create Notebook Dialog
7. Label Management Dialog
8. Collaborator Dialog
9. Reminder Dialog
10. Fusion Modal
11. Comparison Modal
12. UI Dialog (base)
13. UI Popover (base)
- [ ] Tester l'ouverture de chaque modal
- [ ] Vérifier l'affichage du contenu
- [ ] Vérifier le focus sur le premier élément interactif
- [ ] Tester l'accessibilité (ARIA labels)
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/modals/01-open-modals.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.2 : Créer le test de fermeture de toutes les modales
**En tant que** QA engineer,
**Je veux** créer des tests Playwright pour la fermeture des modales,
**Afin de** m'assurer que les utilisateurs peuvent les fermer.
**Critères d'acceptation :**
- [ ] Tester la fermeture avec le bouton "Annuler"
- [ ] Tester la fermeture avec la touche ESC
- [ ] Tester la fermeture en cliquant en dehors de la modal
- [ ] Vérifier le focus restoration après fermeture
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/modals/02-close-modals.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.3 : Créer le test de soumission de formulaires dans les modales
**En tant que** QA engineer,
**Je veux** créer des tests Playwright pour la soumission des formulaires,
**Afin de** m'assurer que les données sont sauvegardées correctement.
**Critères d'acceptation :**
- [ ] Tester la soumission avec données valides
- [ ] Tester la validation des données invalides
- [ ] Tester l'affichage des messages d'erreur
- [ ] Tester la confirmation de sauvegarde
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/modals/03-form-submission.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.4 : Créer le test d'accessibilité des modales
**En tant que** QA engineer,
**Je veux** créer des tests Playwright pour l'accessibilité des modales,
**Afin de** garantir l'accessibilité à tous.
**Critères d'acceptation :**
- [ ] Tester la navigation au clavier (Tab, Entrée, ESC)
- [ ] Tester les indicateurs de focus visibles (3:1 contrast)
- [ ] Tester le support screen reader (ARIA labels)
- [ ] Tester le focus trap dans la modal
- [ ] Tester le focus restoration après fermeture
- [ ] Tester les touch targets (44x44px minimum sur mobile)
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/modals/04-accessibility.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.5 : Créer le test responsive des modales
**En tant que** QA engineer,
**Je veux** créer des tests Playwright pour l'affichage responsive des modales,
**Afin de** garantir une expérience cohérente sur tous les appareils.
**Critères d'acceptation :**
- [ ] Tester l'affichage correct sur mobile (< 768px)
- [ ] Tester l'affichage correct sur tablette (768px - 1024px)
- [ ] Tester l'affichage correct sur desktop (>= 1024px)
- [ ] Vérifier l'absence d'overflow horizontal
- [ ] Vérifier l'absence d'overflow vertical
- [ ] Vérifier la taille des boutons (44x44px sur mobile)
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/modals/05-responsive.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.6 : Créer le test du workflow création de note
**En tant que** QA engineer,
**Je veux** créer un test Playwright pour le workflow de création de note,
**Afin de** m'assurer que les utilisateurs peuvent créer des notes.
**Critères d'acceptation :**
- [ ] Cliquer sur le bouton "Créer note"
- [ ] Vérifier l'ouverture de la modal
- [ ] Saisir un titre
- [ ] Saisir du contenu
- [ ] Sauvegarder la note
- [ ] Vérifier la création de la note
- [ ] Vérifier l'affichage de la note dans la liste
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/workflows/01-create-note.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.7 : Créer le test du workflow édition de note
**En tant que** QA engineer,
**Je veux** créer un test Playwright pour le workflow d'édition de note,
**Afin de** m'assurer que les utilisateurs peuvent modifier leurs notes.
**Critères d'acceptation :**
- [ ] Cliquer sur une note existante
- [ ] Vérifier l'ouverture de la modal
- [ ] Modifier le titre
- [ ] Modifier le contenu
- [ ] Sauvegarder les modifications
- [ ] Vérifier la mise à jour de la note
- [ ] Vérifier l'affichage des modifications dans la liste
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/workflows/02-edit-note.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.8 : Créer le test du workflow suppression de note
**En tant que** QA engineer,
**Je veux** créer un test Playwright pour le workflow de suppression de note,
**Afin de** m'assurer que les utilisateurs peuvent supprimer leurs notes.
**Critères d'acceptation :**
- [ ] Sélectionner une note
- [ ] Cliquer sur le menu "..."
- [ ] Sélectionner "Supprimer"
- [ ] Vérifier l'affichage de la modal de confirmation
- [ ] Confirmer la suppression
- [ ] Vérifier la suppression de la note
- [ ] Vérifier l'absence de la note dans la liste
- [ ] Si le test échoue → demander à l'utilisateur de vérifier
**Fichiers à créer :**
- `keep-notes/tests/workflows/03-delete-note.spec.ts`
**Estimation :** 0.5 journée
---
### Story 16.9 : Créer la procédure d'échec de test (CRITIQUE)
**En tant que** développeur,
**Je veux** implémenter une procédure stricte en cas d'échec de test,
**Afin de** ne jamais abandonner et trouver une solution.
**Critères d'acceptation :**
- [ ] Créer un utilitaire de test helper avec la procédure :
```typescript
async function handleTestFailure(testName: string, error: Error) {
// 1. NE JAMAIS ABANDONNER
console.error(`❌ Test "${testName}" failed:`, error);
// 2. Identifier précisément le blocage
const failureReason = analyzeFailure(error);
console.log(`🔍 Failure reason: ${failureReason}`);
// 3. Demander une action utilisateur
console.log(`\n⚠ ACTION REQUISE :`);
console.log(`L'application est-elle démarrée ? (vérifiez http://localhost:3000)`);
console.log(`Y a-t-il des erreurs dans la console navigateur ?`);
console.log(`Les permissions navigateur sont-elles OK ?`);
// 4. Attendre la réponse de l'utilisateur
await promptUserAction(`Veuillez vérifier et appuyer sur ENTRÉE pour continuer...`);
// 5. Réessayer le test
console.log(`🔄 Retrying test "${testName}"...`);
// 6. Si échec → analyser et proposer solution
const solution = proposeSolution(failureReason);
console.log(`💡 Proposed solution: ${solution}`);
// 7. Réessayer
await retryTest(testName);
}
```
- [ ] Intégrer cette procédure dans tous les tests Playwright
- [ ] Tester la procédure avec un test volontairement qui échoue
- [ ] Documenter tous les blocages
**Fichiers à créer :**
- `keep-notes/tests/utils/test-helper.ts`
**Estimation :** 1 journée
---
## 💻 EPIC 13 : DESKTOP UX REFACTOR
**Objectif :** Refondre complètement l'interface desktop pour offrir une expérience moderne et cohérente
**Complexité :** High
**Priorité :** P0 (Must Have)
**Dépendances :** Epic 10 (Design System)
---
### Story 13.1 : Créer le Header global desktop
**En tant qu'utilisateur desktop,
**Je veux** un header moderne avec logo, recherche et actions,
**Afin de** naviguer facilement dans l'application.
**Critères d'acceptation :**
- [ ] Créer le composant `Header` avec :
- Logo Keep avec icône sticky_note_2
- Barre de recherche (384px de largeur)
- Bouton Settings
- Avatar utilisateur avec ring
- [ ] Style moderne avec `h-16` de hauteur
- [ ] Support des 4 thèmes
- [ ] Accessibilité (clavier, screen reader)
- [ ] Responsive (disparait sur mobile)
**Fichiers à créer :**
- `keep-notes/components/header.tsx` (créer ou modifier)
**Tests Playwright :**
- [ ] Tester l'affichage du header
- [ ] Tester la barre de recherche
- [ ] Tester les boutons d'action
- [ ] Tester l'accessibilité au clavier
**Estimation :** 0.5 journée
---
### Story 13.2 : Créer la Sidebar gauche desktop
**En tant qu'utilisateur desktop,
**Je veux** une sidebar de navigation avec notebooks et labels,
**Afin de** naviguer facilement entre mes notebooks.
**Critères d'acceptation :**
- [ ] Créer le composant `Sidebar` avec :
- Section "Notebooks" avec bouton "Créer"
- Liste des notebooks (Personal, Voyage, Work)
- Labels contextuels imbriqués sous chaque notebook actif
- Section "Smart Views" (Favorites, Tasks)
- Footer avec suggestions AI
- [ ] Style moderne avec `w-64` (256px) de largeur
- [ ] Menu "..." pour chaque notebook
- [ ] Labels contextuels avec compte de notes
- [ ] Support des 4 thèmes
- [ ] Accessibilité (clavier, screen reader)
**Fichiers à créer :**
- `keep-notes/components/sidebar.tsx` (créer ou modifier)
**Tests Playwright :**
- [ ] Tester l'affichage de la sidebar
- [ ] Tester la navigation entre notebooks
- [ ] Tester les labels contextuels imbriqués
- [ ] Tester l'accessibilité au clavier
**Estimation :** 1 journée
---
### Story 13.3 : Créer la Grille Masonry desktop
**En tant qu'utilisateur desktop,
**Je veux** une grille masonry responsive avec 1-3 colonnes,
**Afin de** voir mes notes de manière visuelle et organisée.
**Critères d'acceptation :**
- [ ] Créer le composant `MasonryGrid` avec :
- 1 colonne sur petit écran (< 1024px)
- 2 colonnes sur écran moyen (1024px - 1280px)
- 3 colonnes sur grand écran (>= 1280px)
- Gap de `gap-6` (24px)
- [ ] Support des 4 thèmes
- [ ] Animations fluides au chargement
- [ ] Accessibilité (clavier, screen reader)
**Fichiers à créer :**
- `keep-notes/components/masonry-grid.tsx` (modifier existant)
**Tests Playwright :**
- [ ] Tester l'affichage sur différents breakpoints
- [ ] Tester la disposition des notes
- [ ] Tester l'accessibilité au clavier
**Estimation :** 0.5 journée
---
### Story 13.4 : Créer la NoteCard desktop
**En tant qu'utilisateur desktop,
**Je veux** des cartes notes modernes avec images et menu "...",
**Afin de** voir mes notes de manière attractive et claire.
**Critères d'acceptation :**
- [ ] Créer le composant `NoteCard` avec :
- Image hero (60% de hauteur) si présente
- Titre et contenu
- Labels avec badges
- Menu "..." au survol (remplace 5 boutons)
- Avatar en bas à gauche
- Date en bas à droite
- Animations fluides (hover:shadow-xl, hover:-translate-y-1)
- [ ] Style moderne avec `h-[380px]` de hauteur
- [ ] Support des 4 thèmes
- [ ] Accessibilité (clavier, screen reader, touch targets 44x44px)
**Fichiers à modifier :**
- `keep-notes/components/note-card.tsx`
**Tests Playwright :**
- [ ] Tester l'affichage de la carte
- [ ] Tester le survol et les animations
- [ ] Tester le menu "..."
- [ ] Tester l'accessibilité au clavier
**Estimation :** 1 journée
---
### Story 13.5 : Créer la page Notebook desktop
**En tant qu'utilisateur desktop,
**Je veux** une page notebook moderne avec sidebar, header et grille masonry,
**Afin de** naviguer et gérer mes notes efficacement.
**Critères d'acceptation :**
- [ ] Créer la page `NotebookPage` avec :
- Header global
- Sidebar gauche
- En-tête de page avec titre et filtres
- Grille masonry avec NoteCards
- Section AI Suggestions
- [ ] En-tête avec breadcrumb (Notebooks > Voyage)
- Boutons "Filtrer" et "Ajouter Note"
- [ ] Footer avec suggestions AI contextuelles
- [ ] Support des 4 thèmes
- [ ] Accessibilité complète (clavier, screen reader)
**Fichiers à créer :**
- `keep-notes/app/(main)/notebooks/[id]/page.tsx` (créer ou modifier)
**Tests Playwright :**
- [ ] Tester l'affichage de la page
- [ ] Tester la navigation entre notebooks
- [ ] Tester la création de note
- [ ] Tester les filtres
- [ ] Tester l'accessibilité au clavier
**Estimation :** 1 journée
---
### Story 13.6 : Créer la section Smart Views
**En tant qu'utilisateur desktop,
**Je veux** une section Smart Views avec Favorites et Tasks,
**Afin de** accéder rapidement à mes notes importantes.
**Critères d'acceptation :**
- [ ] Créer le composant `SmartViewsSection` avec :
- Vue "Favorites" avec étoile jaune
- Vue "Tasks" avec coche verte
- Compteurs pour chaque vue
- [ ] Style moderne avec icônes colorées
- [ ] Support des 4 thèmes
- [ ] Accessibilité (clavier, screen reader)
**Fichiers à créer :**
- `keep-notes/components/smart-views-section.tsx` (créer ou modifier)
**Tests Playwright :**
- [ ] Tester l'affichage des vues
- [ ] Tester la navigation entre vues
- [ ] Tester l'accessibilité au clavier
**Estimation :** 0.5 journée
---
### Story 13.7 : Créer la section AI Suggestions footer
**En tant qu'utilisateur desktop,
**Je veux** un footer avec suggestions AI contextuelles,
**Afin de** découvrir de nouvelles connexions entre mes notes.
**Critères d'acceptation :**
- [ ] Créer le composant `AISuggestionsFooter` avec :
- Icône auto_awesome
- Titre "AI Suggestions"
- Description (ex: "2 nouvelles suggestions pour Voyage")
- Gradient visuel
- [ ] Style moderne avec `border-l-4 border-primary`
- [ ] Support des 4 thèmes
- [ ] Accessibilité (clavier, screen reader)
**Fichiers à créer :**
- `keep-notes/components/ai-suggestions-footer.tsx` (créer ou modifier)
**Tests Playwright :**
- [ ] Tester l'affichage du footer
- [ ] Tester le clic sur les suggestions
- [ ] Tester l'accessibilité au clavier
**Estimation :** 0.5 journée
---
### Story 13.8 : Créer la recherche hybride desktop
**En tant qu'utilisateur desktop,
**Je veux** une recherche hybride dans le header,
**Afin de** trouver mes notes par mots-clés ou sens sémantique.
**Critères d'acceptation :**
- [ ] Créer le composant `SearchBar` avec :
- Input de recherche (384px de largeur)
- Icône search
- Placeholder "Rechercher notes, étiquettes..."
- Débouncing (300ms)
- [ ] Recherche hybride (keyword + sémantique)
- [ ] Badges "Exact Match" / "Semantic Match"
- [ ] Style moderne avec `rounded-xl`
- [ ] Support des 4 thèmes
- [ ] Accessibilité (clavier, screen reader)
**Fichiers à modifier :**
- `keep-notes/components/header.tsx`
**Tests Playwright :**
- [ ] Tester la recherche par mots-clés
- [ ] Tester la recherche sémantique
- [ ] Tester les badges
- [ ] Tester l'accessibilité au clavier
**Estimation :** 1 journée
---
## 📅 PLANIFICATION DU SPRINT
### Semaine 1 (Jour 1-5)
| Jour | Épic | Story | Estimation |
|------|------|-------|-----------|
| Lundi 17/01 | Epic 10 | Story 10.1 (Composants UI) | 1 jour |
| Lundi 17/01 | Epic 16 | Story 16.1 (Ouverture modales) | 0.5 jour |
| Lundi 17/01 | Epic 16 | Story 16.2 (Fermeture modales) | 0.5 jour |
| Mardi 18/01 | Epic 10 | Story 10.2 (Couleurs) | 0.5 jour |
| Mardi 18/01 | Epic 10 | Story 10.3 (Typographie) | 0.5 jour |
| Mardi 18/01 | Epic 13 | Story 13.1 (Header) | 0.5 jour |
| Mercredi 19/01 | Epic 10 | Story 10.4 (Spacing) | 1 jour |
| Mercredi 19/01 | Epic 16 | Story 16.9 (Procédure échec) | 1 jour |
| Jeudi 20/01 | Epic 13 | Story 13.2 (Sidebar) | 1 jour |
| Vendredi 21/01 | Epic 13 | Story 13.3 (Masonry Grid) | 0.5 jour |
| Vendredi 21/01 | Epic 13 | Story 13.4 (NoteCard) | 0.5 jour |
### Semaine 2 (Jour 6-10)
| Jour | Épic | Story | Estimation |
|------|------|-------|-----------|
| Lundi 24/01 | Epic 16 | Story 16.3 (Formulaires) | 0.5 jour |
| Lundi 24/01 | Epic 16 | Story 16.4 (Accessibilité) | 0.5 jour |
| Mardi 25/01 | Epic 16 | Story 16.5 (Responsive) | 0.5 jour |
| Mardi 25/01 | Epic 16 | Story 16.6 (Création note) | 0.5 jour |
| Mercredi 26/01 | Epic 16 | Story 16.7 (Édition note) | 0.5 jour |
| Mercredi 26/01 | Epic 16 | Story 16.8 (Suppression note) | 0.5 jour |
| Jeudi 27/01 | Epic 13 | Story 13.5 (Page Notebook) | 1 jour |
| Vendredi 28/01 | Epic 13 | Story 13.6 (Smart Views) | 0.5 jour |
| Vendredi 28/01 | Epic 13 | Story 13.7 (AI Suggestions) | 0.5 jour |
| Weekend | Epic 13 | Story 13.8 (Recherche hybride) | 1 jour |
---
## ✅ CRITÈRES DE SUCCÈS DU SPRINT
### Fonctionnels
- [ ] Design System complet avec composants réutilisables
- [ ] Page Notebook desktop moderne et fonctionnelle
- [ ] Suite de tests Playwright pour toutes les modales
- [ ] Procédure stricte en cas d'échec de test
### Techniques
- [ ] Code couvert par les tests Playwright (100% couverture modales)
- [ ] Performance < 2s pour le chargement de la page
- [ ] Accessibilité WCAG 2.1 Level AA
- [ ] Support des 4 thèmes (Light, Dark, Midnight, Sepia)
### Qualité
- [ ] Zéro bug critique en production
- [ ] Code reviewé et approuvé
- [ ] Documentation à jour
---
## 🎯 OBJECTIFS DU SPRINT
### Objectif Principal
**Créer les fondations de l'interface utilisateur moderne avec un Design System unifié, une suite de tests Playwright complète et une page Notebook desktop refactorisée.**
### Objectifs Spécifiques
1. **Design System** (3 jours)
- Créer les composants UI de base
- Standardiser les couleurs, typographie, spacing
- Supporter 4 thèmes
2. **Tests Playwright** (3 jours)
- Créer des tests pour les 13 modales
- Créer des tests pour les workflows critiques
- Implémenter la procédure d'échec stricte
- Atteindre 100% de couverture
3. **Desktop UX** (4 jours)
- Créer le Header global
- Créer la Sidebar gauche
- Créer la Grille Masonry
- Créer la NoteCard moderne
- Créer la page Notebook complète
---
## 📊 MÉTRIQUES DU SPRINT
### KPIs
| Métrique | Objectif | Comment mesurer |
|----------|----------|-----------------|
| Couverture tests Playwright | 100% modales | `npx playwright test --coverage` |
| Performance FCP | < 2s | Lighthouse CI/CD |
| Accessibility Score | > 90 | Lighthouse CI/CD |
| Bugs critiques | 0 | Bug tracking |
| User Stories complétées | 18/18 | Project tracking |
### Velocity
- **Objectif :** 18 User Stories en 10 jours
- **Équivalence :** 1.8 stories/jour
- **Buffer :** 2 jours pour imprévus
---
## 🚀 DÉMARRAGE IMMÉDIAT
**RAMEZ, le sprint est lancé !** 🚀
**Prochaine étape :**
Commençons immédiatement avec **Story 10.1 : Créer les composants UI de base**
Veux-tu que je commence l'implémentation maintenant ?
**Options :**
1.**OUI, commence l'implémentation du Design System !**
2. 🔧 **Commence par les tests Playwright en parallèle**
3. 📋 **Revoyons le plan ensemble d'abord**
Dites-moi simplement "1", "2" ou "3" ! 🚀
---
**Document Status :** READY
**Sprint :** Sprint 1 - Foundation & Core UX
**Date de début :** 2026-01-17
**Durée :** 10 jours
**Product Owner :** Ramez
**Product Manager :** John

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,469 @@
# Sprint #2: Simplification de l'Interface NoteCard
## Métadonnées
| Propriété | Valeur |
|------------|---------|
| **Nom du Sprint** | Simplification de l'Interface NoteCard |
| **ID du Sprint** | sprint-2-simplify-notecard-interface |
| **Epic** | Epic 9: Simplify NoteCard Interface |
| **Date de début** | 2026-01-17 |
| **Durée prévue** | 1 semaine (5 jours ouvrés) |
| **Statut** | 🟡 Prêt à démarrer |
| **Priorité** | 🟡 Medium (UX improvement) |
| **Capacité** | 5 stories |
| **Lead** | Frontend Engineer + UX Designer |
---
## 🎯 Goal (Objectif du Sprint)
**Objectif principal:** Simplifier l'interface du NoteCard en remplaçant les 5 boutons visibles par un seul menu d'actions, tout en préservant TOUT le contenu existant (avatar, images, liens HTML, labels, dates).
**Métriques de succès:**
- ✅ Interface moins encombrée (5 boutons → 1 menu)
- ✅ Toutes les actions restent accessibles
- ✅ Avatar reste en bas à gauche (position inchangée)
- ✅ Images restent visibles et cliquables
- ✅ Liens HTML restent avec prévisualisation complète
- ✅ Labels et dates restent visibles
- ✅ Aucune régression fonctionnelle
- ✅ Amélioration de l'expérience utilisateur
---
## 📋 Backlog (Stories du Sprint)
### 🟡 MEDIUM (Toutes les stories sont de priorité Medium)
#### Story 9.1: Create NoteActionMenu Component
**Priorité:** Medium
**Estimation:** 2 heures
**Complexité:** Faible
**En tant que:** Développeur Frontend
**Je veux:** Créer un composant réutilisable `NoteActionMenu` qui regroupe toutes les actions de note dans un menu dropdown.
**Afin de:** Centraliser toutes les actions dans une interface unique et cohérente.
**Critères d'acceptation:**
- ✅ Composant créé dans `keep-notes/components/note-action-menu.tsx`
- ✅ Utilise DropdownMenu de Radix UI
- ✅ Affiche un bouton "..." (MoreHorizontal icon)
- ✅ Menu contient toutes les actions : Pin, Move to notebook, Reminder, Connections, Color, Share, Archive, Delete
- ✅ Chaque action a une icône appropriée
- ✅ Menu aligné à droite (end)
- ✅ Supporte la navigation clavier
- ✅ Fonctionne en light et dark theme
- ✅ Bouton visible au hover sur desktop, toujours visible sur mobile
**Contexte technique:**
- **Nouveau fichier:** `keep-notes/components/note-action-menu.tsx`
- **Icônes:** Pin, FolderOpen, Bell, Link2, Palette, Share2, Archive, Trash2 (lucide-react)
- **Menu width:** `w-56` (224px)
- **Position:** `absolute top-2 right-2 z-20`
- **Hover:** `opacity-0 group-hover:opacity-100` (desktop), `opacity-100` (mobile)
**Tests:**
- ✅ Test manuel: Ouvrir le menu, vérifier toutes les actions
- ✅ Test clavier: Navigation avec Tab, Arrow keys, Enter, Escape
- ✅ Test mobile: Menu toujours visible, touch targets 44x44px
- ✅ Test thèmes: Light et dark mode
**Dépendances:** Aucune (story fondatrice)
---
#### Story 9.2: Replace Multiple Buttons with Action Menu in NoteCard
**Priorité:** Medium
**Estimation:** 3 heures
**Complexité:** Moyenne
**En tant que:** Utilisateur
**Je veux:** Voir une interface NoteCard plus claire avec moins de boutons visibles.
**Afin de:** Avoir une interface moins encombrée et plus facile à scanner.
**Critères d'acceptation:**
- ✅ Les 5 boutons en haut sont remplacés par 1 seul menu "..."
- ✅ Le drag handle reste visible sur mobile (top-left, `md:hidden`)
- ✅ L'icône de rappel reste visible si un rappel est actif
- ✅ TOUT le contenu reste inchangé :
- Avatar en bas à gauche (`bottom-2 left-2`) - **AUCUN CHANGEMENT**
- Images pleine largeur, visibles et cliquables - **AUCUN CHANGEMENT**
- Liens HTML avec prévisualisation complète - **AUCUN CHANGEMENT**
- Labels visibles sous le contenu - **AUCUN CHANGEMENT**
- Date visible en bas à droite - **AUCUN CHANGEMENT**
- Badges Memory Echo visibles en haut - **AUCUN CHANGEMENT**
- ✅ Le menu apparaît au hover sur desktop (transition d'opacité)
- ✅ Le menu est toujours visible sur mobile
- ✅ Toutes les actions fonctionnent correctement depuis le menu
**Contexte technique:**
- **Fichier modifié:** `keep-notes/components/note-card.tsx`
- **Lignes à supprimer:** ~289-333 (boutons individuels)
- **Lignes à ajouter:** Import et utilisation de `<NoteActionMenu />`
- **Drag handle:** Conserver `md:hidden` (visible uniquement sur mobile)
- **Reminder icon:** Conserver la logique existante (visible si `note.reminder` est dans le futur)
**Tests:**
- ✅ Test visuel: Vérifier qu'il n'y a plus que 1 bouton au lieu de 5
- ✅ Test fonctionnel: Toutes les actions fonctionnent depuis le menu
- ✅ Test contenu: Vérifier que avatar, images, liens, labels, dates sont tous visibles
- ✅ Test desktop: Menu apparaît au hover
- ✅ Test mobile: Menu toujours visible
- ✅ Test régression: Aucune fonctionnalité cassée
**Dépendances:** Story 9.1 (doit être complétée avant)
---
#### Story 9.3: Ensure Content Preservation After Simplification
**Priorité:** Medium
**Estimation:** 2 heures
**Complexité:** Faible
**En tant que:** Utilisateur
**Je veux:** Que tout le contenu de mes notes reste visible et fonctionnel après la simplification.
**Afin de:** Ne perdre aucune information ou fonctionnalité.
**Critères d'acceptation:**
- ✅ Avatar reste en bas à gauche (`bottom-2 left-2`)
- ✅ Avatar reste 24x24px (w-6 h-6)
- ✅ Avatar affiche les initiales du propriétaire
- ✅ Images restent pleine largeur et cliquables
- ✅ Liens HTML restent avec prévisualisation complète (image, titre, description, hostname)
- ✅ Liens HTML restent cliquables
- ✅ Labels restent visibles sous le contenu
- ✅ Labels conservent leur codage couleur
- ✅ Date reste visible en bas à droite
- ✅ Badges Memory Echo restent visibles en haut
- ✅ Tout le contenu conserve son style et comportement actuel
**Contexte technique:**
- **Aucun changement** dans la logique de rendu du contenu
- **Seuls changements** dans l'interface des boutons/actions
- **Vérifier** que tous les composants de contenu restent inchangés :
- `NoteImages` component
- Link preview rendering (lignes 436-461)
- `LabelBadge` components
- Date formatting
- Avatar rendering (lignes 492-504)
**Tests:**
- ✅ Test avec notes contenant des images
- ✅ Test avec notes contenant des liens HTML
- ✅ Test avec notes contenant plusieurs labels
- ✅ Test avec notes avec rappels actifs
- ✅ Test avec notes avec badges Memory Echo
- ✅ Vérifier position avatar sur toutes les tailles d'écran
- ✅ Vérifier que tout le contenu est cliquable et fonctionnel
**Dépendances:** Story 9.2 (doit être complétée avant)
---
#### Story 9.4: Mobile Optimization for Action Menu
**Priorité:** Medium
**Estimation:** 2 heures
**Complexité:** Faible
**En tant que:** Utilisateur mobile
**Je veux:** Accéder facilement aux actions de note sur mon appareil mobile.
**Afin de:** Gérer mes notes efficacement avec des interactions tactiles.
**Critères d'acceptation:**
- ✅ Le bouton menu est toujours visible sur mobile (pas caché au hover)
- ✅ Le bouton menu a une taille minimale de 44x44px (touch target)
- ✅ Chaque item du menu a une taille minimale de 44x44px
- ✅ Le menu est facile à naviguer avec le toucher
- ✅ Le menu se ferme quand on tape en dehors
- ✅ Le menu se ferme après sélection d'une action
- ✅ Toutes les actions fonctionnent correctement sur mobile
**Contexte technique:**
- **Menu button:** `opacity-100` sur mobile (toujours visible)
- **Menu button:** `min-h-[44px] min-w-[44px]` pour touch target
- **Menu items:** `min-h-[44px]` pour touch targets
- **Breakpoint:** `< 768px` pour mobile
**Tests:**
- ✅ Test sur Galaxy S22 Ultra
- ✅ Test sur iPhone SE
- ✅ Test sur différents appareils Android
- ✅ Test en portrait et paysage
- ✅ Vérifier que tous les touch targets sont ≥ 44x44px
- ✅ Vérifier que le menu est facile à utiliser avec une seule main
**Dépendances:** Story 9.2 (peut être fait en parallèle avec 9.3)
---
#### Story 9.5: Keyboard Navigation for Action Menu
**Priorité:** Medium
**Estimation:** 1.5 heures
**Complexité:** Faible
**En tant que:** Utilisateur clavier
**Je veux:** Naviguer et utiliser le menu d'actions uniquement avec le clavier.
**Afin de:** Accéder à toutes les actions sans utiliser la souris.
**Critères d'acceptation:**
- ✅ Je peux Tab jusqu'au bouton menu
- ✅ Le bouton menu a un indicateur de focus visible
- ✅ Je peux ouvrir le menu avec Enter ou Space
- ✅ Je peux naviguer les items du menu avec les flèches
- ✅ Je peux sélectionner une action avec Enter
- ✅ Je peux fermer le menu avec Escape
- ✅ Le focus revient au bouton menu après fermeture
- ✅ Toutes les actions sont accessibles via clavier
**Contexte technique:**
- **Radix UI DropdownMenu** a un support clavier natif
- **Focus indicators:** Visibles (WCAG 2.1 AA)
- **Test screen reader:** NVDA, VoiceOver
**Tests:**
- ✅ Test clavier: Tab, Enter, Space, Arrow keys, Escape
- ✅ Test screen reader: NVDA (Windows), VoiceOver (Mac)
- ✅ Test focus indicators: Visibles et contrastés
- ✅ Test accessibilité: WCAG 2.1 AA compliant
**Dépendances:** Story 9.2 (peut être fait en parallèle avec 9.3 et 9.4)
---
## 🗂 Dépendances Entre Stories
### Ordre Suggéré
1. **Story 9.1** (Create NoteActionMenu Component) - **DOIT ÊTRE PREMIÈRE**
- Raison: Composant fondateur requis par toutes les autres stories
- Blocking: Story 9.2
- Si échoue, toutes les autres stories échouent aussi
2. **Story 9.2** (Replace Multiple Buttons with Action Menu)
- Dépendance: Story 9.1
- Blocking: Stories 9.3, 9.4, 9.5
- Intègre le menu dans le NoteCard
3. **Stories 9.3, 9.4, 9.5** (Content Preservation, Mobile, Keyboard)
- Dépendance: Story 9.2
- **Peuvent être faites en parallèle** après Story 9.2
- Validation et optimisation
### Graph de Dépendances Visuel
```
Story 9.1 (Create NoteActionMenu)
└─> Story 9.2 (Replace Buttons with Menu)
├─> Story 9.3 (Content Preservation)
├─> Story 9.4 (Mobile Optimization)
└─> Story 9.5 (Keyboard Navigation)
```
---
## 🎬 Acceptation Criteria (Critères d'Acceptation Globaux)
### Pour Toutes les Stories
-**Fonctionnalité:** L'interface est simplifiée et toutes les actions fonctionnent
-**Contenu préservé:** Avatar, images, liens HTML, labels, dates restent visibles
-**Tests:** Tests manuels et automatisés passent
-**UX:** L'expérience utilisateur est améliorée (interface moins encombrée)
-**Code:** Le code est propre, bien documenté et suit les conventions
-**Régression:** Aucune régression détectée dans d'autres fonctionnalités
-**Accessibilité:** Navigation clavier et screen reader fonctionnent
### Critères Spécifiques
#### Stories de Simplification UI
- ✅ Interface moins encombrée (5 boutons → 1 menu)
- ✅ Toutes les actions restent accessibles
- ✅ Le contenu n'est pas affecté
#### Stories de Validation
- ✅ Avatar position confirmée (bas à gauche)
- ✅ Images confirmées (visibles et cliquables)
- ✅ Liens HTML confirmés (prévisualisation complète)
- ✅ Labels confirmés (visibles)
- ✅ Dates confirmées (visibles)
---
## 🚨 Risques et Blockers
### Risques Identifiés
1. **Risque de Régression**
- **Description:** La simplification peut casser des fonctionnalités existantes
- **Probabilité:** Faible
- **Impact:** Élevé - pourrait affecter l'expérience utilisateur
- **Mitigation:** Tests approfondis, Story 9.3 dédiée à la validation
2. **Risque de Contenu Masqué**
- **Description:** Par erreur, du contenu pourrait être masqué
- **Probabilité:** Faible
- **Impact:** Élevé - perte d'information pour l'utilisateur
- **Mitigation:** Story 9.3 dédiée à la validation du contenu, checklist exhaustive
3. **Risque de Position Avatar**
- **Description:** L'avatar pourrait être déplacé par erreur
- **Probabilité:** Très faible
- **Impact:** Moyen - confusion utilisateur
- **Mitigation:** Story 9.3 vérifie explicitement la position (`bottom-2 left-2`)
4. **Risque de Mobile UX**
- **Description:** Le menu pourrait être difficile à utiliser sur mobile
- **Probabilité:** Faible
- **Impact:** Moyen - mauvaise expérience mobile
- **Mitigation:** Story 9.4 dédiée à l'optimisation mobile, touch targets 44x44px
### Blockers Actuels
- Aucun blocker identifié
- Tous les fichiers sont accessibles et modifiables
- L'environnement de développement est opérationnel
- Les composants Radix UI sont disponibles
---
## 📅 Timeline Estimée
### Par Story
| Story | Estimation | Notes |
|-------|-----------|-------|
| Story 9.1: Create NoteActionMenu | 2 heures | Fondateur - faire en priorité |
| Story 9.2: Replace Buttons with Menu | 3 heures | Intégration principale |
| Story 9.3: Content Preservation | 2 heures | Validation - peut être fait en parallèle |
| Story 9.4: Mobile Optimization | 2 heures | Optimisation - peut être fait en parallèle |
| Story 9.5: Keyboard Navigation | 1.5 heures | Accessibilité - peut être fait en parallèle |
**Total estimé:** 10.5 heures (1 semaine à 50% de capacité)
### Timeline Suggérée
**Jour 1-2:**
- Story 9.1 (Create NoteActionMenu Component) - 2h
- Story 9.2 (Replace Buttons with Menu) - 3h
**Jour 3-4:**
- Story 9.3 (Content Preservation) - 2h
- Story 9.4 (Mobile Optimization) - 2h
- Story 9.5 (Keyboard Navigation) - 1.5h
**Jour 5:**
- Tests finaux et validation
- Code review
- Documentation
---
## 🎯 Objectifs de Démo (Pour Sprint Review)
Si vous voulez présenter le travail à la fin du Sprint:
1. **Comparaison Visuelle:**
- Screenshot avant (5 boutons visibles)
- Screenshot après (1 menu "...")
- Montrer que le contenu est identique
2. **Démonstration Fonctionnelle:**
- Ouvrir le menu, montrer toutes les actions
- Tester sur desktop (hover)
- Tester sur mobile (tap)
- Tester avec clavier (navigation)
3. **Validation Contenu:**
- Montrer avatar en bas à gauche
- Montrer images visibles et cliquables
- Montrer liens HTML avec prévisualisation
- Montrer labels et dates visibles
4. **Métriques de Succès:**
- Nombre de boutons réduit: 5 → 1
- Contenu préservé: 100%
- Actions accessibles: 100%
- Tests passés: 100%
---
## 📝 Notes pour l'Équipe
### Bonnes Pratiques
1. **Respecter le contenu existant**
- Ne PAS modifier la position de l'avatar (bas à gauche)
- Ne PAS masquer les images, liens HTML, labels, dates
- Seulement modifier l'interface des boutons
2. **Tester exhaustivement**
- Tester avec notes contenant images
- Tester avec notes contenant liens HTML
- Tester avec notes contenant labels
- Tester sur desktop et mobile
- Tester avec clavier et screen reader
3. **Documenter les changements**
- Commenter pourquoi on remplace les boutons
- Documenter que le contenu reste inchangé
- Mettre à jour le changelog
### Outils et Ressources
- **Documentation:** Voir `_bmad-output/design-proposals/design-simplification-proposal.md`
- **Epic:** Voir `_bmad-output/planning-artifacts/epics.md` (Epic 9)
- **Composants UI:** Radix UI DropdownMenu (`@/components/ui/dropdown-menu`)
### Communication
- Signaler immédiatement si du contenu est accidentellement masqué
- Vérifier la position de l'avatar à chaque étape
- Valider que les images et liens HTML restent visibles
---
## 🎉 Critères de Succès du Sprint
Le Sprint sera considéré comme **succès** si:
### Must-Have (Doit être complété)
- ✅ Toutes les 5 stories sont complétées
- ✅ Story 9.1 (NoteActionMenu) est fonctionnelle
- ✅ Story 9.2 (Replace Buttons) est intégrée
- ✅ Avatar reste en bas à gauche (position confirmée)
- ✅ Images restent visibles et cliquables
- ✅ Liens HTML restent avec prévisualisation complète
- ✅ Labels et dates restent visibles
- ✅ Aucune régression fonctionnelle
### Nice-to-Have (Souhaitable)
- ✅ Interface perçue comme moins encombrée (feedback utilisateur)
- ✅ Toutes les actions sont facilement accessibles
- ✅ Amélioration de l'expérience utilisateur mesurable
- ✅ Code propre et maintenable
- ✅ Documentation à jour
### UX Targets
- ✅ Interface moins encombrée (5 boutons → 1 menu)
- ✅ Toutes les actions accessibles en ≤ 2 clics/taps
- ✅ Menu facile à utiliser sur desktop et mobile
- ✅ Navigation clavier complète et fluide
---
## 🔄 Status Actuel
🟡 **En préparation** - Sprint créé, prêt à commencer
**Prochaine étape:**
1. Révision du Sprint avec l'équipe ou les parties prenantes
2. Affectation des stories aux développeurs
3. Création des branches git si nécessaire
4. Commencement avec Story 9.1 (Create NoteActionMenu)
**Estimation de début:** Immédiatement après validation
---
*Créé le 2026-01-17 pour simplifier l'interface NoteCard tout en préservant tout le contenu existant.*