בעיית הממשק השקט
המשתמש לוחץ על 'שמירה', אבל הממשק נשאר שקט — הוא ממתין לאישור. ללא אישור, הוא שומר שוב, יוצר כפילויות ומבזבז זמן. התראה מסוג toast פותרת זאת ב-200 מילישניות. אנו מעצבים מערכות התראות כבר למעלה מחמש שנים — במהלכן פיתחנו רכיבים לעשרות פרויקטים, החל מפאנלי ניהול ועד SaaS בעומס גבוה. הניסיון שלנו מבטיח שההתראות לא רק מושכות ויזואלית אלא גם נגישות (WCAG 2.1) ואינן פוגעות ב-Core Web Vitals.
Toast לעומת Snackbar
Toast ו-snackbar הן התראות זמניות שמופיעות מעל הממשק ונעלמות אוטומטית. ההבדל טמון במקור שלהן: snackbar הוא מונח מ-Material Design, toast מגיע מפיתוח מובייל (Android). ברשת, מונחים אלה משמשים לעיתים קרובות כמילים נרדפות, אך אנו מבחינים: toast ללא כפתורים, snackbar עם כפתור פעולה אופציונלי.
| מאפיין | Toast | Snackbar |
|---|---|---|
| מקור | Android Toast | Material Design |
| כפתור פעולה | לא | כן (אופציונלי) |
| שימוש טיפוסי | אישור תוצאה | פעולה הפיכה (למשל, 'בטל') |
| זמן תצוגה | 4-5 שניות | 6-8 שניות |
מתי להשתמש ב-Toast
Toast הוא אישור, לא אזהרה. הוא מודיע על תוצאה של פעולה שהמשתמש כבר ביצע. מתאים ל:
- 'הקובץ נשמר' לאחר Ctrl+S
- 'הקישור הועתק' לאחר לחיצה על העתקה
- 'המשתמש נמחק' לאחר אישור מחיקה
- 'השינויים הוחלו' לאחר שליחת טופס
לא מתאים ל:
- שגיאות קריטיות הדורשות תשומת לב (יש להשתמש במודאל או בשגיאה מוטבעת)
- אזהרות לפני פעולה (יש להשתמש בתיבת אישור)
- הודעות ארוכות עם מספר פעולות
בחירת מיקום ל-Toast
מיקומים סטנדרטיים: פינה ימנית עליונה, מרכז עליון, פינה ימנית תחתונה, מרכז תחתון. הבחירה תלויה בפלטפורמה:
- מחשב שולחני: פינה ימנית עליונה — הנפוץ ביותר, אינו מסתיר את הפעולה המרכזית
- מובייל: מרכז תחתון — קרוב יותר לאגודל, אינו מכסה את הכותרת
המיקום נבחר פעם אחת עבור כל האפליקציה ואינו משתנה. ערבוב מיקומים מבלבל את המשתמשים. במחשב שולחני, אנו בודקים על פריסות אמיתיות כדי להבטיח שה-toast לא מכסה אלמנטים קריטיים. זה מפחית פניות לתמיכה וחוסך בתקציב הפרויקט.
אנטומיה ווריאציות
ארבעה סוגים סמנטיים:
| סוג | אייקון | צבע (בהיר) | מתי |
|---|---|---|---|
| הצלחה | ✓ | green-600 | הפעולה הושלמה בהצלחה |
| שגיאה | ✗ | red-600 | הפעולה נכשלה |
| אזהרה | ⚠ | amber-600 | הושלם עם הסתייגויות |
| מידע | ℹ | blue-600 | מידע ללא הערכה |
מבנה הרכיב:
- אייקון משמאל (20×20 פיקסלים)
- טקסט ההודעה (14 פיקסלים, מקסימום 2 שורות)
- אופציונלי: כפתור פעולה (טקסט, 'בטל', 'פרטים')
- כפתור סגירה × (אופציונלי, תלוי בתבנית)
- פס התקדמות בתחתית (מציג זמן שנותר, אופציונלי)
כיצד התזמון משפיע על התפיסה?
- סגירה אוטומטית: 4–5 שניות להודעות קצרות, 6–8 שניות ל-toast עם כפתור פעולה
- Toast שגיאה: 8–10 שניות או ללא סגירה אוטומטית (המשתמש סוגר ידנית)
- אנימציית כניסה: החלקה + דהייה, 200–250 מילישניות
- אנימציית יציאה: דהייה, 150 מילישניות
הטיימר מתאפס במעבר עכבר — זה סטנדרט לפי Material Design Snackbar. תזמונים שגויים גורמים למשתמשים לא לקרוא את ההודעה או להתלונן על פולשניות. אנו בוחרים תזמונים בנפרד לכל תרחיש — זה מפחית את שיעור הנטישה ב-15–20% לפי המדידות שלנו. בפרויקט אחרון לפלטפורמת SaaS גדולה, הפחתנו פניות תמיכה הקשורות להתנהגות בלתי צפויה ב-40% לאחר יישום מערכת toast מתוזמנת היטב.
כיצד לערום מספר התראות?
כאשר מספר התראות מופיעות בו זמנית, היגיון הערימה חשוב:
- חדשות מופיעות למעלה (או למטה, תלוי במיקום)
- מקסימום 3–4 גלויות בו זמנית, השאר בתור
- תור משותף, ללא שכפול של הודעות זהות
מידע נוסף על קיפול
ספריית sonner עדיפה על react-hot-toast בתמיכה מובנית בקיפול: מספר toasts מתקפלים לערימה המציגה את המספר. זה קומפקטי ולא מסיח את הדעת.תהליך העיצוב שלנו למערכות התראות: 5 שלבים
- ניתוח תרחישים — איסוף כל המקומות בממשק שבהם נדרשות התראות וסוגיהן.
- עיצוב — יצירת מוקאפים ב-Figma לכל ארבעת הסוגים, הסכמה על מיקום ותזמונים.
- יישום — כתיבת קוד ב-React/Vue/Angular עם TypeScript, תמיכה בכפתורים אופציונליים וקיפול.
- בדיקות — בדיקה ברזולוציות מובייל ומחשב שולחני, נגישות, Core Web Vitals.
- תיעוד — מסירת רכיבי Figma, מפרטי אנימציה, כללי שימוש.
מה אנו מספקים
אנו מספקים:
- רכיבי Figma של כל 4 הסוגים (הצלחה, שגיאה, אזהרה, מידע) במספר וריאציות (עם כפתור, עם פס התקדמות)
- מפרטי אנימציה (משך, האטה, עיכובים)
- קוד ב-React/Vue/Angular עם תמיכה ב-TypeScript
- תיעוד על כללי שימוש ובחירת סוג
- בדיקות ברזולוציות מובייל ומחשב שולחני
צרו קשר — נשלח דוגמאות מהפרויקטים שלנו. נעריך את המשימה שלכם ונציע פתרון סוהר. כל הרכיבים נבדקו לנגישות (WCAG 2.1) ו-Core Web Vitals. קבעו ייעוץ כדי לדון במקרה שלכם.
לוחות זמנים משוערים
עיצוב מערכת toast/snackbar (4 סוגים × כל המצבים, וריאציות עם כפתור, ערימה, מובייל) — מיום עד 3 ימים. העלות מחושבת בנפרד לאחר בריף. קבלו ייעוץ — כתבו לנו!