new interface

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Tue Jan 11, 2005 12:06 pm

joeri wrote:Maybe the tab names should be looked at. I don't expect to assign things in a preview window.
Bingo, that's one I have to whine to Ton about. The way the preview render code is currently set up, it will only display in a panel called 'Preview'...
I was trying to prove that you use as many (cluttering) lines as the current system.
Yep, but what matters to me is the value of those lines. As I see it, clutter in the view is bad. But, if that clutter has positive aspects to it, then it can be good. If the positive effects of whatever that line or whatever visualises are stronger than the negative effects of clutter and distraction, then it's worth doing. IMO, the SpotBl circle passes this test, of positive vs negative - the Z axis line doesn't.
Maybe the anker can be drawn when selected
Possible, yes. But I'm interested to know how you think this would help, what would it achieve and why.

Cheers

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Tue Jan 11, 2005 1:22 pm

broken wrote: Yep, but what matters to me is the value of those lines. As I see it, clutter in the view is bad. But, if that clutter has positive aspects to it, then it can be good. If the positive effects of whatever that line or whatever visualises are stronger than the negative effects of clutter and distraction, then it's worth doing. IMO, the SpotBl circle passes this test, of positive vs negative - the Z axis line doesn't.
That sounds like an opinion. Removing features because of opinions is not very good.
broken wrote:Possible, yes. But I'm interested to know how you think this would help, what would it achieve and why.
The best way for me to understand the 2d visualization of the 3d space is by wiggling the viewport. This solves all position problems instantly.
I'm pretending to have two eyes by moving the view.
Another way to see position in 3d space is perspective, imaginairy or real (grid) lines that move towards the horizon.
Lamps with ankers give it a place in 3d because of the angle of the line.
It's information, just as valid as the ambula of the lamp.

Why isn't this a problem for objects?
It is a problem for objects, but objects are mostly made in proportion to something I know. In relation to something I know and placed near the grid. If you patch one eye in real life, you know where things are by experience.
They are not an abstract object like your lamp. If the lamp would be a real model of a lamp, with pole etc. It would be easy to see where it is.

Weird how on one hand you want things to be easier to understand, and then you come up with something like a total abstract lamp that has no relation to the 3d space, saying that is unimportant information.
Generly i'd say:
Don't make the 3d stuff to graphical, keep the reallife movie metaphores. Lamps on Poles, Camera on Dolly (add!), Decor on the Set (grid).

Oops, boss coming.

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- » Tue Jan 11, 2005 2:22 pm

ilac wrote: What sort of an argument is that? :?
[...]
Well look at this :
http://www.mentalwarp.com/~fred/divers/screenshot2.jpg
Floating panels don't just "Waste screen area" they make the regions that they overlap inaccessible without moving them.
managing layer may be on and of actions for you, but not for me. I think that managing layers represents 20% of the work that i do.
BTW. You might want to switch to Corel Photopaint. Most panels dock themselves and shift the workspace accordingly. How many people do you know that prefer working with Corel photopaint over Adobe photoshop?

I really like this in photopaint, and i'm not alone. But photopaint lacks lot of professional features that make it unsuitable for people's need. that's why people don't use it. If it has proper lab support and a decent layer system, maybe more people would use it.

Dani
Posts: 143
Joined: Fri Oct 18, 2002 8:35 pm

Post by Dani » Tue Jan 11, 2005 4:22 pm

Let me give my feeling about your work broken.

First: I appreciate your efforts in trying to "humanize" and "efficientize" Blender's interface (though it might be needless to say: that will make some people very nostalgic of the 1.8 UI : some evolve and others, well, [looking for a polite way of saying this...] don't evolve (hrms...))

You seem to be on a good track, though there and quite some things that still need some work (the UI is huge, so there always is some work).

