I did have one problem that after reading several articles I would keep getting a white screen. I have hundreds of feeds with thousands of articles and interrupted a sync – so maybe that was the cause.

The app is so good I missed two subway stops on the way to work. Woops! But I recommend anyone who has an iPhone and a Google Reader account to get this app.

I am in no way affiliated with the Byline team.

You can skip the last 10 minutes or so when he dives into this odd crazy future… but the beginning part really makes you think about how you can add game theory to any business you’re in. I really like the idea of experience points and leveling up for class. That’s something any event-based business could really get into.

h/t Andrew Holz. via fury.com

Being able to make the necessary tradeoffs between conflicting constraints takes skill. I’ve always viewed constraints as my friends. They make me more creative. By thoroughly understanding the limitations that constrain a design solution, I can make the right tradeoffs and come up with the best design solution possible under those constraints. Plus, balancing different constraints often forces me to think outside the box, so inspires innovative design solutions.

Excellent and long article talking about various user-time-wasting or user-annoying things to avoid in your UI.

I think these are perhaps the tenth and eleventh questions you should ask, not the first two. Here’s my list of difficult and important questions you have to answer before you spend a nickel:

It's fairly well documented and has a full suite of specs written in ScrewUnit.

Mamoo let's you stop thinking about the "glue code" you need on a client-side app - and start thinking like "when this happens, I want this to happen." - Event driven architecture in JS.

Checkout the readme for a romp through most of the features.

To whet your appetite, here's a really small, but useful app written with Mamoo.

Assuming you have an ol with the id of "message_list" in your html page, now everytime you create a message, it'll get populated into the DOM.

I also put together a 15minute screencast that gives you a quick demo of a bunch of the features of Mamoo.

Nifty?

Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity.

David Gelernter, Machine Beauty: Elegance and the Heart of Technology

Amen. Amen.

I hate it when people use the argument: "but this worked."

h/t: A design and usability blog: Signal vs. Noise (by 37signals)

People are saying this was a twitter rival. I think their product
could have been great with a slight twist on marketing - making it for
"small group file and links sharing" rather than micro-blogging...
they already had the features - but didn't push it in that direction.

I think the big problem with OpenID right now is that we're all thinking about it like geeks. The main benefit to the user is that he/she doesn't have to sign up for yet another account - or give out a potentially sensitive password (considering most users only use 1 password everywhere).

I don't know what the percentage is, but I would bet nearly all (US) users have accounts at one of yahoo, aol, google (and maybe a handful of other openID providers - google is only supported through an AppEngine app).

I think the UI below would make openID more understandable to more users. You have any thoughts?

Those links (if you haven't checked 'em out) provide some nice insight into how the SproutCore team is thinking about javascript models. It's an interesting pattern of separation.

Basically:

In a model you use MyModel.get('blah') and MyModel.set('blah') and then (it uses ruby helpers) in a view you do something like this:

where bind is telling it to update the view everytime the value 'blah' changes.

It seems like a relatively simple pattern (at least for simple updates). I'm not totally sold on SproutCore itself (and it's defacto lock-in to certain UI) but all-in-all those guys are real smart and are paving the way for real client-side javascript frameworks (not just these libraries that we have now).

He pointed to the success of Amazon's checkout page. His thought is that their checkout page is so well received because it allows users total control of the experience rather than the locked-in Step 1, Step 2, Step 3 process.

It's an interesting idea: allow your users to "play" in your software. The "lipstick" becomes much less important.