My Friend, the Rich Text Editor

Recently, my grandmother and I were talking while I installed some drivers on her computer following an operating system failure. She was worried that her Word had changed and she wouldn’t be able to use it anymore. Although her situation was different, her fears were an eerie reminder of the utter panic many of my friends and colleagues expressed during several other software transitions, including the dreaded WordPerfect to Word. Since I was always one of the ones behind the transitions, I tried to keep an open mind, listen to their troubles, and find solutions for them. As an expert user and macro programmer of Word, WordPerfect, and OpenOffice, I was constantly conducting one-on-one and group training sessions and sending out tips and cheat sheets. It was not unusual to receive weekend phone calls from panicked secretaries, and I’m still slightly shocked that some of my colleagues didn’t push me in front of the commuter train. Then again, it was their attempt at formatting that caused the panicked phone calls. Every experience highlights one key principle: technology changes rapidly, but people don’t. Throughout every panicked reaction, I always fought the urge to ask why they were using a word processor.

For most things, word processors are massive overkill. For starters, they are large programs packed to the gills with features most of us will never use. They consume memory when running and slow down older computers. Do you really need something that can generate labels from a database to type an email? Plus, some of us, even as adults, have a distressing Dennis, the Menace mentality and are easily distracted by all the pretty buttons just begging us to push them. All the bells and whistles distract us from our primary purpose–writing.

Thus, I wish to introduce you to my little known friend, the text editor. Most programmers are already well acquainted with text editors. We love them. They’re quick, easy, and highly versatile. As a writer who frequently programs, I also write in my text editor. Many text editors, including my personal favorites (KEdit (part of KDE) and Bean (Mac)), allow you to show a few rich text styling options. In Windows, the long-forgotten WordPad is a good basic rich text editor, but NotePad also works quite well for basic writing. Yes, the text is frequently quite ugly and unformatted, but in many cases, that is a good thing. Once I have completed my rough draft, I can either print it out for proofreading and edit it in the text editor or I can close my document and open it using the word processor of my choice. When I open the document, the word processor will apply its default paragraph and header settings without any action on my part. If I need to set additional headers, all I have to do is highlight the text and select the header level from my pull down style menu. Then, I’m done.

If I work in an office where a secretary will be taking my document and merging it together with multiple other documents, I probably just made her day because my document is clean. She doesn’t have to spend a day reading the document codes in Word Perfect or clear all the formatting in Word and then reformatting. Everything that I provided was clean, free of the many extraneous document codes that wreak havoc on master documents.

Now, let’s take the text editor a step further and pretend that you are maintaining a blog or a website. Writing your text in the text editor will save you a lot of heartache. As a general rule, word processors do not produce clean html. This means that if you write your text in a word processor and paste it directly into your blog post or your page, you run the risk of importing many other things that although you probably do not see them, can and will alter your page layout. In my experience, saving the document as a web page produces worse results. Even if you are only using a simple cut and paste text operation, you run the risk of pasting some rather ugly stuff when you paste from a word processor to the web.

Recently, a client was showing me a page on his site. He’d written the content in Word, copied it, and pasted it into WordPress. On the page, there was a strange box floating on top of the main content with some illegible text. Looking in the code, I realized the box was an image. When asked, he confessed that when he didn’t like images in Word, he simply moved them behind the text instead of deleting them. In another case, strange coding in an OpenOffice document actually pushed the sidebar so far over you had to scroll to see it. These are only a few examples of what can and eventually, will go wrong and writing the content in a rich text editor would have prevented these problems. Do yourself a favor and use your rich text editor for writing blog and web content.

You may wonder how I run spell check and grammar check as these two features are not always available in text editors. I don’t. Several studies and personal experience have forced me to conclude these features are more likely to introduce errors into my writing than improve it.

Author’s Favorite Text Editors

• Mac
  • Bean
  • TextEdit (pre-installed application)
• Linux
  • KEdit (You can install KDE on most desktops including Windows and OSX.)
  • GEdit
• Windows
  • Notepad ++
  • Notepad (standard Windows install)
  • Wordpad (standard Windows install)
• Online
  • FCKeditor
  • XStandard

Related Posts:

• No Related Posts

Installing Multiple Movable Type Blogs Using Add-On Domains, CPanel, and an FTP Client

The below instructions were written after I received a panicked phone call from a friend who was installing Multiple Movable Type Blogs on Add-On Domains. After reading the available instructions, I understood her pain. At some point, I intend to submit me these to SixApart’s Movable Type documentation, but I’d like to polish these a bit first, so here’s the first draft.

