Comment on sequence of operation

[LeeStoddart]

This is neither a bug nor a new feature - it's more a dawning of understanding and MAY cast light on usability. 8)

 

Last night I think I worked out why I sometimes get stuck with something in the command line preventing some action from happening.

 

The dawning is that it now seems to me that the command line sequence is based on selecting an object or list of objects first, optionally selecting the Attribute section, then doing something with the objects.

 

But my intuitive way of working is first to go to the right screen, then select the objects and then do something.

 

An example of the sort of problem I get to would be... I'm in EDIT LIVE, do some changing of channel levels - then want to check which Pallete is tracking through for a group of fixtures

 

PALLETE

GROUP 16

 

(there are no enter or OK buttons pressed)

 

brings up the Pallete section, selects the fixtures in group 16 and highlights their selected Palletes. Now if that's the correct set of Palletes I don't need to do anything else so I press SAVE

but SAVE doesn't do anything at this point.

 

I think the syntax is that after the GROUP 16 it is expected that either @ or AND or EXCEPT would occur OR that a new section would be selected by pressing BRIGHTNESS or COLOUR for example.

 

 

Perhaps I should also realise that this idea of select an object first is inherent in the way the PW opens - but I don't think like that - I open the PW by doing EDIT LIVE or EDIT BLIND - my way of thinking is get to the screen, select the objects, do something to them.

 

Perhaps this boils down to a request - after selecting the objects be more creative on what I might press next

[K-Nine]

The command line syntax is a complicated part of the software and I understand if it is not always how you think.

 

By necessity it has to be logical and consistent or it wouldn't work at all.

 

All the new commands relating to fixtures, attributes, parameters and palettes were implemented using the same 'rules' as were already in place in the Illusion software prior to the introduction of the moving light functionality.

 

We saw the new commands as extensions to the original command set and did not want to change the syntax of any of the original ones so as not to confuse users.

 

One of the major problems in designing an interface such as on the Illusion is that there are numerous methods of entering commands and they all have to work together (ie front panel keys, external keyboard, mouse operations on buttons, tabs etc).

 

Sometimes, I guess it comes down to learning the 'rules' or syntax of the command structure. Some are common I guess, such as entering a channel level, but we have also implemented many new commands which may not at first be obvious, but hopefully with some practice they will be.

 

With a lot of the command/operations there are often about three different ways to achieve the same result.

 

The attributes are an interesting case, as sometimes you just want to change attribute to look at a different section of the Program Window; other times you want the attribute (eg COLOUR) to be part of the actual command itself.

 

If we could make the software read your mind and predict what you are trying to do then everything would be fine ...

 

I know there were some cases where you had to erase a command on the command line to continue etc. and we have removed some of these during development.

 

Trying to handle every possible combination of command and decide which are sensible and which not is quite a task and hopefully there aren't too many places where it causes annnoyance.

 

... and this was supposed to be a quick reply :shock: