Transform Studio Layout

[HYR]

So the tab order (left to right) _usually_ makes sense I don't think it makes sense in the current Transform Studio layout. You go from X coordinate to Width to Y coordinate to Height.

Rather than change the tab order, I'd like to see it change to width and height on the first line and the X/Y coordinates on the second line.

[Sean P]

Hi HYR,

Designer certainly does have the wrong tabbing order when compared to Photo. I'll get this passed on to development. As for the text box positions, I don't think this is possible as it will have a large knock on effect for our Documentation, Videos, Workbooks and also for other factors, such as the way the 'Link' icon works.

[fde101]

X -> W -> Y -> H

That makes sense to me since it covers the horizontal axis then covers the vertical axis in the same manner.

 

That said, while this doesn't look wildly out of place to me, that doesn't mean I'm confident it is the most optimal order either...  If there is a common use case that is optimized by a different tab order, I'm all for changing it.

If I design a form to enter address information I generally do Name -> Phone Number -> Street  Address -> Zip Code -> City -> State (this is for US addresses) because of the way that auto-fill can be made to work in a lot of database products: if the phone number is the same the address probably is too, if the street address is the same there is a fair possibility the zip code is, and if the zip code is the same, the city and state probably are as well.  By looking up the fields in previous records as I go the database can help to reduce typing on future entries...  so the order that looks right visually isn't always the most optimal.

[Sean P]

14 minutes ago, fde101 said:

X -> W -> Y -> H

That makes sense to me since it covers the horizontal axis then covers the vertical axis in the same manner.

 

That said, while this doesn't look wildly out of place to me, that doesn't mean I'm confident it is the most optimal order either...  If there is a common use case that is optimized by a different tab order, I'm all for changing it.

If I design a form to enter address information I generally do Name -> Phone Number -> Street  Address -> Zip Code -> City -> State (this is for US addresses) because of the way that auto-fill can be made to work in a lot of database products: if the phone number is the same the address probably is too, if the street address is the same there is a fair possibility the zip code is, and if the zip code is the same, the city and state probably are as well.  By looking up the fields in previous records as I go the database can help to reduce typing on future entries...  so the order that looks right visually isn't always the most optimal.

I think the logical choice would be that if you're adjusting the Height, you might want to also adjust the Width. For example, I've drawn a shape out and want to make it square I will first change one dimension then want to tab to the other one!

[HYR]

I agree with Sean. I would expect to tab from `Width` to `Height` when modifying a shape, not the `Y coordinate`.

@Sean P Personally I would prefer the UI to change to make it more obvious, but I can appreciate that a UI change would affect the current docs. Even just changing the tab order would help in the short term.