Program Naming Conventions, drop down list and the tree!

[ulrick65]

Moved discussion from Current Release, Betas, and Bug Reports thread:

http://forum.universal-devices.com/viewtopic.php?t=2051

 

I imagine that calling programs from the current folder and then spidering up (never down) through the file system until it finds a program with the proper name may be easier to implement. This could make the lister easier to implement as it could display only programs found in that manner and obviate the need for predecessors and a tree style display.

 

Then you could have global programs in the base directory, etc.

 

What do you think?

 

Rand

 

So this makes each program available to it's current folder and all folders BELOW it...but not available to folders above it, or beside it in the folder tree? Cool idea to solve the duplicate name issue, but might be a problem if you wanted to call a program from a different tree branch...you wouldn't be able to. This might cause issues to where people would have to duplicate programs within the tree.

 

I like the concept of Public and Private programs (kind of like variables) but I am not really sure I see the benefit in it. Like duplicate names, I don't see a benefit to allowing it really. Do you have an example of where it comes in handy?

[Michel Kohanim]

Hi all,

 

Thanks so very much for the discussion. We are having our own discussions internally and have not yet arrived at a conclusion. Basically, the question is:

1. Should we even allow programs with the same name?

2. Should we disallow programs with the same name in the same folder?

3. If 2 is yes, then how do we differentiate them?

 

I think, personally, we should not allow programs with the same name a) at the least in the same folder and for usability purposes not in any other folder either (the drop down list might get really huge with the path).

 

With kind regards,

Michel

 

Moved discussion from Current Release, Betas, and Bug Reports thread:

http://forum.universal-devices.com/viewtopic.php?t=2051

 

I imagine that calling programs from the current folder and then spidering up (never down) through the file system until it finds a program with the proper name may be easier to implement. This could make the lister easier to implement as it could display only programs found in that manner and obviate the need for predecessors and a tree style display.

 

Then you could have global programs in the base directory, etc.

 

What do you think?

 

Rand

 

So this makes each program available to it's current folder and all folders BELOW it...but not available to folders above it, or beside it in the folder tree? Cool idea to solve the duplicate name issue, but might be a problem if you wanted to call a program from a different tree branch...you wouldn't be able to. This might cause issues to where people would have to duplicate programs within the tree.

 

I like the concept of Public and Private programs (kind of like variables) but I am not really sure I see the benefit in it. Like duplicate names, I don't see a benefit to allowing it really. Do you have an example of where it comes in handy?

[MikeB]

My vote -

 

I think the best solution is the simplest one - don't allow programs with the same name. While it's a small limitation to live with, I think the other solutions are not worthwhile.

 

I think resources are better spent elsewhere.

[Michel Kohanim]

Hi Mike,

 

I do agree with you!

 

With kind regards,

Michel

 

My vote -

 

I think the best solution is the simplest one - don't allow programs with the same name. While it's a small limitation to live with, I think the other solutions are not worthwhile.

 

I think resources are better spent elsewhere.

[Sub-Routine]

So this makes each program available to it's current folder and all folders BELOW it...but not available to folders above it, or beside it in the folder tree? Cool idea to solve the duplicate name issue, but might be a problem if you wanted to call a program from a different tree branch...you wouldn't be able to. This might cause issues to where people would have to duplicate programs within the tree.

 

Correct, you would not be able to call programs from another equal or lesser branch.

 

Many programs are already duplicated, that is why we have duplicate names

 

I like the concept of Public and Private programs (kind of like variables) but I am not really sure I see the benefit in it. Like duplicate names, I don't see a benefit to allowing it really. Do you have an example of where it comes in handy?

 

I wouldn't refer to it as Public and Private, but as a hierarchy.

 

As I wrote, I find it convenient to use programs with the same name. For example, I have four folders, each with unique time constraints, that contain similar programs with identical names. Each folder has fourteen programs. Three folders were cloned from the first and minor changes made to the programs. This allows me to have different actions from the same switches depending on the time of day.

 

If the calling program looked first within it's folder all the programs in each of these four folders could have identical names.

 

 

 

In the screenshot you can see most of two folders. Note that the first two programs in each folder have unique names because some other programs in the folder call them. None of the other programs are referenced from anywhere else, thus duplicate names have no affect.

 

 

 

 

1. Should we even allow programs with the same name?

2. Should we disallow programs with the same name in the same folder?

3. If 2 is yes, then how do we differentiate them?

 

1,2: Just like any file system names should be unique within a folder but duplicate names should be allowed in unique folders.

 

3: That is why I thought of searching only up in the tree, to avoid prefacing program names with folder names. The lowest common denominator would prevail.

 

Doing so would also limit the number of programs in the lister.

 

 

My vote -

 

I think the best solution is the simplest one - don't allow programs with the same name. While it's a small limitation to live with, I think the other solutions are not worthwhile.

 

I think resources are better spent elsewhere.

 

I think that programs with identical names is a concept that it already implemented. And it is done cleverly, thank you dee eye.

The only difference would be to search Up the Tree instead of Down the Tree.

 

I hadn't considered this as a solution but an enhancement. I agree that it should be considered as a product request rather than an issue that needs immediate attention, the current method is quite usable.

 

I hope I am thinking in easiest to implement as well as logical.

 

Rand

