[Bf-committers] [13276] trunk/blender/source/blender:

[GSR]

Hi,
matt at mke3.net (2008-01-19 at 1206.08 +1100):
> Names are there to identify things in a language that's actually
> useful for blender users to understand. "Approximate AO" gives artists
> a good indication of how it works, that it's more of a rough guess,
> differing to other AO. Calling it "Brecht's cool disk-based-spherical-
> harmonics-AO" gives no indication to artists on what it is, and would
> probably deter people from even trying it since it makes no sense to
> anyone but people who read technical papers.

So Raytraced one should be called something like Slow, should not?

Also stop putting words in my mouth to make things sound absurd. I
said Point Based and Raytrace, 2+1 words, with Bretch's Point Based as
fall back in case the system is a variation. Nothing about "cool" or
long phrases, but trying to pick a distinctive name, avoiding a broad
adjetive or qualifier.

And if an artist lacks curiosity about experimenting, he can look for
another field where he fits better.

> Brecht's done a great job in making his feature accessible and fast
> for people to use with minimal fussing around. All the technical

It is a great tech work. It should be clear when I propose he gets a
reference if he deserves it for creating an improved or derived
version instead of the plain paper one.

> details about the technique are there in the documentation, where they
> belong. People who are interested about how it works behind the scenes
> and want to search for papers (in percentage of artists who actually
> want to use the tool and get stuff done right now = close to zero) can
> do that quite easily following the links and descriptions there (or if
> that's not good enough, they can read the code!). This is the correct
> place to be describing things in detail, not on a button name where
> there's not enough space to describe it anyway.

Yeah, because I said the tooltip would not have informative things
like trade offs or short descriptions. I also want that the only way
to know things is a web search. Right, as plus I am saying the name
must be something weird that nobody will realize ever and the tooltip
must be some random poem about light...

Wait, I did not said anything of that. I said one name is being
arbitrarily oversimplified. Never that users are dumb. Then interface
is the dumb and inconsistent thing. No idea how can I write that in a
clearer form.

I am trying to think about users that want to adapt tutorials or
quickly check if a feature is there. Also I try make sure no future
contribution like Screen Space AO causes problems, specially if users
check old books. Instead you propose people have to go a long path,
even checking the code, and that if there is a new contribution,
everyone has to adapt to the side effects instead of just enjoying
it. That is how it sounds, at least.

> It's a bit arrogant and insulting to be demanding people to do things
> and calling it dumbification. It's not a matter of selling things,
> it's a matter of making software that is designed for artists to use
> well. People who want to get things done and have an interface that
> actually helps them use the software more easily are not dumb. An
> interface where you need to search google to find out what every  
> gibberish-filled button does, is.

I ask for a nice tooltip and an unique name, which leads to consistent
& self documenting interface. But that is useless in your view, in
which arbitrary (only in some cases, not all) abstract qualifiers are
better. I am not the one calling users dumb, I am the one seeing users
as people capable of using a vocabulary even if they do not know the
underlying tech or background of every item they touch.

*sigh* All this for seven lines of text wondering about a two line patch:

--- buttons_shading.c	2008-01-19 10:26:02.090043036 +0100
+++ buttons_shading.c.orig	2008-01-19 10:25:13.610045279 +0100
@@ -2185,8 +2185,8 @@
 	/* column 2 */
 	yco = PANEL_YMAX - BUTH - YSPACE;
 	
-	uiDefButS(block, MENU, B_REDR, "Gather Method%t|Raytrace %x0|Point Based %x1",
-		X2CLM2, yco-=BUTH, BUTW2, BUTH, &wrld->ao_gather_method, 0, 0, 0, 0, "Method for occlusion gathering: Raytrace: slow when noise free results are required, but accurate, Point Based: faster and without noise, but inaccurate");
+	uiDefButS(block, MENU, B_REDR, "Gather Method%t|Raytrace %x0|Approximate %x1",
+		X2CLM2, yco-=BUTH, BUTW2, BUTH, &wrld->ao_gather_method, 0, 0, 0, 0, "Method for occlusion gathering: Raytrace: slow when noise free results are required, but accurate, Approximate: faster and without noise, but inaccurate");
 
 	yco -= YSPACE;


GSR