Skip navigation.
KDE Developer's Journals

cwoelz's blog

cwoelz's picture

KOrganizer incident dialogs

While documenting KOrganizer incident dialogs, I was bugged about some small details. In the spirit of doing something about it instead of complaining, created some mockups to express these ideas.

I noticed that you can't select the resource to save the event in the dialog. It seems an important feature to me. Also, the incident description is buried in the end of the dialog. It is hard to know it is even the place to write the description, as there is no label. Here is the original image (correction: this is not the original image, this is a previous mockup. The original image does not have a "Description:" label above the details edit box):

[image:1155]

I moved the description up, and added the resource drop-down at the bottom. Nothing too fancy. The result is here:

[image:1156]

I know that from a task-oriented perspective, adding a description is probably a less common task than setting the time, so the time may deserve to be above the description. But then again, the user can (and should, because it is easier) create the event directly on the calendar main view, so the time is already set. And having where to set the calendar / resource to save the incident avoids displaying that pop up for every incident you save (when you have more than one resource available.

Now to the Attendees tab: the Address Book should be the main source of address right? But here on this dialog, where can you find access to the Address Book? There, at the bottom, hidden under the name "Select Adressees...".

[image:1157]

Since adding by hand one by one of the attendees does not seems to be the most practical way to fill the list, here is a mockup with the address book button renamed and moved up:

[image:1158]

That's all for the moment, but there is more to come.

cwoelz's picture

A little update

I haven't blogged for a while...

I had the pleasure of having Andras Mantia with me here in Brazil. I showed Rio de Janeiro to him, and Buzios, a very nice beach place, before he went to a free software conference in Porto Alegre. I bugged him about making Quanta better for DocBook editing, and he fixed some entity quirks, but other than that, it was leisure time.

I have been working a bit on KOrganizer "quality" recently. The "general status" of the app is not bad at all: the docs are outdated, but not terribly so, the whatsthis is almost complete, (also thanks to the work of Antonio Salazar, the Kontact docs maintainer), there is work in the usability front by the openusability guys. What is really missing is more documentation about using the different resources, as there is currently none. KOrganizer is a very capable application, but I am not sure people know how to use its power, or how to configure the resources.

While working on that, I noticed that it is hard to configure Kontact for groupware use by hand, (without the use of the wizard), as groupware config options are spread betwen KOrg main configuration, (KOrg and KAddressBook) groupware resource configuration, KMail main configuration, and KAddressBook main configuration: five places to touch! To make it worse, there is not a lot of info on the web on how to configure all this stuff. The solution is trust wizards or create a centralized place for Kontact groupware configuration.

cwoelz's picture

Are Modules Tasks Pages a good idea?

With the help of other pim developers, I updated the kdepim tasks page. The kdepim tasks page was a very useful tool during the last release cycle, and is already helping the kdepim quality team and eventual newcomers to quickly see what needs to be done.

Yes, we have a strong kdepim quality team, I am glad to say it. There are several people working on different areas of the pim applications, including the docs, websites, etc... who work silently, and are not explicitely involved with the quality team. However, at leat two guys, (me and Antonio Salazar), are already jumping in when needed. Antonio worked on Kontact docs during the last release cycle, and is working with KOrganizer whatsthis and hopefully with the docs too, and I wrote KPilot docs and whats this back then, and will do whatever is needed for this cycle (I did not decide yet). Some others started helping out in the last release cycle and submitted smaller contributions, and I hope to hear from them again (Hi Ramon and Jörg, how are you doing?). This effort started with the quality team annoncement six months ago.

Unfortunately, it seems that other modules did not have the same results as we did. My email to the quality list about the announcement for this release cycle got no response. I offered help: "If you want to create or update your page to the next release cycle, I can help! Just drop me a line.". Nobody asked (yet).

So if you think the tasks pages are a good idea, and you want to participate in the new release tasks annoncement, please drop me a line, or if you don't, I will go with with kdepim only.

cwoelz's picture

Hello, and what to expect from the Quality Team

Hello you all. I got into KDE development for fun, and I hope to have a nice journey while here. I have some nice ideas about why what we do is important, and I was already a financial contributor to Quanta before starting to help directly. You probably know me (or not) for my Quality Team work.




I found quite hard to discover something interesting to do inside KDE, and to learn my way in the free software jungle, as I am not a programmer and had very little contact with open source before. The process took two years, from a newbie user to an active contributor. (I have a very demanding job, that has nothing to do with software). KDE is my hobby and I love it!


But now to the main question: what to expect from the Quality Team?




The Quality Team has two main objectives

  1. Support new contributors, programmers or not, helping them to
    integrate to the normal KDE development process
  2. Serve as a forum for recruitment, coordination and discussion of
    development tasks

As part of (1), we recommend focus to new guys: one app or module
at a time, one new devel list at a time, try to leverage what you
learned (for instance, use the knowledge learned from the docs to write
whatsthis or vice versa, to do a ui review, write an article telling the
word why your app is a killer app etc. ) I try to act this way.



But a lot of people seems to miss what the objectives are, and
therefore, are disappointed with the results. I am not. As a matter of
fact, I am very happy. But don't trust my words, let's examine together
what was done in the last six months to fullfil these objectives.

(Click the blog entry to read more)

Syndicate content