Consistency through Cura UI

[kmanstudios 1,120]

When you are working in the right side menus and you click in them, the input field is completely selected. However on the Left side, unless it is picking up a setting from the right (Say, per model settings) they do not behave the same. This is annoying

 

Also, in 2 of 3  of your transforms, you have numerical input as well as Icon manipulation. But Rotate is still the red headed step child.

 

While I understand the idea of not worrying about the actual 'low level' things when you are trying to put in new, cool stuff, it is leaving things like this behind that starts to let users think you are only interested in the latest and not really maintaining a whole entity, not just a collection of cool things past. With that "It is almost right' theory in action, this would led me to the orthographic views. They are not. I cannot look top down  to truly inspect my build space because it is occluded by objects in perspective. Or, I cannot look horizontal to make sure anything along the Z is lined up as it should be.

 

Should this be modeled? Yeah, if it is part of the model, but being able to truly manipulate your work space is not the same. For instance, I can turn off keep models apart and stack parts under overhangs and such as well as put gaps between models in side view *IF* I could actually see that the way I do in CAD packages.

[gr5 2,167]

I have also noticed that the left/right/top/front views are perspective and not orthogonal which makes that feature pretty useless.

 

I'm guessing this is what happened - some customer asked for left/right/top/front orthogonal views and some cura programmer decided to implement this feature but simply put the camera in these locations without understanding what an orthoganal view is.

 

I don't think this is a critical feature and probably very difficult to implement so I think it should be removed from Cura until someone implements it correctly because to implement it correctly is hard - you have to then change the functionality of panning and zooming.  And what do you do if someone rotates the view?  You have to switch somehow between ortho and perspective views so you need to keep track of the modes.  Does it snap out of ortho into perspective on rotations instantly?  Or add a perspective button and only allow rotation if the user chooses that?  It seems like a big project to me.

[kmanstudios 1,120]

I am kinda thinking that it may not be so hard to implement an ortho/persp toggle from any view. It is the most standard capability in all cad packages. I could be wrong, but I am thinking that problem got whipped about 30 years ago in basic philosophy of algorithm swapout from one viewing math to another. But, coming from CAD packages and even lowend/free type packages as well, this is the only program that does not do so. I am not comparing slicers as I am not familiar enough with the others to be intelligent about.

[ahoeben 1,948]

1 hour ago, gr5 said:

some customer asked for left/right/top/front orthogonal views and some cura programmer decided to implement this feature but simply put the camera in these locations without understanding what an orthoganal view is.

 

Why be so negative in your assumptions?

 

Here is what happened: this feature has been on the minds of several developers for a long while, but it is actually not trivial to implement so it never got added. It is not seen as a critical issue, and that's why eventually it was implemented in a "better than nothing" kind of way. What makes it more difficult to implement is that the way Cura zooms and pans does not work with orthographic views. This is not unfixable, but harder (read: more work to get right) than just flipping a property on the camera object.

[kmanstudios 1,120]

34 minutes ago, ahoeben said:

 

Why be so negative in your assumptions?

 

Here is what happened: this feature has been on the minds of several developers for a long while, but it is actually not trivial to implement so it never got added. It is not seen as a critical issue, and that's why eventually it was implemented in a "better than nothing" kind of way. What makes it more difficult to implement is that the way Cura zooms and pans does not work with orthographic views. This is not unfixable, but harder (read: more work to get right) than just flipping a property on the camera object.

Actually, I would find a frozen orthogonal to be beneficial. Especially top down. I had to really niggle around a model this morning because I could not see precise location from the top view. The perspective made it impossible to use and did a lot of slewing around the scene to make tiny adjustments where a top down would have been most helpful. I find the orthogonal to be excellent at placement, and the perspective to be useful for inspection.

 

