PTT button should look more PTT-like

[mcdermj]

PTT button is rather unremarkable. We should skin it with a background that makes it more obvious that it's for PTT. Probably rename it "PTT" instead of "TX" as well.

[richark]

Yes - I have actually hit the 'TX light' next to the button a couple times, because it wasn't obvious which was the button.

[mcdermj]

I've thought about making the TX/RX light the actual button, but I'm not sure that's the right semantic.

[richark]

So here are my random thoughts on the UI around this:

1) The TX/RX indicator lights should be separate from the actual control to operate them. There should be a 'status" section of the UI, which includes these artifacts and the status about linked/unlinked. And I love the idea of a RX light.

2) I think the reflector list should be a drop down, but you'd need to figure out a method for adding new ones that was easy to get to from the main page. (I hate the idea of 'new' as one of the drop down options). This makes the initial discovery a little hard, but once you have it populated, I think the experience works better.

3) I keep wanting to use one of my mouse buttons as the PTT. I spent five minutes trying to figure out how to-do this without modifying the app, but didn't find a easy solution. (I think Quicksilver can do it)

4) For me, having to keep pressing on the 'button' on the screen was odd. I know that is the metaphor for the PTT, but when translated to the application interface, it seemed odd. I expected to push it to talk and then push it to stop. That said, if I was using a mouse button (would actually be the right mouse button or ideally one of the couple 'extra' buttons on my trackball) I would want the normal push to talk metaphor. (Yep, I'm a crazy user)

[bhhoyer]

While we’re beating this to death. Having fn F5 for transmit doesn’t help me much compared to holding down the space bar

Saw my first location today! are you doing CALLSIGN Lookup or some network origin?

On Sep 6, 2015, at 11:30 AM, Kenny Richards notifications@github.com wrote:

So here are my random thoughts on the UI around this:

1) The TX/RX indicator lights should be separate from the actual control to operate them. There should be a 'status" section of the UI, which includes these artifacts and the status about linked/unlinked. And I love the idea of a RX light.

2) I think the reflector list should be a drop down, but you'd need to figure out a method for adding new ones that was easy to get to from the main page. (I hate the idea of 'new' as one of the drop down options). This makes the initial discovery a little hard, but once you have it populated, I think the experience works better.

3) I keep wanting to use one of my mouse buttons as the PTT. I spent five minutes trying to figure out how to-do this without modifying the app, but didn't find a easy solution. (I think Quicksilver can do it)

4) For me, having to keep pressing on the 'button' on the screen was odd. I know that is the metaphor for the PTT, but when translated to the application interface, it seemed odd. I expected to push it to talk and then push it to stop. That said, if I was using a mouse button (would actually be the right mouse button or ideally one of the couple 'extra' buttons on my trackball) I would want the normal push to talk metaphor. (Yep, I'm a crazy user)

— Reply to this email directly or view it on GitHub https://github.com/mcdermj/buster/issues/17#issuecomment-138109087.

[mcdermj]

1) There already is an RX light. The LED glows green on RX and red on TX. Just like most transceivers these days. I am tending to agree that the indicator should be separate from the control.

2) I think that's true until you think about how you implement your "linked to multiple reflectors" idea. Having a dropdown with a bunch of reflectors check marked wouldn't be a great interface methinks. And you can't just fill it with reflectors to start out with, because you have to include repeaters and there's literally thousands of them. Bryan and I have discussed this at length.

3) How are you going to run the UI with either the right or left mouse button as a TX key? I have to have some sort of heuristic to detect whether you're merely intending to click something or you want to transmit. This is the same issue as the space bar. I have to know whether you're intending to type a space in, for example, a field in the preferences panel, or whether you intend to transmit. The interface will allow you to assign the space bar. Just go to the preferences and reset it. But you won't be able to type spaces in the reflector input anymore. That being said, it's possible that there's another way to capture these keystrokes. Maybe try to glom on the window as the "last resort" sink of keypresses.

4) I actually spent a lot of time purposely NOT making it click-on/click-off because it was really awkward for me in testing. I always forgot to click it off. I actually hated that about DummyRepeater too. I still think this is the proper metaphor.

Bryan: The location does neither. The GPS location is parsed from the D-STAR stream in either of the two possible formats. It then uses the built-in OS X geocoder (see CLGeocoder) to look up their address based on the location data. It picks the City, State and Country out of that data and displays it. I could display street address, but I thought this would be creepy and unnecessary. In the latest development in the "location-services" branch you can double-click on any of the heard list entries with a location and it will open a popover window that shows a small map of their location.

[bhhoyer]

So when I see a location it was actually sent from the user’s gps data. If he sends it than you can display it, but you’re right putting an address up there is creepy vs just showing it on a map.