[ulrick65]

My first inclination is to agree with Michel and Mike...no duplicate names... but Rand makes some good points I think. My program tree has not grown to that level of sophistication yet, but it will. Having the ability to copy a structure and make minor tweaks is good.

 

However, I dont think spidering up the structure tree will work very well. In concept it seems OK, but I just think NOT being able to reference a program outside of the current folder and it's upline would be a problem. I also think putting the folder names in the drop down would be an issue as it would get pretty long in some cases.

 

Rand: How do your programs function now? Since they have duplicate names, how does it run the right program when called?

[Sub-Routine]

My first inclination is to agree with Michel and Mike...no duplicate names... but Rand makes some good points I think. My program tree has not grown to that level of sophistication yet, but it will. Having the ability to copy a structure and make minor tweaks is good.

 

However, I dont think spidering up the structure tree will work very well. In concept it seems OK, but I just think NOT being able to reference a program outside of the current folder and it's upline would be a problem. I also think putting the folder names in the drop down would be an issue as it would get pretty long in some cases.

 

Rand: How do your programs function now? Since they have duplicate names, how does it run the right program when called?

 

Programs with duplicate names run fine. The only problem with duplicate names is when calling one program from another. Then the first program in the tree with that name is run. Otherwise all your programs could have the same name.

 

Perhaps spidering up is not the answer, but I don't think it would be very difficult to implement and I think it would compliment Folder Conditions.

The alternatives would be to only reference programs in the same folder or not allow any duplicate names.

 

I don't have many programs that reference other programs so if the program I need to run has to be duplicated in another folder it's not an issue to me.

 

To be honest, the naming convention, as it is now, is fine with me.

I'm just throwing out a suggestion.

 

Rand

[wwat]

I think, personally, we should not allow programs with the same name a) at the least in the same folder and for usability purposes not in any other folder either (the drop down list might get really huge with the path).

 

With kind regards,

Michel

 

Although it would be nice to have the ability to have file system type structure and functionality I dont think it can be done with drop down list box and maintain current ease of use.

I'm sure I read somewhere that you are looking at a GUI overhaul (could be wrong), if so then it could be left until then.

 

 

My vote -

 

I think the best solution is the simplest one - don't allow programs with the same name. While it's a small limitation to live with, I think the other solutions are not worthwhile.

 

I think resources are better spent elsewhere.

 

I'd have to agree with MikeB here, better to spend time to have a stable system with solid working features.

[ulrick65]

I don't disagree that this is small potatoes in the grand scheme, but still a worthwhile discussion in my opinion. Something has to be done, it can't stay like it is forever and the fact that UDI is having an internal discussion about it means that they agree with that. If someone were to create a duplicate program by mistake, they could pull their hair out trying to figure out why the heck it is not working right.

 

I just thought it was worth batting some ideas around to give them some user input, which is why I moved the discussion to this section of the forum. Rand's idea has some merit I think...because it allows some easy copying of programs and clarity within the tree (look at the pictures he posted). It makes for a clear understanding of what is going on:

 

Outside Light Triggers/When Dawn/Backyard Off

Outside Light Triggers/When Evening/Backyard Off

 

versus (if you dont allow duplicate names)

 

Outside Light Triggers/When Dawn/When Dawn Backyard Off

Outside Light Triggers/When Evening/When Evening Backyard Off

 

May not seem like much, but add in a folder for Inside Light Triggers, On Vacation, Kids Home Alone, etc. and you end with a dozen programs all doing the same thing simply based on Folder Conditions...but they all have different names. Now, try to find one of those programs in the drop down list! ("Did I name it Vacation Backyard Off or Vacation When Evening Backyard Off or When Evening on Vacation Backyard Off") I'm being a bit rediculous here I know...to make the point.

 

Don't get me wrong, I don't like the spider idea a whole lot...and I am not sure how you allow duplicate names and address the drop down problem, but it just thought it was worth talking about.

 

Lastly. I don't expect UDI are going to drop everything to fix this little issue or change the system. But as mentioned, if they are going to overhaul the GUI anyway...why not put some user discussion and thought into how to tweak the subtle things. In my opinion, some of these subtle things make the difference between a good system and a great one...or a great one and a greater one as the case may be. Let Michel and the guru's figure out if it is too much work for them or not....for now it's just a few bits of memory on the forum, no harm done.

 

Thanks.

[Michel Kohanim]

Hello all,

 

Thanks so very much for excellent feedback. We are surely going for a GUI overhaul. In all likelihood, the easiest way (with most impact) would be to disallow duplicate names in the same folder (just like computers).

 

With kind regards,

Michel

[tazal]

Although it would be nice to have the ability to have file system type structure and functionality I dont think it can be done with drop down list box and maintain current ease of use.

I'm sure I read somewhere that you are looking at a GUI overhaul (could be wrong), if so then it could be left until then.

 

For what it's worth you could have a multi-level dropdown instead of a flat list dropdown, similar to the windows start menu that you navigate through the a dropdown that might contain folders.

 

Now as to implementation difficulty and/or resource consumption I don't know, I'm just throwing it out there as a possible way to deal with long dropdown lists, especially if organized in folder type format.

[Michel Kohanim]

Hi tazal,

 

Good idea ... thanks so very much.

 

With kind regards,

Michel