IR8.01 Beta posted

[Mark Pierson]

Thanks Graham, I hope you're still having fun doing this!

I wouldn't still be doing it if I wasn't!

Ok, but do you have any hair left?

[mathdon]

Way, way back, in the original thread seeking suggestions for IR 8.00,

8. Probably nothing causes more confusion for newcomers than the headings on the keymove sheet. Could we rename/edit the second instance of DeviceButton, the one refering to the upgrade device, not the bound key.

I dealt with this by re-naming the two Dev Button columns as From Dev Button and To Dev Button. It seems to have escaped everyone's notice, especially mine, that I got them the wrong way round! On the Key Moves page, Col 1 should be "To Dev Button" and Col 4 should be "From Dev Button". I've only just noticed this while writing a post to help someone use Key Moves! I'll change them round in Beta 3, which I'll put up shortly.
________________
Graham

[gfb107]

I found the use of two device buttons confusing too. In my usage, I also found that the from/source device button was usually not useful because I didn't have the setup code bound to a device button. So when I implemented it in RMIR I only included one device key, the one you are calling the "To Dev Button".

I also think having both gives the user the incorrect impression that the setup code must be bound to a device key in order to create a keymove.

[mathdon]

Greg's got a good point. All the info about the source is present in the other columns. It doesn't really add anything to say which device button (if any) has the device type and code corresponding to the source.

So what do others think about simply eliminating this second Device Button column?
__________________
Graham

[mdavej]

I personally prefer the way it is, mostly. Whether or not the "From Device" is is assigned to a device button is useful information to me. The confusing thing to me is that the column headers don't really match the dialog. I vote for correcting the headers as you said, leaving the 2nd device column intact. But make the bound key device text in the dialog read "To Device" and function to perform device text read "From Device".

My 2 cents.

[mathdon]

It is perhaps a silly thing to anguish about, but now I've started to think about it I really would like to come up with a meaningful solution to the column naming issue. As it is trivial to rename columns but a lot of hassle to delete one, and even more to put it back later if required, I will opt for renaming unless there is overwhelming support for deleting the second "device button" column.

I think confusion starts with the name of the tab. It isn't really "Key Moves", as when you move something it is then no longer in its original place. It's closer to being "Key Copies", but even that isn't right because the function doesn't have to be on any existing key (or, as Greg points out, not even on any existing device button). The best I can do is "Key Mappings". Anyone willing to go along with a change of tab name?

As for column names, I don't really like the "To" and "From" either way round, because of its implication of moving or copying. How about "Mapped Device" for the first dev button column and "Source Device" for the second one? The dialog boxes would suggest "Bound Device" instead of "Mapped Device", but I think that the computer concept of "binding" is a rather technical term that itself might confuse the naive user.

At the very least, I hope these suggestions will provoke some discussion!
__________________
Graham

[The Robman]

I don't have any good suggestions for the column headings, but I would definitely vote against re-naming the Keymoves tab, because this is what UEI calls them in the manuals (when they mention them at all) and it's how we've been referring to them since the beginning of time. So, while I agree that they're really moves, I think we're stuck with the name.

[vickyg2003]

I think confusion starts with the name of the tab. It isn't really "Key Moves", as when you move something it is then no longer in its original place. It's closer to being "Key Copies", but even that isn't right because the function doesn't have to be on any existing key (or, as Greg points out, not even on any existing device button). The best I can do is "Key Mappings". Anyone willing to go along with a change of tab name?

KeyMove is from some of the remote documentation, so it really should stay keymove. Several of the remote manuals have "Using Keymover" in the indexes. It may not be the best description, but it does jive with Oneforall and RadioShack documentation. Although you could call it Key Magic on the European remotes, but even then they talk about moves once you get down to the bottom.

As it is trivial to rename columns but a lot of hassle to delete one, and even more to put it back later if required, I will opt for renaming unless there is overwhelming support for deleting the second "device button" column

.

I'm glad the column will not be disappearing, since it helps me identify problems in other peoples IR files. I'd like to see the first Dev column be called "Bound Dev" so that it relates to the name.

Some suggestions

From Dev Button= "Reference Dev"
From Dev Button= "See Dev"
From Dev Button= "Refers to Dev"

[Capn Trips]

OK, time for me to chime in here. Fascinating discussion. I never noticed the misnamed "Device" columns before, either!

