August 23rd, 2007 | Published in Bookmarks
I never thought before about the many different designs of watches.
August 23rd, 2007 | Published in Bookmarks
August 22nd, 2007 | Published in Bookmarks
I’m reading a lot about OpenID. I’m trying to determine whether or not it seems viable or likely to be adopted by the larger, non-technical audience of Internet users.
These recent blog post, OpenID: Great idea, bewildering consumer experience, captures better than I can how confusing OpenID can be if you set out to use it. It is worth reading the whole thing, but I want to highlight three points from the post:
The process of selecting an OpenID provider will stump the average consumer. They’re being asked to pick an ID that they will, in theory, use everywhere and forevermore to gain access to everything they own. They’re supposed to obtain this ID by making an effectively random selection from a group of providers they have never heard of.
This is where I get stuck every time. I’ve selected my web site host, domain, and email address based on longevity. Trying to decide which OpenID provider will be around in a couple of years is a difficult task. I’m not certain what other criteria you would use to make a decision.
Various OpenID sites also promote the notion that users should set up their own OpenID provider.
We’ve looked into creating an OpenID provider service from our applications. Yesterday, I saw someone asking for development of a plugin for Jive Software that would ideally make Jive’s Clearspace product an OpenID provider. It seems like every additional OpenID provider will be contributing to the confusion instead of helping.
[UPDATE: See the note below from Matt Tucker, CTO at Jive Software. In re-reading what I wrote above, I wasn’t very clear. Until Matt’s comment below, I didn’t know Jive intended to do anything with OpenID. I just saw someone asking for a plugin that would make Jive’s Clearspace profiles provide OpenID URIs. It more of a comment on desiring more OpenID providers rather than a comment on adding OpenID to any particular application. As I noted in the comments, I’d like to see more applications accept OpenID and fewer provide their own OpenIDs so that it is easier to get over the indecision about choosing an OpenID provider. Sometimes less choice is a good thing. Thanks again Matt for taking the time to clarify.]
And all this is for—what, exactly? To save me from having to pick a user name and password? As annoying as that can be, it’s just not that hard! Remembering an arbitrary user name does cause real trouble, but simply allowing email addresses to be used as IDs can solve almost all of that problem. As more and more sites allow email addresses as IDs, the need for OpenID becomes less compelling to a consumer.
This final point is a key for me. It seems like OpenID is asking people to establish a new, long term identity. However, for those who can establish a long term identity, they’ve already done so using their email address. Asking someone to replace their email address, the address that they have been trained to believe is where they can be found online, is going to be a tough sell.
I understand the desire for single sign-on. I’ve certainly heard the desire for single sign-on from a lot of customers and have spent a fair amount of time building authentication integration.
And yet, when I look at OpenID and all of the obstacles it needs to overcome, never mind the competition from Yahoo BBAuth and Microsoft Live ID, I question whether OpenID will ever receive widespread adoption. The real shame is that there is a true desire, if not need, for a simple, open system to simplify logins for web applications and right now, I don’t see any of the systems solving that problem for the majority of people.
August 21st, 2007 | Published in Bookmarks
A few years ago, I was stunned to find out that there were HTML elements that I wasn’t aware of that could impact how quickly a browser could render a page. I had been developing web pages for years and couldn’t believe there were tags I hadn’t encountered yet.
I then set out to learn every element by reading through the syntax guides and even reviewing the XHTML Transitional DTD. I learned about localization tags like <bdo> and rarely used tags like <dfn>. Any tag I didn’t recognize I read about.
Which is why I’m still reeling from the revelation that there is a scope attribute for <th> tags. According to Veerle and Roger Johansson, the scope attribute is important for accessibility. I didn’t think there were any HTML attributes I hadn’t encountered yet.
So while I glad to have learned a useful and important attribute for accessibility, I’m not looking forward to reviewing all of the attributes again to see if there is anything else I’ve missed. :-)
I’ve been lost over the last few days trying to understand the differing opinions on the status of the next generation of HTML code. Molly, who I’ve had the good fortune to meet and whose opinion I respect, raised the alarm about the state of the W3C development. Jeffrey Zeldman whose article “To Hell With Bad Browsers” kicked off the movement for standards-based web development doesn’t see a crisis at all.
It is pretty clear that something has been going on given the sobering testimonial of Roger Johansson who explained why he abandoned and then rejoined the W3C’s HTML Working Group.
Aside from trying to follow the problems (or lack thereof), I’ve been trying to sort out what the next generation of HTML is supposed to be. A few years ago, I convinced my company to standardize on XHTML. We worked our way through the rendering issues and finally had XHTML adoption throughout the organization.
Which is why I’ve been ignoring HTML 5. I drank the kool aid on XHTML, why would I go back to HTML now?
Seeing so much concern over HTML 5 today by the same people who advocated XHTML confused me greatly. What happened to XHTML 2.0? Why are we going back to HTML?
Come to find out, I missed a change at some point. I remember a lot of concern about XHTML 2.0 being unwieldy and a radical departure from HTML and XHTML 1.0, but I didn’t follow the outcome of those discussions fully.
Turns out HTML 5 is the agreed upon next step for both HTML and XHTML. HTML 5 is designed to resolve the issues between HTML and XHTML and converge them into one specification. While I still have some concerns about dropping the requirement or preference for well-formed markup, I’m now more reassured about the direction our core web technology is headed.
The new elements in HTML 5 sound like improvements. The example of next generation web forms is too good to be true. The clarification of HTML 5 that those participating in the development of the specification have agreed to will be a welcome change and will hopefully prevent someone else from having to do the research I did to sort through the standards mishmash.
Molly’s call for action may have been more alarmist than it needed to be, but there have been some good outcomes from the discussion. If nothing else, I’m now excited about the potential of HTML 5 and finally understand that XHTML isn’t going away anytime soon.
There are many advantages to HTTP Basic Authentication, but despite these advantages, web developers have turned almost exclusively to using cookie-based authentication because of some limitations in how HTTP Basic Authentication can be implemented. Until recently, there has been no way to for developers to control the login form nor provide a way for users to log out.
The advantages of using HTTP Basic Authentication are easier integration. In particular, mod_auth_mysql for Apache makes it possible to easily password-protect areas based on usernames, passwords and roles stored in a central authentication database. The main alternative for authentication, cookie-based authentication, provides a higher barrier for integration projects.
Despite the integration advantages, most web developers use cookie-based authentication because they want to control the user experience of logging in. When logging in using HTTP Basic Authentication, the browser shows a login prompt. Developers have no control over the look of this login prompt; therefore, there is no ability to add useful information like links to retrieve forgotten passwords.
Read the rest of this entry »
August 19th, 2007 | Published in Bookmarks
A few years back I helped build a content management system. At the time, Internet Explorer on PC was the only browser we could use for WYSIWYG editing. As a Mac user, I struggled with the fact that I was delivering a product that I could never use on a regular basis.
At the time, the great promise was sections of the DOM II specification on range. Bugzilla listed support for this part of the specification on its future work. I signed up for a list and monitored the ticket waiting for the day when Mozilla would support WYSIWYG in-browser editing.
Today I read that the Yahoo UI team has finally bent Safari to its will to support WYSIWYG editing. We’ve come a long ways since I was hanging out on the Mozilla developer lists and asking questions about the range implementation. Now that someone has conquered Safari, we are close to assuming that this foundation piece of the read/write web is available to all users.