I Will Have No Hair In Five Years.

MySQL is an open-source relational database system. XML is a markup language designed to provide a good way to organize data and allow computers to get meaning from data (as opposed to HTML, where meaning must be inferred - not something today's computers are equipped to do). So what exactly do they have in common, to both be included in the same post?

They are, colloquially stated, a pain in the butt.

Let's start with XML. The Extensible Markup Language is a descendant of SGML (Standard Generalized Markup Language), which was designed to provide a standard document storage format. XML took that one step further by allowing users to define their own schemata. Once the schema has been defined, the XML document can be validated. After that, it can be transformed through the use of a stylesheet document. Pages thusly transformed will render as HTML, with whatever formatting you specify.

Sounds great, doesn't it? You have a language that you can fully customize to your needs and you can make it look pretty! This, my friends, was what I was still doing at 2:30 this morning, after having started some time in the middle of the afternoon. In my foolish, naive way, I believed that I could create an XML document with sample data, define the schema from that, create the stylesheet, and be good to go. Um...not exactly. The stylesheet is a very finicky animal, and it wants things served to it on a silver platter (oops, I meant "in a particular order, in a particular format). So now I have to figure out how to retool my schema and document in order to display the content I want, in the order I want.

However, MySQL was the topic for the day, when I finally dragged myself out of bed late this morning. After my compatriots and I had input all the data in our database, it occurred to me that one of our tables really needed a 1:1 recursive relationship. This particular table has 7 fields in its primary key. After being reminded of the fact that the ALTER TABLE command does, in fact, exist, I added in the appropriate columns and populated them.

Then I tried to add the foreign key constraint. Nothing worked. It simply would not add that foreign key, choosing instead to give me Error #150. At wit's end, I Googled "mysql 150 add foreign key" and came up with a 2006 MySQL bug report (bug 16290) complaining about the unclear error message that results from attempting to create a foreign key on a non-indexed column. "Aha!" I said to myself. "The columns I'm trying to reference aren't indexed." I created an index on all 7 primary key columns and executed the ALTER TABLE command to add the foreign key - and it worked. I was exceedingly happy.

Quote of the Day:

If you'll come up one by one, unarmed, I'll engage to clap you all in irons and take you home to a fair trial in England. If you won't, my name is Alexander Smollett, I've flown my sovereign's colours, and I'll see you all to Davy Jones.

--Captain Smollett, Treasure Island

iPhones, the Web, and Dashcode, Oh My!

Scene: A twentysomething plays with his iPhone.

Twentysomething: I love my iPhone! I could spend all day doing stuff on it. (thinks) You know, my personal website doesn't display very well on it, though. Everything's all tiny and jumbled up. I wonder how I could fix that?

And so our hero consults The Google for answers. He's not ready to pay the $99 for the privilege of submitting real native apps to the App Store, so he's settling for a little web app development.

There are two ways to develop for the iPhone. One, you can create a full-blown native app, which you can distribute via the iTunes App Store and possibly make money from. Two, you can create a web-based app, which will display in the iPhone's browser. You can't make money off a web app, but you don't have to pay the $99 fee to be in the iPhone Developer Program, either. On top of that, there are really two options for web development: modify an existing web page so it displays well in Mobile Safari, or use Dashcode to mimic the look and feel of a native app.

First, let's look at modifying an existing web page. Web pages are traditionally designed for full-size computer monitors with resolutions of 800x600, 1280x1024, or something similar. The iPhone is considerably smaller than that at 320x480 pixels. If left to its own devices, the iPhone will assume a page width of 980 pixels and scale that to fit the display. In portrait orientation (home button to the bottom), that means tiny pictures and illegible text, since 980 pixels is being forced into 320. Landscape orientation (home button to left or right) fares a little better, since it's only having to reduce to 480 pixels. Still, it generally ends up being pretty tiny.

So, how do we fix that? Obviously, we could leave it as-is and force the user to manually zoom in by double-tapping elements or pinching, but come on. We're classier than that. We're going to make use of a simple meta tag to change the scale. Drum roll please...

<meta name="viewport" content="width=device-width">

Hallelujah, text that's readable without a microscope!*

"That's great," our hero muses, "but I want something...better. How can I create something that looks more like an app and not a web page?"

Enter Dashcode. This is a free program (Macs only, sorry Windows devs) that includes templates, buttons, and code snippets that allow you to create real web apps that look like native apps. You can't take advantage of as many of the iPhone's built-in features this way, but for someone operating on a budget, it's a pretty good alternative.

When you open Dashcode, you can choose a template for your project: Browser, Utility, RSS, Podcast, or Custom. Browser is pretty much a menu interface: You put in a list of stuff, and when someone taps on an item, they get more information about that item. Utility's default interface is a notepad/text area with customizable settings. RSS lets you specify a Feed URL and displays a list of article headlines from that feed. Podcast functions very similarly, but instead of articles, it displays podcast titles and allows the user to listen to them. Custom presents you with a blank slate that you can customize to your needs. Whichever template you choose, you have to provide it with data sources and whatever functionality you need.

Either way you go, you're well on your way to creating a good web app!

*Obviously, there are more things you can tweak to optimize your web page for the iPhone. This is merely the most obvious and easiest. Seriously, Google is your friend.

Quote of the Day:
I was feeling pretty creaky after hearing the TV reporter say, "To contact me, go to my Facebook page, follow me on Twitter, or try me the old-fashioned way -- e-mail."
--Reader's Digest, November 2009, pg. 210

Best Practices for Producing and Distributing Video

Even though the capability to embed videos in web pages has been around since the inception of Macromedia Flash (now Adobe Flash) in 1996, the widespread use of video online has only become truly mainstream during the past few years. Therefore, the guidelines and best practices for Internet videos have still not been completely codified yet. However, in 2005, Adobe posted some best practices for delivering video content:

• Stream. There are three ways to deliver video content: downloading, progressive downloading, and streaming. If a user has to download a video file to play, he or she has to wait until the entire file downloads in order to watch it. In the case of large files (TV shows or movies, for example), this can take over an hour. Progressive downloading stores the meta information necessary for playback at the front of the file instead of the back, allowing the user to start playing the file before it finishes downloading. Streaming does not download the file to the user's computer at all. Not only does this let users view live events, it also protects the creator's copyright, since the data is never stored anywhere but the server.
• Pause. If the video loads with the first frame displayed and the video paused, the user can a) get a cursory idea of the video's content and b) decide if and when they want the video to start. YouTube is a high-profile offender: if you search for a video, then open multiple videos in new windows or tabs in your browser, all of them start playing at once and you have to manually pause each one.
• Preview. This does not seem to be widely implemented, but Adobe suggests playing a five-second clip on mouseover. This would give a better impression of the video's content than just showing the first frame.
• Detect. Some users simply do not have Internet connections that can handle large downloads. If at all possible, a lower-quality version of the video should be available. If working with Flash Media Interactive Server, the Server auto-detects the user's connection speed and serves up the video with the optimal quality for that connection.
• Standardize. There are common naming conventions to be observed. If a movie called "filename" is encoded at 600 Kbps, the Flash movie file should be named "filename_600". This allows the Flash Media Interactive Server to more easily deliver the proper file according to the connection speed it detected.
• Trace. Trace statements aid in identifying server side errors by following the application access activity on the server. It allows you to debug before the page even reaches the user.
• Optimize. The most annoying facet of streaming video is rebuffering. Make sure that you calculate the buffer time accurately. Adobe provides a tutorial on how to calculate this.
• Define. Who are you trying to reach? What are their connection limitations? Is the majority of your audience on dial-up? Answering these questions will help you determine what video content you can provide.
• Encode. The only way to distribute high-quality video is if it is converted into the proper format via an encoder. The best file types will be those that are viewable by most people, such as MPEG.

