design – Page 2 – Factory Joe

Groups for Twitter; or A Proposal for Twitter Tag Channels

This is the post that I alluded to in my last one about Whispering Tweets. I’ll make a disclaimer right now that the title of this post is misleading and actually not about Groups for Twitter. In fact, I’m not at all convinced that groups (at least as they are commonly understood on sites like Flickr) are ultimately a good idea or a good fit for Twitter. But, I do think that there is certainly some merit to improving contextualization, content filtering and exploratory serendipity within Twitter. This is a rather messy proposal to that effect.
Continue reading “Groups for Twitter; or A Proposal for Twitter Tag Channels”

Keynote Template for laying out iPhone apps

November 9, 2008. I’ve updated my template to include the 3G iPhone and to support better layering on individual slides. Now available on its own page.

Blake Burris reminded me that during iPhoneDevCamp I had created a simple Keynote template for laying out flows for iPhone apps, similar to the approach I took in developing exPhone using a Keynote document to do the basic wireframing and page layout design.

Four states come with this template, and can be seen in the figure above. Go ahead and download it and lemme know what you think — if this is useful. And, of course, you’ll need Keynote to make use of this.

The story of exPhone.org

At FOO Camp, we held a session on Green Code and discussed various tactics for reducing power consumption by reducing (primarily) CPU cycles through wiser platform decisions and/or coding practices.

Somewhere in the discussion we brought up the impending launch of the iPhone and it occurred to me that there really wasn’t any substantive discussion being had about what to do with the many thousands of cell phones that would be retired in favor of newer, shinier iPhones.

Thus the seed for exPhone.org took root and began to germinate in my mind — as something simple and feasible that I could create to raise awareness of the issue and provide actionable information for busy people who wanted to do the right thing but might not want to wade through the many circuitous online resources for wireless recycling.

I had a couple constraints facing me: first, I needed to get this done while Tara was traveling to Canada as I wanted it to be an [early} surprise birthday present. Second, I needed to get it done before iPhoneDevCamp so I could leverage the event to promote the site. And third, I had other competing priorities that I really needed to focus on.

I went about designing the site in Keynote (my new favorite design tool), relying heavily on inspiration from Apple’s Environment section. I did a bunch of research and posted a lot of links to a Ma.gnolia group (in lieu of a personal set) and created a Flickr group at the same time. I of course also registered the associated Twitter account.

As I went about developing the site, I felt that I wanted to capture everything in a single page — and make it easy for printing. However, I brought my buddy Alex Hillman into the project to help me with the trickier PHP integration bits (his announcement) and he convinced me that multiple pages would actually be a better idea — not to mention compatible with my primary purpose of encouraging sustainable behavior! — and so we ended up breaking the content into three primary sections: Preparation, Donation and Recycling.

We riffed back and forth in SVN and things started to solidify quickly and we quickly realized that we should make the site more social and interactive. And, rather than build our own isolated silos, we decided we’d pull in photos from Flickr, bookmarks from Ma.gnolia and Delicious and use the groups functionality on Flickr and Ma.gnolia. This meant Alex simply had to toss the feeds into Yahoo! Pipes, dedupe them and then funnel the results in a SimplePie aggregator on our end to output the resultant feeds. It turned out that Pipes was, for some reason, not as reliable as we needed and so Alex ripped them out and ended up bumping up SimplePie’s caching of the direct feeds.

Alex put in extra effort on the Flickr integration side, creating an exPhone user account on Flickr and setting up email posting to make it super simple to get your photos of your exphones on to the site. All you have to do is take a photo of your exphone and email it to myexphone@exphone.org with a subject like this: tags: exphone, ‘the make and model of your phone’ (yes, the make and model should be in single quotes!). We’re kinda low on photos on there, so we’d love for you to contribute!

