jump to navigation

I’m with Jakob: Stop password masking! June 24, 2009

Posted by Michael Kowalski in coding, ux.
add a comment

Latest Alertbox from Jakob Neilsen is Stop Password Masking

Nielsen is completely right on this one, and I’ve thought so for a long time. The thing is, there’s nobody looking over your shoulder. There’s never anybody looking over your shoulder. And if there might be, well, put your hand over the screen or something.

But unfortunately it’s one of those idiocies that has become so ubiquitous that people have been trained into expecting it and will complain if you don’t do it.

Motherapp – because nobody wants to learn Objective C April 6, 2009

Posted by Michael Kowalski in coding.
add a comment

The dilemma du jour for developers: the iPhone is where the app action (ie. revenue + distribution) is. There’s a gold rush on! But come on… Objective C? We have to learn Objective C? This seems like a step backwards into some kind of dark ages. 

Which is why we’re seeing things like Motherapp and PhoneGap. No doubt we’ll see more.

The Guardian Open Platform released March 10, 2009

Posted by Michael Kowalski in coding, work.
Tags: ,
add a comment

Went along to the launch for the new developer platform from the Guardian. They’re exposing pretty much all their (text) content and some useful data APIs for devs to build their own apps. Very much in beta atm, but you can apply for a key here:

Some initial thoughts from me here:

YUI 3.x preview release 2 is out and looking granular December 10, 2008

Posted by Michael Kowalski in coding.
Tags: , ,
add a comment

The Yahoo! User Interface (YUI) Library.

This release gives us the first real look at the widget infrastructure for the new YUI codeline. There are only a couple of fairly simple widgets here, but it looks very promising so far. 

I really appreciate the level of granularity here. With the 2.x codeline, time and again I’ve found myself either overriding “private” methods or abandoning the YUI implementation of a specific widget altogether because it’s too difficult to make it do exactly what I want. I’ve also been unhappy about carrying around a lot of unnecessary code for functionality I’m not using.

With the 3.x codeline it does look like these problems will be resolved. Even as basic a widget as “Overlay” is composed from functional modules. Nice! I’m hoping this approach plays through fully in the more complex widgets like the Rich Text Editor and DataTable; imo this will be critical. 

 YUI 3 is beginning to look like it will really be the business for those of us who are using YUI as the basis for full fledged web applications (though probably overkill if you just want to add some menus to your site). The downside is that it is clearly many months even from beta; this release is some weeks later than expected, and those complex widgets will no doubt take some time to nail.

Still waiting for those YUI 3.0 widgets October 16, 2008

Posted by Michael Kowalski in coding, user interface.
Tags: , , ,
add a comment

I went along to a YUI 3.0 briefing at Yahoo’s London HQ this evening, to see if I could catch a glimpse of their next gen widget set. Via a video link compered by Christian Heilmann at our end, we were given brief code presentations from the YDN team in the USA, covering topics like the new YUI constructor, dependency loading, node and nodeset wrappers, and drag-and-drop. But it’s the widgets I’m most interested in—imo, they are the most compelling reason to favour YUI over any of the other popular libraries if you’re building complex apps. 

The roadmap had predicted a first widgety release this month, and tonight they confirmed that they are on track to deliver 3.0.2 at the end of next week. But while it will contain a first draft of the new base class for widgets, the only actual widget in the package will be… the Logger. Um, seems like there’s some way to go.

On the plus side, the draft architecture looks elegant. They’re making a serious attempt to separate rendering out from behaviour more cleanly than in 2.x, and that’s very promising. The 2.x widget set suffers from too much behaviour baked into individual widgets, DataTable being the worst offender.

For example, in the 2.6 release they split out Paginator, which had formerly been a subclass of DataTable. That was great for me, as I was just about to roll up my sleeves and roll my own pagination for some custom widgets built on top of YUI. But DataTable stills includes a lot of behaviour that would be generally useful in other situations, eg. a nice selection model that deals with multiple selection; also edit-in-place. The “plugin” architecture in 3.0 means that with a bit of care these kinds of behavioural aspects will be implemented as pluggable modules that can be applied to other (especially custom) widgets. 

But not any time soon.

Why Ian Hickson is wrong about br and p tags September 11, 2008

Posted by Michael Kowalski in coding, user interface, work.

There’s an interesting and informative interview with Ian Hickson on TechRepublic where he talks about HTML5 and its growing pains. But there is one thing he says that I don’t agree with:

Most of the “gotchas” in HTML5 are things that we’ve inherited from the legacy of the Web. For example… the br element shouldn’t be used unless you’re writing something that really has a line break like a poem (generally people should be using p instead of br) 

The idea is that by using p tags you are supporting the semantic web by nicely delimiting paragraphs of content. It’s quite a widespread idea, and sounds like a good one. Except that most of the content on the web is written by ordinary, non-technical people typing into some kind of wysiwyg interface. 

So, when that person hits the carriage return key, how does the interface know whether they mean to end a paragraph or insert a line break? Hm, tricky. Probably the application doesn’t have a “poem mode” (and anyway, modes are bad).

In the past, I’ve seen CMS interfaces that tackled this dilemma by supplying different tools in the toolbar for para breaks and line breaks. No, really. Even WordPress, which by and large has a great UI, by default uses p tags. You can get a br tag by holding down the shift key while you type a carriage return. That’s right, you’re supposed to learn a special key combination to type a line break!

The thing is this: when a user hits the carriage return key, the user interface knows only one thing: that they have typed a line break. That’s all. We don’t know anything about their intent. We don’t know if they intend to close off a block of semantically related content. All we know is that they have typed a return. The appropriate thing to do, therefore, is insert a br tag.

Can we have access to the undo stack please? September 4, 2008

Posted by Michael Kowalski in coding.
add a comment

I’ve been working on a new code editor widget. With FF3, we’ve got contenteditable and a reasonable facsimile of IE’s (awful) execCommand API.

The trouble is, there are a lot of operations that are more easily done using direct DOM manipulation rather than execCommand (eg. indenting a code block without some crazy div or blockquote insertion). But from a user experience perspective, I want everything to go into a global undo stack, and DOM changes don’t. 

It would be really nice to have programmatic access to the browser undo stack. In practice, that means being able to push node changes into the stack.

CDATA is not XML August 4, 2008

Posted by Michael Kowalski in coding, work.
add a comment

Another day, another feed supplier who thinks it’s OK to wrap the contents of every element in CDATA so that they don’t have to decrapify their data. Though of course they’ll expect us to parse it out gracefully and not show their crap on the website. 

Idea: a website called ismyfeedcrap.com where you can send this stuff, and get back an objective report that says “yes, your feed is crap, and this is why…” Something like Bobby, a public service for the web.