Other sites add a few more things to think about:

• Arun Chaudhary suggests that when shooting video initially, you should find a location that will enable you to get good sound. Visuals are not nearly as informative if there are no discernible sounds to accompany them. Also, choose descriptive video titles to aid in searching.
• Eric Carlsen suggests that companies should invest in hiring a video professional instead of displaying "user-generated" content. This avoids the amateur feel that pervades many YouTube videos.

In short, the basic underpinnings of video distribution best practices are similar to those of search engine optimization: Create good-quality content that is relevant and easy to find and view, and the visitors will come.

Web Analytics and SEO

I've written a paper on the use of web analytics and search engine optimization. It's available on Google Docs. If you haven't been given access, and you wish to read it, comment on this post with your email address and I'll see about setting up view permissions. Don't worry, I will not display your email address or send it to those nice folks in Nigeria. :-)

Quote of the Day:

Castle: We make a pretty good team, you know. Like Starsky and Hutch, Tango and Cash, Turner and Hooch...

Beckett: You know, now that you mention it, you do remind me a little of Hooch.

--Castle

Coffee Addiction: Reprise

Last week I talked about the fact that web designers have a horrible caffeine habit. Introducing the newest addition to the Coffee Family: Cappuccino.

Cappuccino was created in 2008 by the company 280 North, whose goal was to port Cocoa, Apple's object-oriented desktop application development environment, to JavaScript. It is an open-source framework, built on JavaScript, that allows you to create fully-functional applications that run entirely in your browser. It uses the Objective-J language, which has its roots in JavaScript and Objective-C. One of the key points of Cappuccino is that developers need not tinker with HTML, CSS, or the DOM; the framework takes care of that.