I am surprised that making the change would be so difficult unless it is one of those things based on earlier decisions. But, even a static view that would allow for easier precision placement would be helpful. Since I seem to push the boundaries (in this case, literally, buildplate boundaries) I have run into situations where visually it looks ok and slices, but will not print with the report of 'being too large for buildplate." and, "Add UM3X to accommodate the build size." Most annoying since I only have UM3X machines. But I have found a skootch over one way or another can solve that. But it takes a lot of time to spin move, spin move, spin move, etc.

[ahoeben 1,948]

It is not extremely difficult, just more difficult than time allowed

[gr5 2,167]

kman - I think you have to tell opengl to display things differently.  It's a very different way to convert 3D surfaces to the 2D display.  It's a different set of transformations.  And in this mode you should be able to zoom and pan and it should stay in ortho mode.  But as soon as you rotate (orbit) - you probably need to somehow leave ortho mode - but how do you leave ortho mode gracefully?  you don't want the part to suddenly be redrawn in the other mode (I would think) because now the part would suddenly jump.  So you have to somehow smoothly transition between the two modes.  There's probably a lot of ways to do this so you have to pick one.  Or like you said maybe disable rotation (what you call orbit).  Which makes more sense?  disable orbit?  disconcerting jumps in position of the bed?  Stay in ortho mode forever?  (my cad package is always in ortho mode but it makes parts look strange/distorted  sometimes)  Maybe a toggle button to switch in and out of perspective?

 

Lots of decisions.  Lots of experimenting.  Meetings where UX people disagree with programmers.  More meetings.  Time.

[nallath 1,120]

And don't forget more testing, as these changes are pretty "deep" into the code. So those changes could impact a large number of other features. To be sure it didn't accidentally break some stuff, you need to re-test a whole load of features.

So pretty much what Aldo said; Don't assume malice if we didn't build a feature exactly how it should be. We know that it's not perfect. We don't like it either, but there is only so much things that we can do, so it's a constant balancing act. Constantly having the feeling that we need to defend ourselves isn't really helping

Edited March 1, 2018 by nallath

[kmanstudios 1,120]

On 2/28/2018 at 2:46 AM, kmanstudios said:

When you are working in the right side menus and you click in them, the input field is completely selected. However on the Left side, unless it is picking up a setting from the right (Say, per model settings) they do not behave the same. This is annoying

 

Also, in 2 of 3  of your transforms, you have numerical input as well as Icon manipulation. But Rotate is still the red headed step child.

 

Is it me, or did everyone kinda skip the easy ones to jump all over the obviously more difficult ones?

 

This is a bit annoying as it seems that the above I isolated are not difficult. You rearranged an entire right side menu to operate in one way, but left the transforms out and created an uneven UI experience.

 

And, the Transforms have always been uneven by way of no numerical input into the rotation. I am not looking to model on the Cura platform. But I would like to be able to have consistent results when placing objects into very tight parameters to make sure it prints.

 

