I would expect from a program with the label 'JRs finest selection' that it has gone though a user-centered development. That means
* it has a vision that enable the users to put it into a certain category,
* was implemented with a clear concept according the HIG,
* looks like VDG defined the KDE style/branding,
* and provides sufficient options for individual configuration (the more the better).
Features are secondary and (apparent) simplicity is rather the opposite what KDE users want, IMHO. User-centered development implies an iterative validation of users' requirements and verification of the implementation.

Heiko Tietze wrote:[...]
* and provides sufficient options for individual configuration (the more the better).
Features are secondary and (apparent) simplicity is rather the opposite what KDE users want, IMHO. User-centered development implies an iterative validation of users' requirements and verification of the implementation.

Allow me to play the devils advocate here:
I love the idea of user-centered design but it requires at leas two things:
* we need to know who our users are
* we need to be able to ask them

Survey advertised on planet / the forums will only catch the super engaged users but they might only be a loud minority.
Are we even sure that our users requirements are homogeneous?
Take our 30k users in the public administration of Munich. We will not reach them with a public survey and their requirements likely differ from our powerusers.

Don't get me wrong. We should do user-centered design. I just don't think that public surveys are (the only) way to go.

mbohlender wrote:

Heiko Tietze wrote:[...]
* and provides sufficient options for individual configuration (the more the better).
Features are secondary and (apparent) simplicity is rather the opposite what KDE users want, IMHO. User-centered development implies an iterative validation of users' requirements and verification of the implementation.

Allow me to play the devils advocate here:
I love the idea of user-centered design but it requires at leas two things:
* we need to know who our users are
* we need to be able to ask them

Survey advertised on planet / the forums will only catch the super engaged users but they might only be a loud minority.
Are we even sure that our users requirements are homogeneous?
Take our 30k users in the public administration of Munich. We will not reach them with a public survey and their requirements likely differ from our powerusers.

Don't get me wrong. We should do user-centered design. I just don't think that public surveys are (the only) way to go.

Actually it would be impossible to do iterative validation and verification with surveys I think. I don't think we can target the whole user base at once. Instead, we could pick a number of user scenarios and target them. Like Joe the average user who wants to do this and that, Linda the programmer who has different needs, Aaron the artist who has again different requirements etc... People have been doing that and I think it's a valid approach.

Colomar,

You could have the name of the current pane (the word 'Folders' on the first pane) as a nicely styled drop-down, then the user could switch straight to any pane they wanted and could quite easily see what panes are available (but they'd need to click the drop-down first which isn't great).

If you had an email client bringing together emails from 5 different accounts with tabs to switch between the different accounts, you might have 6 tabs in total - 1 'global' one and then 5 more, one for each account. Like you say, if you had tabs with the text of the email addresses on each tab then it would get cluttered but if you replaced all of the tag labels with icons then you'd need to come up with a meaningful icon to represent each account which might be an issue (and you'd need to have tool-tips popping up all over the place).

If you had the email client with the panes like they are in my mockup (and you could switch between them with a drop-down arrangement), it would have the advantages of:

* You wouldn't have to come up with meaningful icons for each account, then try and remember which icon is which, just show the drop-down to see a full list of panes.

* There wouldn't be any tool-tips that you'd need to wait to pop up, that would make the navigation slow if you couldn't remember which is which.

*The whole thing is scalable - the user could add as many panes for each of their email accounts as they liked and it would never look cluttered (or bare if someone only had one email address) so it'll be easy for us to design something that stays looking good no matter how many (or how few) panes the user chooses to have - whether that's adding lots of email accounts in the email program or multiple panes to navigate & filter your image collection in different ways in an image viewer.

*Each application could have plugins to add functionality by adding more panes that would be hidden until they were needed, extending the applications functionality, but again not affecting the nice UI that we design.

mbohlender wrote:We should do user-centered design. I just don't think that public surveys are (the only) way to go.

Tuukka wrote:Instead, we could pick a number of user scenarios and target them.

Valid point and acceptable solution. Expert methods like the cognitive walkthrough are an option. But that doesn't mean to stop dreaming about a user relationship management.

I would add another important aspect to my list:
* comprehensive documentation for users

Heiko Tietze wrote:I would expect from a program with the label 'JRs finest selection' that it has gone though a user-centered development. That means
* it has a vision that enable the users to put it into a certain category,
* was implemented with a clear concept according the HIG,
* looks like VDG defined the KDE style/branding,

Absolutely!

* and provides sufficient options for individual configuration (the more the better).

Sufficient, yes, "the more the better", no. The "the more, the better" approach is what brought us the often intimidating UIs we have today. The maximum of anything isn't always the optimum.

Features are secondary and (apparent) simplicity is rather the opposite what KDE users want, IMHO. User-centered development implies an iterative validation of users' requirements and verification of the implementation.

If you look at reactions around the net to my "Simply by default, powerful when needed" blog post, you'll see that while people who commented there (which are most likely not representative of "KDE users"!) were not all "Give me all the features and options that are possible!". Of course they feared we might "dumb our software down", but those who understood the "powerful when needed" part of the tagline really did appreciate the "simple by default" part.
They do not want an overwhelming UI, either. They do appreciate a simple default UI. They just want access to "power features" when they need them, and we intend to give them that.

