Instant Results and Spin

After reading the transcript of the SpoolCast episode Luke Wroblewski and Innovations in Web Input, I decided to write about two subjects they brought up. It's a double post! What does it mean?!*

*Yes. This joke is stale.

Isn't Google Instant Awesome?

I mean, really! You start typing and (as long as you're not using Opera) results just pop up (unless your connection's too slow)! It's like magic! It makes Amazon's search suggestions look quaint and your public library's catalog search look positively archaic! Why can't they do magic like that, too?

Well, Google has approximately one quadrillion times the resources of your public library, for one thing. Something like Google Instant takes a lot of resources. If a company tries to implement something like that without the required resources, the resulting performance hit (and probably downtime) is as bad as or worse than not having search at all. Yahoo! actually tried to implement something similar to this in 2005, but they ended up ditching it because they were concerned about server load.

This does put smaller organizations at a bit of a disadvantage, because if people get used to seeing results instantaneously, they start expecting it everywhere. Why should I have to type my entire search query, hit enter, and wait for another page to load? (I guess you could argue that Google is aiding Twitter's nefarious plot to shorten the attention span of the world's population.) Unfortunately, though, businesses have to allocate resources to the activities that will provide them with the most benefit, so Google Instant-esque capabilities are probably going to be fairly low on the list.

Their Numbers Don't Mean As Much As You Think They Do.

I used this analogy recently…there's 160 million iTunes users, and within 48 hours they announce that one million of them were on Ping. So the metaphor I used there was, well if 160 million people are driving down a road, and I put a pile of dog poo on that road, chances are one million will drive through it. — Luke Wroblewski

In a world where Apple can do no wrong, their music social network Ping is a fledgling feature that hasn't yet reached its full potential. In the real world, well, it's been compared to a pile of dog poo. "One million" is a useless measure without context. I'd love if one million people read my blog. Facebook would probably kill a new feature that only attracted one million users. For the iTunes Store, one million is less than 0.7% of their users.

On the other hand, one could argue, for the time period mentioned in this anecdote, maybe 160 million users isn't the metric we should use to judge Ping's success. Surely, not all 160 million people are trying to buy music at the same time. Maybe only half of them are typically online at any given time. That makes Ping's user base…just over 1%. The point is, a company can spin numbers in a multitude of ways to make themselves sound better.

(Wroblewski goes on to suggest that the reason for Ping's disappointing adoption rate is an uncharacteristic lack of attention to detail on Apple's part. Version 2 might be better.)

Usability In The Rainforest

