They've lost the traditional desktop metaphore and went for a network oriented one:

There are also icons representing the three different modes—home, friends, and neighborhood—that are integral to the "zoom" metaphor. In home mode, a user sees the XO Man, and, when she clicks on the icon to launch an activity, the icon for that activity pops into a gray ring encircling the XO Man. In friends mode, she sees icons representing her circle of friends, each identified by nickname and chosen color scheme. Next to the friends are icons depicting the activities in which they're engaged.

If several friends are sharing an activity—say, working on a school report together—they are pictured clustered around the appropriate icon. Our user can ask to be invited into a group activity or can start one of her own and invite others to join. The neighborhood mode gives a broader view of all of the individuals and clusters of friends on the network at the moment and the activities they're involved in.

Sounds very interesting and I'm curious to see the first test results!

So what we do with Lua is essentially all of the application logic from running the UI to managing what we actually do in the database. Pretty much every piece of code in the app that could be described as making decisions or implementing features is in Lua until you get down to the raw processing, which is in C++. The database engine is in C; the interface to the OS is in C++ and Objective C as appropriate to platform. But most of the actually interesting material in the app beyond the core database code (which is SQLite) and the raw processing code (which is essentially Adobe Camera Raw) is all in Lua.

I find this pretty amazing considering Lua isn't really object oriented and is dynamically typed. It looks to me like a primitive version of Actionscript 1. Of course a good editor can do a lot, but still I don't understand why the choose to program 40% of an application like lightroom in a language that seems makes it so easy to introduce typos in your code.

I've seen these things before but never quite understood how it works. Here's some more info that's worth looking into I think (haven't read it yet ):

• Advanced Character Physics
• Verlet Integration (Wikipedia)

I guess you'd use this if you wanted to make games like these:

• TG Motocross
• Orangutwang
• Blast Billy
• BMX Highlands

Looks like I've got some coding to do sometime soon ^^

• Shneiderman's "Eight Golden Rules of Dialog Design":

1. Strive for consistency.
2. Enable frequent users to use shortcuts.
3. Offer informative feedback.
4. Design dialog to yield closure.
5. Offer simple error handling.
6. Permit easy reversal of actions.
7. Support internal locus of control.
8. Reduce short-term memory load.

• Bill Scott's "Nine Tips for Designing Rich Internet Applications ":

1. Make it directly interactive
2. Make it inviting
3. Use lightweight, in-context popups instead of page transitions where possible
4. Use real-estate creatively
5. Cross page boundaries reluctantly
6. Create a light footprint
7. Think of your interactions as storyboards
8. Communicate transitions
9. Think in objects

• Jakob Nielsen's "Ten Usability Heuristics":

1. Visibility of system status
2. Match between system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

• Don Norman's "Design principles ":

1. Visibility
2. Feedback
3. Constraints
4. Mapping
5. Consistency
6. Affordances

To top it off I found another listing of several design rules . They present a set of design principles that are from several sources, and should comprise a complete set of guidelines.

1.   Use simple and natural dialog in user's language
Match user's task in natural way. Avoid jargon, and techno-speak. Present exactly information users need, not too little or too much.

2.   Strive for consistency
Sequences, actions, commands, layouts and terminology should be consistent so as to make the interface more predictable.

3.   Provide informative feedback
Continuously inform user what is happening. It is most important to provide feedback on substantive and infrequent actions.

4.   Minimize user's memory load
Human mind can recognize better than recall. Provide enough information so that the user can take action without recalling a lot.

5.   Permit easy reversal of actions (undo)
To reduce anxiety and encourage experiments.

6.   Provide clearly marked exits
So that the user won't be trapped on any level of the applications.

7.   Provide shortcuts
Enable frequent users to perform often used operations quickly.

8.   Support internal locus of control
Put user in charge, not computer.

9.   Handle errors smoothly and positively
Make the system robust and provide easy to use recovery measures.

10.   Provide useful help and document
Users should be able to get sufficient help information when they get confused.
 

"Let’s say you have a digital camera that shoots in Raw format. However, you’ve been using JPG files ever since you got it, due to a sense of familiarity, simply not having the time to figure out Raw, or because you don’t like the larger file sizes. Sound familiar?"

Well I guess that's me  

Before I would seriously consider it I need

• a bigger CF card,
• a bigger HD/ better pc and
• Adobe Lightroom for windows!

But perhaps I can do some testing in the meantime of course…

This is the start of my blog. It's supposed to become my home on the Internet. The goal of this blog is to become a permanent log of all things interesting I come across everyday. Although I do this primarily for myself,if you have something to say please do so via the comments or by mail.

ps. WordPress and all of the available plugins are simply the best thing I've ever seen! It totally rocks!