Thursday, November 26, 2009

general audience vs advanced audience

Reading Cyrille's blog entry today about Krita and GIMP appropriateness (or rather, how they are not appropriate) for a default OS installation, it got me to thinking about a common pattern we see emerge in applications.

We often end up with general audience apps that represent a good entry level position. They aren't wimps, but they certainly remain lean and the UI stays focused on what they are doing in a way that's approprirate for a general audience. They may make most people happy, particularly because the interface is nice and clean while offering the "things I want most", but they usually leave a more demanding user wanting, particularly people who are professionals in the field in question.

The professionals and enthusiasts will be looking for richer tools that Do More(tm) and often support more sophisticated models. These tools could be viewed as "upgrades" from the general audience applications except that for many people in the general audience these pro tools are vast overkill and even off putting.

The pro tools can't really be streamlined beyond a certain point without losing their audience, and the general audience tools can't be beefed up constantly without leaving behind their audience. Perhaps there is even a symbiotic relationship at play here, at least within the KDE world: the pro tools push the envelope of what's possible in ways that the general audience tools can add selections of features that straddle the general/pro audience but which are complicated to do and so more likely to show up in a pro tool in the first place; the general audience tools take the pressure off the pro tools from having to cater to too broad an audience, and the pro tools take the pressure off the general audience tools from the demands of demanding users.

(As an aside, for all the claims that one can simply have a UI adapt to the user's level of capability has never really been shown to be a real solution. I've seen it fail before, and where it has succeeded it's been for apps that themselves straddle between "general" and "advanced" in audience. Usually it just leaves a mess, and even more usually the suggestion that this is the solution comes from people who have never tried it. Aaaaanyways ..... ;)

The example of Gwenview, Digikam and Krita is a great one, I think.

With Gwenview, you get basic photo downloading from cameras and image manipulation. These "high end" (for Gwenview) features mostly comes from work laid down by the people working on the higher end photo management tools like (though not exclusively) Digikam. Sometimes feature improvements flow from the general audience app into the advanced tool app as well, but in my experience such improvements tend to be of the general audience pleasing type (as one might expect).

Meanwhile, Digikam can concentrate on being a great power tool for photographers, amateur and professional alike and Krita can concentrate on being a great power tool for artists, amateur and professional alike.

The result is a great set of apps for different audiences which help each other improve as they individually advance to better serving their specific target audience. What duplication of effort does exist is offset ten-fold by the resulting benefits for the users of each app in having something targeted to their needs. In KDE, that duplication is often very minimal.

There are other examples of this in KDE as well and they often follow very similar patterns. We have JuK and Amarok; KWrite, Kate and KDevelop; Dolphin and Konqueror ... can you think of some more?

Also, is there a pattern here that we can use when presenting our application clusters to the public?

20 comments:

Spockfish said...

I agree with your story.

But can I do a suggestion which covers the same issue?

We've got now the great Dolphin as file manager, so please make Rekonq the default web browser. It has a very simple (Chrome-alike) interface. For the geek user there's still Konqueror, but the default should be 'non-geek' IMHO.

Regards Harry

ahiemstra said...

I was just thinking after reading your and Cyrille's blogs that it might be nice to actually be able to show this relationship somewhere. So you have Gwenview, digiKam and Krita, but how is a user looking for some more advanced features going to find digiKam or Krita easily, coming from Gwenview?

It would to have that information available somewhere, like on userbase or so. Something like listing the "Related Applications" on the application page with a few words describing its distinguishing features.

So you would have the Gwenview page that has a section with content like: "Looking for something else? These applications might interest you:
* digiKam: An advanced photo manager that allows you to easily manage your photos.
* Krita: A complete photo and picture editing suite with many advanced features.

Having this information available in the actual application might be even better, but that would probably be more work and harder to accomplish. Also, not all developers might be pleased having "Ads" for other apps in their app.

randomguy3 said...

You could argue that KWrite and Kate are essentially different UIs for the same core.

What seems to work well is having a shared set of components, and building up applications that use different subsets of those components put together in different ways.

Wickersheimer Jeremy said...

This means the developers have a lot to gain by cooperating between those projects.

The general feature set could simply be shared as much as possible, i think the kipi-plugins is a good example.

Perhaps there could be a way for an application to point to another which provides similar features (more advanced / more simple).

Although, this seems to be an issue for the distributions and the way they manage packages.
It would be nice if the package manager could suggest applications which offer similar features and indicate their target audience.
Heck, they could even implement a search by feature.

Mark said...

@Spockfish: Agreed about the Rekonq thing.

But please, use some sanity with application name choosing. Rekonq is a horrible name, it only makes sense (if any) to users who already know Konqueror, which are not so many these days.

Especially if you want to cater to the non-geek crowd (like you do), a good name is all the more important.

--
Mark Kretschmann

Spockfish said...

@mark:

Your're completely right. I like Rekonq on how it works, but I don't like the name. Ultimately I would love to see it named just Konqueror (or KDE Conqueror).

But I don't see that happen anytime soon due to the highly sensitive issues surrounding konqueror/webkit/khtml/rekonq...

maninalift said...

I agree with @ahiemstra that it would be good to have greater discoverability and clarity about the role of applications.

It would be good if this could be achieved in the desktop but I guess that is the role of the package manager ... any ideas?

The thing about digiKam vs gwenview, is that while I a agree that digiKam is probably a little heavy for default install, many users have large libraries of photos and would benefit from discovering it.

B. Malengier said...

Ok, a suggestion to make users discover the pro tools:

* In the menu categories, add an icon indicating 'extra'

* When clicked, give an overview of software that is not installed and usefull in this category.

* When clicked on one of these, open the package manager on the package where you now see the description and a screenshot, so the user can install it if wanted

Aekold said...

Great post! It's the most politically correct post of that topic I can imagine.

BTW, I can suggest Krusader as advanced file manager, but Konqueror as main file manager and Dolphin as just failed experiment with KDE4 API. My wife is using Konqueror because it handles all operations in the same window with same manner, she can see the photo without starting gwenview, watch video without Kaffeine, edit text files in the same tab, just using Konqueror. She does not need to know what application to start for some purposes, KIO did it for her.

Aekold said...

And one more thing - what is so different about rekonq? Looking at screenshots I can't see any differences, it doesn't look like Chrome and is not that different, but Konqueror and it's engine is supported by KDE team, and it's big advantage.

megabigbug said...

@aseigo

"Also, is there a pattern here that we can use when presenting our application clusters to the public?"

I propose this pattern (with Rekonq as example).

In the menu, Rekonq is presented (with an other name :) ) as the default webbrowser.
The first time the user quits Rekonq, a notification is displayed and proposes Konqueror.
The user can click on the proposition.
When the user quits Konqueror, a popup asks if the user prefers Konqueror. If the user prefers Konqueror, it became the default webbrowser and the menu is changed.

