Make Word 2007 Save to .doc by Default

While the MS Office 2007 GUI is nice (and maybe even a tad more usable), the (relatively) new docx file format is so proprietary, it's not even funny. Can Office 2003 users open it? Not without the Microsoft-developed "compatibility pack". Can OpenOffice users open it? Not without installing a non-standard file handler for the program (there are instructions for installing this on linux-based systems). Using the format is well and good among 2007 users...but what about when you email that docx writeup (due tonight, no less) to your professor, who uses only OpenOffice? Oops.

The main problem is that the docx format is fundamentally different in composition from the good ol' doc format. The doc format was your standard binary file format, much like image files and executables; essentially, they are text surrounded by Word-readable formatting instructions.

The docx format, on the other hand, is a zip file containing other files that describe the contents, formatting, embedded objects, and everything else the docx file holds. According to Microsoft themselves:

To open a Word 2007 XML file

1. Create a temporary folder in which to store the file and its parts.
2. Save a Word 2007 document, containing text, pictures, and other elements, as a .docx file.
3. Add a .zip extension to the end of the file name.
4. Double-click the file. It will open in the ZIP application. You can see the parts that comprise the file.
5. Extract the parts to the folder that you created previously.

Regardless of the differences, though, the mass switching from one format to another caused by the widespread adoption of Office 2007 is nothing less than inconvenient for those users not using the new Office. You can help by setting your copy to save to the compatible doc format by default :D . After starting Word 2007, go to Orb->Word Options. Select the "Save" tab on the left, and choose "Word 97-2003 Document (*.doc)" for the "Save files in this format:" option. Then click the OK button. From now on, anytime you select Orb->Save, Word should offer the old .doc format as the default format to save to. Hail compatibility!

Three Ways to Securely Destroy Your Data

If you're planning on selling your computer in a usable state, chances are you'll want to securely erase that three to five years of tax forms, social security numbers, etc from your hard drive. The most secure method (for us civilians, anyways) to destroy that data while keeping the drive usable is to start up a version of the linux-based Darik's Boot 'n' Nuke. WARNING: Using DBAN will erase everything, everything, EVERYTHING, from the hard drive. Data, operating system, everything. You won't be keeping Windows (or Mac, or Linux, or any OS, for that matter) or your data unless you back it up. It will effectively give the hard drive a clean slate. Data recovery is not possible for us mere mortals. You might as well try to get the pre-release testing data from a new drive (they do test those before we buy them, right? :| )

1) DBAN

If the hard drive is of no use to you, you don't plan on letting others have it, and you don't trust the Geek Squad to destroy it for you, here are a couple more, rather more fun, alternatives :D

2) Industrial Shredder

3) DIY Boot 'n' Nuke

Progressively Enhance copyable code blocks

I've employed a bit of progressive JS here on the blog to make it easier for readers to copy the blocks of code that I post. Go ahead, try it: click within the code block, and the entire thing is selected. Makes for pretty easy copying, rather than having to carefully select just the text inside the box...
// I'm code!! Copy me!! $ hello world // w00t...

The way it works

Here's how it works: I've defined a function which goes over every single <code> element on the page. For each code element, a textarea element is created and inserted into the DOM tree directly before the corresponding code element. Once a textarea is added to the DOM, it is hidden via CSS. The textarea is given, as child nodes, recursive clones of code's DOM child nodes. Then, the onclick event of the code element and the onblur event of the textarea are set to different functions. The code's onclick function hides the code element, un-hides the textarea element gives the textarea the focus, and selects the textarea's contents. The textarea's onblur function hides the textarea and un-hides the corresponding code element.

It's possible to have the script do this for all code elements on the page, but I've implemented it to only target those code elements to which I've given a class name of "copyable".

The CSS

