Breadcrumbs in Kickoff

[Martin Gräßlin]

On Wednesday 21 December 2011 00:51:45 Alexey Chernov wrote:
> On 20 дек 2011 11:20:23 Aaron J. Seigo wrote:
> > On Tuesday, December 20, 2011 00:33:20 4ernov wrote:
> > > unclear why you so against to approve such a work.
> > 
> > i think it is perfectly fine if you wish to create a modified kickoff and
> > ship it as a separate plasmoid. this is what we've done for a few
> > different
> > plasmoids, including the tasks plasmoid (and that's ended up turning out
> > rather well for everyone i think :).
> 
> No, I mean a contribution with config option or something which can return
> the Back button. I don't think it's perfect idea to fork kickoff because of
> one function.
but that's the point. Now in a month someone else wants something completely 
different. Then it's still not the perfect idea to fork Kickoff because of one 
function. A month later the next config option creeps in and another one and 
another one. And a nice small applet becaume a Frankenstein.

Either you decide that no non-valid config options go in or you have 
discussions about it each other day.
> 
> > i do not want plasma desktop to become a collection of everyone's pet
> > features with a thousand configuration tweaks.
> 
> Exactly. I agree. But as I remember Martin said that we're discussing only
> config option and reverting to Back button wasn't an option. I think, nobody
> also wants Plasma desktop to become a collection of wrong decisions, it's
> even worse.
Yes, I said we can discuss the need of a config option. For that we require 
good arguments why such an option is required. That has not yet presented 
here. Neither we can do it, nor but it was there is a good argument.
> 
> > the back button was not
> > serving everyone well (we got lots of feedback on it ...)
> 
> I didn't say the Back button was ideal. I think a serious usability research
> should be performed to find the better solution instead of it. And I can't
> believe any usability expert could suggest breadcrumbs instead of back
> button as it's just against the basic things one could learn in usability.
So you are a usability expert? I didn't know that. I am no usability expert, 
because of that I do not argue with usability. (Just look through my mails you 
will nowhere find that I say the breadcrumbs are better and the back button is 
worse from a usability point of view). If you have not studied usability, I 
would appreciate that you don't pull such arguments. It a serious field of 
research and we should not do like we know better.
> As to me, my solution is: keep both Back button and breadcrumbs. Here's my
> arguments:
> - no config and no tweaks required
> - users can use both ways
> - no redundancy or duplication as it's just two methods to reach the same
> result (there're thousands of examples with such implementations, e.g. same
> features in main menu, toolbar and context menus in one application)
I'm sorry but all your examples are bad ones. Let's consider them:
* main menu is normally dropped. Finding an option there is a complicated 
task. See for example Unity which basically removed the menu completely.
* context menu you have to explicitly trigger, you have to know that the 
functionality is there.

With Kickoff we are talking about two always visible and directly reachable UI 
elements. This is something completely different. We also have to consider how 
close these UI elements are. Given the new QML design they would border each 
other. That is one of my main concerns that it visually clutters the view, 
makes them inconsistent (only one of four views uses the back button) and 
confusing. I don't see why the average user would need this always there. To 
me this looks like you realized that you don't get your config option and now 
you try to adjust your argument ;-)
> - minimum of code required
this is just not true. This would significantly increase the code size. See my 
other mail on that subject. As I wrote I expect an increase of code size for 
one QML file by at least 10 %.
> 
> I don't mean that it's a bad code or something and I respect all the efforts
> of Martin and whole Plasma team to improve navigation, to find some better
> decisions. But I think such a things should be discussed especially given a
> significant number of critical comments. If something was wrong I don't see
> any problems to solve it.
Which significant number of critical comments? How many users have commented 
here in the thread and reported bugs? 5? 10? 20? We are talking about a 
feature which will be used by millions of users. If we get to a thousand users 
complaining we can start to think about significant numbers.

A small anectode: we had a recent event in the state where I live. In our 
state capital the German government and the Deutsche Bahn want to build a new 
station. It will take many years to build it and will cost several billions €. 
Over the last year there were many demonstrations in the captial with 
thousands of people protesting against the station. Since the last election 
the state is governed by a prime minister of the one big party opposing the 
new station. It really looks live the people is against the station. All the 
protests, nobody in favor of the station.

Last month the people were allowed to decide in the first direct vote since 
the founding of the state whether the train station should be build or not. 
Well it turns out that the majority against the train station is the minority. 
Even in the capital more people voted for building the station than for 
stopping it.

What I want to tell with that: just that it feels that there is a lot of 
protest, does not mean that you are the majority or that your opinion is so 
important. And that's especially true for open source. You have always very 
vocal users who are very demanding. But whether they represent the majority of 
users cannot be said. Here in this case I doubt it given the number of users 
in the bug report.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20111221/f0d387b1/attachment-0001.sig>