An example would be that I have an object that must be placed just in the right position to allow it to print. Now, I cannot depend on the shadow guides because even though it will slice, I still continually get the "Too big for buildplate, add the printer you already have anyway, you know, the one that we say is too small to print on, the one you have, but if you add it, it will print..." (No, that is not what it says, literally, but it is the message it sends.

 

After working quite diligently on it, I get it to work. But I have no way to replace the model with precision because I cannot put in numerical values.

 

And, do not tell me to save the project file. I do that. But if there is a change, I cannot retrieve the changes by way of reload models since the project file has its own model and no longer references the STL file I am replacing.

This is an example of what I am talking about with the placement, which is two errors...(1) Why slice if too large to print?

Should work, yes? HA! Silly mortals!!

(Second Error) Tells me to add printers that are already added, but still too small to print on them....WTF?!?!?!

 

So, while everybody focused on just the viewports, this is a real problem in my opinion as it points to a disconnect in the software and printing cluster as well as a deficiency on being able to replicate positions on buildplates numerically as well as having all of the input fields behave the same across the interface.

 

So, does team UM feel that uneven UI/UX is best practices?

 

Does Team UM feel that disconnected performance between slicer and print cluster is best practices?

 

These two things are not picking on you or making you defend yourself. I do feel they are valid questions in response to the long winded post I felt I had to make to prove the point. And, I accept that this is me....Concise communication is not my strongest suit, hence the actual example. But please do not take 6 things, and use the hardest of them to ignore what should not be so hard. It does feel a bit Penn and Teller.

 

These are the questions that have been ignored in all of the above posts. Focusing on the difficult while ignoring the obvious. And, these issues have been reported by me, before, with files, in their specific areas of threads, so this is not new information.

Edited March 1, 2018 by kmanstudios

[darkdvd 975]

On ‎28‎/‎02‎/‎2018 at 11:59 AM, gr5 said:

I'm guessing this is what happened - some customer asked for left/right/top/front orthogonal views and some cura programmer decided to implement this feature but simply put the camera in these locations without understanding what an orthoganal view is.

 

For information : post on Github "perspective vs orthographic view in CURA" https://github.com/Ultimaker/Cura/issues/3159

[ctbeke 133]

2 hours ago, kmanstudios said:

So, does team UM feel that uneven UI/UX is best practices?

 

Does Team UM feel that disconnected performance between slicer and print cluster is best practices?

 

These two things are not picking on you or making you defend yourself. I do feel they are valid questions in response to the long winded post I felt I had to make to prove the point. And, I accept that this is me....Concise communication is not my strongest suit, hence the actual example. But please do not take 6 things, and use the hardest of them to ignore what should not be so hard. It does feel a bit Penn and Teller.

 

@kmanstudios I can assure you that we think a unified performance and UI/UX are very important. I can also tell you that they're very difficult. I expect great improvements on this in the future, but it's an ongoing process that we constantly have to think about with every new feature we implement, so sometimes we choose speed over UX in order to get early feedback and get it out there.

 

We know what the biggest issues are, and we will deal with them. It's just not possible to fix all of it within 1 or 2 releases, especially with the added list of work for everything else that's going on at Ultimaker. Don't get me wrong, we get your (and everyone's) frustration, but would your rather have the feature/product out there with some improvements to make, or not have it at all?

[kmanstudios 1,120]

2 minutes ago, ctbeke said:

@kmanstudios  but would your rather have the feature/product out there with some improvements to make, or not have it at all?

I do not understand this. Seriously, I really do not understand the question.

 

I do not see making a decision to change input fields, which was done very quickly, the same as making all the input fields work the same, nor it be a problem. Someone overlooked that and made a mistake. That is all....why so defensive? I have not attacked anybody, but rather, when I list several things and the most egregious problems are used to knock other things down, then, yeah, I am thinking that someone is still overlooking and minimizing without proper evaluation. Items 3,4,6 hard,  ergo the rest hard too...no do any at all...move along, move along......

 

My question about Team UM taking things to heart had more to do with the jumping on the "This is hard bandwagon" without really taking a look at the easier things. And, yes, I venture that making the UI consistent from input field to input field easy in comparison based on how that whole thing changed in one version, just not thoroughly, or even addressed when brought up. It is frustrating enough to bounce from one software strategy to another and keep making input mistakes because of changes. It is really frustrating to have to do that in one program.

 

And, with all the things being moved. shoved and changed, is it really that hard to actually put in a rotational input for precision placement?

 

And, I was informed by another user that if something does not get mentioned in a timely manner, here or on github, it goes by the wayside. The method to implement or choose things are up to you guys. But if this is the case, then people such as myself that really do not like to be a nuisance are not going to be listened to.

 

I am just defending, at this moment, the fact that I mentioned several things and people hopped on the most difficult to poo poo the easy stuff too. I made out a list. Seems the basic social construct would be to address the list and not just sweep it all under the rug with the same apparent disregard as being too hard. Or am I missing something here as well.....this is entirely possible too.....

 

And, finally, I really do not understand the above statement.

[ctbeke 133]

About the input field change, I totally agree with you, it shouldn't have ended up in there, it's a worse UX than before.

 

