Please make this with a canola stiyle in mind!

Canola Style ... personnally i don t like.

And remember that canola use efl so virtual keyboard don t, no very great for n800 and 770 user. Also, it ll eat many ressource at start ... and i think that this is too slow when you need to quickly see or write an event.

And the main problem with a canola style is that that require to write in efl ... and :

1) don t know it (will slow down process)
2) don t like it
3) can t be dev onboard as ui require psudo compile ... so can t do it

canola seems like a replacement for the hildon desktop more or less...

i much prefer stuff that lives nicely within hildon desktop

I am pretty sure most programmers incl. myself are able to design better UIs than they program. This is due to the fact that they have to deal with a bunch of constraints. In your words: We'd love to build nice buildings and we even have ideas for very cool buildings. But we only have simple stones to build with and a limited time frame.

I'd actually love to have a bunch of programmers that have to implement my design ideas no matter how hard this turns out to be. Unfortunately i myself am the one who has to cope with my own design ideas. So the programmer in me often overrules the designer in me.

This kind of design seen here is only useful if you have a lot of talented programmers with a lot of time to spend. All others will have to base their designs on the basic mechanisms the UI framework provides. And their software will then lack all those fancy details. In the current example you'd have to make parts of the UI slide in and out of the screen. This is very hard to accomplish if you are dealing with a gtk/hildon based machine that has a major video bottleneck (coincidentially this is true for the current maemo plattforms).

And there's even a downside if someone actually succeeds in this: You'll have a program with yet another new look-n-feel.

Someone mentioned canola. While i think canola looks great and has a nice UI for a media player i really don't want to see something like this in a PIM application. If the PIM application is meant to be used by the average user it should work exactly like all those other programs the average user deals with.

That's really one thing where PalmOS was great and where the Apple Newton was even better: Once the user learned how things look and worked he could be sure that the same things always looked and worked the same. Maemo lacks clarity here. And i am afraid this might even get worse with the inclusion of QT based applications. Today we already have pure-GTK apps, Hildon/GTK-Apps, QT apps, SDL apps, command line apps, libillumination based apps ... And they all look different and work different. This is actually what i think apple really does make better. They force their developers to use certain frameworks and they really spend a lot of effort on design rules. And that's even something i miss since i went from PalmOS to Maemo.

I agree with the above with one caveat: maybe we have not yet seen the best way to implement a PIM interface. All we have are software analogs of real-life tools (rolodex, calendar, post-it notes, etc) because that's what we know and love. But what if someone scrapped that legacy and redesigned a PIM UI from scratch, and it blew away what we're used to? I'd be first on board, learning curve or no.

I must be masochistic though-- I'm forcing myself to use Office 2007 at home.

heh, if so i guess one need to start by canning PIM and related terms.

the kde devs had to do the same when they wanted to retool the menu used to launch programs. as long as it was referred to as a menu, people assumed some stuff about its design.

if i say calendar, people are likely to envision the classical wall calendar, with its page of numbers, and maybe a cute image above...

Oh, naturally. For example, there is no reason to keep tasks / calendars with seperate data. They should both refer to exactly the same kind of information; they're just different views. For some reason, I have yet to meet a PIM tool which grasps that, even though it would make things easier.

A UI needs to be consistent for like functions across applications. This doesn't however mean that all applications regardless of function and visual characteristics must use an identical UI. Absolute contraints on the UI will result in compromises that favor some applications and burden others. How an individual application is used is an important consideration for picking the best UI. One of the worst examples of imposing a UI is the Apple's one button mouse. Would you want to replace the steering wheel and pedals of your car with knobs and buttons because that what your car radio has.

Or replace the car radios buttons by a steering wheel? Oh, did someone say iDrive?

I basically agree with you. But this imho still doesn't need a completely different UI. Some basic new widgets may be sufficient and these could even be used by other applications in turn.

E.g. the application installer introduced the hildon-breadcrumb-trail widget (the navigation bar on top). I really enjoyed re-using this in gpxview and since most users have used the application installer before they were familar with this kind of bar in my program.

Please don't do this as fullscreen app only.
That's why I don't even install canola - pretty but i prefer to use multiple apps at time just for flexibility in exchanging data between them.