Here a some crits, that i hope are constructive :
Although I first though that floating panels were a good idea, now i doubt: they look like a constraint to the coder (where shall I place this thing? there's already so much in this panel, should i create a sequel to this panel ie: edit tools 2) and to the user (where do I find...)
Ton was right when saying that people like the "dashboard" principle: everything is visible or at least easy to find. I might want to change that to :"everything is visible or at least easy to find in one given context"

So the floating panels as they are now in Blender might not be the best solution. However, your work is still in its very early stages so I will wait to see how it turns out.

Anyway, what i suggest is to use a bit more the buttongroup functions that are available in the rounded theme. The render button (F10) look very cramed up with the new theme and arrangement compared to the previous version. (shouldn't "Field" "Upper" and "Freeze" be grouped?)

Also, you might want to at least evaluate Labelled buttons versus Icon buttons. I see a few advantages in well done Icons : as I'm very concerned by the l18n of Blender, this would make things a lot easier. Ton suggested to only translate tooltips and not button labels. To lots of users and to me, it doesn't make much sense: "Blender's localised!" "You sure? all i see is english...". Buttons must be explicit, and keeping the original language is not the way to this...
Icons would 1) justify the non-translation of the buttons ;)
2) give instant feedback, if they are well done.
3) Save Space.
4) Make translators happy...

Another thing that would help translators is bringing button labels OUT of the button, at least where possible: toggle buttons have no need to have the label inside of them! next to them is good enough!

Some other things that could be done to go in the DashBoard way is a thin line with a summary of the context's activated features along the (3D view?) header (with the selected object). (in a coded way... dots, colours, something... hum, is this really a good idea?).

Oh, and will you tackle the headers?
They have a few problems : they do not support vertical position, and the hide the information. I still thing that, for example in the Buttons Window's Header, all the conexts should be visible at once, grouped, but all visible and accessible. Having to click on the material button to acces the world button is quite annoying, and sometimes F8 is just too far (this means, that the "USE THE HOTKEY" argument is not valid... we're trying to make the UI easier no?)

Having said all of this, well, I shall leave you to your thoughts.

Oh, I forgot, the arrows in the numbuts aren't always very well placed and are EXTREMELY annoying for lisibility and translation. What I've already done is recoded that function to draw the arrows, so that size, shape and position aren't hard coded but given by the calling function (ie: each theme can have a different arrow size etc, have them stretched vertically to make isocel triangles). However, the only thing to do to call back default is to send some zeros as arguments.
Why did i do this? to get a hand on C, and to place those arrows out of the way! You might not need to do all this, just move them a bit towards the edge (I use 2pixels and it looks good enough)

Well, this has become a long post, now I'll let you work ;)

Ciao
Dani

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Wed Jan 12, 2005 1:35 am

joeri wrote:Weird how on one hand you want things to be easier to understand, and then you come up with something like a total abstract lamp that has no relation to the 3d space, saying that is unimportant information.
Of course it has a relation to the 3D space, it's situated in it (and has scale, unlike the old lamps). As I've said, it has the same relation to 3D space as the other non-geometry object types.

I still haven't heard any defence about the other problems that that line brings, like the confusion between hemis, suns, and omni lamps, making it look like omni lamps have direction, etc.
Don't make the 3d stuff to graphical, keep the reallife movie metaphores. Lamps on Poles, Camera on Dolly (add!), Decor on the Set (grid).
Many of the lamps are abstract anyway. Hemi lamps, sun lamps, photon lamps aren't usually found on poles because they don't exist in the real world, and so there is no good metaphor. And camera on a dolly? Yeah, let's also add a director's chair, and little 3d best boys and gaffers running around, and big trucks out the back off the grid. There's a limit to how far you can take that.

Anyway, we can debate this all day long, you've given your reasoning, I've given mine, and I'm sure neither of us are going to change each other's mind. The rest is up to the bf-blender people and the users to decide (or at least in a worst case make it a theme option).

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Wed Jan 12, 2005 1:52 am

Dani wrote:Here a some crits, that i hope are constructive :
Although I first though that floating panels were a good idea, now i doubt: they look like a constraint to the coder
Yes, it is a constraint, and this is a good thing. We want coders to be thinking about where to put things, where are they logical, instead of having 'freedom' and just shoving things anywhere. it also makes it easier for coders since if there is already a place laid out, they don't have to go through decisions every time. Hopefully the guidelines and organisational structure generated in this project will make these sort of things much easier and extensible in the future.