My statements were more in general, related to the endless stream of comments we get from the community (which is great!), and to indicate that we really hear you, but at the same time it's also impossible to incorporate all the feedback into our existing backlog. No personal attack whatsoever.

 

It's also true that we often say it's too hard. The reason for that is that, even though Cura is not super old yet, it already has a lot of legacy code due to internal decisions (supporting legacy profiles, dealing with new printers). This makes it hard sometimes to make even the smallest change. Other things are generally difficult to implement, like input fields for rotations (that's a math problem described here: https://github.com/Ultimaker/Cura/issues/2779).

 

Sometimes we want to push features/changes early (often as experimental, not enabled by default), just to get it out there and get feedback. This doesn't mean however that when the feedback comes, we have time or priority to actually do something with it at that moment. All the feedback is recorded in our internal ticketing system though.

 

Again, it might feel a bit defensive sometimes, but I'm just trying to shed some light into all the aspects of our development process. Please keep the feedback coming because our (and everyone's) ultimate goal is to make Cura the best slicer software our there, just not overnight.

[nallath 1,120]

Well, rotation is not in there because rotation is just insane hard to do. Especially when you go into shearing and all kinds of weird transformations that you can do. Have a look at quaternions if you want to know a bit more. But don't tell i didn't warn you that dragons live there (and other imaginary stuff / numbers). So yes. Putting in rotation is hard. If you don't believe my answer, why ask in the first place? I want to fix it, but there really isn't an easy way to do it.

As for a "disconnect", this is just using very large terms to say; "I found a bug". Because that's what you did. So the cluster seems to refuse to do something even though it was sliced. Okay, that should be fixed. But that isn't a UX issue, its a bug.

Not doing hard things is just common sense. Or well, not doing hard things if there is only a few people using it. Every bit of work we do is always a balancing act between how hard it is and how much "value" we think we can get out on it (emphasis on think, as we can and will be wrong in some cases). We don't do this because we *want* to. We do it because we have to.

I don't quite agree with the statement from Chris that we have a ton of legacy. There is legacy, but in quite a few cases it's just simply because of how something is set up. Some choices make option A easy and option B hard. This is always a balancing act and some choices that we made in the past can cause things that should not have been that hard to become harder.

[kmanstudios 1,120]

OK, takiing both of these at once.....

 

30 minutes ago, nallath said:

So yes. Putting in rotation is hard. If you don't believe my answer, why ask in the first place?

Because the question and answer did not get into specifics and therefore was muddled. That is why I was confused. I can see now that you answered specifically with general wording. I do not find it difficult to get lost on such answers......It is me....No worries on that one. Specifics make sense. And, now that I have a place to look later on, when I get into college and start doing real programming and such, this will be something I will be looking into because well, it bugs the heck out of me. And, all other info was specific to the orthographic views, so, yeah, it did seem to all get muddled together.

 

 

34 minutes ago, nallath said:

As for a "disconnect", this is just using very large terms to say; "I found a bug". Because that's what you did. So the cluster seems to refuse to do something even though it was sliced. Okay, that should be fixed. But that isn't a UX issue, its a bug.

Not in complete agreement as I do not know if it is a disconnect between the software on two ends not talking properly, or if it is a UI thing giving out wrong feedback. Kinda like a chicken/egg thing. I did not know how it factored, and I make no such assumptions on whether is bug or what.....just reporting.

 

37 minutes ago, nallath said:

Not doing hard things is just common sense. Or well, not doing hard things if there is only a few people using it.

I will agree that would be the case sometimes as something hard fixed now prevents other things down the road...just my experience is all.

 

38 minutes ago, nallath said:

This is always a balancing act and some choices that we made in the past can cause things that should not have been that hard to become harder.

This would buttress the above statement on how easy things can become problematic at a later date.

 

41 minutes ago, ctbeke said:

Sometimes we want to push features/changes early (often as experimental, not enabled by default), just to get it out there and get feedback. T

I do like the experimental things being put in that section to play with. It is 'at your risk' sort of thing, but without feedback, it can be impossible to field what people need vs. want.

 

