1) Users have an address book entry
The first time you log into OS X it asks you to fill in a form with your information. I figured it was for registration and just put in my name, selected and icon and then clicked that I didn't want it to be sent to Apple. I didn't think about it much until later when I started using iChat and noticed that it had used my icon and had my real name. Then when I opened the address book I found an address book entry for me with the information I had entered. The idea of using your addressbook entry everywhere might seem like a simple idea, but it is not one that has caught on in KDE.- Games shouldn't prompt you with a blank name dialog when you get a high score.
- IRC/chat/aim/kopete should know your name, your nick name, and icon.
- KMail should already know your name (and pgp key!) when setting up an account.
- KDM shouldn't need to have a separate configure spot for the user icon.
- If you update your user information it should update the system.
- Digikam can mark each photo you download as taken by you.
- KWord and the other office applications can mark that you edited/authored the file rather then a blank field.
For KDE 4 I think that when a user first logs into KDE it should be prompted to make an adderessbook entry so that applications can take advantage of this information.
2) Single Toolbars
All through out OS X you will find that application typically only have one toolbar and the vast majority of the time there are around seven actions displayed with large icons and text underneath. Don't think it is possible? Lets take a very complicated application, a development IDE. On top is XCode and on the bottom is KDevelop after creating a project named "foo".

I figured there must be a some large set of rules in OS X for what should be in the toolbars. But when I looked it up in Apple's user interface guildlines Window Appearance section
and I found this: "Toolbars are useful for giving users immediate access to the most frequently used commands." So if you are making a media player just because you have the actions cut, copy and paste does not mean they should be in the toolbar, but Play, Pause and Next should be.
This particular issue has already been brought up several times on the kde mailinglists and for KDE 4 it is almost certain that this is going to be changing to follow this rule. You can set large icons with text by default in KControl today to see how your application will look. Right now the easiest thing to do is to remove non essential actions and to shorten the really long names. You might have noticed me doing this from time to time in applications. As a bonus you will find that you have less code, icons, etc to maintain.
3) Applications present simple default views
Compare the difference between OS X's addressbook on the left and KDE's on the right. A very common desire for addressbooks is the ability to create groups of friends, coworkers, etc. If you wanted to make a group of all of your coworkers in your addressbooks what would you do? In OS X's you just click add in the group box and then drag any entries over. In KDE's you have to edit each user, click on select categories and check the category they are in. To add a category from the same dialog click, edit categories, and after typing in the text then click Add. Of course in KDE I can't see any easy way to view all the users in one group. Editing a user is also simpler in OS X, you just click on edit and then the field you want to change, in KDE you have to click edit which brings up a five page dialog and find the field that you want to change. Probably worst of all is that most of the space in KDE's addressbook is taken up by a resource widget which to this day I still don't know what as a user I would do with it. This really should be part of the configure dialog as it is not something you do every day. One final thing: notice how my name in OS X's addressbook is highlighted with the little icon showing that it is "my addressbook", KDE's doesn't have that.

In fact the above OS X addressbook screenshot isn't even the default view! The default addressbook is what you see below:

