semi/signal

I’ve always played it safe with fonts when it comes to web design, sticking to fonts commonly available across operating systems such as Verdana, Tahoma, Trebuchet MS, etc. However, I’m pretty psyched to see how well the CSS @font-face attribute is supported. Format support is somewhat of a mess: EOT for Internet Explorer and TTF/OTF for WebKit-based browsers (Chrome, Safari). However, Firefox 3.6+ supports the new Web Open Font Format, which is poised to become the new standard and will, hopefully, quickly find it’s way into the other browsers.

If your in Firefox, Safari, or Chrome, here’s a font I’ve loved for a while, Titillium:

TitilliumText999wt

I’ve never really had problems finding fonts for free or even commercial use, but Font Squirrel now makes the whole search process dead simple and super easy. They also seem to have a pretty awesome converter; though I used this oft2woff converter for my little demo above.

I missed webOS Developer Day, but I took a look at the presentation of the Enyo framework (video below). I like most of the bullet points: faster performance, hardware acceleration built-in, etc. However, one point that’s troubling me is the idea of using higher-level controls instead of divs. From the bit of code presented in the final demo, it looks like layout (and pretty much all UI stuff) will be done using JavaScript widgets, which are translated at some point into the appropriate HTML constructs. Obviously, widget-centered development isn’t a new concept (MFC, WinForms, Cocoa… sproutcore and such on the web) nor is it necessarily a bad one (getting something presentable up and running is easier), but there always seems to be a very real and very large loss of flexibility.

When a widget doesn’t look or function exactly how you need it to, and it becomes necessary to make a new one, development within the widget framework can range in difficulty from trivial to near-impossible. As I mentioned when I wrote about Adobe Air, HTML/CSS isn’t perfect, but it’s the most flexible layout and styling framework I’ve come across. Abstracting away that flexibility in favor of plug-and-play widgets makes me cringe… it’s a nice idea, it’s a very (object-oriented) developer-ish idea, but it usually comes with a pretty high cost.

From working with both HTML/CSS and WinForms extensively, I’d say the widget-centered framework model used for desktop apps shouldn’t be replicated for web development. In fact, it should be the other way around: the flexibility of a HTML/CSS-esque system should be brought to the desktop.

How this will play out for Enyo, I don’t know. I’m cautiously optimistic. Being a web framework, everything still boils down to HTML and CSS, but it remains to be seen what level of manipulation will be allowed or make sense (in terms of performance, coding difficultly, etc.) at that level.

I made a little app to get my feet wet with Adobe Air. progTools just packages together a few common functions I find myself using frequently. You can get it my clicking the install badge (one of the very cool aspects of Adobe Air) below.

(h/t to Peter Elst for the AIR Badge WordPress plugin)

What’s offered:

• Conversion to/from a Unix timestamp
• MD5 hash on a string
• MD5 hash on a file
• SHA1 hash on a string

Not too impressive, and only the MD5 file hash really utilizes a desktop feature of the Air framework, but it is somewhat useful and, at least in my case, I won’t end up going to Paj’s Home to use the javascript md5 implementation demo quite as often. Note, Paj’s MD5 library was used and I slightly modified core_md5() for the file hash to deal with hashing successive blocks. I’ll post the code soon.

I initially dismissed Air, back when it was Apollo, as I didn’t see the value in having yet another proprietary framework which didn’t really offer much beyond what was capable within a browser, aside from local file access. A few additions to the framework and a few realizations on my part have shifted my views:

• Air supports HTML/CSS for layout and styling. Looking into cross-platform GUI frameworks, I’ve played around with WinForms (cross platform with Mono), Qt, Gtk, and wxWidgets. I’ve been disappointed to various degrees with all of them. It hit me that the most flexible and powerful cross-platform layout and styling framework out there is the HTML/CSS combo. It’s not perfect (e.g. floats, vertical centering) but it’s pretty damn good.
• Support in Air 2 for sockets and interaction with native applications. This vastly opens the field for the types of applications possible with Air.
• Market support from Adobe. The Air Marketplace is perhaps not too impressive, but it’s a major step in the right direction for desktop apps. Both Microsoft and Apple have their own stores planned, but with the success of such catalogs on smartphones for years now, why did it take so long to figure it out?
• Install badges. They’re cool and important as they provide a bridge between the web and the desktop. Odd, but it seems Adobe more-so than Microsoft or Apple seems to understand the web-desktop relationship. Again, why is Adobe, a company that was fairly divorced from the desktop application space, the first to figure out that this was something important or at least the first to actually build it.