Lastly, I’ve gotta give props to The Dude Dean for his SEO tips. I’m typically not a fan of SEO, but I think when applied ethically, it can definitely help you raise your relevance in search engine results. We’re nowhere in sight, but I’d love to get up in the cell phone recycling results.

I’ve written this up primarily to demonstrate an evolving design process (Keynote to HTML to SVN prototyping to iterative launch) and the use of existing technology to build a simple but rich web application. By leveraging web services via various APIs and feeds, Alex and I were able to build a “socialized” site will little original development where most of our efforts were focused on content, design and behavior. I also made sure to mark up the site with microformats throughout making it trivial to add the organizations I mentioned to your address book or reuse the data elsewhere.

I like the idea of “disposable web apps” or “single purpose apps” that provide useful information, useful functionality or simply reuse existing materials in a novel or purposeful way. I’m also thrilled that Alex and I cobbled this thing together from scratch in a matter of three days. Yeah, it’s not a long-term, high value proposition, but it was great fun to work on and is something concrete that came out of that discussion at FOO Camp.

I of course welcome your thoughts and feedback and invite you to add your own stories, links or photos to the site!

Why I screenshot

Three months ago, Sarah Hatter asked me a question that I had intended on answering then and there. In fact I did, but I had intended to expand upon these thoughts in a longer post:

Actually, I take shot primarily for my own purposes — research, learning and as a repository of interfaces that I can dig up later and imitate.

If I had to go out an search for a specific UI everytime I needed inspiration, I’d be a *much* slower designer than I already am! This way I can capture the best of the web *as* I come upon it, when the moment of inspiration hits.

I think this hints at what I said the other day about cleverness: she is the most clever who is the sum of everyone else’s cleverness (Ok, I didn’t say that exactly, but that’s kind of what I was getting at). On top of that, it’s rather inefficient to try to “innovate” your way to the next big thing when most “inventions” are actually evolutionary improvements to what’s come before. As if social networking and Web 2.0 was new! I mean, the version got ticked up from one-point-oh right?

But that’s not really what I’m saying. What I am saying is that I screenshot for history, for posterity, for education and erudition, for communication, to show off and, heck, for my own enjoyment. Call me twisted, but I really get off on novel approaches to old interfaces, clever disk images or fancy visualizations. Jacob Patton once called me the pornographer of Web 2.0. Nuff said.

Still, there is more to be said. For one thing, I don’t screenshot everything that I see or come across. Just like my blog posts, I tend to like to write about things that are interesting to me, but that, if I’m going to share to the wider world, will probably be of some interest to other folks, one way or another. I never assume interest, but, y’know, I do try to make this stuff look good in the off chance that someone takes inspiration from something I’ve uploaded… as in the case of Andy Baio‘s work on the redesign of Upcoming. According to his own recollection of his design process, he relied more heavily on my shots of the Flickr-Yahoo Account merge than on any other online resource for figuring out how to implement the same for Upcoming. So yay? Go team!

This is the perfect example of why my screenshotting of design patterns can be really useful for clever people. When other smarter people have already solved problems, and start repeating the solutions or interface in consistent ways, it becomes a design cow path. These are most interesting to me because, as the patterns emerge, we start to develop a visual language for web applications that can be used in the place of verbal descriptors like “adding friends” or “upload interfaces“. Rather than speak in the abstract, we can pull from an existing assortment of solutions from the wild that have already been proven in place, that you can interact with, and that you can evaluate on a case by case basis as to whether any given pattern is worth emulating in a new design.

I also screenshot as a way of in-between blogging, I guess. Y’know, like Twitter, Tumblr, Ma.gnolia, Plazes and Last.fm (among others) are all forms of in-between blogging. They’re where I am in the absences between longer posts (such as this one) where I record what I’m up to, what I’m seeing and what’s interesting to me. My Flickr screenshots are probably more often than not more interesting than what I have to say over here, and certainly less verbose. And, most significantly, the screenshot is the new photograph, allowing me to connect through images of what I see with other people who are able to see things the way I see them. Imagine life before the original camera, where everyone’s depiction of one another was captured on canvas in oil paint; before screenshotting became a first class citizen on Flickr, we were living in a similarly blind world, cut off from these representations of our daily experience. But fortunately, as of a few months ago, that’s no longer the case:

