Regaining IDE Efficiency: Property Inspector

[Richard Gaskin]

Inspectors are popular in drawing and layout programs, where object 
properties are relatively limited.

Many (most?) development environments use a property sheet* instead, to 
handle the deep, rich variety of detailed properties developers need to 
control.

Property sheets can help address everything in this list by:

- making better use of space, with more options visible at once

- being more complete, allowing all object properties to be available
   rather than just a selected subset

- providing more efficient navigation; accordion controls have a much
   larger target area than toolbar icons; good ones let you switch
   between grouped categories and one full list sorted by prop name.

- simplifying resizing so the entire resizing complexity goes away

Bonus:

- they're simpler and more cost-effective to develop


Once we extend "the properties" property to handle widgets uniformly 
with LC-engine-native controls, I'll gladly extend my 4W Prop Sheet to 
handle them, and even donate it to the project if they like so they 
won't have to lift a finger beyond providing the uniform access to prop 
arrays.



*If you haven't used an IDE with a property sheet, here's VB's as an 
example:
http://www.afralisp.net/visual-basic-for-applications/tutorials/images/vb-properties.png

-- 
  Richard Gaskin
  Fourth World Systems


Curry Kenworthy wrote:
> 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