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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