The hiding-un-hiding tricks aren't possible without CSS. Well, they're possible, but such an implementation would make the JS much messier. Here I've used CSS to similarly style both code elements and elements with a class name of "codeenhance" (which is used to identify the inserted textareas).
.codeenhance, code { width:430px; color:#000; display:block; background:#eee; padding:0 10px; padding-bottom:1em; margin:0; border-width:3px 1px !important; border:#99f solid; overflow:auto; line-height:1.4em; font-family:monospace; font-size:1.1em; } .codeenhance, .copyable { height:250px; } code { white-space:pre; } .codeenhance { padding:0; } .codeenhance-off { display:none; } The first declaration is the main styling for the code elements. The height specification for .codeenhance and .copyable fix the height of copyable code blocks, so your 159 lines of copyable JS don't take up too much space. I've left the height out of the main declaration, to allow the other code blocks to expand/retract to their contents' size. The white-space declaration for code elements maintains the whitespace as you typed it. The padding declaration for .codeenhance fixes an interesting jumping issue with the textareas. And the display declaration for .codeenhance-off is what hides the appropriate items.

The Javascript

Here's the JS. The explanations are in the code comments ;)
// Enable click-select on code elements function enhanceCode() { // Get all code tags var codes = document.getElementsByTagName("code"); // loop over code tags for (i=0; i<codes.length; i++) { // working only on tags of class "copyable" if (codes[i].className.match('copyable')) { // for each tag, create a new textarea var text = document.createElement("textarea"); // copy the code's children over for (j=0; j<codes[i].childNodes.length; j++) { // special code for Blogger, to take care of extra br elements if (codes[i].childNodes[j].nodeName == "BR") text.appendChild(document.createTextNode('\r\n')); else text.appendChild(codes[i].childNodes[j].cloneNode(true)); } // set the initial classname // (use .className rather than .setAttribute('clas', 'blah') because IE6 // doesn't like the latter text.className = "codeenhance codeenhance-off"; // setup the onblur event text.onblur = decodex; // insert the textarea before the code codes[i].parentNode.insertBefore(text, codes[i]); // setup the onclick event codes[i].onclick = codex; } } } // this = code element; this.previousSibling = textarea element function codex() { // show the textarea this.previousSibling.className = this.previousSibling.className.replace(/ ?codeenhance\-off/, ""); // hide the code this.className = this.className+" codeenhance-off"; // focus and select the textarea this.previousSibling.focus(); this.previousSibling.select(); } // this = textarea; this.nextSibling = code function decodex() { // show the code this.nextSibling.className = this.nextSibling.className.replace(/ ?codeenhance\-off/, ""); // hide the textarea this.className = this.className+" codeenhance-off"; } window.onload = function() { // run the enhancement /after/ the window has loaded enhanceCode(); }

An Alternative to IE8's "Opt-in Standards Mode"?

There's been a lot of opinions expressed about the IE team's introduction of the X-UA-Compatible HTTP header (or, in most cases, a meta tag in the html), otherwise known as Opt-in Standards Mode, with IE8. Most of the opinionators seem to be opposed to the "switch", while a few (PPK of QuirksMode and Aaron Gustafson of AListApart amongst them) have already embraced it. But is there a better way?

Ideas

Reading through user comments on PPK's post, I came across some interesting ideas. BARTdG said

...I think they should solve this problem by adding a "Does this site look odd?"-button (to switch IE8 into IE7-mode)...

And Michiel van der Blonk said

I see a different scenario possible. MS ships the new IE8 with full forward compatibility mode (edge) as a default, as all standards aware developers expect it. But, they also deploy a 'crippled' version of IE8 that has all the security features and what not but will render using the IE6 engine.

Tino Zijdel:

If the problem lies mainly with IE-centered intranet apps then why doesn't MS offer a special fabriqued 'Intranet Explorer'?

An alternative?

What if standards-compliant rendering were placed in the hands of the users?

I mean, this is pretty much the case now, what with people having a choice (most of the time) between using IE6, IE7, FireFox, Opera, Safari, Konqueror, and more. Those ignorant of their options will use what they're given, IE7 (or IE8 with the default mode). Why not leave whether or not IE8 renders properly as an option for the user to invoke?

Suppose IE8 ships with two rendering engines (which is how it looks anyway): IE7's current engine, and IE8's new engine. IE8 Standards Mode could be the default engine, which perhaps degrades to IE7 Quirks Mode given a lack of Doctype. Then suppose that there is a button (or menu item, or statusbar icon, or etc) which allows the user to switch to back to IE7 rendering mode (Quirks/Standard, depending on doctype presence). What could the implications of this be?

Possible issues

Breaking the web

If IE8 mode is the default engine, then IE8 will, by default, "break the web". However, most people have noted that the main recipients of this breakage will be company intranets. I've never maintained an intranet before, but surely it wouldn't be too difficult to implement a "switch" of some sort that can easily be used to mass-switch the company's IE8 installations to use IE7 mode.

More crossover

A major concern that might arise is that we developers will have to develop for both IE7 mode and IE8 mode, to cater to all users. So, what exactly are we doing now? Well, those aiming for cross-browser compatibility are still developing with an eye on IE6, as well as IE7, FireFox, etc. And, if the Acid2 announcement is any indication, IE8's Standards Mode shouldn't be too difficult to cater to, if the design works in other majorly-standards-compliant browsers. As Hixie puts it (albeit on a slightly different topic):

Finally, we could just... [continue] to use JS compatibility libraries for the time being, the same way that everyone has been doing for years. Authors would also have to support IE7 anyway, at least for the forseeable future, so it wouldn't be an additional cost.

Usability issues

"Oh, noes, more menu options??? You'll confuse the poor user!" Please. My favorite website looked fine in IE7, and now it won't work in IE8. What's this? A button that makes IE8 work like IE7? Cool! *click* Hey, it works now!
Even better, in the case of "mass-switched company-intranet users": My favorite website worked in IE7. I've been upgraded to IE8 which, since its been switched to use IE7's engine, still displays the site as it always has. I'm sooo happy. :D
And, honestly, if someone sees the button that says "Switch to IE7 mode", and has no clue what that means, are they going to melt down in a puddle of confusion? No. They will ignore it. If they are the initiated type, they might click it to see what it does, or go in search of someone or something that can explain it to them.

A better solution?

I believe this might be better than forcing developers to add a meta tag (or HTTP header) to their pages (or servers), just to get standards compliance. I'll code my site to standards compliance. Other sites will sit "broken" and, if the user wants, they can view those sites with or without standards compliance. Why did they not come up with this before?

Post Notes

Of course, the best thing would be to just ship IE8 with full (as full as it will be) standards-compliant mode, leaving behind the bloat introduced by carrying two or three rendering engines. Make it a user option to have either IE7 or IE8 installed or, if the user so chooses, both installed side-by-side.

If we must have a proprietary HTTP header, consider James's idea of an era-based header, though I would argue that the "current era" should be the default. Pick an era that you are (or were) compatible with, and render era-less sites with standards compliance. And, of course, let the user override the era if they so choose.

Finally, I very much like the idea of modular rendering engines. You can have whichever interface you like, further combined with whichever rendering engine you like. Want to use the customizable interface of FireFox with IE8's Acid2-capable engine? No problem. This could even be enhanced with an option to use specific engines on a per-tab basis (for those browsers with tabs); this would inevitably bloat the program (per-instance, not every time), but it would be invaluable for web developers working on Linux or Mac (Testing the same site in IE6, IE7, FF2, and Opera, all from the FireFox interface?? Cool!). I mean, how long have computer users had operating systems with alternate shell capabilities (for example, Windows and LiteStep, or, more obviously, linux and your choice of Gnome/KDE/XFCE/etc)? Why should browser users not have the same capabilities?
(This idea of modular engines was not originally mine, but I cannot for the life of me figure out where I read it originally. If anyone has a link to a place where the idea is more fully fleshed out, please do share :D )

KDE4 Update: A Turn for the Worse?

I recently wrote a post about KDE4 and Plasma, and my first impressions about it. Yesterday, I ran aptitude dist-upgrade to find out that KDE4 had an upgrade available. KDE 4.0.1 is here.

The main changes I've noticed since the update is some changed and some missing functionality. The "Add widget" area is no longer; it has been replaced with a "zoom zone". When hovered over, the area expands and gives you a "Zoom out" button. This zooms the desktop out to show all four (or however many) desktops on the screen. To zoom out, you must hover over the corner area again (which is now half as large and in the corner of each "desktop"), though this presents two buttons: one to zoom in by another factor of two, and one to zoom back out to normal. I tried the second zoom factor, and was scared I might not be able to get back :D. Seriously, though, it doesn't work (at all) with compiz; as such, I have no use for it. Fortunately, the "retracted" form of the area is grayed out and unobtrusive. To add plasmoids, you must first unlock them (right-click the Desktop > Unlock widgets), then call up the "add widgets" dialogue (right-click desktop > Add widgets...).

Some of the widgets seem to have had an update as well; most notably, the Digital Clock widget, which I use daily. The change: I no longer have the choice to view a 12-hour clock rather than the default 24-hour clock. Oops.

One nice thing I just noticed: in 4.0.0, whilst dragging plasmoids, if your mouse moved behind a window, the plasmoid would lose focus. You had to go around the open windows to move the plasmoids around. No longer; the plasmoid will continue moving unless you let go of the mouse button. Even behind windows.

Another small plasmoid change, affecting all widgets, is that the per-plasmoid rotate/resize button has been split into individual resize and rotate buttons. It makes sense, but it's slightly annoying for me, since I was used to using the both-in-one button. And it adds clutter to the plasmoid interface. But, it's livable.

I haven't noticed any other changes yet (other than the kde4 apps taking over the kde3.x apps), but I haven't exactly dug deep into the bowels of the available settings.

Overall, the change isn't too drastic (what'd I expect -- it's only a .0.1 update). I miss the 12-hour clock, but that's a fault with the plasmoid's developer(s), not the Plasma devs. The change in functionality of the corner area (the "zoom zone" at the moment) is slightly disturbing -- does the KDE team not know what to do with this area? I would suggest making it a button for the Ctrl+F12 feature (an OS X-style "bring widgets to top and darken the background" feature) and bringing back the "Add widgets" button. The plasmoid resize/rotate button split is the tiniest bit annoying, but livable.

And I eagerly await the day I can choose which widgets are always below and always on top :D

Update: I'm afraid I must apologize for being a bit hasty in my "judgments", as it were. Like my first KDE4 article, this was a "first impressions"-style writeup, detailing the first things I noticed after updating. I have since (at the prompting of my commenters :) ) delved a bit deeper into the update to do what I want to do. while the 12-hour switch in the digital clock plasmoid is a missed feature, ravencrow kindly pointed out that you can switch time modes through the "Regional & Language" section of the KDE System Settings. Select the "Time & Dates" tab, and enter "pH:MM:SS AMPM" for the "Date Format" field. You'll have to restart the X server for the change to take effect, but this will let the clock plasmoid display 12-hour formats again. Yay! As pdx and Sokraates mentioned, and as I so hastily overlooked, the "add widgets" button is still present in the upper-right-hand corner, though you must "unlock widgets" before it will display.

Additional links:
Tux Enclave: KDE 4.0.1 Is Now Available

Web App ideas: QuickMail

I was thinking the other day, I want to build a web app. Yeah. Right after I finish Physics homework, build an AI program, and take finals. Good grief.

What the heck, I can still come up with ideas, right? Google didn't turn up much inspiration, so I started thinking on my own. Here's what I came up with.

QuickMail, a lightweight mail app, designed for those who don't have time to deal with bulky webmail interfaces (am I right, AOL users??). It should support as many mainstream mail services as possible. It should have a clean, simple interface, with little or no bells or whistles. It should be built for speed (both runtime and download time).

Upon entering the site, the user is presented with a login panel, which contains a dropdown with available services, username and password fields, and out-of-the-way links to an about page and other pages that might be accessed before "logging in" (perhaps a "donate" page to pay for hosting, maintenance, etc). Ideally, this panel will be presented as a blackbox-style overlay, to prevent the need to wait for an extra page refresh after logging in.

Once "logged in", mail will be fetched from the user's account (probably through AJAX) and displayed (unread mail only? both read/unread? will there be options?). No registration is required for QuickMail, only the login credentials for the specific service are needed. The user should be able to choose whether or not the app autochecks for new mail (for slower computers, to avoid the constant background JS that would be required), and there should be a button for checking for new mail, regardless of whether autocheck is on or off.

Credentials should be kept only on a per-session basis; the user should be able to simply exit their browser without fear of being "hacked". Most likely, this will involve avoiding cookies, probably keeping the credentials as JS variables.

A mail search function would be nice, though it would be an extra feature, to be implemented after the core functionality is stable.

With this kind of setup, you could type "qm.com" or similar in your url, choose your service, enter your credentials, and read your email, all in the 15min between classes :D ok, maybe not that snappy, but close enough. Once you're done, just exit the browser (or tab) and don't worry about logging out (since you were never really "logged in" to begin with).

So, what do you think? Would you use this? Is it feasible? Anything I missed?

If you think you can implement it, fine, but I'd love to be in on it. If not, feel free to leave suggestions in the comments :)

A well-designed website: many things to many people

In my Advanced Web Design class at school, my professor asked us to post what we thought defined a well-designed website. I thought I'd share my answer here. I'm sure he wasn't expecting anything so involved as this :D

"What makes a well-designed website?" That's quite a question.

As a dabbler in web design, I would say a well-designed website is "good-looking". It should look somewhat elegant. The "Web 2.0 style" -- glossy buttons, spacious openness, minimalistic simplicity, and copious use of gradients -- comes to mind. I can't think of any sites that strictly adhere to all these points, but DynamicDrive is a good-looking site.

As an HCI-minded individual, a well-designed website is made by more than its layout. A well-designed website makes it obvious what the site's purpose is, what can be done on the site, how to go about doing it, etc. Again, simplicity is king, and clutter is sin. Content is easy to skim and understand. The layout does not make it difficult to navigate. If a feature breaks, the site will either gently tell the user so, and make it easy for the user to report the breakage; or the site will function in such a way that the user doesn't notice the difference, and the developer will be alerted. I think Digg is a fairly usable, well-designed site.

As a web developer at heart, a well-designed website is all in the code. Separation of structure, content, presentation, and functionality is something to be strived for. It should be built as follows:

1. First build a mock page (with the final site's design in mind) which contains either mock or real content, and only structure-oriented HTML markup. Presentational markup is sin :) This page is not design-oriented; its only purpose is to structure the page's content in a semantically meaningful way. Any tags that do not directly relate to the structure and/or content of the page should be struck down with a flaming sword of death. Organize things in such a ay that they flow logically along the page.
2. Develop the CSS in an externally linked file. Introduce any design-specific images through the CSS, if possible (and it should be possible). Strive for cross-browser compatibility within the CSS, making the site look as similar as possible from one browser to the next. If any additional markup is required for the design of the site, the CSS should be developed to make the site look good without it; if still necessary, the necessary markup can be added through the next step. Use what you have to get what you want.
3. Develop the functionality (using JavaScript) in another externally linked file. Nonintrusive javascript should be used, progressively enhancing the site after it has loaded. Nonintrusive javascript should also be used to add any necessary additional markup to be used by the CSS. Again, use what you have to get what you want.
4. If possible, convert the finished page layout into a template, and use a server-side language to fill it with dynamic content.
5. Finally, when all is said and done, pull up the page in a browser, and make sure everything works. Turn off javascript, refresh, and make sure everything works. Turn off css, refresh, and make sure everything works. Then browse the web for a while....and see if it works :)

According to these steps, a well-designed website will work across browsers, degrade gracefully in older browsers, respect the wishes of those with Javascript turned off. There are lots of websites that use this methodology (using only semantically-meaningful html, etc). One well-designed website in this case is Dynamix Labs. It doesn't seem that they use any javascript, and if you turn off CSS, the site is still very readable.

As a user, I want information, and I want simplicity in doing what I want to do. A lot of the time, I want information that I can talk about in my blog. I use google as my main go-to source for finding things. If I find a site that gives me good information on a regular basis, I want to be able to subscribe to its RSS feed, or something similar. If I find a site that I come back to on a regular basis (whether I be forced to, or do so of my own free will), I want to be able to customize my experience on that site. I want to be able to change the colors, the landing page content; anything and (usually) everything, I want to customize it to better serve my way of doing things.
One service that I use on a daily basis is Google Reader (you'll have to sign in to your google account), a web-based RSS aggregator. It features "folders" that you can use to organize your feeds, drag-and-drop re-ordering of feeds, and very easy-to-use methods of subscribing and unsubscribing from feeds. Another service that I use regularly is Netvouz, a social bookmarking site. I chose Netvouz over other bookmarking sites because of its folder organization feature. You can organize your bookmarks according to category (and sub-category) and make certain bookmarks private. It's also easy to delete or edit my existing bookmarks, and really easy to add new bookmarks using the Netvouz firefox extension.

I must say, though, that my most frequently used and favorite thing is FireFox. It is customizable in (almost) every way possible; its functionality is infinitely extendable through extensions, which anyone familiar with XML and Javascript can write. It has excellent support for standards; the upcoming FireFox 3 is said to have passed the Acid2 test, which is huge for web developers.

As you can see, from my point(s) of view, a well designed website can and should be many things to many different people.

So, what do you think? What makes a website "well-designed"? What are some examples of well-designed websites?

Note: References to certain things "being sin" should not be taken literally. Putting presentational markup on your page will not send you to hell. Nor will avoiding clutter send you to heaven. These are just my personal pet peeves :)