So... many have complained that they're receiving broken e-mails in their Gmail accounts. Some non-Gmail users also complained that all e-mails originating from Gmail accounts arrive broken. So I thought I'd lend a helping hand.

As far as I can tell the issue here is the use of the "UTF-8" encoding. To Google's credit, UTF-8 encoding is the future and so we should adopt it. Ok, maybe that's a bit too fascist, but it's gonna happen sooner or later. (No, I'm not that naive to think that the world can make everything UTF-8 compliant overnight) What Gmail has done is the "right" thing. If they had implemented a feature that would read the user's default encoding scheme and used that instead of UTF-8 that would have solved some people's problems, but it wouldn't have been the "right" thing. This is a bit of a dicey issue as all e-mail readers/writers have to play by the rules or the poor users suffer. At any rate, here goes.

The reason why a Gmail user can't read that e-mail from your Korean buddy filled with fancy schmancy abbreviated Korean chat phrases is because the sender used an encoding scheme that isn't UTF-8 to compose their e-mail, but their e-mail client didn't correctly specify the encoding used to compose the e-mail in the e-mail header. So you're thinking, "OOoook smart ass! 'Nuf of this ABCD-895 Klingon talk! Tell me how I can read my pal's e-mail inside Gmail, already!". Alright, hold down the temper there... Kids living in the internet age sure has no patience. Sheesh... Ok, so here's how you do it. (Instructions assume the use of Internet Explorer since that's what majority of the people who complained about it were using)

1. Locate the "More options" link to the far right of the e-mail you're trying to decipher.
2. Click "Show original" in the list of links that just showed up.
3. You'll see a new window with the same e-mail (with a lot of weird information at the top) show up.
4. If you still can't read it, then make sure you set the encoding of the Page to your best guess (Korean/EUC would be your best bet if you're used to getting Korean e-mails from your pal) by right clicking on the page and selecting "Encoding".
5. Voila! You can read now!

Now you want to know how your non-Gmail buddies can read e-mails originating from Gmail loaded with extra-fancified and non-emotional chat jargons? Rest assured, I can help you here as well.

1. If you're using a web-based e-mail client such as Hotmail or Yahoo! Mail, etc... then simply open up the broken e-mail and change the encoding to "UTF-8" by right clicking on the page and selecting "Encoding"
2. If you're using a desktop client such as Outlook Express that are reasonably smart, you should have no problems since Gmail correctly specifies the encoding scheme as UTF-8 in the header. It is, of course, possible that something else is messed up and you're still having problems. If that's the case, then look for a way to change the encoding of the selected e-mail to "UTF-8".

I know for a fact that Hotmail.COM defaults to the user-prefered encoding scheme for reading and doesn't specify the charset of the content of the e-mail in the header. This is the source of most people's complaints (at least the ones I've received). What Google could do to remedy this is use an iframe for the content of each e-mail so that people can right click on it and switch the encoding scheme to whatever they want. I hope this helps some of you~

P.S: I should add that I'm extra bitter today about the subject of online communication and the loss of personal emotions in our daily lives among people of the internet generation. I'm sure you've noticed it in the entry. ;)

There's been a lot of buzz around the new feature called "Dashboard" that will be introduced with "Tiger", the next generation MacOS X. Some are screaming foul as they believe it's a rip off of Konfabulator and some argue in greate lengths why it isn't. Others are concentrating on how this could help rapid development of simple desktop apps and how much good it'll do to the web standards that we have in place. I've been for the most part a huge proponent of the idea that in the future, developement of simple (and complex, depending on the requirements) desktop apps can move towards leveraging on the web standards put in place. I don't know if this is because I've been working with the web for over 10 years or because it is truly the best (meaning most widely available, not necessarily most architectural) way to be able to separate content, logic and presentation (I'll, of course, say it's the latter. ^^)

I can, with some bias, honestly say that being able to quickly whip up a user interface is unmatched using HTML and CSS. Don't get me wrong, since I do believe visual tools can do it faster, but I mean this in a programatic sense. Using a visual tool is orthogonal to the underlying technology as I can easily develop such a tool for the HTML & CSS world as well. If you compare writing code to put UI in front of you and writing HTML to do the same, I think HTML and CSS wins all the time. Yes, you can say that there exists other template-based tools out there intended for UI development that can do this faster, and you may be right, but I'm concentrating on being able to do this when you have real-world requirements such as being able to hire somebody right off the street to get down and dirty, or working with technology that has global momentum with a large community-based support, etc... I'm pretty certain that the amortized result will be in HTML and CSS's favor. If you believe otherwise, I'd love to discuss it. :)

So without going into too much detail, I'm pretty certain that a development platform that allows people to develop the frontend using standard web technologies is a big win for web-based application developers who'd like to be able to further their skillset into the desktop-realm. What's important, however, is that that there must exist good extensions that let you do what typical desktop application would be able to do outside the confines of web-vulnerability and security (like file system access, etc...). When I mean good I mean extensibility to create your own modules as well as standard interfaces that are platform-independent (of course it will be platform-dependent in the underlying implementation). I can only hope that however Apple intends to expose esternal services to the javascript environment that it doesn't end up being too cumbersome to get started.

It's worth noting the fact that Microsoft was first(at least in a semi-wide scale) in trying to bring this type of platform to the developers with their HTA effort. When I heard about the HTA framework back when it first came out, I was sold at the approach they were taking. Sure, there were flaws, missing features, etc... but anybody who knows Microsoft will know things don't really start to shine until the 4th version. ;) However, the problem is that Microsoft hasn't touched the HTA project since it has come out. Possibly the same reason why some believe they haven't touched IE 6 for almost 2 years. That's truly a shame, I thought they were really onto something. (I remember seeing some open source project trying to do similar things with the Gecko engine, but I can't find it)

So Dashboard is trying to do a very similar thing for MacOS X. I don't have any hands-on experience, so I can't comment on how good/bad it is, but I'm guessing it'll be pretty solid given that Apple sounds pretty serious about web technologies. I just wish the final product will allow developers to opt not to put their application in a layer that is normally invisible. But, you know what'd most kick ass for me? The ability to just write these web apps on any platform, compile it to a single file and to be able to run it on multiple platforms (even if it means having different binaries for the various platforms). That'd be really cool!