David Gowers a écrit : > Hello Nathael, Hi ! Nice to have a constructive answer from time to time :) > Removing customizability is best. I'm not kidding. Customizability is > what happens when you can't figure out how to make the program behave > sensibly in 99% of situations. Every point of customization is also a > point of potential confusion, for both the coder and the user. Hum, I think there is a misunderstanding here. So I'll use an example. First, what I call a tool menu is this: http://www.nathael.org/Data/tool_menu.jpg These are dockable. And we can create as many windows as we want, with groups of these tabbed inside. This is customization. The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable as well. You cannot think of creating one interface that will fit 99% of the current and future users, or you plan not to count current users that will have to switch to another program, or to create a fork (even their own one). And there is NO possible confusion, neither for the user, nor for the coder in this. > Difficulty of maintenance as hard-coded options go up is a fact, it's > not at all insulting. In order to achieve very reliable code, software > must be tested with every combination of options available. This means > to achieve moderate reliability, software must be tested with 50% or > more of the combinations of options available... > > To show some perspective on this, you can regard each togglable option > in the GIMP preferences as a bit in a binary number. In SVN head, this > binary number is 43 bits long [...] means that there are > 8,796,093,022,208 combinations of options to test already. > [....] I cannot agree with you here. Once again, I'll use the kernel as an example here: I won't bother counting the number of options and the possibilities resulting, I'll just state that it's the > biggest piece of code I have ever seen, and still the most reliable. Are kernel programmers "superhero" ? "genius" ? Tell me, I'm one of them, I'll appreciate :) Another example I'll use as some spoke about it previously: Gnome. I'll not bother counting the options you can find in gconf either. Still, gnome is stable (from my point of view at least, but most will agree) and even if it's not a perfect display manager, I think it's a very good one that manages to perform it's task. And the Gnome example is most accurate, don't try saying the contrary this time: it uses GTK, and it's also a GNU project. So with these two example at hand I cannot agree at all. >> > Sorry, but the GIMP user interface sucks and that urgently needs to >> > change. >> Has there been a survey about this ? > Alexandre addressed this, but also : 95% of software UIs suck quite > badly. This is because most often they are simply written as an > afterthought to the backend: 'oh, we need to make this FOO capacity > available to the user. What's the easiest way to do that?' rather than > designing the frontend first and designing the backend so it fits well > with the frontend. This leads to incoherent UI -- and customization of > dubious value. Right and wrong. Right, the UI must not come as an afterthought. But the UI is not the main part of an Image manipulation program, it's here to give access to it's capabilities. So designing the UI first is just silly. Both have to be thought in parallel. But this is very hard for a project like Gimp, when programmers are more interested in the backend part and when this part is made up of small parts added one by one with no global initial view. But this is free software, and those not happy with this should rather go programming commercial software ... and discover that the grand discours about planning the design is just that. > The recent changes, OTOH, were based on real UI work with users to > discover what things users most often had trouble with. I just hope you did not ask users that would like to have a photoshop clone for free. That's why I pasted the points from GimpCon 2006. Users tend to want what they have with the commercial software. Gimp is not that. >> And do not tell me (or others) it is not good because other programs have too >> much customization possibilities. > It is not good, precisely because they have too much customization > possibilities. > We need a meaningful minimum of customization, the absolute least > customization for the greatest potential effect; that is the ideal > customization situation for any software. I still do not see why more possible customization hurts. When the UI is well thought, then customization goes easy. >> > And we are going to make some much more drastic changes in the future. >> Please remember that user are working with The Gimp. Changing the user interface >> drastically because you do not feel like keeping the old one will discourage > Feelings have nothing to do with this. Reasoned, rational, open review does. > Anyway, changes discourage and encourage people all the time, but > changes should be made due to their actual merit, not their secondary > effects. Right, I can only agree here. But then I do not see the merit behind having an empty window when you start gimp, with most menu being empty. >> So, one point I already brought to the discussion, here and on IRC: the >> possibility for the user to customize the interface, or in other words, "Not ONE >> interface for everybody". >> When I said this on IRC (that the interface should be customizable, as it is for >> so many free softwares, mind, window managers for example) I was told that this >> is an ineptitude, because the most used user interface (M$ OS's one) is not >> configurable. > I would be interested to read the appropriate section of the IRC log, > if you have it. 11 or 12 of March, in the evening, on #gimp on irc.freenode.net Someone may have the logs. I was drizzt. > Personally, I think Apple is a better example. They don't actually > have *stellar* UI, but they do have good UI, because they really work > at it. We can see, through their UI designs, that carefully considered > simplicity is something that works quite well. Very good example: OSX dock is customizable, you can change the icons in it !!! imagine a dock in wich you cannot change the icons displayed ... As any display/window manager, you can also change your desktop background. One more customization. People like things to be customizable. You will not be able to prove the contrary. >> Then, another point: using configurations, as it is done for window managers, >> which users can share. I think this would be a good improvement. >> Thus, you can make things move as much as you want, as long as the user can come >> back to a configuration he nows and can use. > > What exactly is stopping users from sharing their gimprc, templaterc, > or whatever now? Nothing, so why not use it more intensively ? >> Now, the points I criticized about the changes I noticed, and possible solutions: >> >> * The main menu (files, image, layer, ...) is no more in the toolbox (at the top). >> I do not understand, as there is still the place reserved, (so this is screen >> place lost) and it is in every image window. >> Then, when I want to open a new window, or acquire a screenshot, or scan... I >> have to use the menu of a current image ! This is silly ! > Perhaps, but it was decided that it was less silly than having 2 > separate top-level menus, and I have to agree -- having 1 top-level > menu is vastly less confusing and has saved me a lot of time. ??? This is a new thing, I do not understand when or what it saved for you then. > And of course, if you don't like that menubar taking up space, you can > disable it It's it not being here but still taking up the space that is strange: http://www.nathael.org/Data/unused_menu_space.jpg >> One suggestion (not from me but which pleases me): have the main menu dockable, >> as are the tools menus. > I don't understand this suggestion at all. The tools menu? do you mean > the dialog where you can toggle which tools are available or reorder > them, or the toolbox itself (which is not dockable per se -- other > things can dock to it, but it cannot dock to other things) See previous "definition", what I call tool menus seems to be the "other things that can dock to it" >> * About the lasso tool : > [....] > With adept use of the new tool, the only common usage of the old tool > you lose out on is single-stroke selections -- it is possible to make > them, but harder; more often I end up pressing ENTER to close the > shape, so the difference OLD versus NEW is 'click-drag' versus > 'click-drag, ENTER'. Ho, very nice UI improvement ! How are we supposed to discover this ? Nice to know anyhow. I don't mind having to press enter to finish, but I cannot discover it. If you plan for good UI, then a small tooltip saying "press enter to close the selection" (of course with a setting to enable/disable tooltips, or it would not be fun) would be a UI improvement. > I do think we would benefit from an option to automatically close the > shape; I don't like pressing Enter. Yep, I agree here, but you were the one telling there are too many options :) BUt this would be a nice option for the lasso tool :) > And, I think we could provide the 'select nothing' facility > reasonably, if the user just clicks once and then hits Enter -- this > is IMO a fairly clear indicator to select nothing. Wouldn't "Escape" be a good choice? but then, it's only a replacement of the Ctrl+Shift+A shortcut. And shortcuts are already customizable. I hope you do not plan to remove this feature !!!! >> * acquisition menu moved (and renamed in the french version at least) > [....] > For their convenience too! Lost time in the short term is just a fact, > it occurs with all changes. For definite improvements, that lost time > is the price for the later gained time from the UI improvements once > you learn them well. Right, but I do not see the improvement >> And then, on the same point, you create a new menu entry called "create" but the >> "New image" is still outside of it ! > This is a compromise due to how frequently the user will use 'New Image' I use it less than 10% of the times I use gimp... and I must not be the only one. But I use screenshots and scanning very often on the other hand. >> This can be between 2 minor versions, but when you say you are redesigning the >> user interface, don't do it across major releases. > > This makes no sense to me again -- I'm not trying to insult you, I > just look at it and think 'what does that mean?' > > After all, redesigning UI is a big, noticable thing. Making such a > change between eg. 2.6.6 and 2.6.7 would be very rude and would > contradict expectations. We have always had major changes between > stable release series -- 2.2 was notably different from 2.0, as was > 2.4 from 2.2, 2.6 from 2.4, and as 2.8 will be from 2.6. Big changes. > Why (and how!?!) should we, could we, break this trend? From my experience, when you are redesigning something, it can be done accross minor releases (2.6.6 to 2.6.7 and then more parts for 2.6.8, and some more again for 2.6.9 and so on. But not some parts for 2.6, some for 2.8, and some last bits for 2.10 Releasing is not a requirement (or so I think). If there is job to be done, you do it before releasing a major release so that ALL the changes are done for the major release. When all of you are saying "we are redesigning the UI" but here is only one part, I feel like it is a work in progress. This is completely contradictory to performing major releases. You do not release a work in progress as a major release. Am I the only one with this point of view ? > I suppose it is reasonable to not care too much about those people who > leave the GIMP community because they are put off by the need to adapt > to ultimately beneficial changes -- these people probably do not have > the patience to do anything significant in the community anyway. Reduced to those having time to do significant things to the community it will be very small !!! And then, didn't it occur to you that those developing for other projects have no time for the Gimp project ? But mind, you are using their tools (the Linux kernel for example, or gcc, or any other one) How would you feel if they started saying "we don't care about those not contributing. Will you contribute to all the projects you are using? Have fun And thanks once again for reading down to here. Nathael Pajani, alias drizzt. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