And, following off that last observation, I screenshot for posterity. Now that this internet thing has caught on and it’s been around a bit, it’s fun every now and then to reflect and go back to the days of the first bubble and take a look at what the “it” shine was back then (now it’s the “floor” effect — formerly known as the “wet floor” effect — but back then maybe it was the java lake applet?). Which is all fine and well, but once you start poking around, you’ll notice very quickly that the Wayback Machine is way incomplete. And while Google’s cache is useful, it certainly tends care more about the textual content of a page rather than how it originally looked. And that’s where screenshots could make up the difference, just as photographs of real life offer us a way to record the way things were, screenshots provide a mirror in time into the things we see on screen, into the interfaces that we interact with and the digital communications that we consume (check out this old view of the QuickSilver catalog compared with its current look or how about the Backpack preview or when Gmail stored less than 2GB of email?).

I don’t tend to think about the historic value of things when I shoot them; I do tend to evaluate their interestingness or contribution to a certain series along a theme. And yet, I’m curious to see, over time, just what these screenshots will reveal about us, and about the path we took to get to where end up. For one thing, web application development has changed drastically from where it was just a few years ago and now, with the iPhone, we’re embarking into wholly undiscovered territory (where it’s unclear if screenshots will be possible). But these screenshots help us learn about ourselves, and help us see the pieces-parts of our everyday experience. If I screenshot for any reason, perhaps it is to collect these scraps of evidence to help me better understand and put order into the world around me, to tie things together visually, and to explore solutions that work and others that fail. Anyway, it’s something I enjoy and will probably keep doing for the foreseeable future.

Raising the standard for avatars

Not long ago, Gravatar crawled back out from the shadows and relaunched with a snazzy new service (backed by Amazon S3) that lets you claim multiple email addresses and host multiple gravatars with them for $10 a year.

The beauty of their service is that it makes it possible to centrally control the 80 by 80 pixel face that you put out to the world and to additionally tie a different face to each of your email addresses. And this works tremendously well when it comes to leaving a comment somewhere that a) supports Gravatar and b) requires an email address to leave a comment.

Now, when Gravatar went dark, as you might expect, some enterprising folks came together and attempted to develop a decentralized standard to replace the well-worn service in a quasi-authoritarian spec called Pavatar (for personal avatar).

Aside from the unnecessary invention of a new term, the choice to create an overly complicated spec and the sadly misguided attempt to call this effort a microformat, the goal is a worthy one, and given the recent question on the OpenID General list about the same quandary, I thought I’d share my thoughts on the matter.

For one thing, avatar solutions should focus on visible data, just as microformats do — as opposed to hidden and/or spammable meta tags. To that end, whatever convention is adopted or promoted should reflect existing standards. Frankly, the hcard microformat already provides a mechanism for identifying avatars with its “photo” attribute. In fact, if you look at my demo hcard, you’ll see how easy it would be to grab data from this page. There’s no reason why other social networks couldn’t adopt the same convention and make it easy to set a definitive profile for slurping out your current avatar.

In terms of URI locating, I might recommend a standard convention that appends avatar.jpg to the end of an OpenID as a means of conveniently discovering an avatar, like so. This concept follows the favicon.ico convention of sticking the favicon.ico file in the root directory of a site, and then using this icon in bookmarks. There’s no reason why, when URLs come to represent people, we can’t do the same thing for avatars.

Now, off of this idea is probably my most radical suggestion, and I know that when people shoot me down for it, it’s because I’m right, but just early (as usual).

Instead of a miserly 80 pixels square, I think that default personal avatars should be 512 pixels square (yes, a full 262,144 pixels rather than today’s 6,400).

