On Mon, Mar 30, 2009 at 9:00 AM, Nathael Pajani <gimp@xxxxxxxxxxx> wrote: > 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" ? The kernel is made up of modules, which are almost entirely independent. With this, the total amount of testing needed is much reduced, because any given module has only a few options and can be tested independently. GIMP, which is an application, has a UI, and all options effect the user's perception of that UI. For the core of the program, a simplification such as is applied to the Linux kernel, is impossible; the core behaviour of the program stands as one whole thing to the user, and we test it as one whole thing. This kernel comparison just does not work. Please stop using it. > 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. Gnome also is structured in many individually testable components, like the kernel, and unlike GIMP. I (and, I think, some of the core GIMP developers) would like GIMP to be structured like Linux or Gnome -- this has great advantages -- but it definitely is not where GIMP is at currently. >>> > 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. I don't know what to say to such a viewpoint. Of course you need to adjust your plans as you get feedback from actually implementing them -- this is what led to the current form of the free-select tool -- but the whole idea of an application is to provide capabilities to the user .. the interface should not be dependent in any way on how the feature is actually implemented, just that the way it's implemented should be reasonably straightforward and plain. The UI actually is the main part of an Image manipulation program; at least, it's the main part of GIMP. I can quote Sven as saying that the majority of code in GIMP deals with UI, and my own investigation of GIMP code confirms this. Dealing with users is a far more complex undertaking than almost any backend task you can think of. > > >> 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. Who do you think compiled that list? AFAIK, it's Peter Sikking, the same guy who has researched on and written a lot (all?) of the specs on gui.gimp.org >>> 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. We may be talking about different things here; things like docking dialogs is not a customization problem -- it's not a special switch like some things in GIMP preferences are, just a structural arrangement for the components already provided; it can be dealt with in a single place in the code, unlike a global option. > People like things to be customizable. You will not be able to prove the > contrary. What people like, and what actually works well for them, are two different things. This is a common problem in UI, especially in open source software -- people want things that effectively reduce their ability to use the program well. It's just like, I find some smokers inexplicably attractive, but it would be foolish of me to try to 'hook up' with such a person, as I'm very careful about my health. People want irrational things sometimes, and we should not accommodate their poor habits of thinking and acting in these cases. So we do not provide such customizations; we only provide customization within what we have worked out to be feasible limits. >>> 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 ? You said it would be a good improvement, implying that there is something to improve. If nothing is stopping this, how can it be an improvement? I do not understand that. > > >>> 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. It's not a very new thing. I always compile the latest development version myself, and have been using this feature for many months now. In particular, some keyboard-shortcuts could only be used in the toolbox. This is no longer the case, so keyboard shortcuts behave more consistently now. This used to bother me quite a lot, where I would hit a key, and because the toolbox had focus rather than the image window, the keyboard shortcut would not be recognized. > >> 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 Again, that is not a menubar; it's a place to drop images. > > See previous "definition", what I call tool menus seems to be the "other > things that can dock to it" I don't understand what you mean here at all, sorry. > > >>> * 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 ? It gives a message in the statusbar 'return commits, escape cancels, backspace removes last segment' When you have drawn >= 2 points in a polygon or a >= 2 freehand segments. > 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. Maybe this is only in development versions (2.7) so far. But it is there. It also matches with the behaviour of rectangle and ellipse tool (ENTER confirms the selection) >> 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. Escape is already used, as noted above. > And shortcuts are already customizable. I hope you do not plan to remove > this feature !!!! I have no idea what you're talking about. The keys that a tool depends on internally are hard-coded, and have never been effected by the configurable shortcuts. >>> 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. I can only suggest you review the UI spec for this change. Also, if you are taking screenshots much of the time, it might be sensible to either assign a keyboard shortcut to it, or use a separate screenshot taking program. > > >>> 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. Well, this is not applicable here. Even-numbered major releases (2.0, 2.2, 2.4, 2.6, 2.8, 3.0) are stable series, meaning after the first release in the series is made, only bugfixes are added. For example, 2.6.1 is the first set of bug-fixes in release series 2.6. We can only do significant redesign in the development versions (2.1.x, 2.3.x, 2.5.x, 2.7.x, 2.9.x). > 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 agree, but I don't think it's applicable to GIMP. You can only afford to act based on such an idea, if you have many active developers or a very small code-base; GIMP has neither, so we must work at things piece by piece. > > >> 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 !!! There's lots of ways to contribute to the community; for example an artist who shows off their artworks with a note 'made with GIMP' and a link to the GIMP website, is contributing to the GIMP community, helping to get new people into the world of GIMP. Or someone who writes an article, 'I like GIMP because..', or someone who writes a tutorial for doing some particular thing in GIMP. However it's a sure thing, if you have not the patience to spend some time doing things in the community, then you will not contribute anything significant to it, and in fact, you will not BE anything significant to it; Hence, we should not assign importance to transient users. If we are attracting users who are then later repelled from GIMP by the behaviour of the same version they first used, then *that* is a serious problem; and we are addressing such problems through the UI redesign. David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