When I first saw this I laughed at it because I thought this addressbook must not be able to do half of what KDE's can, but it can and in this view it was perfectly usable. You search for someone and their name pops up, click the "+" to add someone. Click the multi-column button for multiple views and you can add groups (and smart groups, aka searches). Adding an LDAP server is in the configure dialog just like in KAddressBook
Lets taking a look at another KDE application. The other day I loaded up Quanta so I could see what has changed sense I last used it. Notice how much of the window is actual productive space where you can work on your document. A quick list of actions presented to the user:- 13 different top menus!
- 34 toolbar buttons in the primary toolbars
- 5 left sidebar things
- 2 bottom sidebar things
- 2 right sidebar things
- 6 tabs of toolbars on top of the edit window each with around 10 toolbar items
- Tabs for each open file
Granted this isn't as bad as KDevelop, but still it feels like the developers tried to cram everything on the main screen to the point that I as a user have absolutely no idea where to look for things. I personally hate the idea of the sidebars and find it way to confusing, and to have them on every side of the screen is too much. Application do not need to present this much to the users on the default view and in many cases it is redundant. When I started clicking on buttons the entire screen started changing (as things showed and hid) and after ten minutes I gave up and quit.
This issue is different for each application. Typically the default configuration and view of open source application don't get much attention because the developers never have a clean install :) Hopefully developers will take a minute to look at their appliciation and make some large changes for the better.
4) Drag And Drop
Unlike the promises that Windows had and the lackluster support in Linux OS X really does have drag and drop support.
- Installing most applications is not harder then dragging the application (folder) to where you want it to be
- If you are viewing/editing a document it shows up in the caption bar as a little icon, just drag that icon to make a shortcut
- Can't forget that to eject your CD you drag it to the Eject button (formally the trash)
- I typically open files, import, and extract from application using drag and drop.
Part of the problem why Linux doesn't take advantage of drag and drop as much is that we developers have a right mouse button. Simple things such as selecting, right clicking and choosing and action you don't do in OS X because you can just drag the objects around. Because we have a right click we don't get around to implementing the drag and drop. The problem comes when there are options in the right click menu that arn't anywhere else. It would be better to think of the right click menu as a toolbar, and use the rules that apply.
For akadamy it might be fun to go out and buy a bunch of single button mice and put them on every computer and see how the developers fair and discover what actions are impossible with a single button mouse.
5) Integration
Closely related to drag and drop is desktop integration. Beyond the fact that every application uses ctrl-q to quit I am talking about:
- Utilizing the addressbook to get the current users information.
- Playing a song/playlist from the media player in the photo album application when doing a slideshow.
- A photos screensaver uses your photo application to select an album.
- A screensaver that uses album covers.
These are just a few things that I have seen in OS X. When writing your application think about how it can be utilized elsewhere on the desktop. For example digikam could also include a screensaver in its source tree. In Tiger OS X took this to the next level with Automator. A small application that lets you build scripts in a gui environment. A wonderfull example was a script that got all new mail and put them on your ipod. Providing ways for other applications to hook into your is important. Unfortunately querying applications just isn't implemented. For example I can not query kmail for all unread mail or kaddressbook for users in my family group. This might be fantastic project for someone to start for KDE4.
If an application can be converted to a web application (hint: KColorEdit, KTuberling (Potato Guy), KDict) without any loss of functionality then either that application really should be a web application, kpanel applet, or it should be improved to take advantage of KDE better.
6) The Window Manager has planes
Application such as Photoshop or Qt Designer 4 display a number of windows up on the screen at the same time. After launching them in KDE if I brought KMail on top I would have to then manually bring each Designer window up top. In OS X clicking on one window will bring every window in that application to the top. I wrote a small patch for kwin so that KWin will behave this way. Although simple it is quite amazing when used.
I hope to get this in KWin for KDE4 as a configure option. Perhaps the default?
7) Application Folders
Unless you have been living under a rock you already know that applications distributed in OS X can just be folders with a .app extension. I have seen a number of small projects start to enhance the file ioslave to give it this capabilities, but nothing has really come out of it. Someone should take the time to add the support officially to KDE. At the bare minimum written in Python (or javascript, bash/kdialog, ruby, etc) would be able to work and developers could even release KDE applications. That would create a fantastic little sub community that could easy pass around their applications. Users would just love this feature. I have written a small script which will generate app folders of all of the existing KDE applications (those that have .desktop files) for the KDE-darwin project which can be fun to play around with.
8) A Common Viewer
Apple includes an application called "Preview". In essence it does something very similar to Konqueror. It can open any file that I give it. It doesn't let you edit it, but simply view it. It is a small application that can view images, pdfs, but not html, Safari is used for that. For KDE 4.0 Konqueror should be split into three different application. A web browser (Konqueror), a viewer (Viewer) and a File Browser (Browser, ok you can come up with a better name). The backend for these three different applications might be very similar, but their user interfaces should be different so that they can best serve users.
With this viewer then KDE wouldn't need to have all these separate applications:
- Fax Viewer (KFax)
- KView
- KGhostView
- KPDF
- KDVI
Update: recently a new project was started to do just this: Okular
Heck you could really remove most of KDE Graphics for this one application. Which brings us to the next section.
9) The number of core applications

When you first use OS X you might be a little annoyed that there isn't a Start Menu (or equivalent) to let you explore the list of all installed applications. Part of the reason is because in Finder when you click on Applications there are around only twenty application installed. Combined with twenty more in the Utilities Folder. This might not blow your mind until you start to count how many there are in KDE and we don't even provide all of the same functionality (no DVD player, Automator, Dictionary and manu of the utilities). Ok yes they only include one game, an opengl chess game, but still the numbers don't look good. There is a lot of duplication in KDE that can be trimmed down.
- KEdit should have been removed long ago.
- CD playing and ripping should be in Juk or [insert your favorite music player].
- Adding the above KViewer will "remove" a lot of applications.
- Konversation, KOpete, KSirc, only one is needed.
- KAppfinder really shouldn't exist at all, applications should have a desktop file and if not a bug should be opened against them.
- kget shouldn't be listed as an application, but just something that shows up from within Konqueror.
On the personal side I am working on improving audiocd so that it can be very easily intigrated into Juk or any other application and when that is done i'll move KAudioCreator either to kdeextragear or to my own person website for archive purposes depending upon demand.
10) Where is number 10?
I didn't want to mention the panel or the file browser to much because there are already efforts underway with Plasma and some thoughts on Konqueror. Because these two are so heated and quickly take over any sane topic those two could easily overwhelm any feedback from this article. When discussing this article please refrain from branching too much into them. There will be many discusions on them at akadamy.
Hopefully you have learned some new things about OS X. I know that most Linux developers come from the Windows world so you know exactly what you are completing against there, but take the time to check out your competition on the OS X side. Not just from Apple. For example I recently downloaded the application "Colloquy" which is a third party IRC client. After using it for a few minutes my impressions were that it was a better application that anything that we had. You might find that in OS X they are doing something you have never seen in Windows or Linux.

2 comments:
will your patch for kwin will go in kde4 ?
having windows grouped by application like the Mac does would be so sweet.
You mentioned that applets or setting gizmos should be turned into web applications/applets.
The one problem with web apps is the interfaces suck. Every last one of them.
Why?
Because web interfaces are based on batch I/O, not interactive I/O. All we've done is taken the protected-region terminals of yesterdecade and fancied up the interface.
That said, I acknowledge that client-side is not going to mysteriously replace web-based interfaces. Sadly.
Post a Comment