Microsoft research evaluating different user interface designs by which applications disclose to users what sort of authority they need to install themselves.
Anyone who's been around this site for awhile (all three of you) knows that I have a long standing series of beefs with Apple on how they handle podcasts on the iPod/iPhone. In summation- Apple initially treated the UI for podcasts very much like that for music/songs and have subsequently updated with a series of patches and band-aids to compensate that slowly increment towards a passable podcast UI.
Apple's new iPhone software includes another one of these fixes that is likely spurned on by the same issues I brought up in my previous post on this topic- the seek and slider functions are terrible ways to get around a podcast track. So, they've provided a very welcome "30 second" rewind function. Also gone are the shuffle and repeat functions, which didn't make a lot of sense for podcasts in my opinion anyway (more music thinking transposed to podcasts)
It's welcome, but I still consider this a patch. We now have three different ways on the same screen to move around the track: Seek, slider, and 30 seconds. More UI equals more decision points and more complication. I suppose it would be passable to do this, but as I pointed out before, the first two are pretty much worthless for long podcasts, the seek function is too clumsy and the slider is impossible to do anything with accuracy. The original iPod click wheel did a decent job of allowing you to move around the track with few problems, I had no issues with that interaction.
I feel like this whole podcast UI needs a "from scratch" redesign- perhaps my next related post will be a mockup of a series of ideas I've had over the years, since Apple seems to only pay enough attention to podcasts to add one small feature with each release that only slightly moves the bar forward.
A report by 37signals on their redesign of the signup chart for their Highrise product.
PS: Since yesterday, the more appropriate "Pay as you go | No hidden fees | No surprises" line was replaced on the live site by the redundant "Our customers" quotes.
Scenario 1: New user from a trusted IDP If an AOL user comes to the buy.com site with their current UI (as opposed to the suggested modified UI), and has never created an account at buy.com before, then they would enter their @aol.com E-mail address, and choose "I am a new customer." In that case, buy.com would show them an account creation form. However, let's assume buy.com is willing to act as an RP, and it has decided to trust AOL as an IDP. Assuming they switch to the UI model suggested above, then when the user visits the buy.com site, they would enter their @aol.com E-mail address, and choose "Help me sign in." Admittedly the phrase "Help me sign in" is not as explicit as "I am a new customer" however so far our usability tests have shown it works just as well (though we would like help getting more data to confirm that fact).
In this scenario, buy.com could detect that the domain name is for an IDP that it trusts. It could then redirect the user to AOL to verify their identity. Assuming the user approves sharing their identity, then the user will be redirected back to buy.com which can automatically create an account for them, and log them in.
It’s ironic (and predicable) that the interfaces SUPPLE comes up with for dexterity/visually impaired people are just better interfaces than the controls. The optimized interfaces almost always display more information in a way that requires less clicking than the original interfaces. No wonder they perform better! It’s just a direct application of Fitts’s law and GOMs analysis.
One interesting thing to call out: The interfaces for SUPPLE are defined by schematic intent, not by layout. The computer translates a user-flow markup into an actual interface. We’ll probably see a lot more of this as we need to design web sites for truly divergent screen-sizes (computer, mobile, wall screens).
http://crave.cnet.co.uk/mobiles/0,39029453,49295452,00.htm Here's the Modu phone concept. It's an interesting idea of having a core unit that might plug into other UIs that share some core functions and information (like an address book). The article shows a music player, phone and car stereo "plug-ins"
Of course, this is nothing new- we're already pretty darn close to this already. My iPod- I dock it at my computer at home, I (essentially) dock it into my auto's stereo system, I set it up with portable speakers, and dock it at work. It's already a device that works in harmony (sometimes) with all these other devices and interfaces, but with the added bonus of being it's own self contained UI. It's making these modules more meaningful such that the user experience is married to design of the devices that's missing- that's what this concept is looking to address.
I'd like something in the middle- ideally, I'd like an...well, let's say iPhone... that I could slide into a small lightweight keyboard, I want to be able to dock it *into* my computer at home, have it marry up into my car stereo; in which case I'd like to be able to just slide it in like an old cassette tape.
We talk a lot about mobile phones around here.... a LOT. Well, here's more fuel for the fire: a new method that puts the ABCD layout surrounding the traditional phone key buttons. Faster than the multi-tap, but qwerty it's not. Still not a bad compromise I suppose. What do you think? Looks a little "loud" to me from a design perspective. But I understand the diffculty of laying a qwerty orientation into that design.
I'll pit this in the "moderate" middle of the road design with the Pearl/Sure-Type devices.