Technology Is At Its Very Best When It’s Invisible

Apple’s iPad 3 video starts off with what I think should be the guiding principle behind all user experience:

We believe technology is at its very best when it’s invisible. When you’re​ conscious only of what you’re doing, not the device you’re doing it with…

Apple is still a hardware company and selling iPads, so they used the word “device”, but it’s safe to change this to “technology” and not loose anything. Go ahead, read that sentence again before continuing.

That principle is the reason the iPad is dominating the tablet market. That principle is the reason the iPhone sells so well despite its high price tag (in a bad economy no less) and being so locked down. If it wasn’t for that philosophy Apple would be in trouble. That principle is the explanation for everything that technology implementors just don’t get about Apple. Same goes for Facebook and even Google (to a degree). That principle is everything in consumer technology.

This is why I disagree with the “learn to code” mantra of 2012. It’s well-intentioned, but it shouldn’t be necessary. It violates this golden principle. It completely flips this principle upside down. It makes only the technology visible and abstracts what you’re actually trying to accomplish. It’s the complete opposite of what users want and expect from technology. That is why programming never became mainstream. That’s why repairing your own car or home appliances isn’t mainstream. When you make the technology the focus, you loose.

We won’t have flying cars until the necessary technology is simplified to the point where it’s as simple as steering in the direction you want to go and some basic driving flying rules (which are etiquette more than technology limitations). You don’t expect people to understand lift coefficient (CL) or Angle Of Attack (AOA) to go grocery shipping. That’s why we have pilots and people drive cars. I expect a pilot to understand these concepts and avoid a stall. When it’s Jetsons simple, we’ll have flying cars.

Want to enable creation? Abstract the technology to the point where the user only focuses on content creation. There’s a reason why email didn’t take off until AOL made a pretty easy to use client (by 90′s standards). There’s a reason photo sharing didn’t takeoff when you could just email them to someone. There’s a reason why people aren’t creating content outside walled gardens. People only care about the activity and the goals they have in mind, not the technology that makes it possible.

The last major innovation in web content creation outside a walled garden was the WYSIWYG editor. Look around, few still exist. The ones that do are focused on FTP of static pages to a web server. Not one that I’m aware of would let a user generate for example a WordPress or Drupal theme without touching code. Purely WYSIWYG. It’s 2012 and it’s not possible to create a blog theme without merging markup and some server side code (PHP in this example). As a reference point support for a handful of CMS’s would cover a huge chunk of the web not owned by large companies. You shouldn’t need to understand CSS selectors to set a background color and you shouldn’t need to know #000 (or #000000) is “black” (which can also be used).

The suggestion that users are in the wrong for not being willing or able to learn is invalid. They shouldn’t need to.

Enabling content creation needs to be done the same way enabling content consumption is done: by making it so the technology is invisible and task at hand is the sole focus. Why should creating a spreadsheet with my finances be less technically complicated than publishing a paragraph of text on the web?

We’ve failed if the only way to participate on the web is to fully understand the technology. Walled gardens have manage to abstract it fairly well. Surely there’s a better way1.

1. I’ve got more thoughts on that, but I’ll save it for another day/blog post.

Adventures With document.documentElement.firstChild

Here’s an interesting DOM test-case I ran across inadvertently yesterday.

For the purpose of this post assume the following markup:

< !DOCTYPE html>
<html>
<!– i broke the dom –>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>Testcase</title>
</head>
<body>
<p>Something</p>
</body>
</html>

If I use document.documentElement.firstChild I don’t get consistent behavior. In Firefox and IE I get the <head/> element, which is what I was initially expecting. In WebKit (Safari/Chrome) and Opera. I get the HTML comment which I wasn’t.

Continue reading

view-source: Now Supports Links

A very cool change landed in Firefox 3.1. View source will now create links where appropriate (a rather old bug I might add). I must have copy/pasted millions of url’s over the years out of view source so that I can look at a JS or CSS. This is an immense help for anyone who does this quite often.

Just another great piece of polish for Firefox 3.1.

Rebreaking The Web

It’s happening again. Once upon a time, browser vendors started adding their own features without consulting with each other and agreeing upon standards. What they created was a giant mess of inconsistencies across browsers and platforms that is still in effect today. Ask any web developer and they can tell you of the pains that they have suffered trying to make seemingly trivial things work everywhere consistently. It’s no easy task. Before IE 7, even an ajax required something along the lines of:

var httpRequest;
if (window.XMLHttpRequest) { // Mozilla, Safari, …
    httpRequest = new XMLHttpRequest();
} else if (window.ActiveXObject) { // IE
    httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}

That’s right, IE 6 didn’t support the native xmlHttpRequest object (more here). This is just one of many examples in JavaScript and CSS. document.all anyone?

