Regaining IDE Efficiency: Property Inspector

[Curry Kenworthy]

Howdy Folks,

As more client projects have caught up with 9, now I'm currently 
spending the majority of my time in LiveCode 9 IDE. That's both good and 
bad. The bad is that the 8/9 IDE's UI is much less efficient and much 
less polished than 6 was. And I'm starting to feel the cumulative impact 
of the less efficient and more tedious UI during my work! I like an 
efficient environment. That way I can get more work done in less time 
for my clients and addon users, and also train people how to accomplish 
tasks very easily in LC.

Some time ago I mentioned that the big IDE update was more of a 
downgrade, when it comes to UI and UX; way too many good things lost in 
the remake, very obvious to a hands-on user. But specifics were desired, 
and I didn't have any opportunity to focus on that until now when I'm 
dealing with these things daily while I work. So I'm starting to compile 
a big list of the current IDE defects. I will be filing QA report(s) on 
these soon. Obviously a big win-win for LC.

Posting here first, in case any of these are already filed (please let 
me know, I'll sign on) or anything to add.

I'm starting with the Property Inspector.
	
PI Fields:

- PI fields don't scroll with mouse scrollwheel. None of them do. 
(Sometimes the group containing them can do so, but that's not very 
well-designed or consistent either; more on that below.) Just paste or 
type more text than the field's current height, and then try the 
scrollwheel - nothing.

- PI Tooltip field is short, only one line high, can't resize unless you 
resize window or visit another tab and back. Window can't resize taller 
unless you visit another tab; tedious.

- Some PI fields are resized to their content height, but that causes 
side effects. If a field contains too much text, the window may be 
resized extremely short and when changing to other PI tabs, controls 
won't be shown until you resize the window again, but that doesn't 
always fix it permanently, more fiddling require as you change tabs. I 
suggest a better-planned approach to resize, not just fully maximizing 
the height of all fields, but either way it needs to work smoothly; 
that's the main thing. The PI is pretty important.

- Using tab key to cycle through fields, 9 PI usually places cursor at 
the start of the text, whereas 6 PI selected the entire text. Selecting 
the entire text was more efficient in most cases.

PI controls:

- Sometimes there is plenty of room horizontally for two columns, but 
the large empty horizontal space is not utilized, requiring a tall PI 
window.

- When we have little arrows and also a slider for the same value (such 
as Blend Level) it serves no purpose for slider click to increment by 1. 
Little arrows already do that. Those slider clicks should increment by 5 
or 10.

- When we have a slider with no field or arrows (such as Effects tab 
Drop shadow Color Opacity) we need more control and more info. There's 
no way to even tell what the current Opacity value is! Could be shown 
via field, tooltip, arrows ... something. Again here, the click 
increment by 1 doesn't seem very useful.

- Since effectFilter setting is no longer supported, should it show up 
in the UI? I would love to have it supported, that would be good for 
optimization, but otherwise there's no need to see it.

Custom Properties:

- Can't resize the Value field. And it doesn't accept the Tab key. 
(which was also imperfect in 6 but at least accepted.) No wrap control. 
Currently pretty useless for editing longer text.

- Faulty window resize. To test, resize to make the PI window very tall, 
then shorter again. The element list always gets taller with the window, 
but never contracts again, even when there's only 1 element, so it 
becomes ridiculously big and the Key and Value fields are no longer in 
view without scrolling.

- Value field bug or critical flaw: it is or was easy to lose changes 
when editing the Value of a prop if you click in the wrong place. Now it 
seems better testing this time in 901rc1; this may have been fixed already?

- Inefficient when adding new element, requires extra click from user to 
select the newly added element, another extra click to select the name. 
Clicks matter! It could be already opened for editing after creation, 
with the entire Key field text selected. Or just use the ask dialog as 
before.

- Easy to confuse the "Add Array Key" "+" buttons with adding a new 
element, and that's fine to learn, but even after you learn it, it's 
still easy to click by accident. Then there's trouble; if you didn't 
want an array, the problem is that you've permanently lost the original 
Value for that key. That may be a big important text that is nontrivial 
to lose with a single click! Prop values are important. Possible fix by 
putting the original value into the value for the newly created 
subelement when changing a single element into an array.

PI window and tabs:

- The PI tabs (Basic, Contents, Custom...) are one thing that is almost 
more efficient now than in 6. Good! But still needs improvement. I say 
"almost" efficient because the little tab buttons are way too small - 
about 11x10 px on my screen. That's takes more effort and concentration 
to click, and these are your highest-traffic PI controls. Even 16x16 
would be an improvement. Unless there's already a setting for this that 
I missed.

- The little target icon in the tab bar to "Select object to inspect" 
usually does not actually select the object! But sometimes it does; 
inconsistent. Unless there's a trick I need to learn. And no, I never 
touch the lock. I hate the need to type a select command in the message 
box (for a control or group that's hard to select by mouse) when this PI 
select button is glitchy.

Good start?

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/