Any any case, the panels were needed and are here to stay. They are doing a reasonable job, but have not reached their potential, which is what this project is all about trying to improve.
Anyway, what i suggest is to use a bit more the buttongroup functions that are available in the rounded theme. The render button (F10) look very cramed up with the new theme and arrangement compared to the previous version. (shouldn't "Field" "Upper" and "Freeze" be grouped?)
Well, we have got some guidelines for how the grouping ('alignment') should be used, in order to keep things clear and consistent. The reason those three aren't aligned is that Upper was intended to be a menu between Upper and Lower, which suits the nature of that control better. This isn't easy in the code right now, so we're waiting to see what we can do about that.
Buttons must be explicit, and keeping the original language is not the way to this...
Icons would 1) justify the non-translation of the buttons ;)
2) give instant feedback, if they are well done.
3) Save Space.
4) Make translators happy...
Unfortunately, while something like that may make it easier to translate, it's not the way to go and it's not worth sacrificing usability for. Icons definitely don't always give instant feedback. Particularly in 3D, where so much is abstract, it's very difficult to communicate something quickly, clearly and obviously with pictures (especially when Blender's icons are so small, too). This is what TrueSpace attempted, and it turned out terribly. I understand there are problems in Blender's translation system that makes things difficult, but the right solution is to fix the translation system at the core.

Now on the other hand, a customisable toolbar with favourite buttons as icons has been talked about a bit, and would probably be an excellent addition. This is not in the scope of this current project though.
Another thing that would help translators is bringing button labels OUT of the button, at least where possible: toggle buttons have no need to have the label inside of them! next to them is good enough!
I'm curious about how you think this would help - there would still be the same amount of space left for text, right? Just the background is different.
Some other things that could be done to go in the DashBoard way is a thin line with a summary of the context's activated features along the (3D view?) header (with the selected object). (in a coded way... dots, colours, something... hum, is this really a good idea?).
I think better feedback in the 3D view can definitely help give give a good overview of the state of the system, as long as it's done sensitively. If you've got some concepts, please go ahead and make a mockup!
Oh, and will you tackle the headers?
Not at the moment. There are plenty of things in Blender that can be improved (the headers and the toolbox are two big concerns), but that can wait for a later date. This current project is hard enough work as it is :)

Cheers

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- » Wed Jan 12, 2005 2:54 am

I think that a compromise can be found for the lamp z-line.
some trying :
Image
As the axis has a different shading and color, it can't be taken as a lamp direction, so the difference between the lamps stay clear.
with some opacity set in the theme, the user could choose how apparent the lines are. I think that in this way they are less intrusive, but still give usefull information.

when you look at the screenshot, the lamp location is clear. It would not have been so if there was no lines at all. It is useful for tutorials and documentation when the user can't rotate the view to see where is located each lamp.

There is a problem with those z-lines when there is a lot of lamps at one place, but i don't have solution for this case. Maybe a Drawline option in the lamp properties ?

Vek
Posts: 0
Joined: Wed Nov 24, 2004 7:42 am

Post by Vek » Wed Jan 12, 2005 3:10 am

Just to add my opinion here - floating panels are incredibly irritating, for the reasons given above - especially when you're on an image... you can't pan cuz its already at the pan limit. This makes photoshop for example frustrating to me. I have often wished that photoshop has some sort of snapping toolbox like blender already has... it just makes more sense... for that kind of editing.

Bellorum
Posts: 0
Joined: Wed Jan 21, 2004 3:27 pm

Post by Bellorum » Wed Jan 12, 2005 3:50 am

I don't understand the problem some seem to have with photoshops floating panels. If you don't want the panels obstructing your workview, resize the workview so that it doesn't - voila! If that doesn't cut it, use Tab. Can't be easier than that, really. However you do it, panels take up screenspace, so if their fixed or floating really doesn't make for much of a difference. Note that I'm not saying I want this in Blender. For Photoshop, though, it's perfect.
There's no such thing as democracy. There's only the tyranny of one, and the tyranny of many.

Money_YaY!
Posts: 442
Joined: Wed Oct 23, 2002 2:47 pm

Post by Money_YaY! » Wed Jan 12, 2005 5:16 am

The simple fact is, what you are doing now will be nice for some. But it will never appease everyone. And for a lot it will just make things messy again.

I will ask for floating panels till I puke, and others will not use them, who cares. Just keep at helping as you like it is obvious that no one has a method to make everything in blender. But as a user and not a coder I feel left out of the design flow that happens. But that is my problem.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Wed Jan 12, 2005 9:08 am

Money_YaY! wrote: But as a user and not a coder I feel left out of the design flow that happens. But that is my problem.
There is not much that can be done about that. Even at NeoGeo I felt out of the design flow, and there I made 1/3 of the desiccions.
For now it's a matter of importance, not unwillingness.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Wed Jan 12, 2005 9:24 am

