30
« on: April 10, 2006, 08:44:56 AM »
I think we have two choices:
1) Go with the flow of the screens bundled with MACH and leave tweaking to rugged individualists
2) Do a bit more work on the Screen Designer interface to allow the average mortal to tackle the screens.
I think there are a couple of structural improvements which Art might consider, which should enhance things:
Assuming that there are maybe 100 common functions (a subset of which sows up as the vast majority of buttons on any MACH screen), there may not be a requirement for each screen set to individually program each button. As an example, it the "Mist Cool" button always does the same thing (or the "Jog/Step to the right button for that matter), the function could be explicitly called by simply assigning a hot key "key stroke" or input to it, assigning it to a button name (on a tabulation list) and calling it a day. Basically this would allow someone to pull up the default table of functions within a window in SD and make modifications without going button by button. It would also allow someone to add a standard button with full default feature set (including VB code) by simply drawing it and referencing the variable on the list.
If each of the button graphics now had a standard name (how many names do you need to define "E-Stop?), then as long as the button sizes for a given function were the same, a single variable could be set defining the directory where the button graphics for that design were kept. This would allow people to change button cosmetics quickly without overwriting others.
The ability to "break" text from the button as a separate layer would allow buttons to be re-scaled without affecting the text and would allow alternate text (foreign language, or specialty tool for example) on a screen without re-creating button structures. Call this text a "transparent" bitmap layer. This would be used in conjunction with the concept of "stacking" bitmaps. If all the stacked buttons were opaque, and all the text transparent, then only the top text and button could be seen. Upon assigning a button location, a small table could pop up allowing a choice of which graphic and label could be seen under what condition. This combines the functionality of a button, its reverse function, an LED, etc. into one spacial unit. If not invokable, the button could simply turn to the background screen color an "disappear" or alternatively become a universal "greyed out" color. If START had been hit, then STOP would appear as the only viable option, etc. There will of course be exceptions where there are more than one choice, but I think these can be addressed easily on an individual basis.
I feel implementation of the above concepts will allow more intelligent and versatile screens to be quickly constructed (rather then creating more intelligent screen artists :-) .
Standing back and looking at the user interface reminds me of the discussions about the lines drawn between CAD, CAM and CNC. On screen designing, you have the physical tool, the interface mechanism between the screen and the physical tool and the GUI interface between the human and the screen. What I'm proposing is a methodology to make the last section of this command chain more user friendly by allowing the designer of the interface a greater ease in quickly creating more innovative solutions without worrying about the rest of the underlying code structure.
Just a couple of thoughts,
Jeff
Guest
Show Posts