New idea for both KM and RM

[The Robman]

When KM started, it was just a tool for creating upgrades, but then once the SAVE and LOAD options were introduced, it became a tool for both creating and re-using upgrades. However, the overall design of the tool is still geared towards creating upgrades, and this is the design that RM was modelled on.

I see alot of posts from people in other forums, such as Remote Central, looking for any solution for their problem EXCEPT JP1, because JP1 seems too complicated.

My guess is that if these folks see the Setup panel in KM, or the first tab in RM, and they see all the protocol and device code info, this is what intimidates them, because they have no idea what a infrared protocol is, nor what device codes to plug into it.

So, I think it would be a good idea to split the Setup panels in both programs into two. The first would just contain the bare essentials for a newbie who is loading up an upgrade that someone else has created. These ingredients would be...

1) Remote selection
2) Device mode selection
3) Setup code number
4) Upgrade code blocks

Gone would be the Protocol, device code, sub device code, EFC/OBC switch, etc. To access these functions, you would need to either go to a different tab, or press a button labelled "Config" or something like that. However, if you were to press the NEW button (indicating that you are about to build an upgrade from scratch) all these feature would be activated for you.

The only field I'm not quite sure how to deal with is the "Unit Code" field. While this should ideally be grouped together with the device code fields, this is the one field that a newbie might understand. If this newbie has a device (like Replay, Tivo, etc) that uses the unit code to differentiate between multiple units in the same location, the newbie might want to use this in his upgrades, and I'm not sure that it's a good idea to send him to the new tab where we've just hidden all the complicated stuff.

Greg, Mark, thoughts or suggestions?

[Mark Pierson]

I need to absorb this a little bit more, but here's some initial thoughts...

While you're right that the Protocol details are the most obscure point in JP1, they are also the most important. To me, you need to know those details before you can even start thinking about creating an upgrade.

That said, it seems to me that the most common way for people to get this info is via learning. John's decoder work has simplified things a whole bunch, though we still see newbies intimidated by it. When done properly (and a known protocol is decoded), the IR/decoder combo presents the user with everything they need.

Now, when you're talking about modifying an existing upgrade, in most (if not all) cases, the Protocol details do NOT need to be changed. In this scenario, all the user needs to do is change the Remote, possibly the Device Type, and then goto the Buttons sheet (and/or Layout tab in RM) and correct any possible button assignment problems.

I think one of the biggest problems newbies encounter is the discrepancies found in the JP1 for Beginners documentation. From both a KM and IR perspective, they're seriously outdated, and RM isn't even discussed. Also, there's no easy way for anyone to be able to figure out if an existing upgrade is available to suit their needs (correct Protocol, Device, Sub-Device, etc).

We really need to come up with an easy to follow "Getting Started" type tutorial. I know, it's gets talked about all the time, and minor steps have been taken to get it done, but it never happens. David's "self help" guide is the best effort I've seen to date, but it still needs some work.

Given all of the above, I don't see how hiding anything would help. Though, as I said, I'll have to ponder it longer.

[gfb107]

Maybe the solution is to add a wizard mode to RM, that would be used for creating new upgrades. The wizard would only ask to the user for one or two pieces of informaton on each screen, and would always include plenty of verbage to explain everything being asked.

Modifying an existing upgrade could be done using the current interface (or maybe a slightly modified one). Advanced users would also use this interface. I could even make it so that when an exisiting upgrade is opened, RM would automatically switch to the Button or Layout panel. RM has the Remote and Device Type always visible, so those can be adjusted by the user at any time.

[The Robman]

All of the info that's currently displayed and modifyable is needed when you create an upgrade, what I was talking about was aimed at people who are just using pre-existing upgrades.

The thing thatmade me think of all this was LeeSweet's mistake where he changed the EFC/OBC switch when trying to load a Replay upgrade.

I just think that the more we simplify things by hiding stuff that doesn't need to be changed, the more accessible it will all be for newbies.

Plus, some better documentation, which has been on my "to do" list for ages. While's Tommy's Beginners doc is very complete, I think it overwhelms alot of beginners.

[Nils_Ekberg]

I personally like the idea of seeing everything that can be changed however; I believe the idea of a "wizard or basic mode" is a good one since it would reduce a lot of the simple mistakes that happen. I would however; like to see it implemented like a lot of other products have, like WinZip, where you can choose to be in either mode by default at startup.

One product I like has the approach that it starts in basic mode and has an option to switch to “Advanced” mode.

Some time back there was a thread in jp1-km where we were discussing just this. The concept that was kicked around then was only showing the panels/fields that were absolutely necessary and having a pull down for advanced functions. I think a good approach would be to startup in basic mode and switch to advanced if the user either selects advanced or new.

[The Robman]

I'm envisioning an EDIT button, or something like that, were you default to a sort of "browse" mode. In this mode you can only change the remote and setup code *, which of course is all you need to change when you are using a ready made upgrade. Not only is changing the protocol and device codes not needed, it will almost definitely break the upgrade.

* Note: the Functions and Buttons sections should always be editable.

[vasqued2]

Plus, some better documentation, which has been on my "to do" list for ages. While's Tommy's Beginners doc is very complete, I think it overwhelms alot of beginners.

After I created the first draft of my Self Help guide, I also started to update Tommy's documentation. I made minor updates to the first four sections and then added a fifth section on 'Adding an Existing Device Upgrade to Your Remote' because I wanted to reference it in the Self Help guide. The purpose was to show how easy it was to use existing upgrades.

Unfortunately I didn't get through everything before I went back to work. We're in crunch time now to hit a 10/31 implementation date and I haven't had time finish my updates to Tommy's doc or update the Self Help guide based on the feedback I got.

Rob, I can send you what I have if you like or if you want me to keep banging away on it slowly I can.

David

[The Robman]

Of course. I can't guarantee that I will get to it any sooner as I'm in permanent "crunch time" mode at work myself!

[gfb107]

The only field I'm not quite sure how to deal with is the "Unit Code" field. While this should ideally be grouped together with the device code fields, this is the one field that a newbie might understand. If this newbie has a device (like Replay, Tivo, etc) that uses the unit code to differentiate between multiple units in the same location, the newbie might want to use this in his upgrades, and I'm not sure that it's a good idea to send him to the new tab where we've just hidden all the complicated stuff.

I've always wondered why there any protocols parameters other than "Unit Code" for the TiVo protocols. I imagine using any value other than the defaults for those parameters would cause the upgrade not to work. I expect the same is true for Replay, and maybe even Dishplayer. Would it make sense to eliminate the other device parameters, so that the only device parameter is Unit Code, at least for these protocols?