More reasons why you should not follow Human Interface Guidelines by Matthew R, in a comment on the post The Beauty Of 99¢ iPhone Apps, by Jens Alfke:

Problem with this “live by our rule or die” approach is the fact that many apps for the Mac, we love so, because they disobeyed the HIG. And I don’t necessarily mean extreme apps like Shapeshifter, but take for example the HIG saying “don’t create your own menu bar extras. That’s reserved for the System.” We completely shrugged that off and created our own menu bar extra-apps anyway. If there was (run with me on this) an App Store for the Mac; then apps like Quicksilver and Twitterrific would have been turned down.

Other apps which breaks the HIG in this manner are:

And this is only one way in which the HIG in not followed in these applications. I am sure there is a slew of other ways as well. Developers break these guidelines, sometimes for a reason, sometimes by mistake, sometimes because the HIG simply did not describe a specific use case.

This is when the HIG are getting dangerous: They have become not only law in the sense that virtually everyone and their blogospehere mother were screaming for Apple to follow their guidelines. Now the same guidelines are the arbitrer of good applications for the iPhone. It is law.

Not to mention games. They are their own mini-environments with custom user interfaces.

Link: Matthew’s comment →

Reading the documentation for the iPhone software development kit I found this in the iPhone SDK Agreement:

3.3.5 Applications must comply with the Human Interface Guidelines and other Documentation provided by Apple.

In other words: No new interaction concepts, no cool user interfaces, only the same that already is. Apple will decide based on flawed guidelines whether you spent weeks researching and testing your interface or not. Surprising move from a company so focused on being the leader of user interface design.

What he said:

Design is thinking made visual

My take:

Design is thinking about communication.

His position is excellent when applied to a static or at least linear medium like movies, not so with nonlinear, dynamic, interactive stuff. Oh, I also just happen to love how “design is thinking made visual” feels on your tongue.

Updated 2008-02-26

Long have I been looking for a way to break long strings of letters over multiple lines in a good way. None of the CSS inline or HTML/CSS <span> examples I have found have been able to automatically apply to long links or file names. I have found this a special pain when dealing with development for Growl due to the narrow width and often found long file names or URL:s often passed as message content.

For example, let us say you have a 300 pixels wide column but have to write a URL or two there. It will look like this with overflow: visible;:

Take a look at http://this.verylongurl.net/some_content_here/and_link_text_here/index.html, it’s good. So is this http://www.anynormalurl.info/2008/02/22/blogging_url_today.php.

And like this with overflow: hidden;:

Take a look at http://this.verylongurl.net/some_content_here/and_link_text_here/index.html, it’s good. So is this http://www.anynormalurl.info/2008/02/22/blogging_url_today.php.

Or like this where you manually have to split the string into separate <span>:s with added CSS rules to avoid ugly spaces, a method that is also not especially nice to search engines or screen readers:

Take a look at http://this.verylongurl.net/ some_content_here/ and_link_text_here/ index.html, it’s good. So is this http://www.anynormalurl.info/ 2008/02/22/ blogging_url_today.php.

There has to be a better way

To the rescue comes the <wbr /> tag which is a behavioral and in a sense optional tag for web browsers which essentially says “it’s okay to break here if you want”, not unlike like a hyphen. Which means some browsers will interpret it slightly different, but as long as we can get a good way to break these long links and filenames we will be happy.

Adding a few such tags to our example will give the desired result:

Take a look at http://this.verylongurl.net/some_content_here/and_link_text_here/index.html, it’s good. So is this http://www.anynormalurl.info/2008/02/22/blogging_url_today.php.

So, we can now use the split and join code to easy accomplish what we are looking for to add a line break after a slash:

document.getElementsByTagName(changeThisElement)[i].innerHTML = indata[i].innerHTML.split(”/”).join(”/“);

The Complete Code

This goes in the <head> tag of your document:

<script type="text/javascript" charset="utf-8">
<!--
  // © Niklas Brunberg 2008 — www.interaktion.info. All rights reserved.
  // This software is distributed under the BSD License, you can use it with
  // both open and closed source software. For the legal fine print, 
  // see: http://www.opensource.org/licenses/bsd-license.php
  // 
  // Version 1.1
  // 
  // Using this code:
  // 1. Make sure you add a onload="addWBRfunction();" to the <body> tag.
  function addWBRfunction()
	{
		var indata, i, changeThisElement;
    
    	// 2. If you want to use this on another kind of element, just replace "p" with e.g. "span" or "dd".
		changeThisElement = "p";
 
		indata = document.getElementsByTagName(changeThisElement);
 
    	for (i=0; i < indata.length; i++)
    	{  
			// Splits after periods (.) after underscores (_) after slashes (/)
			// and repairs any problems possibly caused in certain tags ending with "/>"
			document.getElementsByTagName(changeThisElement)[i].innerHTML 
			= indata[i].innerHTML.split(”/”).join(”/<wbr />”).split(”/<wbr>>”).join(”/><wbr>”).split(”.”).join(”.<wbr />”).split(”_”).join(”_<wbr />”);
		};
	}
  // 3. There is no step 3.
//–>

As far as I am aware there is only one problem with the and that is the lack of hyphens. If you know a way to set a hyphen only when the browser choose to use the tag I will be more than happy to hear from you. This should work in Safari 2, Firefox 2, Opera 9 and Internet Explorer 6 and later versions of these browsers.