On the web, usability refers to the ability of users to find and use stuff on a website. (How's that for a circular definition?) According to Mel Pedley on Accessites.com, there are five core components of usability:

1. Learnability: On a first visit, can users find what they're looking for?
   
2. Effectivity: Can users do stuff quickly?
   
3. Memorability: If it's been a while since a user was on the site, can s/he still use the site?
   
4. Reliability: How error-prone are users while using the site?
   
5. Enjoyability: Do users like using the site (or, at least, do they not hate it with the burning passion of a thousand suns)?
   

Let's explore these concepts with a site we're all familiar with: Amazon.com. Sarah has been living in a rural area with ridiculously slow dial-up for the past several years, and has just discovered that you can buy products online. She needs to order a new DVD burner so she can mail her mom some home movies. She types "buy stuff online" into Google.

She sees that Amazon is the first result, and decides to click on it. (Hey, bonus points for findability!) She is then dumped onto Amazon's main page.

Okay, not a problem. Amazon's apparently a big site, which makes sense since her search query was very general. She looks around for "DVD Burners", or "Computer Components", or anything that looks like it could be what she's after. There's "Computers & Office" in the sidebar, and voila! There's "Computer Components" right there.

Lots of computer components to choose from. She remembers now why she asked her nephew for help the last time she needed to buy computer parts. Where are the DVD burners?

She scrolls down and – oh, there they are! Her nephew told her once that optical drives are the same as CD/DVD drives, so she clicks there.

She's still looking in the upper-left corner when the next page loads, so she immediately sees the link for "DVD Burners" in the navigation and clicks on it, too. No use in seeing all that other stuff she's not after.

Now that Sarah has found the DVD burners, let's evaluate how Amazon has been doing so far.

• Sarah could find what she was after with relative ease, so they get a point for learnability. (On the other hand, if she had been looking for something more obscure, she probably would have had a harder time of it.)
• She didn't have to waste a lot of time to get to where she was going, but she had the benefit of already knowing that "optical drives" and "DVD burners" were synonymous. Therefore, Amazon's effectivity was mediocre.
• This is a first-time visit, so we're not analyzing memorability.
• Sarah could easily have missed the link she needed to click on a few different times, because it was not necessarily put in a place that made the most sense. Reliability may or may not be an issue.
• So far, Sarah doesn't have a problem with using the site, so its initial enjoyability is not an issue.

What could Amazon do better? This is a hard question. One's first inclination might be to say that they should make it easier to find what people are looking for. The problem with that in this case is that because Amazon carries so many products, if they tried to make it easy to find everything, that would make their site too complex and cluttered to find anything. Burying some things three or four levels deep may be the best way to organize the information. Sometimes you have to make compromises to create the best site possible.

Accessibility Is The Path To Awesomeness

Accessibility in the context of a Web site is the degree to which that Web site is usable by people with disabilities. Web pages often have access issues for the following groups of people:

• Visually impaired people using screen readers
• Hearing impaired people using browsers with no sound
• Physically impaired people
• Color blind people (About.com, "Definition: accessibility")
  

That's one definition of accessibility in an online context. A simpler definition might be: A web site that everyone can use. That's a touch simplistic and idealistic, but it gets closer to what accessibility truly is.

There are a lot of resources out there devoted to helping web designers make their sites more accessible. The University of Minnesota, for example, has a long list of resources and tools related to accessibility. It's pretty overwhelming. About.com also has several articles about accessibility.

There's a simpler method, though, and while it's not 100% foolproof, it will get you fairly close to an accessible website. It is this: Use common sense and well-formed HTML code.

"But," you protest, "what about access keys, and alt text, and all those other things they talk about?" Remember what I said about well-formed HTML code. Images are required to have alt attributes in order for a page to validate. (Pages will still validate with blank alt attributes, though. That's where using common sense comes in: does the page still make sense without the image and without any alt text?)

Access keys (alt+[key]) are slightly different, as they are not required in valid HTML code. It also doesn't always make sense to use them. Using too many on a page can be overwhelming for a user. You also have to be careful not to use keystroke combinations that are already used for browser menus or other similar functions.

The WAVE report for the main page of Wikipedia reveals the access keys that are in use there. By my count, there are 14 different access keys, which make varying degrees of sense. Alt-F might make sense if the search field were labeled "Find articles", but it is not. Alt-U for "Upload file" does make sense, but Alt-K for "Related changes"? Another problem with using Alt-F to get to the search field is that that combination is used in nearly every Windows program to access the File menu. Firefox gets around this by adding Shift to the access key combination (Alt-Shift-F), but Safari overrides the default (Alt-F always brings up the search field).

Wikipedia does do something right, though. If you disable styles on the page, the navigation drops down to the bottom of the page. This makes it easier for people with text-only browsers or screen readers to get to the content.

Another important aspect is the color scheme. If you're planning on designing a Christmas website with red text on a green background, remember that about 5-7% of people suffer from red-green color blindness, or protanopia/deuteranopia, which would make it extremely difficult or even impossible for them to even see that there's text there. Tritanopia is another type of color blindness that affects a person's ability to see blue. One of my friends in college suffered from monochromacy and could only see shades of gray. When choosing colors, you might try using a graphics editor to convert them to grayscale and see if there is enough contrast there even without any "real" coloration.

Finally, organizing content in a way that makes sense is probably the most important step towards accessibility. Remember, you're not designing just for someone with a disability. You're designing for everyone.

Beauty In Type

@font-face {
font-family: "FontinSansRegular";
src: url('fonts/fontinsans.eot');
src: local('?'), url('fonts/fontinsans.woff') format('woff'), url('fonts/fontinsans.ttf') format('truetype'), url('fonts/fontinsans.svg#webfontn8vXGJ0x') format('svg');
font-weight: normal;
font-style: normal;
}

Do you know what this is?

It's the future.

Okay, maybe it's not quite that dramatic. However, it does represent a huge step forward in web design. It's a web font declaration in CSS.

Let's go back to the dark ages, when Internet Explorer and Netscape Navigator ruled the Internet. In those days, text online was rendered in whatever fonts you had on your system. Running Windows 95? You got Arial and Times New Roman. Running a Macintosh? Default fonts were Chicago and New York.

Then came CSS, Internet Explorer 3, and the core fonts for the Web project.

The core fonts project aimed to provide a set of fonts that would be widely downloaded and used, which was supposed to ensure that websites looked the same across platforms. The downside to this was that the fonts had to be present on the user's system, not just on the web server. Granted, due to Windows' near-complete domination of the computer market, the vast majority of people probably did have the fonts installed. With the new (partial) CSS implementation in IE 3, you could specify typefaces. Yes, that's a choir of angels you hear singing "Hallelujah".

It still wasn't perfect, not by a long shot. You were still limited to whatever fonts your users had on their systems. You could be reasonably sure, however, that the fonts included in the core package were going to be present for the vast majority of your users. I mean, I could design a page using Footlight MT Light, but it might fall back to Times New Roman on your system.

With the introduction of the @font-face declaration in CSS 2, you could finally reference fonts that weren't stored on the user's computer! In the example above, I'm telling the browser to grab the Fontin Sans file, which is stored in the subfolder fonts. On my server. Not your computer. As long as you're using a browser that's at least as new as Internet Explorer 4, you'll see Fontin Sans on this webpage.

"Wait!" you say. "It displayed your fancy-schmancy new font after a minute, but when it first loaded, [it was in Times New Roman/I couldn't see any of the text]! What gives?"

Yeah, that's the problem with using @font-face. Pingdom says that fontinsans.ttf is one of the last things to load, and it takes a comparatively long time to load on top of that. Until it loads, the page is in limbo. Different browsers handle this limbo time in different ways. Firefox and Opera temporarily fall back to the next font in the font stack. Safari completely hides the text (though not the underline on hyperlinks, interestingly enough; if you load that page in Safari, you can see random lines going across the screen). Internet Explorer, for me at least, takes so long to load the entire page that it renders in Fontin Sans when it finally displays.

When the page is finished loading, though, the typeface is so beautiful that it makes Michelangelo weep.

(Again, maybe not quite that dramatic.)

Want to learn more?

• Web Typography
• 50 Useful Design Tools for Beautiful Web Typography
• Web Open Font Format
• Arial or Helvetica?
  

Buildings, Triangles, and Big Balls of Mud

Christopher Alexander had a problem. Actually, all architects had a problem. There they were, being hired to design buildings, and their clients understood the buildings more than they did. The problem, essentially, was translation. How could an architect take what the client described and turn it into what the client wanted?

Simple, Alexander said. Clients want basic variations of a set of buildings. We need a language that describes basic stuff (that's a technical term) in our problem domain, building buildings, that is simple enough to be understood and used by our clients: a pattern language. "The elements of this language are entities called [design] patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Design patterns are not one-size-fits-all, cookie-cutter solutions. Instead, they are skeletons, templates, general descriptions of how one might solve a type of problem. For example, it has been determined that people like rooms where natural light comes in from two directions. That's a design pattern. Notice that the pattern does not say, "Put one 16"x30" window on the north wall, and one 24"x30" window on the west wall." It says, "The optimal room has natural light coming in from two directions."

Alexander came up with this concept in 1977. To this day, it has had a mixed reception in architecture. In 1987, however, Kent Beck and Ward Cunningham got the idea of applying the principles of design patterns to software. The "Gang of Four" (Gamma, Helm, Johnson, and Vlissides) popularized that usage in their 1994 book, Design Patterns: Elements of Reusable Object-Oriented Software (Wikipedia).

Good design patterns, in computer science, are classified in four categories: creational patterns, structural patterns, behavioral patterns, and concurrency patterns. Creational patterns define how an object is created. Structural patterns define relationships between entities. Behavioral patterns define methods and patterns of communication between entities. Concurrency patterns define how to deal with multiple threads in a program. Wikipedia has some good descriptions of software patterns.

An example of a good design pattern is the creational pattern abstract factory. An example of an abstract pattern is the AbstractCollection class in Java. This class provides the basic skeleton required to create a collection of objects. It has methods to add items to the collection, remove items from the collection, get the size of the collection, etc. Individual methods in the class can be overridden in subclasses to provide functionality specific to that implementation. Several classes implement AbstractCollection in a more specific way. ArrayList, by way of AbstractList, implements the methods so that they work with a resizable, sortable list of objects of a specified type. List implements them to work with a list of specifiable, but fixed, size.

To put it in simpler terms, an abstract factory pattern is like the definition of a triangle. The abstract definition of a triangle is that it is a shape with three sides. The abstract methods would be implemented in the classes RightTriangle, ObtuseTriangle, and AcuteTriangle, which would place restrictions on the angles of the triangle, as shown below (Wikipedia).


Bad design patterns are called antipatterns. While good patterns have dry names like "abstract factory", "composite", and "chain of responsibility", antipatterns have been given such monikers as "spaghetti code", "God class", and (my favorite) "big ball of mud". The big ball of mud starts out as a relatively simple piece of software, then through the addition of bits of throwaway code, quick fixes, and piecemeal growth, becomes an unwieldy, mutant program that would take a good deal more time and money to fix than it would have taken to properly maintain it in the first place. By leveraging all of my considerable artistic talent, I leave you with this insightful look into big balls of mud:

Norway, Ireland, and Redmond

Microsoft has a hand in everything, it seems. One of their current ongoing projects is SQL Server Modeling, formerly known as Oslo. (If you're interested, it has been released as a Community Technology Preview.) According to Douglas Purdy, this consists of:

• M, a language for defining queries, schemas, etc. (like MySQL);
• Quadrant, a tool for interacting with SQL databases (like Access); and
  
• Repository, the back-end that communicates between applications and systems and stores data (SQL Server).

It was originally conceived as a sort of broad cross-platform modeling solution. M is open-source, but MS's implementation ties it to SQL Server. (Parts of the original Oslo project were split off into Dublin, .NET Services, and WF/WCF 4.0, while the modeling bits listed above stayed with Oslo.)

M has three specifications: T-SQL (Transact-Structured Query Language, Microsoft's proprietary extensions to SQL), grammar (originally called MGrammar), and EDMX (an XML file defining an Entity Data Model) (source). M is a domain-specific language (DSL). Its purpose, according to Microsoft, is to make it easier for users to interact with the database.

It's kind of difficult, as someone who has never heard of SQL Server Modeling before this week, to determine what, precisely, is its purpose. On first glance, it appears to be a set of data manipulation tools. However, Microsoft's aim seems to be more all-encompassing than that. It doesn't help that their aim has changed drastically in the three years they've been working on it. Time will tell if it catches on, and in what capacity.

Quote of the Day:
Beckman: Your country is calling you, Mr. Bartowski.
Chuck: Uh, well, then I think my country might have the wrong number.
--Chuck, "Chuck Versus the Ring"

Yay for Holidays...

...when I have way too much time on my hands. Here's some of the stuff I've been doing.

1. Installed Firefox 3.6 beta 4. I can't begin to describe the joy my nerdy little heart felt when I discovered the Zelda persona. Now my browser is complete with the Triforce, Sages' Medallions, and some Rupees thrown in for good measure. (Personas are skins for Firefox. Chrome supports something similar, but none of their themes appeal to me.) The beta has also changed the behavior for opening links in new tabs: instead of opening all the way to the right, like in Firefox 3.5, they open right next to the parent tab. I still cannot stress enough how much I dislike the Awful Bar, but other than that, I can't complain about anything. Firebug and the Web Developer Toolbar still work, so I'm happy.
2. Downloaded the source code for Chrome OS. I successfully followed the instructions to build a working version of the OS, but neither my bootable flash drive nor the .vmdk image would work in VirtualBox. For some reason, the OS refuses to log in with my Gmail account, my other Google account, or the default chronos login. Sigh.
3. Tinkered with some Java. A (non-programming) friend of mine was trying to write a Java program that would display information in some arrays and perform some basic calculations, but didn't know how to get the program to pull individual values out of the array. I helped her figure out how to do that and write a while loop that would perform the calculations on all five sets of values. Yes, perhaps there are greater things to get excited about, but I love the smell of success on a Saturday morning, no matter what form it comes in.
4. Stayed up way too late on Thursday night/Friday morning to snag all those amazing Black Friday deals. </sarcasm> The best deal came today, when I got Firefly: The Complete Series for $10.99.
5. Did some video editing. Nothing like a little editing to tell you that your awesome system that scores 5.2 and above on all aspects of the Windows Experience Index is really just an underpowered piece of junk. But I'm happy with the output...quite happy, in fact.

And in the spirit of Thanksgiving, here are some programs I'm thankful for:

1. Foxit Reader. It does everything Adobe Reader does, only faster and without all the bloat. In addition, Foxit has paid programs for editing and creating PDFs, like Adobe, but their programs are cheaper.
2. Parallels. I've got a WinXP and a Ubuntu Linux VM with this. The sad thing is that some of my older Windows games function better on the VM with a fourth of the memory that's on my Win7 computer. Some things I just don't understand.
3. GoldWave. This is the best audio editing software ever. True, it isn't open-source like Audacity, but it just feels more intuitive to me. Plus, it has a very generous trial period -- you'll have plenty of opportunities to decide whether you like it. The Noise Reduction feature is the best thing since cotton candy.
4. TextWrangler. This far outstrips Notepad. It has (limited) code highlighting, and it preserves indents when you hit Enter.
5. Tap Tap Revenge 2. I can't afford Guitar Hero, so this is the next best thing. I only wish it had more songs that I like.

Well, I mentioned Firefly, so I have to have another quote from there today!

Quote of the Day:

Take my love, take my land,

Take me where I cannot stand;

I don't care, I'm still free,

You can't take the sky from me.

--Firefly theme song

More iPhone!

As a follow-up to "iPhones, the Web, and Dashcode, Oh My!", it is possible to mimic the look and feel of a native app/Dashcode-generated web app without using Dashcode. There are several WebKit-specific CSS stylings that will generate native-like gradients, rounded corners, etc. My favorite (because I like shiny stuff) is -webkit-gradient, which allows you to have a light color gradate to a dark color without having to create a separate image in another program and load it in. Here's the correct syntax for the gradient:

background-image: -webkit-gradient(linear, left top, left bottom, from(#ccc), to(#999));

Explanation from left to right. background-image is the CSS property for, well, displaying a background image. Instead of specifying a URL as a value, though, in this case we're specifying a -webkit-gradient. The gradient requires several values:

1. Type of gradient. There are two types: linear and radial. Linear gradates in a straight line from Point A to Point B. Radial gradates in a circle from a specified point for a specified radius. An example of the two types is at webkit.org (only viewable on a WebKit-based browser like Safari or Chrome).
   
2. One or more points. Point values accepted are coordinates, percentages, or the keywords "left", "right", "top", and "bottom".
3. Starting color. Colors can be specified in hex values or RGBA (red, green, blue, alpha).
4. Finishing color. Colors can be specified in hex values or RGBA (red, green, blue, alpha).
   

Moving on to rounded corners. This is slightly more annoying to code. Each corner must be coded separately. Assuming the rounded corners are being applied to a list, the code to generate rounded corners is as follows:

#header ul li:first-child a {
  -webkit-border-top-left-radius: 8px;
  -webkit-border-top-right-radius: 8px;
}
#header ul li:last-child a {
  -webkit-border-bottom-left-radius: 8px;
  -webkit-border-bottom-right-radius: 8px;
}

In the first CSS declaration, the CSS code is looking for an anchor tag within the first instance of a list item within an unordered list within the header div. In the second declaration, the code is looking for an anchor tag within the last instance of a list item. The corner radius has to be applied to the first and last li tags separately, instead of applying it to the entire list, because if it's applied to the entire list the li's style will override the list's.

There are many more things you can do with JavaScript, Ajax, and CSS to approximate the feel of a native app on the iPhone. Check out Building iPhone Apps with HTML, CSS, and JavaScript to learn more.

Quote of the Day:
Jayne: Testing, testing. Captain, can you hear me?
Mal: I'm standing right here.
Jayne: You're coming through good and loud.
Mal: 'Cause I'm standing right here.
--Firefly, "The Train Job"

All Kinds of 'bilities

Findability is the quality of being able to be located by potential users. You may have the greatest website about (insert favorite subject here), but if it's buried, unorganized and unlinked, in the depths of Angelfire, nobody will ever know about it. Findability != SEO; it is focused on humans, not search engines. If findability efforts benefit search engine rankings, that is good, but it is not its primary aim. Findable websites not only facilitate initial visits, but they encourage visitors to return and to recommend the website to friends.

Findability does not exist in a vacuum. It is a part of SEO, but it is not a bunch of keywords stuffed in a page. It is useful content, organized for people to find, read, and use. Once people find your website, they have to be able to use it. Usability describes how easy it is to, well, use the website. Usability is different from accessibility: usability is more about organization and ease of use, while accessibility is about making sure that the website is available to the maximum number of people.

Members of Aarron Walter's Findability class at the Art Institute of Atlanta came up with the following definitions for findability, accessibility, usability, and SEO:

Findability: The quality of being able to be navigated or located.

Accessibility: The general term used to describe the degree to which a product (e.g. device, service environment) is accessible by as many people as possible. Usability and accessibility are often confused. See Also: http://www.w3.org/WAI/

Usability: The term that describes the quality of a website that determines how well tasks can be accomplished and how easy the website can be used. This can be broken down into many qualities, such as learnability, memorability, and efficiency. See also: http://www.useit.com/alertbox/20030825.html

SEO:Search optimization is a hyper-competitive endeavor that requires intense focus and a thorough, up-to-date understanding of how the search engine algorithms and robots operate.

(source)

Resources:

• The 10 Worst Findability Crimes
• Findability, Orphan of the Web Design Industry
  

Quote of the Day:

http://www.flickr.com/photos/morville/ / CC BY-NC 2.0

iPhone Web Development Resources

Yay, time for List Monday. Today's list: sites about iPhone web development.

General:

• iPhone Web Development presentation, covering Mobile Safari's limitations, using the viewport, iUI, and more
• Put Your Content In My Pocket, discussing best practices for optimizing web content for the iPhone
• Manifest Interactive's free tools, including several useful JavaScript/jQuery utilities
  

Working with the viewport:

• Configuring the Viewport, telling you everything you ever wanted to know about the viewport
  

CSS on the iPhone:

• Optimizing Web Content, covering the behavior of the iPhone OS when it encounters conditional CSS
  

Using WebKit:

• 6 WebKit Tricks, revealing the secrets behind some (rather gimmicky, but pretty cool) tricks to enhance the display of content
  

iUI:

• iUI on Google Code, obviously, the official code site for iUI
• Writing an iPhone Page In Minutes Using iUI, which gives sample code and general practices for developing with iUI
  

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

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

JavaScript Will Not Get You Coffee.

Apparently, web developers are chronic coffee abusers. There's Java, the programming language. There's CoffeeCup, a web design program similar to Dreamweaver. There's JavaScript (which, coincidentally, has nothing to do with Java), which was originally codenamed Mocha. I'm definitely sensing a pattern here.

Anyway, JavaScript was developed in 1995 as a relatively accessible language for amateur web developers. It was originally designed for Netscape Navigator; Microsoft developed a similar language, JScript, to fix compatibility issues with Internet Explorer and provide a language that could handle the catastrophe of changing centuries, but today both languages are considered nearly synonymous. JavaScript is run client-side and is object-oriented. According to Tiobe, JavaScript is the ninth most popular programming language, behind such languages as Java, PHP, and Basic.

JavaScript code must be enclosed in <script> tags with the type attribute set to "text/javascript". You can code anything from a simple line of text -- document.write("Hello, world!") -- to a confirm box that appears after you click a link on a page, to a window that opens with a sound clip. The possibilities are endless.

I actually have only passing knowledge of JavaScript. My abilities with that language consist of Googling what I'm after, with "javascript" tacked on the end, and modifying code I find to fit my needs. I know only enough to be dangerous, as they say. But hey, we all have to start somewhere, right?

Quote of the Week:
"What's in a name? That which we call a rose/By any other word would smell as sweet." --Juliet, Romeo and Juliet