The
Singleton pattern is very well known to .Net developers, especially the static implementation.
Lately I have encountered several versions of the
generic Singleton, among them the one described in
Arnon's post.
However, there is one possible pitfall to this approach, as it makes this code possible:
Singleton<MyClass> obj = Singleton<MyClass>.Instance;MyClass obj2 = new MyClass();While I personally like the idea of having the freedom to use the same class in two different ways throughout the application, I know some people like their Singletons - well, single.
On the other hand, if you write a class from the start as a Singleton this is not an issue.
There is an inherit risk in decoupling a class from it's expected behavior, so take this into consideration before using this pattern.
I wrote a while back on available tools for generating help file for your .Net application, and recommended using the Sandcastle Help file builder (last updated on 01/2008). It a GUI wrapper for the Microsoft Sandcastle document compiler.
You also need to enable xml documentation file creation in your project properties. and there are further instructions in a Codeproject article (which may also be a bit outdated).
Seems the situation is about the same almost a year later: NDoc is dead, NDoc05 was last updated during 2006, and Quick Doc viewer hasn't been updated for a while.
The problem was determining the state of the page load (since a page requires several hits before completion on average).
Turns out I need to check on track backs to my post, as Anthony Stevens (you should read his "
about" page)
found a solution to my problem:
Once the page load is complete
WebBrowser.ReadyState property will be set to
Complete, and then you can take the loaded page and wreak havoc on it.
Writing a blog using Community server is not difficult. Adding pictures to a blog hosted on Community server is a real pain.
So I gave up and tried installing Live Writer, and this is what I got:
But I don't want Windows Update Agent - I only want to install Live Writer!
(It's annoying enough to go through the download form and needing to opt out options like this one:
"Help us improve our software by allowing Microsoft to collect data about your installation. If you have chosen to install Windows Live Toolbar, we will also collect data about your system, how you use our software, and the web sites you visit")
יש רופאים באתר? כי הייתי רוצה לקבל תוצאות של רמות הטסטוסטרון של האדם שהגה את הקמפיין הישראלי השנון והמתוחכם של "בחורות בביקיני רצות בסלואו מושן" (הסלואו מושן זמין באתר) המפרסם את דאודורנט Axe.
אז עשיתי בדיקה - באתר היפני סרטון הפרסומת הוא שיעור אירובי (לא, לא בביקיני). באתר השוודי יש סרטון מצחיק עם בן אפלק.
ואת הפרסומת המושקעת והקורעת בארה"ב אני משאיר לכם לצפייה (אין בכלל ביקיני):
לתשומת לב רבני הימין הקיצוני:
"עשרות מיליוני הודים צפו במכשף טנטרי מנסה במשך שעות לחסל ספקן באמצעות מנטרות, לחשים ובצק מקולל. לספקן שלום."
(תודה ליעל על הקישור)
פוסט אורח: ממשק שימושי ככלי שיווקי / רן לירון
ממשק אפקטיבי הוא כלי מרכזי ביצירת אתר אפקטיבי. בשונה מהתפיסה הרווחת, עיצוב טוב של ממשק איננו עניין של אסטטיקה וטעם אישי.
אפקטיביות של ממשק נגזרת מגורמים רבים, וביניהם:
- הדרך שבה אנשים קולטים ומעבדים מידע
- הדרך שבה אנשים עובדים
- הציפיות של משתמשים ממערכות ממוחשבות
ועוד.
נושאים אלו נבדקו לעומק באמצעות מחקרים מדעיים. ממחקרים עלו סידרה של כללים לבניית ממשק יעיל. כללים אלו נכונים לממשק של כל מערכת ואתר, כמו גם לכל חלקי האתר - לבאנרים ולתפריטים לחדשות וקישורם, למידעונים וטפסי הרשמה.
מאמר זה ובמאמרים הבאים שיפורסמו כאן, אציג כמה מהכללים המרכזיים ליצירת ממשק אפקטיבי ואת הרלוונטיות שלהם לנושא עיצוב אתרים ושיווק.
כלל מספר אחד לעיצוב ממשק אפקטיבי : הקפד על פשטות. (חוק KISS).
למה זה טוב?
ממשק פשוט = ממשק נוח, ברור ויעיל. הפשטות צריכה להישמר גם ברמת חווית המשתמש הראשונית ("נראה לי שפשוט לבצע רכישה מהאתר הזה") וגם בפועל ("הצלחתי להשיג מה שהתכוונתי בדיוק, בקלות ובמהירות).
איך עושים את זה?
הנחיה 1: צמצם את הרכיבים המוצגים והפונקציונאליות שהמערכת מציע למינימום ההכרחי
דוגמה טובה בולטת :
googleכדי לצמצם בכמות הרכיבים חיוני לזהות מה חשוב לכם ומה חשוב למשתמש, ולהציג רק את המינימום ההכרחי. מה שחיוני למשתמש ולמודל העסקי - להציג. מה ש"nice to have" - להוריד, או להעביר לעמוד מקושר. כן, לפעמים צריך לקבל החלטות קשות ולחתוך בבשר החי.
טעות נפוצה בחשיבה: "כמה שיותר אפשרויות ופונקציות, יותר טוב". משתמשים מחפשים מה שנוח, ברור וקל לשימוש, בלי מאמץ. יותר רכיבים במסך = יותר מאמץ. יותר החלטות = פחות נוח.
טעות נפוצה בביצוע: העמסה.
עמוד שמכיל המון אופציות, מידע ובאנרים מבטיח שאף אחד מהם לא יזכה למלוא תשומת הלב. אם יש באתר רק מספר רכיבים בודדים, הסבירות שהמשתמש יתייחס אל כל אחד מהם גבוהה בהרבה. יתרה על כך: עמוד עמוס שמאלץ את המשתמש להתאמץ ולחפש מידע בין פרטים רבים שלא רלוונטיים לו, מגדיל את הסיכון שהמשתמש יאבד עניין לגמרי וינטוש את האתר.
הנחיה 2: פישוט תהליכים - מינימום clicks לכל משימה
תהליכים מורכבים פוגעים באפקטיביות של תהליך מכירה בשלוש דרכים:א. הרתעה: משתמשים נרתעים מתהליכים שנראים במבט ראשון כמחייבים השקעה של זמן, או קבלת החלטות רבות.
ב. נטישה: כל לחיצה על כפתור מחייבת החלטות. "לאשר או לא?" "להמשיך או להפסיק? כל מעבר שלב, לחיצה על כפתור, סימון check box וכו' מהווים צומת החלטה. בכל צומת כזו עלול המשתמש לבחור לנטוש. ככול שתמעיטו בצמתי ההחלטה, תגדילו את הסיכוי שהמשתמש יסיים את התהליך.
ג.בלבול: כל החלטה שהמשתמש מקבל מגדילה את הסיכוי לשגיאה. כל שגיאה בתהליך מגדילה את הסיכון לתוצאה שגויה ולקוח לא מרוצה.
חשוב להקפיד שתהליכים, מילוי כגון טפסים, גם יתפסו כפשוטים במבט ראשון (לא להציג המון שדות למלא במסך הראשון, לא לחלק את התהליך להמון שלבים) וגם יהיו פשוטים לשימוש בפועל.
הנחיה 3: שמירה על ריווח (White Spaces) בין רכיבים
ככול שהמסך עמוס יותר ברכיבים צפופים, כך קשה יותר לזהות כל רכיב בנפרד בסריקה מהירה והמסך נראה מורכב יותר. שמירה על רווחים בין רכיב לרכיב יוצרת תחושה של מסך עמוס פחות ולכן פשוט יותר לשימוש.
דוגמה טובה: Facebook: למרות שמסך הכניסה לאתר מכיל רכיבים רבים, ושלושה אזורים שונים שמציגים שדות קלט, התחושה הראשונית שהוא יוצר היא של ממשק פשוט. אפקט זה מושג, בין השאר, ע"י שמירה על ריווח בין הרכיבים השונים בעמוד.
הנחיה 4: היצמדות לקונוונציות ממשק מקובלות
מה שמוכר - פשוט לזיהוי ולתפעול. מה ששונה - מורכב יותר. לא פעם, מתוך רצון להיתפס כשונים, חדשנים ומקוריים, עולה הפיתוי "להמציא את הגלגל".
אם חשוב לכם שהמשתמשים שלכם יבינו איך המערכת שלכם עובדת ללא מאמץ מצדם, וישתמשו בה באופן שהתכוונתם, אל תבלבלו אותם עם ממשק לא מובן. קונבנציות מקובלות כגון הצגת קישורים בצבע כחול (רצוי עם קוו מתחת) וניווט שנמצא במקומות המקובלים (פס ניווט עליון, בר ניווט בצידו של המסך) מקלות על המשתמש להשתמש באתר בצורה אפקטיבית - עבורו ועבורכם.
דוגמה טובה: אתר מכירות הענק
Amazon.
האתר מציע מגוון אדיר של מוצרים, ועשיר מאוד בתוכן ובפרסומות. למרות זאת אין בעיה למי שמגיע לאתר, להבין בדיוק איך למצוא מוצרים ולבצע רכישה. האתר נראה חדשני ודינאמי - בלי לנסות להמציא את הגלגל בעיצוב הממשק.
לסיכום: לא פשוט לבנות מערכת פשוטה. שווה להשקיע בכך זמן ומחשבה. שככל שהמערכת שלכם תהיה פשוטה יותר, כך תשתפר האפקטיביות שלה בהשגת המטרות המרכזיות שתגדירו לה.
אתם מוזמנים לשלוח שאלות, בקשות והערות, לכתובת:
RanL at matrix.co.ilרן לירון הוא מעצב ממשק בכיר בחברת
מטריקס, מרצה לעיצוב ממשק ושימושיות ב
ג'ון ברייס ומורה
לאיקידו בבית הספר "רונדו".
מאמר זה פורסם לראשונה במסגרת המידעון סודות השיווק
מה אתם מתכננים לעשות מעבר לשעות הכנס?
בלי לדעת את שעות הפעילות (מתי תהיה תוכנייה באתר?), אני מניח שכמוני, רבים ימצאו את עצמם חסרי תעסוקה בערבים.
אמנם ידוע לי שמתוכננת מסיבה באחד הערבים, והערב השלישי יהיה בסימן "אני בדרך הבייתה", אבל זה עדיין משאיר ערב פתוח.
אז מה אתם מתכננים לאותו ערב?
As a .Net developer you are not bothered by trivialities such as character encoding, since the framework uses Unicode by default.
But what happens when you need to encode your text so someone else (non .Net) will decrypt it, and that someone uses a single byte per character?
Let's start with few definitions:
-
ASCII - a standard that uses a single byte for each character, but only defines 128 possible symbols. There is no such thing as "Hebrew ASCII".
-
ANSI - Same idea, but here you can use the remaining bits (out of a byte) to encode non-English specific characters. The problem is every language uses a specific version. The ANSI character table may look different on different computers, depending on the configuration.
-
Unicode, UTF-8, etc - Using 2 or more bytes for each character, allowing room for all languages (as long as both sides agree to use the same encoding)
(If you wish to learn more, you should read Joel Spolsky's "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)")
Here are your options:
-
-
-
Encoding.UTF8 - Will encode ASCII text with a single-byte representation, but will switch to a longer representation for non-ASCII strings.
-
Encoding.Default - ANSI encoding based on the computer's configuration, meaning both sender and receiver should share the same locale.
-
Encoding.GetEncoding - Uses a specific code-page to determine the desired encoding. You should try using this method if you need ANSI encoding. However, you still need to determine the code page you require.
-
Encoding.GetEncoding(862) - Uses
MS-DOS Hebrew encoding, with
Hebrew characters starting at bit 128.
-
Encoding.GetEncoding(1255) - Uses
Windows-1255 Hebrew encoding, with
Hebrew characters starting at bit 224. This encoding matches the
ISO 8859-8 standard, which is also used by
Unix.
I'm trying to research the subject, and for some reason the NetFX3 site sample's link appears broken.
Update: Currently using the SDK sample, trying to boost the service's queue performance.
למצוא עבודה בגוגל
Steve Yegge wrote a loooong post with tips for finding a job at Google.
He gave all sort of tips, most of them self-explainatory (you should know about Hashtables, Algorithms etc).
But there was one golden advice:
Don't let the Interview Anti-Loop get you down.
But what is the Interview Anti-Loop?
Every single employee E at any company has at least one "Interview Anti-Loop": a set of other employees S who would not hire E.
The solution is simple:
"The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. Just as long as you don't feel meta-bad, everything is OK. You should feel good that you feel bad after this happens, because hey, it means you're human.
And then you should wait 6-12 months and re-apply. That's pretty much the best solution we (or anyone else I know of) could come up with for the false-negative problem. We wipe the slate clean and start over again. There are lots of people here who got in on their second or third attempt, and they're kicking butt.
You can too."
When you leave work this weekend, turn off your computer, light and air conditioner - and try to keep doing this every day.
And there are other ways to help the environment.
More info - on the Earth Hour 2008 web site.
After going this week to the
Microsoft performance open house, here are few things to consider:
- Create performance counters of your own to measure various statistics.
- Try to avoid using interfaces and virtual methods to supports inlining.
- If you use a "Contains" method on a collection of structs, be sure to override the "Equals" method, since the default Object.Eqauls method used boxing twice - once for the parameter and the once for "this".
- Similarly, you should override the GetHashCode methods for structs, since the default implementation for a struct is very inefficient.
- Use Perfmon.exe to monitor the "% time in GC" - a high value may indicate mid-life crisis.