So here it goes: Can a self-taught web standards developer who knows just enough JavaScript, jQuery, ASP and ActionScript (read: can borrow your code and manipulate it to do what he wants) to be dangerous, but has no real foundation in programming or computer science, learn to make iPhone apps?

We're about to find out. In my downtime this summer, I'm undertaking trying to learn enough Objective-C to create some basic apps. Since I've always been the type to learn from books, and there's always something new to learn about the web and computers, I figured, why not give it a shot?

Even the dumbest iPhone app stands to make a few bucks. So my goal is simple. Make a $1 app that will get downloaded enough to pay for the investment of learning how to make it. I'm gonna estimate that cost will land somewhere in the neighborhood of $250* after the $99 developer membership with Apple and the cost of a few good books. And if the first one doesn't catch on, well, it's another tool for the old toolbelt.

* That cost doesn't include the cost of a new iPhone. We'll get around to that eventually.

Labels: iPhone

After almost four years in hibernation, I've resurrected this blog, as I refocus the site to tackle web development, social media and emerging trends in the digital publishing world.

Is this flood of social media, Facebooking, Tweeting, AJAX and what-have-you overhyped? You bet. The backlash is already underway, but if you're a professional in this space, it behooves you to at least try to stay on top of it all, and if you can't, you've got to at least fake it, right?

So with that in mind, we relaunch in the hopes not of developing any sort of following, but simply to chronicle the developments as they happen and keep track of points of interest along the way. Lofty aspirations, no?

I suppose a redesign that integrates some key components of the modern-day web is in order as well. One thing at a time.

Labels: Facebook, social-media, twitter, web-standards

I'm a stickler for semantics when I code a site, but the more I think about properly coding input forms with semantic markup, the more I think that it's actually semantically correct to use tables to structure a form.

Sound like anathema? Maybe so. But I'm certainly not the first to suggest that tables are actually suited for the task.

Here's my take: As long as you aren't using attributes in the table to manage the layout (remember our friend CSS?), I think table rows, headers, data cells and captions are all worthy of marking up a form. And more important than being worthy, I will argue that tables are essential for form layout, especially with backwards-compatibility in mind. Because while you can lay out a form with CSS and avoid tables completely, your layout may not necessarily degrade gracefully in older clients. However, with tables, forms still maintain a structure that allows them to make sense, with or without CSS.

Here's the issue: The relationship between a piece of data and it's label doesn't have to be visual, but when you have two or more pieces of related data (or potentially hundreds, thousands, etc.), representing the relationships that exist between different items in the same group of data is absolutely essential to interpreting the meaning of said data.

A table indicates the very essence of those relationships, and it just happens to do that in a very visual manner, the same way a carraige return indicates a new paragraph, which is a visual clue that a new thought is on the way. In the case of HTML, the <p> tags make this distinction, which I ironically forgot to include in the first version of this post.

Anyway, think about the last form you filled out. If you entered your name, address and credit card number, you were giving away what will essentially become tabular data. Your vitals become part of a table when it enters the database, and then likely again when it's displayed in a customer record.

So isn't this data tabular before it enters the database as well?

If that's the case, it stands to reason that a <label> element belongs in a <th> cell, and the ensuing input element would be placed in a <td> cell.

So now the question becomes, is placing a <label> inside of a <th> cell redundant? I'd say no, because of the added functionality that a <label> element, properly marked up with a for="" attribute provides. With a matching for="" attribute, most browsers allow you to activate the labeled element by clicking on the text of the label. Of course, you could duplicate this functionality with some DOM scripting, but that seems like a lot of work just to avoid one extra element in your code.

Can you layout a form without a table? Absolutely. But is it semantically incorrect to use a table to structure your form? I don't think so.

Labels: accessibility, semantic-code, tables, XHTML

Reknowned CSS guru Tantek Çelik gave an rock-solid presentation on "Meaninigful XHTML" at Web Essentials '05. I wasn't there, but he's posted the deck to his blog, so you can relive the presentation in the comfort of your own monitor like I just did. That's swell.

And now after reading his presentation, I need to go back into my templates and change how I deliver links to other people's blogs. I guess I never really thought of linking to a blog as a citation, but that's essentially what your doing. Ah, semantics. Gotta love 'em.

Labels: semantic-code, XHTML

Molly Holzschlag drops some knowledge on what to expect as the browser shifts from the desktop to the palmtop, if you will. And no need for shades, because it sounds like the future ain't to bright for front-end developers.

The crux of the issue: The varying flavors of XHTML (specifically, XHTML-MP and XHTML Basic) supported by various handheld devices, and the lack of consistent implementation of those standatds (sound familiar?) in said devices. Just when you thought browser testing was about to die, it's really just begun.

And now we're wondering: Has anyone assembled a handheld device browser testing lab? Will there be a way to emulate these browsers on the desktop to streamline the process? When will clients start asking for this stuff?

Labels: mobile, web-standards, XHTML

I've been writing HTML/XHTML for the last decade or so, since a college internship. I taught myself the basics back in the mid-90's with the help or a friend and one of those "Learn HTML in 24 hours" books. It probably was something more like 10 hours before I really felt like I "knew some HTML". And the idea of making a website that anyone in the world could visit was fascinating to me being a journalism major at the time. Cutting out the middleman and becoming your own publisher was pretty spectacular to me.

I've literally been feeding myself on the proceeds of my markup ever since.

The coolest part about this is that despite spending so much time mastering web development skills, there's always something new to learn, a new approach to take or a better way to build your site. First it was Photoshop. Then it was JavaScript and CSS. And despite no real training in programming, and not really having the brain of a programmer, I learned some PHP. Then I took on ASP and ColdFusion. I was into Flash for about a year or so. Then back into CSS. Then I took up interest in accessibility. And before I knew it, I had to learn C#/.Net, and in the process, joined it with Web Standards to take my skills to the next level.

But after doing a code review today on a standards-based client site today, I realized just how satisfying it is to know that I've poured the last decade of learning into the templates I've just produced. I think that's pretty cool. Sometimes I have to remind myself that just because I read blogs of developers who really are professional site builders like myself, the fact of the matter is that it's still a rare breed of website developers who've been in the game this long and who are actually using web standards.

Labels: CSS, Flash, web-standards, XHTML

ESPN.com snuck this beauty into their Bill Simmons RSS feed: "Free Fantasy Football Drafts from Work or Home! Sign up!". The more I think about it, RSS has become the TiVo of the Internet, allowing you to effectively "skip the commercials" and go directly to the content you want.

So ESPN is now striking back by forcing aggregators to pick up a post which is nothing more than an advertisement for their Fantasy Football service, which by the way, choked pretty hard during last Sunday's opening weekend. While it's a savvy move by the self-proclaimed Worldwide Leader in Sports, I'm not to sure how I feel about it. I subscribe to ESPN.com's Bill Simmons feed so I'll know when he posts a new article. I don't want -- or need, for that matter -- a reminder to set up a Fantasy Football team.

Then again, at least the ad was ESPN related. How long before we see them selling a spot in the Simmons feed to outside advertisers? Given his wild popularity and the gaining traction of RSS aggregators, I think it'll be sooner rather than later.

Meanwhile, local site Boston.com just added RSS feeds to their news section, and we're waiting patiently for their (hopefully) forthcoming sports page RSS feed.

Labels: advertising, RSS