Once you get over a trivial number of friends - once you have more than one social circle - Twitter doesn't scale at all. If I send a public reply, my followers get it... but don't have the context originally.
So, it works well, until you get beyond one social circle, and then the whole thing goes to hell. It's great for shouting something to a larger group (at the Sharp Edge Beer Palace!), great for content-free posts (I'm pooping!), but terrible for conversation.
It's interesting to see that both Google Buzz and Facebook Status Updates address this; you have well-threaded replies that don't ping your followers unless they were one of the repliers. Buzz scales better than Facebook; Facebook defaults to emailing you further updates, while Buzz simply bumps replied-to responses that you previously replied to to the top of your stack.
Dunno. I still don't understand Twitter. A friend mailed them a (relatively huge) public security bug three or four years ago, which took them the better part of three or four years to fix. (An http: should have been an https: when pointing at Gmail.) Not impressed?
Twitter vs Buzz vs Facebook updates
UI/UX
Fifteen years ago, a person I'd met wound up landing a job with Microsoft; he was incredibly well versed in DirectX, and was part of the team at Bungee that wrote Halo, one of the best selling and most popular videogames to date.
I saw him give a talk on "why was Halo so popular?", and the question was "any secrets for UI design?" His answer was very simple: "Dip it in floor wax. Make it shiny. Make it so pretty, people walking by want to *watch* it being played. But mostly, just dip it in floor wax." I talked to him afterwards, and fleshing out the theme, their strategy was a two step approach:
- First, make the controls and physics model as intuitive as possible. Users shouldn't feel they have to learn the system, as much as just pick it up as they go.
- Second, layer on the best eyecandy you can find, so that users *want* to keep looking at it, and bystanders give it a look as well.
Some organizations have full-time user experience teams, responsible for tasks from creating overarching guidelines to guide development to doing low-level development of the UI on projects. At our organization, I haven't seen this, but I have seen contracting out UI and UX to a design firm, and then insourcing the development behind it. But some projects don't do either, and that's where I think we can realize the biggest gains for development, clients, sales, and operations.
Here's a large list of UI Style Guides for 50ish organizations: http://www.theuxbookmark.com/2010/08/interaction-design/a-monster-list-of-ui-guidelines-style-guides
In the list, it's kind of interesting to compare Apple's iPhone App Style Guide vs the Android User Interface Guidelines. The MITRE Group published 700+ rules in six categories on the topic... in 1986, and while technology has advanced (the WWW!), this seems incredibly useful for mainframe and other text-drive applications. For "best Federal site", NASA has their act together. As far as "best informational site", read the Philosophy page on BBC GEL.
Any other great UI/UX links out there?
Statistics for UI Testing
So, you've setup two copies of your web application, and don't know which is better. You know you have 10,000 users, and you randomly give 50 people the new copy, and see how that goes. 23 of them don't like it. Is that statistically significant?
Here's a quick article summing up all of statistics for user experience testing. It's long, but I'm bookmarking that one for the next time the numbers come out close to even, and I need to be able to explain what those numbers mean.
IE6
So, I had to give this explanation today at work, why developers don't really care for IE6. It ballooned into something postable, so here goes.
IE6 was built around 2000, and ignored several significant web standards at the time. IE6 was somewhat of a "lesson learned"; IE7 is better about following those standards, and IE8 is better still.
Firefox was built around Netscape/Mozilla, and importantly, they followed the public standard as much as they could. Firefox largely behaves like Safari, Chrome, Opera, and the tons of tiny-marketshare browsers out there.
Manager asks: So, why support the standard, instead of IE, which is the big kid on the block? Almost all of our customers use IE!
Answer: Because IE is slowly moving towards the standard, too. If we support Firefox, IE8 is easy, and we probably get IE7 as well with almost no changes. IE6 is the fly in the ointment here.
If we support IE6 - the original idea - then IE7 is a special case, IE8 is another special case, Firefox is a special case, and so on.
If we can encourage users to move away from IE6, that's our best case scenario. I believe Microsoft officially ended all support - including security patches - for IE6 when Server 2003 SP1 left support, April 2009.
Google has stopped supporting IE6 entirely, for example, politely letting users know they need to upgrade "for the full site experience". Sites like IE6NoMore offer a pretty slick CSS popup for those running IE6, giving them a few upgrade options.
But in the meanwhile, since customers do use it, IE6 is here to stay, and it's easiest - and most maintainable - to build to the standards, and hack our way back to IE6 until it's done.
Usability
I've been working part-time on refactoring a larger application (200+ pages), focusing on developer maintainability, scalability, and also look and feel. The maintainability is pretty simple; adhere more closely to style guidelines in the code, make more logical use of design patterns in the layout, and make sure the code is written for the long run.
The look and feel - aesthetics and usability - are trickier beasts. They're the bottom priority, since you *can* sell an ugly duck of an application as long as it does work; you can't ethically sell an application that doesn't work, but looks like it was dipped in floor wax... unless you build video games, and have the ability to patch after release, I suppose. (Here's looking at Sierra for some of their adventure games that replaced the text interface with a mouse, and were unbeatable until v1.1 came along.)
I'm slowly building a comprehensive set of rules to guide the developers building the new pages, but meanwhile, am having to make and justify a huge number of minuscule decisions. When there are large gains to be made in reducing server load for the same number of users, it's hard to justify a fifteen minute discussion on how to indicate onscreen that a field entry is required.
So, let me put that here.
First: *
Second*:
*Third:
Fields with a * are required.
The first three - and most common - choices are here. The first one is visually cleanest; the required * is easy to pick out, but doesn't distract you visually. The second one seems the most logical to me, as it follows sentence structure; the interface is telling me what to enter, whether it's required, and then letting me enter it.
So let's justify the third by knocking down the other two. If someone's using a accessibility device - magnifier or a full screen reader - they may stop entirely at the label then the entry, and not pan right (or read right) to get to the required *. Or, all of the boxes may be the same length, so adding an extra * to the right might throw off our column layout.
As far as throwing off a column layout, I'm a pretty big fan of the right hand side of a label (First, Second, Third above) being lined up with the labels above and below it. It just looks sharp.
| Test | |
| Example | |
| Another Example |
vs.
| Test | ||
| Example | ||
| Another Example |
My current preference might actually be bold or italics:
Fourth
Fifth
Depends on your font; with Blogger's default bold, I don't think that's visible, and the italic isn't much better.
The other thing to mind, used successfully, is having regions of the screen required, and other regions optional. Giving a quick example:
Required Fields
First Name
Last Name
Optional Fields
Age
Sex
That last one isn't bad, but works better for a single page of form data, while not working nearly as well in an application with many pages of input.
In the current application I'm working with, the original Three above wins; asterisk to the right of the input field. It's a wide interface, with plenty of room to each side of the form label and form input. It's also a closed commercial interface never meant for a wide release, so the odds of incompatibilities with screen readers are low.
What are you using for required fields? What's the preference?
CAPTCHA and Microsoft Asira
A CAPTCHA is a quick test on a web server, to tell if the person accessing the server is a human or a computer script. They might display a few characters scrambled slightly, and ask you to type them back in. Since a simple script isn't doing image processing, the odds of a script accessing the page (or signing up for an account!) is pretty slim.
The problem is usability. I'd consider myself pretty good with computers, and occasionally I'll hit a site that scrambles the catchpa enough that I have to give it two or three tries. Less computer savvy users are going to have significant problems signing up for an account. You can make the scrambling less aggressive... but that ups the number of scripts that can then slip by.
Microsoft Research seems to have come up with a hugely usable solution, based on the work of several other groups. Take an image, base a "yes or no" question on it, and have them cycle through ten pictures quickly. That gives a script a 2^10 (1 in 1024) chance of guessing them all correctly, but if the pictures are simple enough, that gives the average user an almost certain chance of getting it right. Other groups had done this with relatively small pools of pictures, where a script could then learn which images should get which answer. Microsoft brought in a business partner and used three million known images, asking the easy to answer question:
"Is this a dog or a cat?"
(And for the record, CAPTCHA is a Completely Automated Public Turing-test to tell Computers and Humans Apart. The acronym feels like a stretch, so it goes down here at the bottom.)