AnneW said...

@ahiemstra: With a little updating of relevant Applications pages on userbase, it could be made clear which level of user each application is addressing (maybe not addressed as user, but as something that infers use-case). Then it would be a simple matter for the applications Help options to point to that Applications page.

Spockfish said...

@Aekold:

Just try it. The fact that is has no cluttered menu with all kind of 'geeky' stuff that the average user does not need is just.... refreshing. And with the comparison with Chrome I did not mention it's colors, but the basic layout. And in that case Rekonq is like Chrome.

Add the advanced 'a tab is a thread' and you've got a great browser.

The engine (webkit) has IMHO way more support out there than KHTML.

But I can only advise you to try it. You will be surprised by it's maturity allready (although it is just 0.3).

Aekold said...

@Spockfish:

Ok, I'll try it, but still chrome is mostly redesigned user interface, where you have maximum available space for the "workspace" an minor space for toolbars and stuff, and I can't see the same with rekonq.

About engine, I have no problems with Konqueror, so main feature for me - platform integration, native look and native feel. That's why I am not using Firefox or even Arora, they're alien in the KDE. When KDE guys will say that WebKit integration with KDE is perfect - it will be the day I'll think about WebKit-based browser as my main browser.

Spockfish said...

@Aekold:

"When KDE guys will say that WebKit integration with KDE is perfect - it will be the day I'll think about WebKit-based browser as my main browser."

That's just wat Rekonq is all about!

Sinok said...

To me Reconk is nowhere from ready to be the default browser, at least the version from the Opensuse factory, that is normally quite fresh.
It is, at the moment, inconsistent in terms of UI with the KDE HIG (no menu, the Toolbar is not an actual toolbar ...), it lacks some usual browser shortcuts as F6 to edit the content of the address bar, Ctrl+L to reload the content of the page and surely a whole lot of others lacks.

Seriouly guys, are you out of your minds? What's the point in introducing a beta software as the main browser? Wait at least it is considered as stable an ful fledged in terms of features. God damn novelty freaks :D.

Diego Viola said...

Merge Rekonq best features into Konqueror.

alien said...

rekonq IMHO just started (with 0.3) as a usable browser. The only problem I have with konqueror is gmail (chough please do not kill me cough).
PS: I am using rekonq right now.

I am guessing with KDE 4.5 or 4.6, rekonq can be the default "simple get me to the web" browser and konqueror can be the advanced "take me to your master" browser.

@someone who mentioned ad's for every application

Package managers, if done right, should do that for a user, not the desktop applications, again IM_H_O.
But one thing I can take from that, when I look for "photo" in kpackagekit, I should be given the options with the information about what I am getting. A screenshot will be great.

But again, I am no usibility judge. I will get used to whatever is thrown at me! :-) Unless one day I learn how to program with Qt.

Dr Jan said...

This is a very interesting post because I wasn't aware of the 'family' groupings.

I think the key is communicating the groupings to a wider audience. ahiemstra has some good ideas on how to achieve this.

Diego Viola said...

Having two browsers is a stupid idea IMO.

Just merge Rekonq best features into Konqueror.