2e9bd2ab60
Nella Timeline — la vista di default — lo stato di un task era solo un cerchietto colorato: ambra col puntino da 1.5px per "in corso", violetto col puntino da 2px per "in revisione". A 20px sono lo stesso oggetto. Solo "in revisione" aveva un title; gli altri tre stati non avevano ne' testo, ne' tooltip, ne' aria-label — l'opposto della regola UX 3 del design system, che chiede colore + testo, mai colore da solo. Il punto pero' non era la somiglianza fra i due colori. "In revisione" non significa quello che dice5547e55, che lo descriveva come controllo qualita' interno: nel flusso reale vuol dire "consegnato, aspetta l'OK del cliente". E' uno stato che richiede un'azione, e per questo un cerchietto muto era il problema vero. - Le quattro icone si distinguono per forma, non solo per colore, quindi reggono anche in bianco e nero e con un daltonismo: vuoto -> punto -> spunta vuota -> spunta piena. La spunta compare a lavoro finito e si riempie a lavoro confermato. - Pill di testo solo su "in corso" e "in revisione". "Da fare" e' un cerchio vuoto e "fatto" ha il titolo barrato: etichettarli aggiungeva rumore, non informazione. - Il conteggio dei task in attesa sta nell'header della fase, quindi si legge anche a card chiusa. Serve davvero: l'admin puo' forzare una fase su "completata" dalla select, e in quel caso la card parte collassata con dentro la richiesta. - Legenda + micro-copy sopra entrambe le viste: chi revisiona, e che ogni pagina include un giro di revisione — l'informazione commerciale che il cliente non aveva da nessuna parte. Rimanda alla chat della fase, che esiste gia'. - Colonne del kanban cliente colorate con le stesse tinte dell'icona in Timeline: prima erano quattro colonne grigie identiche. - Icona aria-hidden + sr-only, cosi' lo screen reader annuncia lo stato anche sui due che non portano la pill. La barra di avanzamento non e' stata toccata: un task in revisione conta come uno in corso, cioe' zero. Cambia il tipo di lavoro, non l'avanzamento — gonfiare la percentuale le avrebbe fatto dire una cosa che il contatore "x di y task" smentiva una riga sotto. Visual e copy in un solo file, e la legenda si genera da TASK_STATUSES: un quinto stato non lascera' indietro una lista scritta a mano. Stessa disciplina di5547e55, nata proprio perche' due liste fisse avevano fatto sparire dei task senza un errore. Nessuna migration: e' solo UI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
50 lines
1.6 KiB
TypeScript
50 lines
1.6 KiB
TypeScript
"use client";
|
|
|
|
import { useState, type ReactNode } from "react";
|
|
import { ClientKanban } from "./ClientKanban";
|
|
import { TaskStatusLegend } from "@/components/client/TaskStatusIndicator";
|
|
import type { ClientView } from "@/lib/client-view";
|
|
|
|
export function PhaseViewToggle({
|
|
timelineView,
|
|
phases,
|
|
token,
|
|
}: {
|
|
timelineView: ReactNode;
|
|
phases: ClientView["phases"];
|
|
token: string;
|
|
}) {
|
|
const [view, setView] = useState<"timeline" | "kanban">("timeline");
|
|
|
|
return (
|
|
<div>
|
|
<div className="flex items-center justify-between mb-6">
|
|
<h2 className="text-lg font-bold text-foreground tracking-tight">Fasi del Progetto</h2>
|
|
<div className="flex items-center gap-1 bg-muted rounded-lg p-1">
|
|
<button
|
|
onClick={() => setView("timeline")}
|
|
className={`px-5 py-1.5 rounded-md text-[11px] font-semibold transition-all ${
|
|
view === "timeline" ? "bg-card text-foreground shadow-sm" : "text-muted-foreground hover:text-foreground"
|
|
}`}
|
|
>
|
|
Timeline
|
|
</button>
|
|
<button
|
|
onClick={() => setView("kanban")}
|
|
className={`px-5 py-1.5 rounded-md text-[11px] font-semibold transition-all ${
|
|
view === "kanban" ? "bg-card text-foreground shadow-sm" : "text-muted-foreground hover:text-foreground"
|
|
}`}
|
|
>
|
|
Kanban
|
|
</button>
|
|
</div>
|
|
</div>
|
|
|
|
{/* Fuori dallo switch: gli stati sono gli stessi in entrambe le viste */}
|
|
<TaskStatusLegend />
|
|
|
|
{view === "timeline" ? timelineView : <ClientKanban phases={phases} token={token} />}
|
|
</div>
|
|
);
|
|
}
|