This installation was done on BlueHost without direct access to the server, but the instructions should work for other hosting companies as well. In the past, I’ve used a custom .htaccess file to do many of the things discussed below. That was easiest for me, but unless you really know what you’re doing, you could, and probably will, really screw up your site. My advice, if you are wondering what .htaccess means or have only a vague notion what it means courtesy of Wikipedia, leave the .htaccess file alone. The steps below should work without customizing your .htaccess file. Hopefully, this will make the installation a bit more accessible to semi-geeks and do-it-yourselfers. If you’re still a bit daunted by the task, go to Rent-A-Coder or a similar site and post a job. Make sure they set-up and test each of your domains prior to final payment!

1. Backup all your internet files and databases and store them in a safe place on your personal computer. If, heaven forbid, something goes wrong, this will save you many hours of anguished hair pulling and heart ache. Your hosting provider should have instructions on doing this. If not, CPanel and PHP admin (MySQL interface) which are used by many providers, have step-by-step instructions. These may be better than what you host provides and are definitely worth reading.
2. Download a copy of Movable Type and unzip it.
3. If you have already set up subdomains and add-on domains, delete them. Using CPanel, delete the subdomain. Then, delete the add-on domain. This is CPanel’s required order.
4. Connect to your host using either an FTP Client or the CPanel file manager. CPanel file manager will probably be faster than FTP and is well suited to deleting files and adding folders.
5. Go to your /public_html folder. In this folder, delete everything except your .htaccess file. This gives you a clean slate and helps you see what still needs to be done. Note: Don’t delete you .htaccess file. Typically, it is hidden from view unless you click "show hidden files".
6. Create a folder in the /public_html folder for your subdomains/add-on domains, label it, and jot down the folder name. For example, mine is labeled vhost.
7. Create a folder in the /public_html folder and label it mt-static. (This is directly from the Movable Type Quick Install instructions.)
8. Create a folder in the /public_html folder and label it .cgi-bin. Open that folder and create a folder within /public_html/.cgi-bin and label it mt. (See Movable Type Quick Install Instructions.)
9. Go to your CPanel.
10. Click Add SubDomain. (If you do not do this first, you will be unable to select the appropriate directory for your add-on domain!). Type in the url of your add-on domain without the .com in the box provided. Under file location, type in your folder name and click create.
11. Go back to your main CPanel screen.
12. Click Add-On Domain. Select the domain name from the pulldown or type it in if it’s not available. Click add-on. In step 4, select from the pulldown the folder you created earlier for your subdomains/add-ons. Click create.
13. Go to your FTP Client, refresh it, and verify that your add-on domains now have folders under your /public_html/(subdomain/add-on) folder. Example: /public_html/vhost/. Now, check each of the new add-on domain folders and verify that they are empty. If they are not empty, delete all files and folders! (These were created automatically by your web host and point to some variation of a coming soon page. They may conflict with other files later on, so delete everything.)
14. Setup your database. I prefer MySQL because that is what I’m more familiar with. If you use something other than MySQL or PostgreSQL, you will require more instructions than what I am providing here. Write down the database type (ex. MySQL), complete database name, username, and password. The database name and username are the ones displayed in MySQL Admin’s table after you create them. Typically they look something like mysite1_mt, where mt is the name of the database you created. You will not be able to access the database without the mysite1_ prefix! The same applies to your username.
15. In your FTP Client, go to the /public_html/mt-static folder you created earlier. Click upload and navigate to your local copy of Movable Type. Inside the Movable Type folder, open the mt-static folder. Select all (ctrl + a for most folks) and click upload. This does not erase the files from your computer. It copies them to your web server. Now, go play with your dog or read a book while everything is uploading. Uploading files is like watching water boil. The longer you watch, the longer it takes. Most FTP clients make a noise when their done uploading. If yours doesn’t or you don’t know if it does, check back every fifteen to twenty minutes.
16. Once the mt-static files are finished uploading, go to /public_html/.cgi-bin/mt/. This is where you will put everything except mt-static. Click upload. Select all (ctrl + a) and scroll through until you locate the mt-static folder and deselect mt-static. Click upload and and take a nice long walk. Come back in an hour or so.
17. Now, follow the directions on the Movable Type Quick Install to navigate to your page and set up your primary domain blog. Once that is complete, return to your FTP client.
18. In your FTP client, go to /public_html/.cgi-bin/mt/mt-config.cgi and download this file to your computer.
19. Open the downloaded mt-config.cgi using your text editor (Notepad, TextEdit, BBEdit, KEdit, etc. They all work for this.)
20. Under Required Settings, change the CGI Path and the StaticWebPath. To prevent security conflicts in Firefox, Safari, and Opera, the root url (ie: http://example.com) must match the root url of the primary site. In other words, if your primary site is http://www.example.com, your CGI path and Static Web Path should both begin with http://www.example.com, instead of http://example.com. If it does not, some features including writing new posts and changing themes will not function properly in these browsers. (They will still work in IE, which should make you question using it, but that’s a topic for another day.) In the end for the Primary Site’s blog with url http://www.example.com, your paths should look like this:
    #======== REQUIRED SETTINGS ==========
CGIPath http://www.example.com/cgi-bin/mt/
StaticWebPath http://www.example.com/mt-static/
StaticFilePath /home/example/public_html/mt-static
#======== DATABASE SETTINGS ==========
ObjectDriver DBI::mysql
Database examp1_mt
DBUser examp1_admin
DBPassword admin
DBHost localhost
    This allows all our add-on domains to access the stylesheets, widgets, etc.
21. Save the file using the mt-config.cgi name to a new location on your computer. When you do this, turn off the .txt extension and set the text encoding to ASCII. (Type text encoding into your help to locate this on your text editor.) This way you still have the new one and the old one.
22. In your FTP Client, go to public_html/.cgi_bin/mt/. Upload the new mt-config.cgi. When it asks if you want to replace the existing file, click yes.
23. Refresh your blog and verify that it still looks the same. If it doesn’t, there’s a typo in the urls, you wrote in the mt-config.cgi file. An easy way to check is to copy the url from your local mt-config.cgi and paste it into your web browser. If you get an page not found error message, the url is wrong. Correct the error and repeat step 21. Server error messages are a different ball game and may stem from a variety of causes including old .htaccess settings, corrupted files, etc. These should be troubleshooted by a professional. My advice is to take a screen shot of the error message and post the error on Movable Type’s forums or contact your host’s help desk.

In the past, I’ve used Scripts and Fantastico to automatically install software. I’ve never had good luck with these methods because the installation didn’t meet my needs, so I prefer manual installation. In theory, you could cut out steps 7, 8, 14, 15, 16, and 17 using one of these or a similar product where the Movable Type files are provided by your web host. I haven’t tried it and my host does not provide Movable Type on either of these platforms, so I don’t know.

Suggestions and comments to improve the above are welcome. Enjoy!

Related Posts:

• No Related Posts

The Truth About Grammar Check and Spell Check

A while back, a friend of mine showed me her daughter’s English paper. Her child’s paper was riddled with grammar and spelling errors. Accompanying it was a note from the teacher requesting a parent-teacher conference to discuss her daughter’s English skills. My friend was clearly affronted by the suggestion that there was anything wrong with her daughter’s work and firmly stated that she had personally run the grammar check and spell check before her daughter turned it in. I didn’t think much of this incident until a few days ago when I received a error riddled email from a well-educated friend who, while not a native English speaker, is well known for his precise sentence structure. He also happens to be the harshest and most precise editor I have ever had the pleasure of encountering. I called him later on and learned that his IT department recently turned on MS Outlook’s grammar check and spell check on all the computers. Although he was puzzled by some of the errors reported, he assumed the program was correct and accepted each and every change. Horrified, I suggested he return to the old-fashioned method and walked him through turning off the spell check and grammar check. Then, I did a little research and discovered some startling facts.

• Several studies suggest spell check and grammar check increase errors.
• In tests, the best grammar check program tested only caught 50% of errors.
• According to surveys, most school-age U.S. children regularly use a computer. Logically, they also use the grammar check and spell check.
• Some teachers require printouts showing that the child used grammar check and spell check. This printouts include word count and readability statistics including grade level.

Considering my personal experience with these programs, these facts are not surprising. Even in graduate school, our professors routinely advised us to use grammar check and spell check. In the same breath, most of them gave us a list of problems they’d experienced with these tools. Personally, I have not run grammar check in several years and rarely require the spell check feature, although I do leave it turned on. I regularly post to blogs, forums, and message boards and frequently write articles and short stories without using these features. The reason I don’t use them is simple- the word “maybe”.

English grammar contains many instances of maybe. It relies on an evolved, loose syntax that frequently borrows from other languages that use different grammatical structures and everything is contextual. The result is a set of rules with phrases such as “if you have this, you may want to do this or this, but you can also use this”. Grammar check and spell check programs are all written in computer programming languages. These languages are built using strict logic chains, specific syntax, and grammar. In many ways, they are more mathematical equations than languages and as I have tried to explain many times in the past, you simply cannot program “maybe”. Even the more sophisticated algorithm-based programs suffer from this affliction. Computer programs are not a substitute for knowledge!

Grammar check is not a substitute for a good understanding of the English language and a grammar handbook. I keep a well-worn copy of Stunk & White’s The Elements of Style by my desk and use it frequently. I check my spelling using several dictionaries. One is a large unabridged dictionary, which no office should be without. The others are discipline specific. Since research suggests people are more likely to skim computer screens than paper, I print out my writing. Then, I manually proofread it and enter the revisions. I normally repeat this process several times, checking the revisions each time. In my experience, this is the most accurate method of producing clean, consistent copy and I apply it to everything I write. Yes, it takes longer, but clean copy is worth an extra ten to fifteen minutes.

Sources:

Related Posts:

• No Related Posts