Cappuccino is a cross-browser implementation, working under IE, Firefox, Opera, Safari, etc., on Linux, Windows, and Mac. Some workarounds to address IE's shortcomings have been included in the framework, so web app developers have that much less to worry about.

If you want to get started with Cappuccino, it's easy enough. Download the Starter kit and go through the tutorials. It doesn't seem to be any harder to learn than similar languages. Happy developing!

Quote of the Day:

All that is gold does not glitter,

Not all those who wander are lost;

The old that is strong does not wither,

Deep roots are not reached by frost.

--The Lord of the Rings: The Fellowship of the Ring

Office Online

This is why I'm still using Office 2003:


Microsoft Office has been the de facto standard for office suites for, well, pretty much as long as it has existed. Need to generate a document with words, numbers, formulae, and/or pictures? It's a pretty safe bet you'll be using a Microsoft product for that. However, MS Office is a touch pricey and many people (and businesses, for that matter) cannot justify spending that kind of money every time a new version comes out.

Enter Web office apps. These are stripped-down, but free, MS Office-like programs that run inside your browser: Google Docs, Zoho, and the upcoming Microsoft Office Web Applications, to name a few. Due to limited time, I only tested the slide show apps included in each of these. (I also tested 280 Slides, which is a web app built on Cappuccino; there is no corresponding suite of office programs to go with it, but it's a neat program by itself.) So, how do they compare to each other and with the current non-Web app, MS Office?

Microsoft PowerPoint (Microsoft Office) is the standard. It does not run within your browser; it is a standalone program included in MS Office. It has transitions, animation, clipart, picture cropping, WordArt, everything. By default, files are saved in *.ppt format (except for the newest version of Office, in which case it is saved in *.pptx format). These files are readable in a multitude of viewers, and you can even use the "Pack and Go" wizard to include PowerPoint Viewer with your presentation. MS's decision to replace the menus with a ribbon interface in Office 2007, however, dramatically impacted its usability for longtime Office users who were used to where everything was in the menu system.

Features: 9/10 (could benefit from including more templates)
Ease of Use: 8/10 (Office 95-2003), 5/10 (Office 2007)
Ubiquity: 10/10
Overall: 9/10 (Office 95-2003), 8/10 (Office 2007)

Google Presentation (Google Docs) has the advantage of being run by the ever-ubiquitous Google. It has a word processor, a spreadsheet app, a slide show app, and a form editor. When you create a slide show, you can save it to your computer as a PowerPoint presentation (*.ppt). It has some decent slide templates. Entering text, pictures, and simple shapes is fairly straightforward. There does not appear to be any way to animate slide elements or have transitions between slides. If you want to have different font sizes associated with different list levels, you will have to manually change it yourself; you're also stuck with whatever bullet styles Google has assigned to each level.

Features: 6/10 (includes enough basic tools to get the job done)
Ease of Use: 8/10
Ubiquity: 8/10
Overall: 7.33/10

Zoho Show (Zoho) immediately runs into some issues. Unlike Presentation and PowerPoint, Show lacks any sort of right-mouse click functionality, meaning you have to find everything in the ribbon at the top. It allows you to change bullet styles, but some of the symbols may come across as question marks in your presentation if your browser does not support the proper font. Again, templates are limited, but that seems to be pandemic across all presentation programs. It will export to a *.ppt file on your computer.

Features: 6/10 (comparable to Google Apps)
Ease of Use: 5/10 (lacks context menus)
Ubiquity: 7/10 (lacks Google/MS name recognition)
Overall: 6/10

280 Slides has fewer templates and layouts to choose from than the other applications. You can have any bullet you want, as long as it is a large circle. Its features are simple and relatively easy to find, but limited. It does not support animation. It will export to a *.ppt or *.pptx file on your computer.

Features: 5/10
Ease of Use: 9/10 (no context menus, but good organization)
Ubiquity: 5/10 (lacks Google/MS name recognition)
Overall: 6.33/10

Zoho and Google are fairly comparable, so between those two I would choose Google, due to its ubiquity, (admittedly limited) context menus, and company stability -- Google is not going anywhere anytime soon. 280 Slides is good for tossing together a quick presentation on the go, but it lacks some of the features of the others. All in all, for basic needs, web app suites will get the job done, but for any higher-level functionality, looks like we'll be keeping our copies of Office for a while.

Quote of the Day:

see more Lolcats and funny pictures

Stop Reading This Blog.

Seriously. Stop right now. Go watch Dr. Horrible's Sing-Along Blog. And then go watch Firefly and Castle.

Done? Great! Now that you've seen some great shows, let's talk about rich media. Rich media is loosely defined as "pretty stuff that is informative or entertaining in some way". Got a graph showing how Napoleon's army got smaller the closer he got to Moscow? That's rich media, because it has a lot of information packed into one diagram that can be read in many ways. Got a TV show online? That's rich media. Got a website that tells you everything you ever wanted to know about emotions manifesting themselves in blogs? That's rich media, too.

Did you notice anything different about Dr. Horrible's Sing-Along Blog? Instead of showing an air date, Hulu lists it as a "web exclusive". What's really impressive, however, is that it won an Emmy. An Emmy, folks. A television award was given to something that was never shown on the boob tube.

A few years ago, television networks started putting some of their shows up on their websites for viewing (after they aired on TV, of course). Now, most shows are online within 24 hours of their initial air date, which is threatening to invalidate Nielsen ratings and cause a major shift in TV viewers' habits. Since currently online shows have typically only one 30-second commercial at each break instead of two to four minutes' worth, I'd say it's a pretty safe bet that online broadcasts don't generate as much money for the networks as traditional TV.

Still, putting shows online has the potential to expand a show's audience. Maybe someone has a scheduling conflict that prevents them from watching a show when it airs, but they discover it online. Maybe they even go out later and buy the season DVD, which equals money for the network anyway. Networks are already trying to figure out how best to monetize their online content, and I predict that they will continue changing and refining their strategies. Online rich media is here to stay.

Quote of the Day:
Zoe: Cap'n'll have a plan...always does.
Kaylee: That's good, right?
Zoe: It's possible you're not recalling some of the cap'n's previous plans.
--Firefly