(1) Keep the Worksheet/Tab named KeyMoves. It's been that way forever, agrees with most documentation, and has the virtue of being LESS bad than any other name one can think of. It's intutive if not 100% precisely accurate for all circumstances;
(2) Column 1: "Target Device". "From" and "To" are really confusing, regardless of where you put them. I think that "Target" comes closest to describing what you're doing on this worksheet and is still pretty intuitively understandable to most, I would think;
(3) Column 2: "Target Key" or "Target Button". "Target" is same argument as above, while I'm ambivalent about "Key" vs. "Button";
(4) Column 3: Not sure what purpose it serves, but I guess if it's too hard to delete it, leave the "=" sign there;
(5) Column 4: "Source Device". Again, I believe taht the term "Source" is pretty intuitive, and an "<N/A>" would also be self-explanatory for most users. Agree to NOT eliminate this column;
(6) Column 5 and on: OK as they are.

My $.02.

[Capn Trips]

While we're at it, I would carry the "Target ..." formulation over to the Macros and Special Protocols Tabs as well.

And I've always found the name of the "Special Protocols" tab to be misliedaing, or perhaps vague would be a better term. Maybe renaminig it "Special Protocol Functions" would ease my ... unease, but I realize that is kind of long and may not be practical.

Just my 3'rd and 4'th cents.

[mathdon]

I would have put money on history dictating that Key Moves remains as Key Moves, and on IR usage dictating that the first Dev Btn column would become "Bound Device", so that's what it will be unless someone comes up with a better suggestion.

I still prefer my "Source Device" to all of Vicky's suggestions, but another idea that has come to me is to omit the word "Device" completely from that column and call it "Function Source". That fits in best with the dialog box saying "Function to perform".

More comments welcome!

Edit: I was still writing this when the Cap'n posted his comments. I quite like the "Target" idea, but I think it unnecessary for the other tabs. If we are to keep uniformity across tabs, I would opt for no prefix on the first column, just leaving it as "Device Button".
_________________
Graham

[Capn Trips]

I gotta say that "Bound" has always left me scratching my head, and I for one would be happy to see that term done away with.

Waddaya think of my "Target" suggestion?

[vickyg2003]

I gotta say that "Bound" has always left me scratching my head, and I for one would be happy to see that term done away with

.

I thought that was just me. I quite agree Bound never felt right. I like target too.

[mathdon]

On further reflection, I'm warming to the Capn's idea of putting "Target" before "Device" and "Key" in all the relevant tabs. Macros, for example, currently has "Key" and "Macro Keys". Calling the first one "Target Key" seems to make the distinction clearer.

I'm also warming to my own "Function Source" suggestion for the second Dev Btn column of Key Moves. Views?

I share the Capn's unease about the name "Special Protocols". When I started with JP1 this conveyed absolutely nothing to me, apart from a feeling that it was probably something of little relevance to my needs. But I imagine that, like "Key Moves", it is immutably enshrined in history.

The column that gets filled with "=" signs has no function. I presume its purpose is to make the grid line read like an assignment statement in a computer program. It seems harmless, if unnecessary, and certainly not worth the effort of removing it. (The removal problem is that the remaining columns have to have their column numbers changed consistently throughout the program, and there are a great many references.)
_______________
Graham

[Capn Trips]

On further reflection, I'm warming to the Capn's idea of putting "Target" before "Device" and "Key" in all the relevant tabs. Macros, for example, currently has "Key" and "Macro Keys". Calling the first one "Target Key" seems to make the distinction clearer.

On that, I'd prefer the "Macro Keys" column be changed to "Function Sequence" or "Command Sequence", since it's not always "keys" that you are assigning in a macro, but you are creating a sequence of functions or commands.

I'm also warming to my own "Function Source" suggestion for the second Dev Btn column of Key Moves. Views?

Not sure. I slightly prefer my "Source Device" but your formulation conveys the same general sense, I suppose.

I share the Capn's unease about the name "Special Protocols". When I started with JP1 this conveyed absolutely nothing to me, apart from a feeling that it was probably something of little relevance to my needs. But I imagine that, like "Key Moves", it is immutably enshrined in history.

I think that has less historical baggage, since Special Protocol Functions do not exist outside our little closed JP1 world. Keymoves have existed in most UEIC Remote manuals for DECADES, but Special Protocols are all ours.

The column that gets filled with "=" signs has no function. I presume its purpose is to make the grid line read like an assignment statement in a computer program. It seems harmless, if unnecessary, and certainly not worth the effort of removing it. (The removal problem is that the remaining columns have to have their column numbers changed consistently throughout the program, and there are a great many references.)
_______________
Graham

Roger. No problem leaving it.

"If it works, don't fix it!"