broken wrote: I still haven't heard any defence about the other problems that that line brings, like the confusion between hemis, suns, and omni lamps, making it look like omni lamps have direction, etc.
Hmm. I'm in the defence corner?
Shouldn't your proposal be better beyond the doubt to make a change?
I agree that people confuse things. I confuse the brake from the gas, does that mean we should remove the brake? no. A solution should be found.
different icons for different lamps is fine. nonsens, but fine. In your philosophy the camera needs different icons too then for wide angle, video camera, etc. So do the objects; polys, nurbs, subdivs.
Many of the lamps are abstract anyway.
Hemi lamps, sun lamps, photon lamps aren't usually found on poles because they don't exist in the real world, and so there is no good metaphor. And camera on a dolly? Yeah, let's also add a director's chair, and little 3d best boys and gaffers running around, and big trucks out the back off the grid. There's a limit to how far you can take that.
The sun is not in reallife?
Now you are mocking me. There is a directors chair in blender, it's the scene button. The concept of using sets for example would be easier to understand if there was a directors chair in the scene. Or other animation ideas that are now connected to the interface while other animations are on 3d objects.
"There's a limit to how far you can take that."
Yes, but Z-ax on lamp is not as far as truck in back (lib link).

You just made a poor design decision (you agree that can happen?) and are spending more time on defending it then fixing it.
Anyway, we can debate this all day long, you've given your reasoning, I've given mine, and I'm sure neither of us are going to change each other's mind. The rest is up to the bf-blender people and the users to decide (or at least in a worst case make it a theme option).
Sure, I'll get commit rights from Ton and add the z-ax myself ;)

Eternl_Knight
Posts: 0
Joined: Mon Dec 06, 2004 2:22 am

Post by Eternl_Knight » Wed Jan 12, 2005 11:46 am

*laugh* Joeri, you hit the nail on the head about one thing here. Blender is not a democracy and no matter what the suggestion/patch given the the "main" development team - if they don't like it (regardless of how much the users might), it doesn't go in. And you're pretty important as far as users go - compare it to those of us who have no influence!

Anyhow, I know that the benefit of open-source is simply to fork when you want to (look at intuitive-blender!), but hubris such as this tends to cause a downfall. Look at FilmGIMP (now Cinepaint). The GIMP developers had the ability to get some of the biggest film studios developing with them, their hubris led to the fork and now the studios will have nothing to do with them. *sigh*

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Wed Jan 12, 2005 12:34 pm

Eternl_Knight wrote:*laugh* Joeri, you hit the nail on the head about one thing here. Blender is not a democracy and no matter what the suggestion/patch given the the "main" development team - if they don't like it (regardless of how much the users might), it doesn't go in.
The dynamics of an opensource application are different than a commercial one. There is no need to please the user. Only need to please the developer. Broken can pretent he does it for the user, but that's just nonsens. They have the user in mind but why would he implement something he is against? To please me? That would be,.... work! I don't expect him to, just as he can't say how I should alter my animations. He can give advice, but I decide how it will look. Ofcourse he does not need my animation in his work, if he did, he would also be very passionate if I removed a scene he uses with one I think is 'better'.

Frustrating? Yes. But not a bad thing. Look at all the great things the team has done, they far outway the negative things.
Time also fixes alot. Bad ideas bubble away over time.

I can't believe the discussions on 2.37 the day 2.36 was released. They make me wanna yell: "Can't you first make an animation with 2.36 before you 'need' the next feature?". That is a thing that worries me a bit, because the blender focus is on development the users are also turning into techies. They start to believe it's important.
Eternl_Knight wrote:And you're pretty important as far as users go
Don't know about that.
I don't think there are important users in the current setup. The lack of user forum on a blender domain is a very big hint.

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Wed Jan 12, 2005 1:57 pm

joeri wrote:There is no need to please the user. Only need to please the developer. Broken can pretent he does it for the user, but that's just nonsens
Oh, that's nice. So "pleasing the user" really means "pleasing you"? I'm not a user? The other people who like such changes are not users? Hanzo, who requests it independently is not a user?

Please don't imply that the only person I care about is myself, that's unfair and simply not true. If it was, I wouldn't have spent weeks and weeks of my own time on the menus, which I don't even use myself. Besides, if I really didn't care, I would have put this stuff straight in BF. But it's not, it's in tuhopuu precisely to get feedback.

I'm exhausted from this thread. I'm willing to compromise with something like efbie's idea in order to please the most number of users, but later, when I have some energy again.

Post Reply