Aaron J. Seigo: Applications that are shipped with KDE are required to follow the KDE guidelines and standards, so obviously the project understands the importance of such things. In fact, a tremendous amount of effort has gone into codifying as much of these standards as possible in the KDE foundation technologies so that it isn't necessary to burden individual developers with the task of compliance. This guarantees users get consistent applications when they are built on KDE.
To me, that's much more impressive and important than a certification system, since it addresses the problem directly rather than poke at the symptoms. This is especially poignant in the Free software world where the motivation for achieving a "certified KDE" sticker would be far less than it would be in the commercial development world.
Havoc Pennington: I think this would be unrealistic right now, because there's no one who would have the substantial time required to do the evaluation work. But it's certainly something we'd like to have as usage of Linux/UNIX on the desktop grows.
Waldo Bastian: There is certainly a strong encouragement to follow guidelines and standards within KDE. Consistency among applications was one of the major driving forces for the creation of the KDE project. We try to achieve that both through the KDE style guide, which was published several years ago already, and by offering standardized solutions through the KDE framework. Especially the latter is very effective.
We have considered creating some form of unofficial "stamp of approval" or at least "rating" wrt standards compliance of applications but so far we haven't been able to find enough manpower to pull that off.
An "official" stap of approval is even harder in that respect since it would put much higher demands on such process with respect to issues as fairness, objectivity and processing time.
3. FreeDesktop.org is a very useful organization, created to do what in my opinion should have been done years ago... I can't help thinking how things can work out though (in order to unify the two desktops in a way that brings consisntency to the Unix desktop), when the two HIGs are not compatible. For example, the OK/Cancel order in a window just to name one and change all the third party apps to comply with any new rules, can be quite time consuming, if not possible. How can the FreeDesktop bring interoperability between the two DEs with such issues at hand?
Aaron J. Seigo: FreeDesktop.org has already brought KDE and GNOME closer together in terms of interoperability when it comes to things that really matter like the clipboard, so there is no question about it having already been a benefit. But FreeDesktop.org is not a source of magic solutions. There will most likely continue to be differences when it comes to interface details for the foreseeable future. The situation is similar on other contemporary platforms as well, so I don't know if this is really a problem to be too concerned about though it is something I'd like to see addressed over time. This is why I helped start the Open HCI project which is currently in its earliest of days.
Of course we are ultimately at the mercy of the individual development teams and their developers. If one group decides cooperation, consistency and user-centric solutions are more important than achieving their own interpretation of an aesthetic world, then everyone benefits (including the developers). When users and developers support the project(s) which have values similar to their own, this reinforces "good" decision making and removes mobility from those making "poor" decisions. Having more than one project for people to support makes this process fault tolerant.
In other words, grass roots user and developer support is more potent than FreeDesktop.org alone can be in these matters. In turn, FreeDesktop.org needs to reflect those broader interests to be effective.
Semi-off-topic sidebar on the Ok/Cancel issue: KDE has implemented things in such a way that allows all KDE applications to have the order of these buttons flipped with a change to a single line of code. It is exactly this sort of brilliant design that allows KDE to be so internally consistent. So the question often comes down to whether or not we SHOULD make a change, rather than if we CAN. Personally I think it is irresponsible to impose personal aesthetics on your users in a seemingly random fashion by disrupting the interface they know without *very* compelling reasons to do so.
Havoc Pennington: There are certainly benefits to each intermediate step. For example, if all my apps work with the same "recent documents" feature, then that is a big user-visible improvement (bug fix, really). It's a big improvement whether or not all orthogonal problems are also solved.
That said, the shared HIG problem is an interesting one and I'd like to see some progress there. Seth and Aaron are just starting on it so I'm optimistic.
Waldo Bastian: There are always solutions possible. However, instead of focussing on the hardest issues, I think it is much more productive to focus on those areas where results can be achieved relative easily. 100% consistency between the different enironments doesn't come overnight, it will be a long process, but I'm convinced that we will also be able to solve the hard issues somewhere along the road.
4. Some systems, such as Mac OS X, hide the directory stucture from users who don't purposefully look for it. However, products such as Konqueror and Nautilus currently do not do this, and almost flaunt it with address bars in the file manager and so forth. Do you forsee more "hiding" of the Unix underpinnings in the future, or would you prefer to expose users to them? Also, how has Apple's OS X interface influenced you, if at all?
Aaron J. Seigo: I foresee both happening simultaneously. No to sound too Zen about it, but there is more than one path that leads to the top of the mountain. As there are benefits to various amounts and types of exposition depending on the particular use case, rather than simply choose one level of abstraction we need to decide when and how to abstract away the underlying details and when to allow easy but direct interaction with those details, preferably with the user in control of that decision.
Today there is room for improvement on both ends of that spectrum. So I expect in the future we'll some developments that help insulate the user from gross detail, while other developments work on reflecting the underlying OS more accurately in the interface.
As for OSX's interface, for me it was a lesson in user respect and self-confidence, both good and bad.
It's taught me that no matter how well you've done in the past, you can still make amazingly obvious and stupid mistakes. Everyone is fallible and nobody has all the answers yet. It also showed me that when you take away options you disenfranchise your users: look at how many things were added back into Jaguar due to user demand that had been removed in 10.0.
It's also taught me that eye candy is a more important part of the user experience for most people than I had previously considered. They'll put up with dreadfully slow start up times and all sorts of "dot-oh" interface blunders if it looks like a visual masterpiece.
Finally, it showed that you can introduce radical new concepts into an interface that have real benefits (such as dialog sheets) and users will grok them even if they aren't available in other popular interfaces. So we shouldn't be too afraid to introduce new UI concepts.
Havoc Pennington: I think more hiding is generally appropriate, yes. In star trek future, something better than a hierarchical filesystem might be nice. In the meantime, users don't want to see /usr, in the general/default case.
Regarding Aqua, when doing a new UI component, we generally survey existing UIs in that area; for example here you can read about the new GTKFileSelection.
So OS X usually factors into those kinds of discussion.
Waldo Bastian: I see it as a similar issue as wit the command line. Users shouldn't need to know about it but it should be available to them when they so desire.