The end result of this problem became to be known as the “Web Standards” movement. Simply put it’s an idea that code should follow a standard that results in consistent output across all browsers on various platforms. Write once, run anywhere. While it’s taken years for this to manifest, it’s slowly become a reality. Firefox, Safari, Opera have fairly consistent rendering (at least in comparison to the mess of just a few years ago on the browser scene. IE 6 was fairly poor in terms of modern web development, but IE 7 made progress, and IE 8 is Microsoft’s greatest effort to date to bring their browser up to speed.

Continue reading

Meta Stupidity

As Robert O’Callahan, John Resig, Anne van Kesteren all point out, this idea of using a meta tag to select a rendering engine is bad. Here are my personal thoughts on the issue. Not as a browser developer but as a web developer.

Essentially the argument by the IE team is this: Rather than fix the problem, lets create a larger problem so the smaller one isn’t very noticeable.

Yea, that’s how I parsed the blog post. For anyone who disagrees, perhaps I interpreted it wrong because they didn’t select the correct parser because they didn’t include the following:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;raccettura=serious;OtherUA=4" />

All joking aside it’s an insane idea guaranteed to set things back.

Continue reading

Secrets In Websites II

This post is a follow up to the first Secrets In Websites. For those who don’t remember the first time, I point out odd, interesting, funny things in other websites’ code. Yes it takes some time to put a post like this together, that’s why it’s just about a year since the last time. Enough with the intro, read on for the code.

Continue reading

Coda Coolness

So I downloaded and tested out Coda a little bit today. My initial impression is that I’m very impressed. It could be the new standard. A few like Alex King point out that it uses Safari as the default engine. I don’t think that’s so bad. Nothing stops you from using 2 windows one being Firefox (obviously running Firebug). I think the editor itself is rather well polished and very refined. The use of Bonjour to allow for collaboration makes it perfect for multi-developer environments. And yes, you can have more than two developers collaborating in 1 document.

My typical workflow is very abrupt. I tend to have Firefox, IE, and an IDE open at all times when coding pages. Not to mention a KVM switch to go between platforms. This still consolidates several things, and with a much nicer UI.

I’ll need to try it (for actual development purposes) for a few days before I could tell if it really works as well I hope. Panic is one of my favorite Mac developers. Really well polished products are their specialty.

IE Table Border Bug?

I encountered this the other day. Firefox, Safari and Opera do what I expected and believe to be correct. I’m curious if anyone can explain this, or knows of a workaround that “doesn’t suck”. Take the following testcase:

< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html lang="en">
 <head>
    <title>IE Table Border Bug</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <style type="text/css">
        table {
            background-color: green;
            border-collapse: collapse;
            border-spacing: 0px;
        }
        table td {
            width: 100px;
            border-bottom: 3px solid red;
        }
            table td.strip {
            background-color: #fff;
            border-bottom: 3px solid #fff;
        }
    </style>
</meta></head>
<body>
<table>
       <tr>
           <td> Test</td>
           <td class="strip"> Test</td>
           <td> Test</td>
       </tr>
 
</table>
</body>
</html>

Example

Pay attention to the bottom border. Should be flush with the green cells.

Firefox 2.0

Firefox Render

Close Up:
Firefox Render (Close Up)

IE 6

IE Render

Close Up:
IE Render (Close Up)

IE 7

IE7 Render

Close Up:
IE7 Render (Close Up)

Strange, but interesting. Excuse the poor quality of the screenshots. I cut these up really quick. Perhaps this weekend I’ll do a nicer job.

Komodo Convert

After reading about Myk’s use of Komodo, I decided to give it a try. I’ve yet to find the truly perfect IDE, so I’m always open to good alternatives.

For years I used BBEdit Lite, which was good enough for my somewhat basic needs, TextWrangler came and I moved over. On the Windows side of things, I had tried numerous editors for years, ultimately using Eclipse, ConTEXT, and (on a few occasions) jEdit. Mainly on the Windows side it has been ConTEXT, since it didn’t have the restrictive feel many IDE’s have. On the downside, it didn’t do much.

At work, I’ve been using Macromedia HomeSite. Overall it’s not too bad, but it does have it’s quirks. There’s definitely a bug in FTP that causes it to occasionally not show all the subdirectories when you nest to deep. Then it sometimes randomly throws errors at you. Most of the time they can be safely ignored, making me wonder if they are still errors when nothing bad happens.

So I downloaded Komodo Edit (free) on my Windows Laptop, and my Mac Mini, installed it on both, and played around. First order of business was playing with some local files. End result was that it handled things very well. I didn’t have to fuss around to much to get things accomplished… I like that. Next step was to try the FTP functionality (SFTP and SCP as I don’t like FTP). It worked, I was able to edit a few files and it performed rather well. Also nice was that it let you know it read the directory from cache. Most will hide this info from you.

In the end I decided a few things were missing. The most notable thing missing and preventing it from replacing HomeSite was the sidebar file manager. I work on many files, so I need a quick way to get to them. File –> Open wasn’t going to work. I decided to file a bug and request a similar feature as an enhancement. Other editors do a similar sidebar file tree, this wasn’t something revolutionary.

Ends up there is an Remote Drive Tree Extension that provides the functionality I desire. Sweet! The usual install process, restart and I’m going. Works perfectly. Only thing missing is drag/drop support so I could easily add files or move them around, renaming would also be helpful. Perhaps those features will come in the future.

So after a little time with it, I’ve decided I’m ready to try it for a week, and see if it handles my needs for the week. It has now qualified for testing.

I think I like it so far. I do have a few pet-peeves though:

  • FTP support is still a little buggy.
  • Slow startup time.
  • Prefs feel somewhat awkward and not as intuitive as one would hope.

But it’s still beta, so there’s time for it to grow.