Web Fonts - Why Haven't I Heard About This Before?

Most of the web only uses selective number of fonts, such as: Arial, Verdana, Sans, Times New Romans. But, what if we want to display certain text with certain fonts other than those - to convey some emotion maybe, or to portray certain values, etc? Are we stuck with those selective fonts?

It's true we can make the text to be bold, underlined, italics, etc. But I want to use "waiting for the sunrise" as my font type instead of "Verdana"! This is not easy to achieve because of several reasons:

1. We are putting stuff on the web, so if the machine where the browser is running has the font that we want, it will display it. What if it doesn't? Then it will revert to the "default" font. 
2. All machines or computers have those basic selective fonts - that is why people are mostly sticking with them, so they can be sure that whatever they put on the web will be displayed as intended on the browser.
3. So far people have been working around this by using images - so if I want a menu or a logo with some font type that is not among the standard, I can make it an image using my image editor and include that in my web site as an asset/image file. This then ensures that it will preserve my intended design of the logo or menu or whatever. 
4. But of course, making everything an image is a pain. It's hard to modify, it is not searchable by default, people cannot select/highlight from it, and it's bandwidth consuming. But we kinda stuck with it. 

Aren't there any other alternatives? 

-- read more and comment ...

Asking For Assistance While Minimizing Interruptions - How To Do It Well

It is always somewhat a dilemma when you have to interrupt somebody to ask him/her to help you. There is always a tension between the pressure or desire to solve your problems/issues/bugs and complete your task AND the realization that everybody has their own set of tasks to complete and you are just about to interrupt & tell them to drop what they are doing and focus their attention to help you.

Each person will have their own tendencies:

• Some will just be too shy or reluctant to seek help and just keep banging their heads and hope miraculously or by luck that they will be able to resolve it. Therefore some issues can just linger in the bug list unresolved or taking longer than necessary to be closed.
• Yet a different group of people will ask, discuss, and talk about their emerging problems/issues/bugs all the time with their colleague - and creating noise, constant interruptions, and annoying. 

We all know that the balance lies somewhere in between. We want to respect out friends/co-workers/colleague privacy, time, and work - while at the same time trying to find possible reasonable solutions or pointers in solving our issues.

This blog post is not about how long should you wait before asking question to others, but is about when you actually decided to ask somebody about your problem - and how to do it well.

One of the rule of thumb that I have heard and embrace is the 15 minutes rule - that if you encounter a problem and cannot solve it immediately, try to find some answers/pointers/hints on how to resolve it with all your might in approximately 15 minutes, and if you are still stuck, then get help from others. This works in theory but often what somebody does in that 15 minutes or so is just weird or not helpful at all. I have seen somebody basically just stare at their code up and down the screen and then declare a surrender. Or, hitting the same scenarios again and again, recompile, test with the same code again - which predictably yield the same errors/wrong results/problem as before. Some will Google their issue and read the search result and do nothing about what they read or just skim through the results.

To be able to ask for help well, I recommend doing the following:

1. It is important to know and understand the error message you are getting - if any. You should not go to somebody equipped with "it does not work". It is really bad when somebody comes to you and just say "it's broken" and when you ask "What's the error?" that person replies "don't know".
2. Do your own homework and reasonable research first. The 15 minutes above should be counted toward this. Trying possible scenarios and fixes, what works, what does not, noting them down, etc. Then communicate this to the person that you are seeking help from - so they don't have to waste their time in trying what you ave tried again. Bring screen shots, print out, examples, etc.
3. When you are about to interrupt people, I recommend asking whether the person has some time to spare or whether they are free at the moment. I know some of my friends to away from their desks during lunches precisely because of this reason - so they are not interrupted during lunch. It's a good practice to respect people's time and space - and asking beforehand whether they can be interrupted or not goes a long way.
4. If the problem is not that urgent, try email. Of course describing your problem in an email may take more time (screen shots, etc etc) and some times it is just not possible. But this also an alternative to get help from others without pressuring them to drop everything on their plate and solve yours.
5. When people allow you to interrupt them, then describe your context, settings, cases, and ask your question decisively and quickly. It's confusing when someone just storm to your cubicle and say "It's broken, does not work at all!". OK - so what do you want me to do?? Here is an example: "Bob, I have been getting some errors in ELMAH about 'null reference error'. From the trace, it seems to be coming from ProfileEdit.ascx - which uses a custom editor template for a textbox for a string value. If I use a regular textbox, it works fine, only when using the custom template then the error shows up. The custom template uses same validation rules - which I am not familiar with - and the calculated null values come from that line. Do you have any ideas or hints that will help me?"
6. At this point, we have to give them the freedom whether they want to respond now or later. Your colleague may say "Hm, let me look into it, I will let you know" - then we ought to thank him/her and leave, go back to our desk and do something else or do some more research. 
7. Also try to ask for help during non-peak time. I like to ask help early in the day or right after lunch, before my co-worker get into their working zone mode. Since he/she is not in their zone yet, then it becomes less of an interruption for my co-worker(s).  
8. If you have additional suggestions/recommendations, please post them in the comments!

I am not saying that I have been perfect in doing all these - far from it. So here are some of the mistakes or common error that I have done, or I have witnessed people did (if some of these describe you then You're Doing It Wrong!):

• Send an email to co-worker about a partially described problem, then coming to that co-worker's cubicle/office and asking "Have you read my email? What do you think?". Why is this annoying? Because it's redundant and also pressuring the co-worker to immediately see/solve your problem. If you are going to send an email, send a intelligent and good description of the problem and your question. A good analogy is like creating a question/post on a forum (or StackOverflow) and then wait! If it's urgent (which is usually not), then why send an email?
• Coming into co-worker's office/cubicle and saying "Can you come here real quick and check what I am doing wrong?" Why is this wrong in so many different levels? Because it shows an almost complete disrespect for the co-worker's attention/time/load - and expecting him/her to just drop whatever he/she is doing and solve my problem or help me. Plus, I am usually to lazy to do some research and try to articulate my problem to my co-worker - so bringing him/her to my workstation is just so much easier. 
• Coming into co-worker's office/cubicle, describing the problem and just stand there, fully expecting the other guy to help RIGHT NOW - even some times when he already said that "give me a minute".
• If you have additional scenarios, please post them in the comments!

Now, even if you follow all these recommendations - that does not mean your co-workers won't be mad at you and always help you with super-eagerness and save your life - I know I don't some times. But, the bottom line is that when you respect your co-workers' time, space, and attention (by minimizing interruptions), most of them will be more likely to return the favor and more willing to help you.

One exception to all of the above: if the issue at hand is URGENT (i.e. we pushing for production, crunch time, "server is down!", etc) - then all goes out the window and try to do whatever it takes to get the job done. But again, this is usually only occupies a small percentage of our work time and mostly preventable. 

Now, stop interrupting me!

-- read more and comment ...