colomar wrote:

* and provides sufficient options for individual configuration (the more the better).

Sufficient, yes, "the more the better", no. The "the more, the better" approach is what brought us the often intimidating UIs we have today. The maximum of anything isn't always the optimum.

Features are secondary and (apparent) simplicity is rather the opposite what KDE users want, IMHO. User-centered development implies an iterative validation of users' requirements and verification of the implementation.

If you look at reactions around the net to my "Simply by default, powerful when needed" blog post, you'll see that while people who commented there (which are most likely not representative of "KDE users"!) were not all "Give me all the features and options that are possible!". Of course they feared we might "dumb our software down", but those who understood the "powerful when needed" part of the tagline really did appreciate the "simple by default" part.
They do not want an overwhelming UI, either. They do appreciate a simple default UI. They just want access to "power features" when they need them, and we intend to give them that.

I tend to agree with Colomar here.

Heiko Tietze wrote:I would add another important aspect to my list:
* comprehensive documentation for users

Not sure whether comprehensive user documentation should be needed for core applications such as file manager or music player. In my opinion, all features should be easily discoverable from the UI. Few users would bother to look at the docs anyway. Perhaps howto-style documentation would be useful for some more special use cases, but generally we should aim for self-explanatory UIs.

Boys and Girls - my beloved Copywriters (yes that means you whomever it is reading this)! I don't wanna rush you but we need to settle on a name for this as I'm itching to write a massive blogpost with all the bells and whistles! So a name?

jensreuterberg wrote:Boys and Girls - my beloved Copywriters (yes that means you whomever it is reading this)! I don't wanna rush you but we need to settle on a name for this as I'm itching to write a massive blogpost with all the bells and whistles! So a name?

I'm not sure about the whole concept sadly Jens, but frankly I'm not even sure of what I'm going to have for dinner, so who am I to say?

One more suggestion: "Elegance by KDE". Aaron Seigo once introduced the concept of elegance in software design, and he didn't refer only to UIs, but we could use it.

Tuukka wrote:One more suggestion: "Elegance by KDE". Aaron Seigo once introduced the concept of elegance in software design, and he didn't refer only to UIs, but we could use it.

"Elegance" was mostly the motto for KDE/Plasma 4, but it should still apply today, so why not?

jensreuterberg wrote:Boys and Girls - my beloved Copywriters (yes that means you whomever it is reading this)! I don't wanna rush you but we need to settle on a name for this as I'm itching to write a massive blogpost with all the bells and whistles! So a name?

Alright. Trying to be completely serious (for once):

I envision a kind of quality brand that we as KDE can put on certain applications to signal that they hold a consistent and high level of quality:

- Efficient and maintained code
- Designed according to the HIG and in cooperation with the VDG
- Well-integrated on Plasma
- User experience is "Simple by Default, Powerful When Needed"
- Inviting and comprehensive documentation (including a website with screenshots, etc.)

I do not think we should call it a "Software Compilation", nor should that name be used, as that will easily bring people's expectations back to KDE SC4. As far as I have understood, we want to break free from that legacy, and we don't want to give people the feeling that these applications are only for Plasma.

I think we should talk about this as a quality brand, and we should be willing to put this on applications created outside of KDE as well - though external applications would still need to follow the HIG, be approved by the VDG, etc.

As such, I suggest:



And someone who's a better artist than me can improve on that!

I really love the "Elegance" idea.

veqz wrote:I envision a kind of quality brand that we as KDE can put on certain applications to signal that they hold a consistent and high level of quality:

- Efficient and maintained code
- Designed according to the HIG and in cooperation with the VDG
- Well-integrated on Plasma
- User experience is "Simple by Default, Powerful When Needed"
- Inviting and comprehensive documentation (including a website with screenshots, etc.)

I do not think we should call it a "Software Compilation", nor should that name be used, as that will easily bring people's expectations back to KDE SC4. As far as I have understood, we want to break free from that legacy, and we don't want to give people the feeling that these applications are only for Plasma.

I think we should talk about this as a quality brand, and we should be willing to put this on applications created outside of KDE as well - though external applications would still need to follow the HIG, be approved by the VDG, etc.

As such, I suggest:



And someone who's a better artist than me can improve on that!

I agree with the suggested criteria.
However, I don't think "inspire of KDE" makes sense grammatically. What exactly do you mean by that? "Inspired by KDE"? Or "Inspiring KDE"? Or... what?

How about "KDE Showcase" apps?

We could stamp that on any apps that we collectively agree meet the simple criteria Heiko and others here suggested:
* It has a clear vision
* It follows the HIG
* It's fulfills the "Simple by default, powerful when needed" experience

If devs are prepared to participate in review then we could include code quality as well, otherwise it might be too much to add that. But whatever the criteria perhaps "KDE Showcase" might provide something for app developers to aspire to while still feeling inclusive.