43 minutes ago, ctbeke said:

My statements were more in general,

yeah, I get lost on that stuff sometimes.

 

Words are not my 'fourte', hell, they are not even my 'onete'. I am a complete visual thinker and is one of the reasons I became a commercial artist, but never an art director. "Tell me what you mean" said the person needing direction; "Here, let me show you" said the person who winds up illustrating it anyway..... What I can see in my head hardly ever makes it to my mouth, or in this case, fingertips, in proper order or usage. So, thanks for working with me on this one.....I was getting really lost there guys.

[nallath 1,120]

The Connect issue is because the printer has a much less advanced detection system to check if something can be printed. The printer only gets a min x,y,z and a max x,y,z. Cura takes way more into account, which in this case leads to the very small area where Cura does accept it, but the cluster software doesn't.

 

We explicitly added the feature to have both applications check for size, as you can also manually send files to the cluster. You always want it in Cura, because it's just easier and faster for users to see it right away (Doing it on the cluster is just another safety check)

[kmanstudios 1,120]

Out of curiosity, the printer would see that as an error but allow you to override, I did have to do that sometimes. Cura connect cannot do the same?

[nallath 1,120]

I'm not a 100% sure about the behaviour, but it could also be that it was a thing that you could only override when the machine is in developer mode.

 

Right now, connect can't override it (We could make it, but it's not something that I think we should, as it's pretty easy to wreck your machine if you do it)

[ahoeben 1,948]

1 hour ago, ctbeke said:

About the input field change, I totally agree with you, it shouldn't have ended up in there, it's a worse UX than before.

 

The current behavior was requested, I thought the request had merrit so I implemented it. The change was tested (I assume) and merged. I have since then made a follow-up PR, well before the release of Cura 3.2, that fixes most of the issues people had with the change (while keeping the original usecase of tabbing between fields), but that PR has been sitting there for more than a month.

[kmanstudios 1,120]

Then I would think that making the UI of Cura represent what is capable would cut down on frustrations. Maybe just a visual fudge factor.

 

And, nope, did not require developer mode. I am not that proficient yet to get into such a thing. I just popped up as a warning just like the material thing does and allowed me to override it.

 

Most of my things I am making really pushes the physical boundaries of the printer.

[kmanstudios 1,120]

Just now, ahoeben said:

 

The current behavior was requested, I thought the request had merrit so I implemented it. The change was tested (I assume) and merged. I have since then made a follow-up PR, well before the release of Cura 3.2, that fixes most of the issues people had with the change (while keeping the original usecase of tabbing between fields), but that PR has been sitting there for more than a month.

Someone requested the input fields on the right side and left side to be different? It is not whether the use is good or not. It is just not consistent on the left and right sides.

 

The exception is the per model settings. Since that is accepting the actions (Maybe inheriting is a better word? asks the non-programmer....so far.....) those fields mirror their UI counterparts. It is the physical scale and positions that are not working the same way.

[ahoeben 1,948]

Someone requested the sidebar fields to behave different than they do.

 

Please stop patterning.

(edit: you got me riled up, fortunately auto-correct made my remark friendlier)

Edited March 1, 2018 by ahoeben

[kmanstudios 1,120]

I certainly did not mean to get anybody riled up. And, I do not know what patterning is as you have used the word. I am just trying to understand.

[ahoeben 1,948]

I was going for another word, but autocorrect made it into patterning. I'm going to leave it at that.

[jkushwara 0]

First time posting - I too would very much like a rotation numeric input option. Would it be easier if the rotational value could be zero'd out or reset after multi axis transforms ? I know gimbal lock is a pretty serious issue in 3D packages and understand the difficulty. 

 

Also seconded on the orthographic views - and also understand it's a completely different approach to camera design. Just thinking out loud, but what about a simplified visualization mode to give users a tool for model positioning until a fully orthographic camera mode is possible ? Could be as simple as a flat color model outline displayed from X Y or Z axis ?