Now it’s not all sunshine and roses. Making an HTML/AJAX app in Air brings up a problem every AJAX developer has likely faced at some point. Javascript is slow… very slow. JavaScriptCore/Nitro, V8, Chakra, Tracemonkey… it doesn’t really matter (though performance improvements are being made), once your volume of data grows you’ll cringe at how slow things become. Coming from C++, C#, or even PHP, it’s painful to witness. In progTools a file only a few megabytes large will noticeably stall the application (I didn’t do the call asynchronously, but that’s besides the point). ActionScript is perhaps better and interop to a native executable could also alleviate the issue, but ultimately I’d simply like a faster JavaScript engine.

A second issue, relevant but not specific to Adobe Air, is code signing; you’ll notice the scary warning when installing progTools. Code signing is bullshit. Expensive bullshit. Yet, every platform developer is requiring it due to some misguided attempt at security. If you want to install progTools, the chain of trust is between me » this web server » you. Sticking a certificate authority in this chain is nonsense – a typical user will not know the CA and cannot establish any level of trust with some random, corporate CA.

Coding signing simply punishes small developers and establishes a new industry to leech from our wallets. In addition, as this user on StackOverflow asserts, it may well hamper the success of Air:

When you visit a site that lets you download an AIR app, it pops up big red screaming warnings about the imminent trashing of your computer, the theft of your identity and a life of torment[1]. Unless, of course, all the bedroom programmers decide to cough up the ongoing cost of certification.

User encouragement FAIL. Hobby developer encouragement FAIL. Technophobe terrorficiation avoidance FAIL.

I love AIR, but I don’t know what they were thinking with the installer. Laywers’ office moved closer to the developers’ over at HQ or something?

Anyways, I’m done ranting. I’ll eventually suck it up and get a certificate as I’m powerless to do anything else.

As for Air, I’ve just scratched the surface, but I’m impressed.

oh, and if you’d like to see something added to progTools, just let me know.

Interesting post on the realization that :hover (in CSS, this defines what occurs when the mouse is over an HTML element) is no longer viable for layout on touchscreen devices.

When I sat down to a redesign of the Gameplan2 admin interface I suddenly came to a realisation, :hover doesn’t work. It’s entirely possible I’d skim read this somewhere, but somehow the implications for my design work had passed me by until I saw an iPad in use.

I came to the same realization when designing the Ekkio web client, and realizing I couldn’t open the file and folder submenus on my Palm Pixi.

The arrows on the left would only appear when the user hovered over a file or folder. The solution, as shown, was to always show the arrows, but make then a lighter shade; on hover or when the dropdown is open, the arrows become a darker shade. This works well, despite the visual clutter of the arrows always being visible.

I agree with Croll’s conclusion,

So my proposition is this: :hover as an web interface design tool going forward is going to be less and less important.

I see :hover (and javascript mouse events such as onmouseover, for that matter) being unused or used only for non-essential stuff, such as added visual flair.

On a related note, touchscreen also don’t allow viewing the alt-text when hovering over an image. This is probably not a big deal when it comes to web layout, but it sucks for reading xkcd.

A similar issue to the one I mentioned in my previous post. The problem is the same, the behavior of anchor elements is broken, however, the cause seems to be different.

The image above demonstrates the issue. The area enclosed by the blue box is the anchor element. It’s a block-level element (display:block) and positioned using position:absolute. The area enclosed by the white lines is part of a paragraph element. When the paragraph element overlaps the anchor element, the functionality of the anchor element is broken (oddly, the functionality on the border of the anchor element is still active).

I’ve found two solutions.

• Reduce the width of the paragraph element or it’s container to prevent the overlap
• Use a transparent gif for the background of the anchor element. The same solution for the issue described in my previous post

I’ve previously expressed dissatisfaction w/ the look of my homepage but apparently there were functional issues as well. I never did a thorough test of the page in IE (either version 6 or 7), just a quick glance to see that the layout was correct, this bit of carelessness bit me in the ass as I’ve recently discovered the links weren’t working in IE.

The problem was the result of IE not allowing background:transparent AND filter:alpha on the anchor elements. Having both breaks the behavior of the elements (i.e. they don’t function like links and you can’t click on them). I needed the filter attribute for the translucency effect, so my fix was to simply use a 1×1 transparent gif for the needed transparent background.

oh, and these links are somewhat weird. They have no content, they’re just empty block elements absolutely positioned on top of their parent div (whose background image contains the text identifying the link’s function to the user). When hovered over, their background changes to a image that gives them a border. When clicked, their background changes to black and opacity decreases so it’s a translucent shade over the parent div. When unselected (i.e. another link is clicked), they have to go back to being transparent where the user sees right through to the parent div.