I have just recently noticed that some folders in Snow Leopard just refuse to be compressed using the “compress [folder name]” command (available under the right-click menu). For the life of me, I could not get the folders to finish compressing, with the symptoms including the famous “5 seconds remaining” progress bar status and the progress bar quickly jumping to about 90% and then just hanging there forever. I once left my Macbook Pro to compress a folder overnight (around 8 hours) and it was just stuck on “5 seconds remaining” status.
Initially I managed to avoid this issue by using utilities based on the 7zip compression, although it is less than ideal, since most of them want you to pay before they let you create archives other than the 7zip format or .7z. After a while I was getting fed up with having to skirt around the issue and decided to investigate and guess what, the culprit is the usual dot files. If you have taken the folder to a Windows machine, say from a USB stick, then brought the folder back to OS X, then you are likely to encounter this issue.
The fix is quite simple. Just bring up the terminal.app (applications > utilities > terminal.app) and type “dot_clean” then drag the errant folder into the terminal window and terminal should display “dot_clean” followed by the path to your folder. Press enter and voila! You should now be able to compress your folder from the option click menu and it will finish. I have not yet encountered this bug in Lion, but who knows, it might be lurking in there somewhere.
Although it’s not my main occupation, I have dabbled in front-end development for sometime. I have enjoyed working with new front-end techniques, such as those provided by features included in the HTML5 and CSS3 specification. Compared to the way things were 10 years ago, these features look like designers’ dreams. They greatly simplify the development of front-end interfaces that are not only easy on the eyes, they are also more mobile-friendly with some great features added for accessibility.
However, I am beginning to see a trend with front-end designers trying to apply too rigid a control on their designs, resulting in the loss of accessibility for the end users. While it might be fine for twenty-something designers to use 8pt text to render a whole article in a web page and then disable zooming so that their layout can “look good”, it is not fine for everyone, especially those over the age of 40.
When smartphone browsers (starting with mobile Safari) implemented a “pinch to zoom” feature to allow people to view web pages with larger text (which is then reflowed), I thought that this was the beginning of an accessibility trend which would allow people to view hard to read text a little bit closer. However, it seems that a lot of designers responded to this by disabling the end users’ ability to zoom the viewport, supposedly to maintain the layout. While I understand that need to maintain a layout, I don’t think that sacrificing usability is the answer, In the end, the content that is supposed to be delivered to the end user does not get the message through, because the layout might “break” if the user zooms the page in. This is why I have enabled the “force zoom” feature in my Chrome for Android browser, so that at least I might have a chance to read what’s on the page, rather than looking at a pretty layout and not being able to read the article.