Bryan: The location does neither. The GPS location is parsed from the D-STAR stream in either of the two possible formats. It then uses the built-in OS X geocoder (see CLGeocoder https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLGeocoder_class/) to look up their address based on the location data. It picks the City, State and Country out of that data and displays it. I could display street address, but I thought this would be creepy and unnecessary. In the latest development in the "location-services" branch you can double-click on any of the heard list entries with a location and it will open a popover window that shows a small map of their location.

[mcdermj]

Yes, the location is derived from GPS data. It's combined with Apple's geolocation database (which is a built-in service but accesses the Internet to get the data) to get the city/state/country. For example, if I'm taking my ID51 through New York City, Buster will display "New York, New York, United States" when it receives my GPS packet.

Note, though, that the map display is as accurate as possible from the GPS coordinates, so you can zoom the map down to the street level if you want. I'm putting the final touches on this code so that I can hopefully do a pull request today to bring it into master which will make it show up in nightly builds.

[richark]

1: Yep -status separate from control.

2: So I think the drop down still works, even in the multiple reflector scanning scenario. When I want to 'connect' to a reflector the intent is different then when I want to scan. When I connect, I have a specific purpose in mine and a that drives the specific location. When I scan, it is just that, scan. So there would be a separate button to initiate the scanning. To follow the normal radio model, I would mark reflectors when they are created for being included in the scan or not.

3: You are right, the left/right clicks would be a horrible idea. But I do have 'extra mouse buttons' that should be fair game.

4: OK

I still haven't seen any GPS data come up yet. I know my 880 in the truck sends it, so I am going to try it there.

[mcdermj]

2) There is no "scanning" initiation. The capabilities are different on a real scanner and what we're doing. A real scanner has a single receiver that it has to tune to every channel sequentially. We're listening to ALL channels simultaneously. Your initial impression was correct, this is connecting to all the reflectors at once. We can only decode one audio channel, but this is more like having a VFOA/VFOB setup, except we can have VFOA-VFOZZZZZ. I think the functionality here is having multiple reflectors receiving and designating a "transmitter" that will have first crack at the audio and will be the destination when you hit the PTT button.

What I'm thinking is this. You really don't edit the reflectors once they're added to the list, so we really don't need to support the editing feature. That leaves open the double-click action to be link. So, you can double click a reflector to link to it, and double click it again to unlink. When you link it, it'll turn a green color or something to say that you're linked. In the new system, you'll be able to have multiple green reflectors. You'll still have an "add reflector" button, but it will throw up a popover window that will allow you to input a new reflector. The currently selected reflector (which I may change the selected color to red) will be the one that transmits. That's selected with a single click as default.

The problem with your "mark the reflector to be added to the scan like a normal radio" is that this isn't a function to be added at reflector add-time. It's actually going to be bandwidth intensive to do the "scan" because we'll be listening to a bunch of packets at once. We don't want to encourage people to have a bunch of sessions open at once like they would when they do it at add-time. This also pushes us towards having to have a full-on "edit" interface for the reflector entries, because you should be able to edit the entries. You also are going to have to display these setting somewhere which makes that widget a lot less simple.

If we were doing the single-reflector link in the future, I would probably think about a drop-down a lot more. Then we could just have current-linked reflector be the selected one and come up with an add interface of some sort.

[mketech]

In response to Sep 6, 2015 comment: 4) I actually spent a lot of time purposely NOT making it click-on/click-off because it was really awkward for me in testing. I always forgot to click it off. I actually hated that about DummyRepeater too. I still think this is the proper metaphor.

Perhaps a compromise can be implemented? Have you considered adding the option to 'lock' or 'toggle' the PTT button like Robin does with his DVTool app? This allows those of us that would like that option but yet not force everyone to use it that way. This would allow me to use my Mac while in a QSO instead of having to hold down a key. Thank you.

[bhhoyer]

Jeremy has a strong bias against too many knobs and switches. I generally agree with him.

The sticky PTT button however, is implemented on many radios as well as some software, clearly indicating it’s a “preference”.

I would hate a world where my left-handed friends were “left out”.

Personally I assign PTT to the spacebar cuz it’s big and at the bottom of the keypad and easy to hit. I find mousing to a button awkward.

Bryan

On Jan 16, 2016, at 6:46 AM, mketech notifications@github.com wrote:

In response to Sep 6, 2015 comment: 4) I actually spent a lot of time purposely NOT making it click-on/click-off because it was really awkward for me in testing. I always forgot to click it off. I actually hated that about DummyRepeater too. I still think this is the proper metaphor.

Perhaps a compromise can be implemented? Have you considered adding the option to 'lock' or 'toggle' the PTT button like Robin does with his DVTool app? This allows those of use that would like that option but yet not force everyone to use it that way. Thank you.

— Reply to this email directly or view it on GitHub https://github.com/mcdermj/buster/issues/17#issuecomment-172213075.