פוסט 17: מסמך סטנדרטים לעיצוב ופיתוח של ממשק משתמש

28 בנובמבר 2009


זהו פוסט המשך לפוסט הקודם, אשר שייך לסדרת הפוסטים בנושא UI . בפוסט זה אפרט שלבים וטיפים שיעזרו בבניה של מסמך סטנדרטים של ממשק משתמש.



GUI Standards Document


בפרויקטים גדולים של מערכות תוכנה עם ממשקי משתמש רבים קיים צורך בכתיבת מסמך סטנדרטים בתחילת הפרויקט. מסמך זה משמש את כל הגורמים המעורבים בעיצוב-פיתוח GUI: מנתחי מערכות (System Analysts), מעצבי מודולים (SW Designers) ומתכנתים (האנשים שבפועל בונים GUI ומקודדים לוגיקת קליינט).


מסמך סטנדרטים הנו מרכיב הכרחי בכל שלבי הפרויקט. לרוב עיצוב ראשוני (ובחלק מהמקרים סופי) של מסכי המערכת נעשה ע"י מנתחים. מכוון שהם נמצאים בחזית, ז"א מול לקוח. חלק מתהליך הניתוח והאפיון של הפרויקט הנו עיצוב UI שנעשה בשיתוף עם לקוח (ישנם מקרים חריגים שלקוח לא מעורב בתהליך הנ"ל). בפרויקטים גדולים מעורב מספר גדול של עובדים הקשורים לעיצוב ופיתוח UI. על מנת לקבוע סדר עבודה ותקנות ברורות שיעזרו לתהליך גם מבחינת צמצום זמני האפיון-פיתוח וגם מבחינת השמישות ה- GUI.


תרשים עם פעולות שיכולות לעזור בכתיבת המסמך והטמעתו:





  1. קבל את התחייבות הארגון לעבור דרך תהליך הסטנדרטיזציה: במילים אחרות קבל OK של הממונים שלך. חשוב שגם האנשים שיהיו צרכני המסמך יבינו את חשיבותו (אף אחד לא אוהב לבזבז זמן על משהו שלא ישמש אף אחד);

  2. גייס תומכים לתהליך הסטנדרטיזציה: גייס את דעת הקהל. יתכן מצב שמספר עובדים לא יקבלו בהבנה את המסמך, יהיו אמירות כמו: "למה אנו צריכים את הדברים האלה?", "אנו יודעים לעבוד גם ללא המסמך!", "עד עכשיו הסתדרנו ללא המסמך!" וכו'. – לא אציג כאן את דרכי השכנוע, מאמין שמי שלוקח על עצמו את התפקיד של מהנדס UI/UX ומוכן לכתוב את המסמך יידע לשכנע בצורה טובה.

  3. אסוף מידע: בצע איסוף מידע ממשתמשי הקצה (לקוח), על סביבת העבודה (באתר לקוח), תהליכים עסקיים, זרימת עבודה ומשימות, אסטרטגיה ארגונית וכו'. [זמנים: 2-3 ימים בממוצע]

  4. הגדר סוגי הסטנדרטים הנחוצים: בד"כ קובעם סטנדרטים עבור: מודל ארכיטקטוני של קליינט (MVC, MVP OR MVVM), סוגי הפקדים עבור סוגים שונים של מידע (Data Models, Data Sources), תקן של תבניות מידע קבועות בפרויקט (Data Templates), כללי נווט בין מסכים (מפת המסכים), מבנה של מסך ראשי, הכוונה למבנה כללי של טפסים, סוג ה- GUI (Tabular, Single Window, MDI Window, Multiple Window). לווה כל בדוגמאות. [זמנים: 5-10 ימים בממוצע]

  5. הגדר מספר מסכים שיעוצבו בהתאם לסטנדרטים: בד"כ לא ניתן להחיל עיצוב לפי סטנדרטים על כל המסכים במערכות גדולות, השתדל לתכנן לפחות 85% מהמסכים בהתאם לסטנדרט שקבעת. הדבר יאפשר שמירה על "עקרון העקביות" שמאוד חשוב.

  6. לווה מסמך בדוגמאות: השתדל לתת כמה שיותר דוגמאות לעיצוב המסכים, כסה מספר מקסימאלי של סוגי הפקדים נתמכים בהתאם למקרי השימוש. ספק דוגמאות מסוג "עיצוב מומלץ" ו"עיצוב לא מומלץ". אנשים שיעצבו מסכים בהתאם למסמך יפנו יותר לדוגמאות מאשר לטקסט יבש.

  7. בנה תבניות כלליות: בנה מספר תבניות מוכנות של מסכים, טפסים, פאנלים, מסגרות, סטים של פקדים וכו'.ברוב מערכות מידע יש דמיון בין טפסי המידע (Win-Forms), השוני הוא בכמות, סוג ומיקום הפקדים (כמובן יש גם שוני בהתנהגות המסכים). תבנית מוכנה יכולה לצמצם זמני עבודה, מעצב המסך יוכל להשמיש תבנית לצרכיו (לרוב ייעשה Drag-and-Drop וישנה את הפקדים, סגנון וסטנדרט יישמרו).

  8. שתף ועדה טכנולוגית בהחלטות עיצוביות והצג בפניה את המסמך: הצג מסמך בפני פורום מקצועי-טכנולוגי. שתף פורום בהחלטות עיצוביות שנתקבלו בעת כתיבת המסמך. במידע ויהיו הערות לשינוי/תיקון דברים במסמך – עדיף שיהיו בשלב זה ולא בשלב שלאחר ההפצה של המסמך. [זמנים: 3-4 ימים בממוצע כולל DR]

  9. הפץ מסמך בין גורמים רלוונטיים ובצע הדרכות: לאחר אישור הגורמים הרלוונטיים (אחרי שמסמך אושר בוועדה טכנולוגית) הפץ מסמך בין אנשים שיעצבו ויפתחו מסכים. מכוון שאנשים לא אוהבים לקרוא מסמכים עדיף לבצע הדרכה במקביל להפצה. ההדרכה לא יכולה לכסות את כל הנושאים ולא יכולה לתת תשובות לכל הבעיות שיצוצו, היא תאפשר הכנסה של אנשים לעניין המסמך והם ייחשפו לדברים עיקריים במסמך. [זמנים: כתיבה של מסמך: 1-3 שבועות בממוצע, הדרכות: 2-7 ימים בממוצע]

  10. יישם והטמע סטנדרטים: זוהי מהות המסמך, אחרת זה יהיה עוד נייר מיותם בסדרה אינסופית של מסמכים שאף אחד לא מתייחס אליהם. החל מרגע ההפצה של המסמך כל מי שמעורב בעיצוב-פיתוח המסכים "אמור" להיצמד אליו, ז"א להשתמש באותו סט פקדים, באותן טכניקות, באותו סגנון (Look-and-Feel), באותם כללים של שמישות וכו'. [זמנים: 2-4 שבועות בממוצע]

  11. וודא הטמעה של סטנדרטים: בצע ביקורות תוצרים (Design and Code Review). וודא שמסכים מעוצבים בהתאם לסטנדרט שנקבע. זה מתקשר לסעיף הקודם – תן משמעות לתקנים שאליהם התחייבת. [זמנים: אין הגבלה, מתבצע לאורך כל הפרויקט]


  12. עדכן מסמך בהתאם לשינויים המתבקשים: מסמך סטנדרטים הנו ייצור חי. מפעם לפעם יתכנו שינויים בעיצוב המסכים שיידרשו שינוי בסטנדרט מסוים. במקרים מסוימים נגלה שמשהו מהמסך לא מתאים או לא עומד במבחן הזמן. לאחר שינוי המסמך דאג להפיצו בין גורמים רלוונטיים ובצע הדרכות (חזרה לסעיף 9 ולרוב גם ל- 8).


 


קווים מנחים בכתיבת המסמך



  • זכור למי מיועד המסמך: רמת הפירוט הטכני וכלל התכנים צריכים להיות מותאמים לאנשים בעלי רמה טכנית שונה. במידה ומסמך מיועד למנתחי מערכות וגם למפתחים, התאם לרמה למנתחים אשר לא בקיעים בפרטים הטכניים ספציפיים של פיתוח. אם מסמך מיועד למפתחי התוכנה אפשר לספק פירוט טכנולוגי יותר מורחב.

  • עקביות: אחד העקרונות החשובים בעיצוב UI. ממשק התוכנה חייב להיות עקבי. המשתמש המודרני מצפה "להיכנס לעניינים" תוך זמן קצר. אם נשמור על עקרון העקביות בכל מסכי המערכת המשתמש יוכל לבצע פעולות בצורה אינטואיטיבית, על סמך הניסיון מתוכנות קודמות ו/או על סמך מה שהוא למד לעשות במסכים ראשונים במערכת החדשה. למשל: המשתמש התרגל לפתוח חלון מודאלי (Dialog-Window) עם פרטים מורחבים של רשומה ע"י לחיצה כפולה על שורה בטבלה (Data-Grid), אם מסך מסוים יאפשר פתיחת טופס בלחיצה אחת – לרוב זה יעצבן את המשתמש ופעולה שלעצמה אינה בטיחותית. המסמך חייב לכלול הסבר כיצד לשמור על עקביות, עקביות בכמה רבדים: מיקום כפתורי פעולה, יישור שדות הזנה, סוגי פקדים (בהתאם לסוגי מידע שהם מקבלים), מתי עושים קליק-כפול ומתי קליק-אחד, כיצד להציג הודעות שגיאה, כיצד להתריע על שגיאות וולידציה וכו'. תאר עקביות בסגנון (Styling) או בעיצוב הטפסים: שימוש בצבעים לרקעים, צבעי אזהרה/שגיאה, צבעי הפונטים, גדלים של פונטים ואייקונים. תאר כיצד לקבוע את פריסת הפקדים בטופס, תן המלצות לגבי החלוקה (טאבולארית – Tabular GUI, דף נגלל, אזורים מתקפלים וכו'). במידה ושפת הממשק הנה עברית התייחס לזרימת הטקסט הנכונה (Right-to-Left Flow Direction) – מאוד חשוב שמפתחים ידעו לקבוע מראש את זרימת המסך מימין לשמאל בשלבים מוקדים של פיתוח, אם יתחילו פיתוח הטפסים עם כוון LTR יהיה מאוד קשה לשנות את הזרימה אח"כ. זכור לבצע שלב 11 (וודא הטמעה של סטנדרטים) מפרק קודם – בצע DR-ים (Design Review) לתוצרים של אנשים, וודא שעקרון העקביות נשמר.

  • קבע סטנדרטים והצמד אליהם: בהמשך לסעיף הקודם, לרוב צריך לקבוע סטנדרט של סוגי הפקדים (ספק דוגמאות לשימוש בסט הפקדים של הפרויקט – Controls' Toolbox), סטנדרט של סגנון (פורט בסעיף הקודם). סטנדרט של איכות (מאוד חשוב) – כיצד לוודא עיצוב ופיתוח המסכים מתבצע בהתאם לסטנדרטים שקבענו, ספק To-do List לביצוע בדיקות הנ"ל. קבע מודל עבודה – מיהם האנשים שיהיו מעורבים בעיצוב ופיתוח מסכים, מי האנשים שיעשו ביקורת לתוצרים, מיהם אנשי הקשר שלך (אתה לא יכול להתפצל לכמה אנשים כדי לתמוך בכולם).

  • על תמציא גלגל מחדש: למד מניסיונם של אחרים, השתמש בסטנדרטים המקובלים בשוק התוכנה או במערכות דומות. ראה דוגמאות של מסמכי סטנדרטים ברגונך (במידה וקיימים), השתמש בדוגמאות ממקורות אחרים. אם מפתחים יישום לשימוש בסביבת המשרד – ניתן לחכות יישומי אופיס או יישומים אחרים המוכרים למשתמש שלך (רבים מכירים ממשקים של MS Office, רבים משתמשים בקיצורי סטנדרטיים, זכור לא לדרוס קיצורי דרך של מערכת הפעלה).

  • דוגמאות: לווה מסמך בכמה שיותר דוגמאות מוחשיות. השתמש בצילומי מסך, מבנה טפסים, תבניות, שימוש בסגנונות. ספק דוגמאות מסוג "תעשה" ו"אל תעשה". לפי ניסיוני, רוב האנשים פשוט לא קוראים מלל (מתכנתים אף שונאים מלל, לעומתם מנתחי מערכות יעדיפו משהו כתוב), לכן דוגמאות גראפיות תהיינה מאוד יעילות.

  • כללי נווט: הגדר כללי נווט ברורים בתוך המסכים והחוצה. באילו מקרים ייפתח חלון מודאלי ובאילו מקרים נעדיף למקם תוכן הטופס בתוך המסך. כיצד מנווטים בתוך המסך, קיצורי דרך של מקלדת, זרימת העבודה בתוך המסך, שימוש ב- Wizards. ספק מפת מסכים לדוגמא, המפה תכלול דוגמאות של "הכלה" (Screen Composition) ודוגמאות של נווט (Screen Navigation).

  • שפת הממשק: הכוון משתמשים לשפה משותפת, בנה מילון עסקי עבור UI, עדכן מילון מפעם לפעם. חשוב שכל מי שמעורב בעיצוב ופיתוח המסכים ישמור על עקביות גם בתגיות (Labels), בהודעות (Error/Info/Warning Messages). הנחה משתמשים להשתמש באותו סגנון בהודעות, כפתורי פעולה אחידים (האם להשתמש במילים כמו "שמור" או "שמירה", "פתח" או "פתיחה", "חפש" או "חיפוש"). מילון עסקי זוהי שפה ייחודית של ארגון, אבל גם כאן אני לא ממליץ להמציא גלגל מחדש, מילות צווי ברוב התוכנות הנן זהות. דאג להדריך "עורכי דין" להשתמש במלל קצר, אפקטיבי ופרודוקטיבי ("עורכי דין" או "בלשנים" – אנשים שמכניסים טקסטים ארוכים ומסורבלים בממשקי משתמש, בד"כ מנסחים הודעות בשפה גבוהה שלא באה מעולם המחשבים).

  • סט פקדים (UI Widgets): הכן רשימת פקדים ופרט מקרים בהם יש להשתמש בפקד מסוג מסוים. סט יכול להכיל פקדים מיוחדים (Customized Controls), ייחודיים לפרויקט, אשר נבנו לפונקציונאליות עסקית ספציפית (למשל: גרפים מיוחדים, שעוני דשבורד, פאנלים עם תבניות מוכנות, Grid Tables מיוחדים, סיירי מדיה וכו'). ספק דוגמאות ויזואליות (Screen Snapshots) למקרי שימוש ולאופני שימושי. אין צורך לפרט על פקדים סטנדרטיים כגון: תוויות, תיבות טקסט, תיבות בחירה (קומבו), רשימות תקניות (List Box) ועוד פקדים שלרוב ידוע כיצד להשתמש בהם.

  • סגנון של טפסים (Look-and-Feel): כפי שהסברתי בסעיפים קודמים, חושב להנחות מהו הסגנון של הממשק, מהם צבעי אזהרה, ידיעה, שגיאות. אם יש תקציב לגרפיקאי שיעשה את עיצוב הממשק, חושב להראות לאנשים מהו העיצוב הסופי המצופה. במקרה שמודל העבודה על המסכים "מעצב UI" + "מתכנת קליינט" (לרוב מקובל בעבודה עם WPF), יש לקבוע תחומי אחראיות לתוצרים ותחומי החפיפה; לרוב גרפיקאי יעצב תבניות, סגנונות, אייקונים ולוגואים (בהתאם למבנה המסך הראשי), המתכנת חייב לדעת לא "לפלוש" לאזורים של מעצב (למודל הנ"ל אקדיש פוסט נפרד). לרוב אנשים שמעורבים בעיצוב-פיתוח UI ירצו לדעת כיצד התוצרים שלהם ייראו בעיצוב הסופי, במקרים אלה אפשר לספק להם תבנית גרפית שאותה "ילבישו" על המסכים שלהם. ללא קשר לתוצרים של גרפיקה, חושב להסביר לאנשים כיצד לשמור על אחידות עיצובית כדי לתת Look-and-Feel אחידים לאורך כל המסכים.

  • נגישות ושמישות (Accessibility and Usability): קבע כללים עבור נגישות ה- GUI בטפסים של הפרויקט. הסתמך על סביבת העבודה אצל לקוח: קהל היעד (האם יש מוגבלות פיזיות כלשהן אצל משתמשי הקצה), תצורת המחשב (גודל המסך, סוג המסך, איכות המסך, מערכת הפעלה, כוננים וכו'). קבעי כללים עבור שמישות. ציין כיצד לוודא שטופס שמיש וחסכוני מבחינת הפעולות (כיום מושג "GUI ארגונומי" מאוד נפוץ).

  • הדרכה: (סעיף 9 בתרשים) במהלך ההדרכה של צרכני המסמך מומלץ להראות כיצד בונים מסך. הסבר כיצד לחסוך פעולות מיותרות, הראה כיצד להשתמש בתבניות מוכנות, הראה כיצד ייראו למקם פקדים בהתאם לזרימת המסך/שפה. ציין נקודות חשובות במסמך שעליהם לא ניתן לדלג.

  • בצע DR (Design Review): חשוב לקבל חוות דעת מגורמים מוסמכים לגבי המסמך לפני ביצוע הדרכות והפצה. בצע DR לעיצוב של מסכים של צרכני המסמך (סעיף 11 בתרשים עליון).

  • עקרונות וקווים מנחים לעיצוב:


  1. מבנה: הצע מבנה היררכי, קבץ פקדים לתוך מסגרות בהתאם פונקציונאליות משותפת, הוצא פקדים משותפים למסגרות שחופפות למסגרות נושאים. אסור שלמשתמש תהיה צריכה להיות תחושה שממשק מאיים ועמוס.

  2. פשטות: זהה תהליכים כללים וראשיים, הגדר אזורי הפעלה לתהליכים אלה, השתמש במודל מופשט, סדר פקדים והיררכיה בצורה נוחה, הגדר קיצורי דרך של מקלדת לפעולות נפוצות.

  3. שקיפות: הצג את מירב האופציות הזמינות באותו המסך (ללא עומס חזותי), אם עמוס – חלק למספר חוצצים/אזורים. אל תציע מיליון דרכים לביצוע של אותה פעולה, תרגיל משתמש שפעולה כלשהי מתבצעת במקום מסוים (שים לב שב- MS Word 2007 כל הפעולות מתבצעות רק דרך Ribbon ולא כמו ב- MS Word 2003 ניתן היה לבצע פעולה גם דרך סרגל כלים וגם דרך תפריטים).

  4. משוב: למשתמש צריכה להיות תחושה שבכל שלב הוא יודע מה אמור לקרות, הוא מצפה לתגובות מסוימות של הממשק. ספק משוב רלוונטי כתוצאה מפעולת המשתמש, אל תציג הודעה עם תוכל מבלבל או לא קשור לפעולה שבעקבותיה הוצגה ההודעה. ספק חיווי ברור למרחש, גם אם זה מוריד מ"סקסיות המסך".

  5. גמישות: בנה ממשק גמיש וסלחני. אל תטריח משתמש בפעולות מיותרות. השתדל לספק לו שירות מודרני שיקל על עבודתו (כמו למשל השלמות אוטומטיות של טקסטים וגיבוי אוטומטי). תאפשר לבצע שגיאות בלי להציג הודעות אימה (כמה דוגמאות לכותרות של שגיאות מפחידות ומיותרות: Fatal Error, Unrecoverable Error, Unknown Error). למרות שזה לא תמיד קל מבחינה תכנותית, השתדל לתת אופציה של Undo-Redo (תבנית Memento).

  6. שימוש חוזר: עשה שימוש חוזר ברכיבי ממשק (גם פנימיים וגם חיצוניים). הדבר יאפשר תחזוקה קלה ומשתמש יתרגל לאותו סגנון העבודה, יכיר מסכים חדשים ביתר קלות.


קבע קווים מנחים לעיצוב אינטואיטיבי, נקי, שתף אנשים בדוגמאות ובקש מהם לשתף פעולה ביניהם. הגדר מהו עיצוב אינטואיטיבי (כיצד לגרום למשתמש ללא הדרכה מעמיקה להפעיל מסך על סמך ניסיונו הקודם ועל סמך ניסיונות מהפעלת מסכים אחרים במערכת). הנחה לגבי עיצוב חסכוני, אסור לעצב מסכים עמוסים. קבע חלוקה לרמות ולחוצצים (Tabs) בהתאם לעומס של פקדים.



 


דוגמא למבנה של מסמך



  1. תוכן עניינים

  2. הסבר על מסמך (כולל מדריך לשימוש נכון במסמך – אופציונאלי)

  3. מילון מונחים (מושגים טכניים שנפגשים במסמך – אופציונאלי)

  4. מבנה של חלון ראשי (תשתית)

  5. שירותי תשתית UI (השירותים ברמת GUI שכל מודול יכול לצרוך מתשתית, כמו: שירותי הדפסה, איות, עזרה, חיפוש, סרגלי כלים, תפריטים וכו')

  6. מפת מסכים (לרוב בתחילת הפרויקט לא ידוע אילו מסכים יהיו, המפה תכלול מסכי תשתית וחלק מהמסכים הראשיים, עיקרה לתת הנחייה כיצד לבנות מפות פר מודול)

  7. רשימת סטנדרטים (פירוט מלא + דוגמאות)

  8. רשימת GUI Widgets (סט פקדים של הפרויקט + דוגמאות שימוש)

  9. סגנון גראפי (ראה הסבר למעלה לגבי Look-and-Feel)

  10. רשימת תבניות מוכנות (כמובן מלווה בדוגמאות)

  11. מילון עסקי עבור UI (רשימה עם טקסטים עבור כפתורים, תוויות והודעות)

  12. מדריך לבניה נכונה של מסך (עם דוגמא ממשית מתוך הפרויקט)

  13. משאבים משותפים (מקשי קיצורי דרך גלובאליים, טבלאות מערכת, גלריית אייקונים/תמונות, מילוני לוקליזציה, הודעות שגיאה, לוגרים ועוד)

  14. דוגמאות "עשה" ו"לא עשה" (צילומי מסך עם הסברים)

  15. רשימת טיפים ועקרונות מנחים

  16. רשימה של אנשי קשר ואחראים (לפני סגירת המסמך קבע מיהם האנשים שירכזו את נושא ה- UI ויהיה בקשר איתך)

  17. מקורות

מקווה שדברים אלה יעזרו לכם בתכנון וכתיבה של מסמך סטנדרטים ובכלל בתפיסה של UI נכון. המון אנשים חושבים שהם "יודעים" איך לעצב/לפתח מסכי GUI על מסך תחושה אישית ועל סמך ניסיונם בהפעלה של תוכנות אחרות, אין זה אומר שהם באמת יודעים כיצד לעשות זאת. מסמך זה ייתן להם קו מנחה ברור כיצד להתקדם בעיצוב המסכים בפרויקט תוכנה, הוא ישמש גם צוות אפיון וגם צוות פיתוח, יהווה הסכם כתוב לגבי תקן איכות (סטנדרט) בעיצוב UI.




בהצלחה 😉



מקורות מידע נוספים:


http://www.ambysoft.com/essays/userInterfaceDesign.html


http://www.fltk.org/hig.php


http://www.humanfactors.com/downloads/aug04.asp


http://msdn.microsoft.com/en-us/library/aa217660(office.11).aspx


http://www.pbdr.com/guistd/index.htm


http://mip-site.lsec.dnd.ca/qsd_current_version/sw_eng/di/ui_guidance.htm


http://www.classicsys.com/css06/cfm/article.cfm?articleid=20



ראו בהמשך פוסט על "עיצוב ממשק משתמש מודרני", אשמח לקבל הערות/תיקונים לגבי הפוסט. לרשימת הפוסטים של הסדרה לחצו כאן.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

2 comments

  1. Tovi26 בפברואר 2010 ב 22:03

    Good afternoon. Every day you may make progress. Every step may be fruitful. Yet there will stretch out before you an ever-lengthening, ever-ascending, ever-improving path. You know you will never get to the end of the journey. But this, so far from discouraging, only adds to the joy and glory of the climb. Help me! It has to find sites on the: Does tetracycline work for acne. I found only this – tetracycline active ingredients. New medicamentosa of computer is not moved as it is quinolone, tetracycline. When then in acne, the acid is checked, tetracycline. With respect :eek:, Tovi from Latvia.

    Reply
  2. Gavin25 במרץ 2010 ב 4:44

    Good afternoon. Wonderful and informative web site. I will recomend this site. Excelent work. Help me! Looking for sites on: Clock glass stained wall. I found only this – buy wall clock. He solidified that those of static awareness prices hydrolyse establish responsible businesses of court, wall clock. It is just commonly about the context of people a pet feels not already, wall clock. With love ;-), Gavin from Malaysia.

    Reply