There are a couple reasons and potential benefits for this:

Leopard’s resolution independence supports icons that are 512px square (a good place to draw convention). These avatars could end up being very useful on the desktop (see Apple’s Front Row).
While 80 pixels might be a useful size in an application, it’s often less than useful when trying to recognize someone in a lineup.
We have the bandwidth. We have the digital cameras and iSights. I’m tired of squinting when the technology is there to fix the problem.
It provides a high fidelity source to scale into different contortions for other uses. Trying blowing up an 80 pixel image to 300 pixels. Yuck!
If such a convention is indeed adopted, as favicon.ico was, we should set the bar much higher (or bigger) from the get-go

So, a couple points to close out.

When I was designing Flock, I wanted to push a larger subscribable personal avatar standard so that we could offer richer, more personable (though hopefully not as male-dominated) interfaces like this one (featuring Technorati’s staff at the time):

In order to make this work across sites, we’d need some basic convention that folks could use in publishing avatars. Even today, avatars vary from one site to the next in both size and shape. This really doesn’t make sense. With the advent of OpenID and URL-based identity mashed up with microformats, it makes even less sense, though I understand that needs do vary.

So, on top of providing the basic convention for locating an avatar on the end of an OpenID (http://tld.com/avatar.jpg), why not use server-side transforms to also provide various avatar sizes, in multiples of 16, like: avatar.jpg (original, 512×512) avatar_256.jpg, avatar_128.jpg, avatar_48.jpg, avatar_32.jpg, avatar_16.jpg. This is similar to the Apple icon .icns format … I see no reason why we can’t move forward with better and richer representations of people.

Onward!

An early look at Comic Life 2.0

Cris Pearson twittered that he’d uploaded some shots of the new Comic Life 2.0 welcome page. Take a look and let him know what you think. For more, join the UI Review group.

Problems with OpenID on Highrise

Turns out that 37 Signals’ implementation of OpenID could use some… getting real.

Let me go over these issues and provide either resources or remedies.

Normalization of OpenIDs URLs

Look at these three URLs and make a note to yourself about any differences you see:

To a lay person (or even your average geek), these URLs all represent the same thing — especially if you type any of them into the address bar, they’ll land you on my out-of-date homepage.

But, in the land of OpenID and URI evaluation, these differences can be very significant, especially when you get into the differences between OpenID v1.1 and the forthcoming v2.0 (which adds support for inames).

To the contrary of some discussion on the OpenID list, the way in which you normalize an identity URL very quickly becomes a usability issue if the cause of OpenID login failures are not immediately obvious.

Remedy: Given some of the issues folks have had with OpenID at Highrise, DHH decided to make usability the priority:

I’m going to fix the trailing slash issue on URL-based OpenIDs. We’ll be more liberal in what we take.

This should mean that folks logging in with OpenID shouldn’t have to guess at what their appropriate identity URL looks like, instead only substantively know what the important parts are (i.e. the domain and any sub-domain or path(s)).

Outstanding issues: Of course, 37 Signals can do this, but what happens when the identity URL that someone uses on Highrise doesn’t work elsewhere because other consumers aren’t as liberal with what they accept?

Lack of support for i-names

One of the issues (features?) that OpenID v2.0 brings is the support for i-names, a controversial schema for representing people, businesses and groups using non-familiar formatting codes.

I’ve heard that there’s somewhere in the ballpark of 20,000 i-names users in the wild (I happen to have =chris.messina but never use it), but compared with the over 70 million (and growing) URL-based OpenID users, this is an incredibly small minority of the overall OpenID landscape.

Nevertheless, one potential point of frustration for these users is in the lack of standardization in implementing or indicating support for i-names, as Rod Begbie pointed out in the Highrise forum, to which DHH replied, . We don’t support iname OpenIDs for now, though. We’re just supporting OpenID 1.1.

And this, I imagine, is going to be a common issue, for both OpenID implementors (dealing with support requests for support of i-names) and for i-names users, such that I question, as others have, the wisdom of offering support for i-names identifiers, when issues still clearly remain in the usability of basic URLs.

Remedy: Once the OpenID v2.0 spec has been finalized, there will need to be a new logo to indicate which version of OpenID a consuming site supports; this will hopefully work to set expectations for i-names users.

Outstanding issues: At the same time, the addition of i-names to OpenID v2.0 has caused a lot of concern for folks, many of whom have simply decided to stick with v1.1.

Personally, I don’t see the long term value in fragmenting the OpenID protocol away from more familiar URL-based identifiers. I want something simple, straightforward and obvious. Otherwise, v2.0 is going to be a headache to advocate, to implement and to support that a lot of folks with just stick with v1.1.

Double delegation aka the Sean Coon Problem

My buddy Sean Coon pinged me the other day to see if I could help him debug the problems he was having signing into Highrise with his OpenID account. When he had signed up, he had used seancoon.org as his OpenID URL. He’d started playing with it, but then left it, only to return later, unable to login.

His problem was three-fold, but I’ll first address a basic issue with delegation that some folks might not be familiar with.

As it turned out, Sean had delegated seancoon.org to resolve to ClaimID as his identity provider. The problem was that he used http://claimid.com/spcoon as his identity URL instead of http://openid.claimid.com/spcoon, which is where his OpenID was actually stored.

Typically when people use claimid.com/[username] as their OpenID identity URL to login to sites, this transformation takes place invisibly. This is because ClaimID delegates to themselves.

The problem lies in that Sean delegated seancoon.org to his ClaimID profile, which in turn was delegated to ClaimID’s OpenID server. If this sounds confusing, it is, and that’s why it’s not allowed in OpenID.

As I understand it, delegation can only be done once, or else you might end up in an infinite chain of delegations that may end in some grandious infinite loop. By restricting your delegation hops to one, a lot of problems are avoided.

Remedy: In this case, Sean only needs to re-delegate to openid.claimid.com/spcoon, and fortunately, there’s a handy WordPress plugin that can handle this for him.

Outstanding issues: Delegation is probably one of the coolest aspects of OpenID, since it allows you to use any URL of your choosing as your OpenID and then let someone else deal with the harder part of actually talking to all your services. Furthermore, you can delegate any number of services and set up fallbacks in case your primary identity provider is taking a nap. Communicating how this works and how to resolve and communicate errors when things go wrong is one of the biggest holes in the OpenID offering, and with user experience experts like 37 Signals joining up, I hope that these issues get the amount of due diligence and attention that they deserve.

Untested assumptions

Finally, I discovered a serious mistaken assumption in the Highrise sign-up process. To test out this issue, I created a test account, using http://google.com as my OpenID:

Now, here’s the problem: they didn’t force me to login to that OpenID when I signed up; instead they just assumed that I knew what I was doing and that I was using a valid OpenID.

So here’s the email that I got confirming my account. Note my username:

Of course when I go to login, I can’t, and I’m locked out of my account — since I can’t login and prove that I own google.com — which, notably, is the same result as if I’d mistyped my OpenID. Fortunately, 37 Signals gave me a backdoor, but it kind of defeats the whole purpose of using OpenID and suggests that you shouldn’t let folks arbitrary set their OpenIDs without having them prove that they really have control of their stated identifier.

Remedy: For implementors, you must get proof that someone controls or owns an OpenID if you’re going to rely on it as their primary identifier. You can’t assume that they’ve typed it correctly or even that they’ve even used a proper OpenID. And, most importantly, you’ve got to stress test such a new system to make sure issues like this are avoided.

Oh, and it does appear that MyOpenID.com OpenIDs are totally not working at this time; I’ve put Scott Kveton and Jason Fried in touch, so hopefully they can resolve the matter. Interestingly, if you’ve delegated to more than one identity provider and you’re using your own OpenID URL to login to Highrise, you should be able to get in.

Conclusion

It’s still promising to see folks like 37 Signals get on board with OpenID, but we clearly have a long way to go.

I hope I’ve clarified a few of the current issues that people might be seeing, or that are generally confusing about OpenID, and I admit that while I’m trying to clarify these things, a lot of this will still sound like Greek to most folks.

Given that, if you’re having issues getting OpenID, feel free to drop me a note and I’ll see if I can’t help resolve it.

ClaimID adds social networking

In spite of previous disavowals of having social networking aspirations, identity link aggregator ClaimID has now added the ability to add other ClaimID members to your profile as contacts.

Interestingly, they restrict you to adding friends who have OpenIDs (since every ClaimID profile URL is an OpenID) and use the XFN microformat to define your relationship.

This is a significant decision because, presumably, every OpenID has an owner. As such, adding one of these “verified” OpenID URLs as a contact to your verified OpenID URL could represent a higher trust level — a stronger “claim” as the lingo goes — than simply using the XFN rel-me attribute to create a “weak” relationship claim. Or so goes the theory.

Meanwhile, I’ve recently been reordering my Flickr screenshot collections and have created a set devoted to adding friends interfaces. If you have examples of similar interfaces, leave me a link to the source and I’ll get them added!

37 Signals’ new app Highrise launches

With narry a word on the 37 Signals’ blog SvN, the veil has been lifted on their long awaited CRM tool called Highrise.

There are a number of posts that capture some of the many features of Highrise on the SvN blog and are worth a look:

In the meantime, I’ve collected a bunch of screenshots (nice catch Allen) — in addition to their great tour — that will give you a sense of what the app is all about.

I’m totally excited about their adoption of OpenID, but I have to admit, their implementation — especially in the forum — is a little odd. I love the auto-adapting interface for inputing your OpenID, but the fact that I can’t sign in to the forum with the OpenID that I created my Highrise account with kind of misses the point.

And still no sign of microformats either, but a guy can hope right?

Anyway, it is exciting to take a look at all the interface greatness in this app — definitely some fine work. Whether I’ll become a paying customer is up in the air, especially as open source solutions like CiviCRM exist (though without the interface trappings that make 37 Signals products so attractive). I do like what I see so far, though — and if I can find a way to fit it into my workflow, I’ll likely end up a pretty satisfied user.

Customizing the QuickSilver Cube Interface

Update: 4/14/2007: I’ve recreated the NIB file to use the latest version of the Cube Interface source.

Update: Oops! I wasn’t very specific about that .nib file. I’ve updated the instructions to make it more clear now. As for HEX colors in the Color Picker, try the HexColorPicker. Thanks Frank!

There was a trend awhile back to tout your custom QuickSilver interface. At the time I resisted doing anything hardcore, content to enjoy other people’s works.

Well, without any QuickSilver updates lately, I finally gave in and copied a style I found in the forums created by Axlin by following the instructions provided by Hawk Wings.

To save folks the hassle, I’ll make this really easy for you.

First, make sure you’re running the latest version of QuickSilver (β51). Next, install the Cube interface if you don’t have it already. Third, launch the Cube customization interface.

Ok, once there, make your settings look like this:

Now, here’s where it gets a little dicey. You’ll need to first download the replacement QSCubeInterface.nib from my server. Navigate to ~/Library/Application Support/Quicksilver/Plugins in the Finder and make a backup of the existing QSCubeInterface.nib file in that directory. Now, right click on QSCubeInterface.nib and select “Show Package Contents”. Drill into Contents/Resources and unzip the QSCubeInterface.nib.zip file in this directory, overwriting the existing .nib (you should have already made a backup).

Now, quit and restart QuickSilver and you should be good to go. Lemme know if it works for you and if you come up with any other interesting examples of customization, post them to the QuickSilver Flickr group.