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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
