Have Other User Intefaces Been Considered ?

Over the past 15 (or thereabouts) years there have been several radios (both receivers and ham transceivers) which have used (or at least allowed) computer based (PC) user interfaces (UI).

This started with analog radios which, although they had a 'real buttons-and-knobs front panel', on the backside they had an interface that you could plug into with a computer if you wanted to. Then we had some analog radios that didn't have the buttons-and-knobs front panel (the Kachina and Ten-Tec Pegasus come-to-mind) but instead required that you interface with them through a PC UI. Then we had radios which began to use digital signal processing (DSP) and some of those off-loaded at least some of the processing to the PC and had a 'thick' inteface UI (the FLEX-5000 for one). Now we have radios which are (almost) entirely 'digital' - having co-located dedicated processing hardware (e.g. the FLEX-6000s) with a thin-EtherNet client UI used to take the place of the buttons-and-knobs that many of us grew up with (eons ago ....).

For the most part, ever since we began to move away from the physical buttons-and-knobs front panel, the PC UIs have taken their cue, on how they should look, from the previous physical front panel interfacing radios .... until the FLEX-6000 radios.

I confess .... I'm having trouble with the buttons-and-sliders on the right side of my SmartSDR UI screen .... with most of the real-estate being taken over by the panadaptor/spectrum analyzer display (I like the word Panadaptor ..... reminds me of when I was a kid - given a 1950s era Radio Products Panadaptor - got it working with my Lafayette HE-10 shortwave receiver - learning to adjust the IF amp's frequency response gave me an appreciation of critical-coupling and bandpass tuning).

I do not want to start a fuss. I'd just like to know if there are others who look at the Perseus UI (and similar) and think 'Ah ....' then the thought .... How hard would it be to use the API to build something similar for the FLEX-6000 ?

I you saw my cellphone you'd start laughing ..... 'being' a 3G phone is all that it can manage.

A good friend (ham of course) and his wife are both iPhone owners .... when I'm with them somewhere I find out which one has upgraded most recently (I should buy some Apple Stock .... its gotta' go up) .... We can be having lunch on a Saturday, or going to a hamfest, and if I innocently make the comment "I wonder ... ?" out comes the iPhone and it's 'Google-to-the-rescue'.

Paul, No thanks.If I wanted a radio "that looked like the ElecraftKX3 plugged into a FLEX-6000." I would buy it.That's why I buy Flex! No knobs in my house.Ps. I go to radio museum to see those knobs antique devices.

I always have to chuckle whenever this topic comes up, and that the comparison to the controls for a vehicle or various other mechanical types of machinery is frequently brought up.

Basically the premise being that those items have physical controls and never software only controls. And they do so because physical controls make more sense, and yes, they basically do for mechanical things like vehicles and machinery. But that notion fails to consider that those types of objects are all "touchable" physical entities to begin with. And the controls that evolved to drive them are derived from that. In the case of our radio spectrum, it is mostly in the abstract. Nobody has every physically "touched" the radio spectrum with their hands to manipulate it or otherwise control it. So knobs and buttons of our radios are not just natural extensions of existing mechanical properties of the object being controlled like the controls are for vehicles and machinery.

So basically the knobs and buttons control interfaces that have dominated radio hardware user interfaces for 100+ years now were by virtue of necessity and cost considerations, not because they were ever the "optimal" way to do it.

The SDR technology of the last 10-15 years finally provides the opportunity to cost effectively do things that are truly more optimal to get around around the radio spectrum. Our beloved waterfall and pan adapters are a big piece of that. Those who "get it" when it comes to all this SDR stuff already know this.

But there certainly is legitimate debate for how to best design the interface to allow the user to get closer to the radio spectrum itself in various scenarios. But also there isn't a single best solution, there are differing operating styles and goals, with differing operating needs. So just one user interface is not appropriate for all use cases. And yes, physical knobs and buttons control panels do also have a place for certain operating regimes.

My view is that people basically have not changed in a long (long) time. If you take a healthy human baby (at the right age for this sort of thing) and hold something bright-and-colorful in front of her-or-his face the child will reach out to grab it (and then they usually try to stick it in their mouths .... doubtless for further 'analysis'). If we had access to a baby from a thousand years ago (in good health) and ran the same test then I'm confident that the same results would be noted.

How many of us 'suffered' as we grew up being told, by those-in-charge, "don't point" ? (Is skeet-shooting an extension of pointing ? Seems likely.)

When NASA was gearing-up to send a few guys to the Moon 50 years ago what did they come up with for significant instrumentation changes ? A lot of the round gauges that populated aircraft got changed to vertical strip indicators - When the tape went 'up' the quantity was increasing .... When the tape went 'down' .... you get the idea.

What's been the big craze in aircraft instrumentation for the past 20 (or so) years ? Glass cockpits .... But have the engine throttles changed ? I don't believe so .... you still push them forward for more thrust or pull them back for less.

(Comment - several years ago I was in a western European country on business. The light switches in my hotel room were toggle switches wired so that up-was-off and down-was-on .... Gave me fits. I'll give-a-hint - the toilet was in a little room all by itself; when I first walked into the bathroom and looked around - I became concerned.)

The point is .... If something is familiar to us, and it works well, then making a change is risky as it may introduce unforeseen difficulties. (Has there ever been a major software release that was well tested beforehand ?)

Your comments about the throttle controls vs. the instrumentation in modern aircraft underscores my point. The throttles are simply extensions of doing something "physical" to the engine. Whereas most of the instrumentation provides visual representations of many things that are not inherently visible otherwise, or at least visible with the required precision.

As for the shiny objects aspect, I want the dynamically changing RF spectrum information to always be the shiny object, and for it to not be competing with the radio's UI controls for my attention :).

@ Paul. When one gets to designing things more complicated one needs to factor in psychology, neurology and many other disciplines to take into account instinctive behaviour. It is not just a matter of a designer giving the pilot a cockpit and saying 'learn it as I ain't changing anything'.

Regarding the light switch issue - that is the price you pay for being out of step with the vast majority of counties in the World (drives me nuts when I visit the USA too).

Actually when I posted my original inquiry I was thinking of a software UI that would be more in-line with other radio's UIs (e.g. the Perseus).

However .... it's interesting that you made the comment you did ..... I've actually wondered (day-dreaming ?) at the practicability of putting together a physical UI (a 'box') that would (as you described) plug into the FLEX-6000.

(Back in the late 1980s I bought a Ten-Tec Paragon Transceiver and I've always thought that it has as 'sanitary' a radio control panel as I've ever seen. And then of course there' s the National HRO-500 Receiver .... goodness they're pretty.... <g>)

Just imagine a 'box' that looked like the ElecraftKX3 plugged into a FLEX-6000.(One of the guys that I see every September at a hamfest in western Arkansas has a KX3 - the first time I saw his - it was all I could do not to call Elecraft and buy one.)

But like the K3 you really need to be EXTRA careful not to push the wrong button or hold a button too long or double click a button.. it then becomes a UI Nightmare with multiple nested menus to page thru.

Frankly I like the very clean SSDR visual interface

That said I have seen several interesting graphical UI.. for example

1. NaP3 has a really functional panadapter that shows spots and worked spots on the waterfall.... something we desperately need in SSDR.

2. the FMD-DUO UI uses different colors for different slices so you can quickly distinguish them..

I've considered this, and often joked with my local friends that I could
interface a Elecraft K3/0 Mini to work with the Signature Series via a
BeagleBone Black or Raspberry Pi translator. Now that the remote audio codec is in place, it could be made to be a seamless experience.

I actually thought
about building it but the $700 for a K3/0 Mini was more than I was
willing to spend for a novelty item I didn't really care about.

I
figured I could unveil it at Dayton and then run around Benny Hill with
both the Elecraft and the Flex people chasing me with pitchforks for
committing an act of heresy.

I was a RF/Systems Engineer (back-in-the-day) and don't have the experience to know for sure what's practical to implement in a software-based UI.

My question (roughly speaking) was wondering-aloud how difficult it would be to use the FLEX-6000 API to put together a UI that is a bit less 'innovative' (i.e. more 'traditional') than what's currently provided ?

If I don't have any serious misunderstandings about what's implemented in the FLEX-6000 hardware then I suspect (but don't know) that there's enough horsepower-under-the-hood such that a minimalist interface can be implemented without-reinventing-the-wheel.

There is already an Open API which provides the data from the radio in VITA49 format. It's up to you to decide how you want to display it... I might add that they have not currently opened up the internal Display API but I am betting that will happen too...

I remember the initial shock and a profound sense of loss, way back, when our new PDP-11/32 arrived with only a key on/off switch on the front panel.... what happened to all the toggle switches and lamps !?

I go way back before that ... We programed our computers with patch panels.. It was a miracle when we got a teletype and paper tape to load machine language code. Our computers were so slow, that if a tube burned out, I could grab it with a glove and change it out before the program lost its next step

I believe that was about when I taught myself that there was such a thing as series and parallel circuits while figuring out how to set off firecrackers electrically using the stranded steel wire in the battery powered phones that my folks bought me. (I ran the phone line from the wall in my mom's kitchen outside and up into the trees that were my imaginary 'ship' .... I 'sailed' the South Pacific from the pine trees in our backyard .... the TV show "Adventures In Paradise" was my favorite.)

I had a cousin who was a physicist who was working on the very early computers in the 1940-50's He caused me to become really interested in computers. He would let me wire up program patch panels for him which I thought was really cool.

So in 1958 thinking I was the high school computer maven, I built a 4 bit 8 tube computer for a Science Fair. My physics teacher said "Blah"... ( i stole that design from Popular Electronics)

So I built 2 - 4 bit computers and hooked them together with wire to send counts from one to the other.... My physics teacher said "Blah"

So I built a single tube transmitter and used my Mom's 1935 AM Radio, connected them to the respective computers and sent data counts wirelessly over the air between them.

My physics teacher said "Amazing...But it's illegal"...

"Why?" I said, He said; "You need a Ham License to use that transmitter"

"What's a Ham License?" I said

I got a Ham License, won the Science Fair which got me far too young admission into engineering college and the rest is history.

When people comment about how difficult it was to program computers with toggle switches, etc. and how nothing much could be done with such simple programming, I am reminded how they had to reprogram the computers on the LEM and Command Modules in the Apollo program. It must have been a nightmare reprogramming the things on Apollo 13 in order to bring the guys back safely!I don't remember how many lines of code they had to enter in HEX with a simple numeric keypad.....I have seen the documentaries, and all of that "modern" technology looks so ancient to us now!

Myself... I began programming in the late 70's on punch cards and FORTRAN. Then moved to various forms of basic. I have dabbled a little bit with "Processing" a derivative of JAVA in order to customize two different MIDI Controllers for my 6500, based upon the excellent work that William is doing. I have gotten stalled right now, trying to get my tower and LP in the air. But then I hope to finish some more elaborate stuff with the MIDI controllers and API functions. I have the theory in my head, just don't have the time to do it yet.

I still haven't wrapped my head around the transition to "object" level programming vs the linear logic of subroutines, IF/THEN/ELSE, DO Loops, and such that were the mainstay of programming when I was in college. At present, I know enough to vaguely follow what people are discussing, and perhaps take a few ideas and implement them as variations, but couldn't do much of it myself from scratch....yet.....I am a fast learner!

In the subject of "interfaces" my opinion is that there many, if not most functions that are easier and more efficient using the type of interface provided in SSDR right now. But there are others, such as tuning frequencies rapidly during a contest or searching for DX that seem to work better when there is some physical feedback, such as in a weighted tuning knob, where it is easier to control not only the amount of change but the speed of it at the same time.

The same thing is true when driving a car. My dad had a mercury back in the day that I absolutely hated to drive because its power steering was "too powerful." i.e. it gave me absolutely NO tactile feedback from the road. I felt so isolated from the road that my hands couldn't keep good control of the car.... It weaved back and forth because every slight fidget was translated into movement on the road. My other car, on the other hand, had some mechanical feedback that gave pressure back to my hand and let me know when I was applying turning pressure to the wheel. This was very important. It was an issue that many automotive engineers had to put into their designs when they developed the "drive by wire" systems using electrically operated steering motors linked to a wheel with no actual physical connection to the steering train.

On the SDR, there are still several functions that are much more convenient to activate on my MIDI panel without losing focus on the computer screen, rather than mousing around looking for the correct menu to drop and click. But that is the beauty of SDR...I can design a MIDI interface, or others can design one for their iPad or Android and lay it out exactly the way we want it... the best of both worlds!It is a great time to be a ham......

When people comment about how difficult it was to program computers with toggle switches, etc. and how nothing much could be done with such simple programming, I am reminded how they had to reprogram the computers on the LEM and Command Modules in the Apollo program. It must have been a nightmare reprogramming the things on Apollo 13 in order to bring the guys back safely!I don't remember how many lines of code they had to enter in HEX with a simple numeric keypad.....I have seen the documentaries, and all of that "modern" technology looks so ancient to us now!

Myself... I began programming in the late 70's on punch cards and FORTRAN. Then moved to various forms of basic. I have dabbled a little bit with "Processing" a derivative of JAVA in order to customize two different MIDI Controllers for my 6500, based upon the excellent work that William is doing. I have gotten stalled right now, trying to get my tower and LP in the air. But then I hope to finish some more elaborate stuff with the MIDI controllers and API functions. I have the theory in my head, just don't have the time to do it yet.

I still haven't wrapped my head around the transition to "object" level programming vs the linear logic of subroutines, IF/THEN/ELSE, DO Loops, and such that were the mainstay of programming when I was in college. At present, I know enough to vaguely follow what people are discussing, and perhaps take a few ideas and implement them as variations, but couldn't do much of it myself from scratch....yet.....I am a fast learner!

In the subject of "interfaces" my opinion is that there many, if not most functions that are easier and more efficient using the type of interface provided in SSDR right now. But there are others, such as tuning frequencies rapidly during a contest or searching for DX that seem to work better when there is some physical feedback, such as in a weighted tuning knob, where it is easier to control not only the amount of change but the speed of it at the same time.

The same thing is true when driving a car. My dad had a mercury back in the day that I absolutely hated to drive because its power steering was "too powerful." i.e. it gave me absolutely NO tactile feedback from the road. I felt so isolated from the road that my hands couldn't keep good control of the car.... It weaved back and forth because every slight fidget was translated into movement on the road. My other car, on the other hand, had some mechanical feedback that gave pressure back to my hand and let me know when I was applying turning pressure to the wheel. This was very important. It was an issue that many automotive engineers had to put into their designs when they developed the "drive by wire" systems using electrically operated steering motors linked to a wheel with no actual physical connection to the steering train.

On the SDR, there are still several functions that are much more convenient to activate on my MIDI panel without losing focus on the computer screen, rather than mousing around looking for the correct menu to drop and click. But that is the beauty of SDR...I can design a MIDI interface, or others can design one for their iPad or Android and lay it out exactly the way we want it... the best of both worlds!It is a great time to be a ham......

Technically the LM was not programmed with toggle switches -- its program was hard-wired into core memory. However certain trajectory variables involving subtle forces (light pressure, etc) could not be modeled far in advance and these were uplinked via telemetry during the mission. As a contingency if communications were lost, lists of these variables and state data were periodically read up to the astronauts, who could enter them by hand using the DSKY keypad (not toggle switches): http://www.ohiocityproductions.com/kscvisit.com/art/apollo-AGC-pad.png

The Apollo Guidance Computer had about 72 kilobytes of core memory, 4k of re-writable memory, and a memory cycle time of 11.7 microseconds, equating to roughly 85,000 instructions per second. The production AGC was wire-wrapped: http://www.ibiblio.org/apollo/AgcWirewrappedBackplane.jpg

However, running mostly assembly language it was capable of fly-by-wire real time control of the vehicle, plus navigation, monitoring of instruments and driving numeric displays. No Apollo guidance computer ever crashed during a mission, although during the Apollo 11 lunar descent it almost did. I did a custom edit combining various NASA audio files of the Apollo 11 descent which emphasized the decision making on the computer problem. Most people have never heard this. It and my transcript were posted here: http://forum.nasaspaceflight.com/index.php?topic=35230.msg1229852#msg1229852

It may be interesting to those working with critical real-time or embedded software systems.

Yes, I remember hearing the 1201 overrun error (or something like that) and the last minute reset that got things back on line seconds before an abort was required. I also remember that they almost ran out of fuel in the descent engine. Of course I was only 5 years old back then, but my little brother and I were more versed in things Apollo than many of the newscasters appeared to be. (in a 5 year old mind!)

I have seen footage of them using the DSKY pad. memories, memories....

Stu would obviously be the best person to ask but my understanding is Stu wrote a contest centric UI. Which is actually smart. If all you want to do is work a contest, you don't want all the fru fru stuff muddying up the water vs. laser focused on the one goal fast efficient contesting.

When I originally saw the term MIDI in the FLEX forums I remembered years ago when people were creating really clunky sounding imitations of piano music (or Stars-And-Stripes-Forever via MIDI; shudder) .... I was not 'current' and did not realize that the MIDI interface has spawned several physical interface 'boxes' .... now I see the attraction.

(True Confession - I still think it'd be neat to put a 'thin-box' together that looked something like the Ten-Tec Paragon's front panel but with a circuit board behind it that interfaced with the physical front-panel controls and then provided the data interface back to the FLEX Radio.)

Paul, I have had that idea for quite some time. But, I have planned to use an old Drake rig I have sitting here that has so many internal problems, that it is beyond salvage. BUT, the case looks nice and all the controls and knobs are there. So, finding a way to interface the controls to an Arduno or even one of the NUC computer modules, and using that as a remote control to SSDR, or even another stand alone app to control the radio, would be a fun project. Just not near enough time to do it. Not to mention all my boatanchor friends would disown me!jamesWD5GWY

While I admire your inventive-ness (I have my R-4B in the closet), do you think perhaps that we are straying perhaps a bit far afield .... from reality ? (I'm beginning to imagine John Cleese in one of his skits working on something like this ('The Bureau Of Funny Control Panels ?') ..... or perhaps a famous canine from that side of the pond ?)

Only a bit :-) But, it can be done and would be different!But, straying from reality? Not really. Hardware is there, just requires hooking up all the correct parts and writing some software to go with it. And, it's better than throwing away an old rig that still looks good.jamesWD5GWY

See the circular viewport in front of Gromit ? Remember the picturesof the round CRTs at Palo Alto Research Center ('PARC') in the 1960's ?We could slip one of babies in there - at convenient eye level.(This could be the new human interface radio control panel design mantra !)

(What was it that the guy said when asked why he wanted to climb Mt Everest ..... "because it is there.")

re> your comment "it's better than throwing away an old rig that still looks good."

You give me hope .... It almost broke-my-heart when I read that theNational HRO-500 Receiver wasn't-all-that-hot as regards dynamicrange (its bipolar transistors are somewhat prone to overloading) ....

@Robert: you hit the target talking about "Software defined knobs". I think we only need some kind of K3-0 device with open programming APIs. I don't think we need more buttons: if only SSDR would give detachable panels we could position all controls in a very simple touchscreen display and position a panafall for each other big monitor.

@James: I am going on with my arduino projects and now I have programmed most of the SSDR controls. The ones I prefer are the two dedicated knob for filter bandwidth: they can work in HI/LOW or SHIFT/WIDTH mode; you can toggle between with a short click on any of the two knobs and you can reset (normalize) filter bandwidth (400HZ CW, 2400Hz SSB) with a long click. It is the same behaviour you can find in a K3 rig and I think it is the best I ever found. You can use it without having to look at the monitor nor to deal with mouse. Simple use it while you are looking signals on the panadaptor.This part of my code is still not very stable, but there is a part of it, that give you the opportunity to program your own knobs and that works fine. You will find my libraries at this link https://community.flexradio.com/flexradio/topics/arduino-library-and-examples.

@Robert: you hit the target talking about "Software defined knobs". I think we only need some kind of K3-0 device with open programming APIs. I don't think we need more buttons: if only SSDR would give detachable panels we could position all controls in a very simple touchscreen display and position a panafall for each other big monitor.

@James: I am going on with my arduino projects and now I have programmed most of the SSDR controls. The ones I prefer are the two dedicated knob for filter bandwidth: they can work in HI/LOW or SHIFT/WIDTH mode; you can toggle between with a short click on any of the two knobs and you can reset (normalize) filter bandwidth (400HZ CW, 2400Hz SSB) with a long click. It is the same behaviour you can find in a K3 rig and I think it is the best I ever found. You can use it without having to look at the monitor nor to deal with mouse. Simple use it while you are looking signals on the panadaptor.This part of my code is still not very stable, but there is a part of it, that give you the opportunity to program your own knobs and that works fine. You will find my libraries at this link https://community.flexradio.com/flexradio/topics/arduino-library-and-examples.

Thank you Enzo! I have downloaded your libraries. I do appreciate all your hard work. I have thought of using different devices as a control surface for SSDR and the idea I have for recycling an old transceiver keeps coming back to me. It would be a fun project in my mind. And using something like an Arduno to interface the controls on the old radio to my computer would be a challenge but, doable.Thanks again. jamesWD5GWY

Well, there is the work William is doing. What I am doing is a new and replacement for the FRS FlexLib. The UI will be runnable everywhere and take the best parts, well, what I perceive as the best parts of the SSDR plus some missing features. After that process is complete I will create an HTTP based UI That will be markedly different. While some like the panadapter concept it is too married to the single application model. I will be removing that restriction and, indeed, making both the spectrum display and waterfall option. There is no reason why a smartphone display would not suffice to adequately handle a qso, spot to log entry.

Is it feasible to implement a FLEX UI under LINUX, and by virtue of that have it functional on both native LINUX boxes as well as under OSX (a friend, another ham, tells me that he has had reasonable success at porting LINUX applications to run under OSX) ?

I believe that it is correct to say that anytime a software application is run under an OS other than what it's native to .... that processing speed suffers .... but I've been reading that there are people who believe that PC hardware is now fast enough to allow running virtual OSs for everything (multiple OS 'windows' all open on the same PC desktop ?).

Paul, that is, what you just said, the necessity, being the mother of the invention. Yes, my primary goal is to have a smarter SSDR running on Linux. As it happens, it will also run on Mac and Windows and Raspberry Pi. In theory, it should work on Android but there are other things I plan for Android so it may get a unique UI and even more unique features.

Your second paragraph is kind of wrong, well, depending on what you really meant. If you are strictly talking about Parallels or KVM or VMWare, it depends. KVM, of which I know the most actually, depending on the app, could run faster in a virtual machine. I am not doing a virtual machine implementation, these will be native apps and, absolutely, run faster than a virtualized Windows environment running SDR. There is a real world case where rather than buy every employee their own machine, they get a virtual version of what that machine would be running. It's called virtual desktop Infrastructure. That provides way better security and cost structures to companies. You've likely heard a lot about 'the cloud'. That is, essentially, what in a business environment you are talking about. There is about a 10:1 ratio between a host machine and the number of virtual machines it can support. When you talk about something just a degree or two away from that, 'containers' there is a 100:1 ratio. However, what I am doing won't require virtualization. It is a single app that will natively run on Linux and many other platforms, even Windows. Having said all that, the one can I have, to date, kicked down the road is DAX / virtual audio channels. At this moment I do not know how to create a virtual device in Linux. It's not an impossible task, just not one I taken on as yet. The other issue is DAX is used to logically connect HRD or CW Skimmer to SSDR. Where they are all Windows applications connecting to them from not Windows is problematic. However, the better design is to connect to other apps through UDP/IP, which is how the IF data gets to SSDR to begin with. Why convert that to an OS audio device just to have it converted back to raw data. I believe FRS is resolving this problem. What I am doing will directly handle spotting, logging, and LOTW uploading. I don't mean, necessarily, one gigundo application. As part of this effort I will spawn off service endpoints, singularly focused services with a discrete internet address and requests will be made to it. It will be blindingly fast.

As far as what your friend said, yes, one can port a C or C++ program from Linux to Mac. There are other languages where no port is required. In the case of S(er)SDR the only difference between the versions, Linux and Mac, will effectively be the GUI itself will look more like Mac apps and not Window or Linux apps. But beneath the appearance will be identical code. This will be very exciting.

I am using the Behringer interface. It's not that I miss buttons and knobs - I don't. It's just a fact of Windows life that you need focus. When operating a contest, or split DX pileups, having instant access to functions is a real advantage.

WB5AGF: "...ever since we began to move away from the physical buttons-and-knobs front panel, the PC UIs have taken their cue, on how they should look, from the previous physical front panel interfacing radios .... until the FLEX-6000 radios."

There is actually a furious debate within the UI design community about this exact topic. Namely whether real-world shapes, textures, indicators and controls should be slavishly replicated in the computer UI. Those are called skeuomorphs, and the new approach is called "non-skeuomorphic design".

The Perseus UI and other discussed knob radio computer UIs are skeuomorphic. SmartSDR is a step toward non-skeuomorphism. I don't know if this was a formal intent by the designers but that was the result.

The older skeuomorphic approach often uses screen real estate for essentially decorative elements. These are disparagingly referred to as "chrome" by the non-skeuomorphs.

There are stronger and weaker forms of non-skeuomorphic design. A weaker form might be "let's not blindly replicate real-world UI elements if we can think of a better way". A strong form might be: "every real-world shape and texture must go, absolutely no color gradients, no drop shadows, no chrome of any kind." It is sometimes called the "flat look" UI. Microsoft and Apple are both moving their UIs in that direction.

OTOH the non-skeumorphs produced the flat, tiled Windows 8 UI. In their zeal to jettison all chrome, gradients and drop shadows, they have sometimes produced UIs which are non-intuitive, hard to read, and difficult to use.

I personally like the SmartSDR interface, even though it's not perfect. It feels uncluttered, clean and fresh, and puts the big panafall display front and center. If only they'd implement hotkey commands for common controls, you could operate it with all the controls minimized and off screen.

I also like the SSDR interface on the whole. It is, however, riddled with minor inconsistencies and annoyances. Once 1.5 is out of the door, I would like to see the release after that to address the UI.

In that regard, that would be an outstanding move for FRS to undertake. Move away from the single monolithic fat client app. In other words, 1) have each pan be a child of the desktop not a child of the HWND_MAIN (app). Right now the main app is, for lack of a better word, using a border layout, there is are the buttons, BAND, DAX, etc on the left, the VBox on the right, menu across the top and whatever on the bottom. What takes up the most real estate is the pan in the center. If a user could move that off to another window the main app real estate reduces dramatically. 2) In the tabbed VBox on the right, using a small form like a laptop not all the dialog boxes are visible, in order to get to EQ I have to close several others. They should be scrollable. Or, ideally, let the user put the pan and the TX dialog in front of him and the others off line of sight.

We actually had a lengthy discussion about skeuomorphism when we started work on the interface. Apple had started down this path several years ago as did many others, but the thinking in the industry (software/UI) was leaning away from these types of interfaces. Apple is a perfect example as they altered out most of the skeuomorphic elements of their applications as time moved forward. I think for Apple, most of these elements are gone.

I actually like skeuomorphic design, but one issue with it is that it tends to be a fashion-style thing. What looks good today will look tired tomorrow. Also the skeuomorphic elements I may like might remind you of something you really dislike. For example, I might make a Collins looking knob and lots of folks might like it, but someone with a Collins that didn't work well for them (ok bad example) might dislike the trip down memory lane. In the early SmartSDR days we talked about it on and off for a couple of weeks and decided to go with simple design elements with an emphasis on trying to provide an intuitive and clear interface.

I have never been a fan of skeuomorphic software UI designs at all. All too often they severely constrain the usability of the software by making the user try to use a "picture" of a physical object on a computer screen that in reality cannot actually be physically touched and manipulated. And to then attempt to control it using a proxy device such as a mouse and mouse pointer. Horribly inefficient, and not user friendly at all.

Clear back in circa 1997 Kachina did seem to basically understand this with the UI they had for the 505. They made no attempt to draw circular knobs at all. And the control panel that they designed wasn't just a picture of a traditional radio on a computer screen. Though the UI certainly could have been improved upon. But for what was arguably one of the first efforts in this area, they did actually do a pretty good job of it.

It's an interesting subject. I can say that Google and Oracle are not abandoning the 3D look and feel. No, they don't simulate wood grain or rich Corinthian leather but subtle raised buttons with recessed labels, Android's Material look. Background that are, rather than white or light blue have a subtle linen texture. Very subtle stuff, just not boring Windows API buttons boxes and labels, ala 1989.Isn't Microsoft's new Word doing an open book look and feel with 'pages' that can be 3d flipped and have real dogear page corners?

Good discussion. A really interesting frontier is to shift toward activity-specific interfaces and away from mapping buttons to hardware features. With the APIs it's pretty easy to purpose-build interfaces for contesting, DXing, digital or whatever you like. You can interact with them on a computer or tablet screen or on 3rd-party control surfaces.

Simple example: why would a contest interface offer you a WARC band - or a band you don't have an antenna for? Better example: a pan showing an entire band with a fast tune knob and a second gang-tuned pan showing +/- 10 or 20 khz centered around a cursor with a slow tune knob. This is about an hour of coding in the FlexLib API once you've built the frameworks.

I've been wondering if it's feasible to put a UI together that would provide graphic appearances of all commonly accessed radio controls and that, as part of the configuration process, you then selected how many of those appearances you wanted and where they went on the UI screen ?

I can't remember which one but back about 20 years ago there was a very high-end ham radio transceiver that had so many controls on the front panel that, the one time I got to use one, I had trouble finding the receiver volume control.

Many years before that there were some ham transmitters (the Hammarlund HX-Fifty and the Central Electronics 100V & 200V) that had little swing-open doors on the front panel that covered controls that were mostly set-and-forget.

I like the idea of being able to put the set-and-forget controls out-of-the-way so that the remaining screen real estate can be used for the controls that get constantly adjusted.

N9DG: "I have never been a fan of skeuomorphic software UI designs at all. All too often they severely constrain the usability of the software by making the user try to use a "picture" of a physical object on a computer screen that in reality cannot actually be physically touched and manipulated."

Yes, that is one argument against skeuomorphic design. There have certainly been mindless excesses: e.g, graphical leather stitching on the Apple calendar which conveys no purpose. Likewise complaints were raised (from designers, not customers) about the iPod player app modeled on a reel-to-reel tape deck. They said most people haven't even seen a tape reel, using that as a metaphor is anachronistic.

That said, the reel-to-reel metaphor worked very well. It instantly communicated visually what the app was, what speed it was running, whether rewinding or playing, etc. By contrast the non-skeuomorphic replacement takes longer to visually grasp, and the stripped-out drop shadows makes it unclear what is a pushable button vs what is not. In essence it is a digital speedometer vs an analog gauge: http://www.kammcs.com/img/podcast.jpg

The very desktop metaphor of computer UIs is by definition skeuomorphic -- folders, trash cans, etc. These were chosen to rapidly convey function to users, so they don't waste time blundering around an unfamiliar interface.As in all debates there is a logical reason to non-skeuomorphism. In a properly-designed UI, users may no longer require the visual hand-holding of a real-world metaphor. Cutting the shackles to that can free the designer to produce a "digitally authentic" interface which is (theoretically) more effective.

However -- in reality anti-skeuomorphism has produced interfaces which many users find sterile, unfamiliar, puzzling, ugly and (worst of all) inefficient. This design trend has ironically materialized at the very time hardware and software are more capable than ever of showing helpful gradients, textures, etc with little to no performance penalty.

The chief UI designers at Apple and other companies pay lip service to Bauhaus design, which says "form follows function". However their actual implementation of flat UI design often repudiates this. It prioritizes form (the flat non-skeuomorphic look) over function (readability & intuitive elements). In essence, it is a new version of the much-maligned "chrome", no different than other fads of the past like automotive tail fins. It reality it is "chromeless chrome", non-functional flat design elements which adhere to an austere UI doctrine, yet interfere with and obscure the underlying function.

When I speak of Software defined knobs I am not thinking of skeuomorphism. In fact I would rather see the computer UI designed around the available input devices for the computer.

When I think of Software defined knobs I am thinking of knobs that can be configured to the taste of the user. Having such knobs can be a great enhancement to the existing user interface. It doesn't have to be a knobs or no knobs world. Such an interface is useful not only for contesting, but can be used as an interface when you are on battery power.

Flex Radio can continue to provide the world-class interface as they are doing and we can add our own knobs as we see fit using the provided API.

One of the things that I personally find about skeuomorphic designs is that they are generally distracting to what I'm actually wanting to do with the software. My mind has to process and then summarily ignore all of the visual "detail" of say something like a button graphic, its glossy texture, its embedded LED, and all the various other treatments done to it that seek to make it look like a real physical button. Then multiply that mental effort by a whole screen full of them. Same story for the panadapter window having the look of a room light shining on it.

Adding the look of a glossy surface to the spectrum display area to emulate the look of a light shining on it is also distracting. It is simply built-in visual QRM, and is the visual equivalent of adding a tone or some other kind of non-radio spectrum audio to the radio's audio output just because. When I look at the panadapter / waterfall I want to see nothing but a
graphical representation of the otherwise not visible and abstract radio
spectrum. And nothing else.

When the "Pretty Betty" graphics came out for PowerSDR awhile ago I did not like any of them, not a one. So I simply created my own set of graphics, they certainly won't win any awards for their artistic qualities. But I sought to make them be very clear, and to have very clear edge definition. The various button looks of the available default choices in PowerSDR with all their polished graphic treatments were all tossed. All of that graphic polish to make them to make look like "real" objects, also made the whole UI look like "mush" to me, everything on the UI screen sort of just ran together. My brain had spend considerable energy trying to ignore all of the UI controls graphic details that made them look like physical objects.

So for example with my customized PowerSDR skin, when a button is clicked on, the entire button turns green, not just a simulated LED in the middle of it. Some treatments were necessary to enhance the clarity of the edge boundaries between the buttons etc., but that was basically it.

Bottom line is for me I want to see "radio", the otherwise not visible RF spectrum, not the "radio hardware". And ideally, would love to get to the point where when I'm operating the radio's UI, that it is almost as if the UI isn't even there at all. But the whole notion of skeuomorphic radio UIs is the exact opposite of that, they deliberately seek to have you see and focus on the radio "hardware", so in that kind of UI the radio spectrum presentation provided by the panadapter / waterfall area then becomes secondary.

Again, I want to stress there is no single UI that is right for everyone, and every use case. That's beauty of SDR, there can be a multitude of designs. And the UI design choices to drive the radio hardware no longer need to be mutually exclusive of each other. The radio hardware can accommodate them all.

Maybe User Interfaces should be left up to the User. User created UI. I'd like to be able to flip the 0's to 1's by just wishing for the change, I'd also wish that my mind was capable of keeping track of which 0 needs to be flipped. Till then I'll settle for whatever interface is provided and adapt to that.

One thing I've learned over the last two years is this forum is filled with people unable to be happy. They aren't happy with the company.They aren't happy with the software.They aren't happy with the software update cycle.They aren't happy with not knowing what the company employees are working on.They aren't happy with not knowing when software will be released.They aren't happy not knowing their pet wish, right behind that pony, may or may not be coming.They aren't happy knowing their pet wish, right behind the pony won't be coming.They aren't happy knowing their pet wish, right behind the pony will be coming.They aren't happy with the software appearance.They aren't happy with the software behavior.

Maybe what it all comes down to is this forum is full of people unhappy with themselves, therefore, they can't be happy with anything else.

DDUTIL already supports a user programmable physical interface, actually 2 of them. One is the FlexControl and one is the Genovation keypad. The FlexControl allows control of several slider funcions as well as up to 12 push button macros. The Genovation keypad allows up to 48 individually programmable buttons which execute specific macro functions. The macro functions are stackable and can be very complex. Many macro functions can also control slider values. The can also be toggled. When I push NB, the NB turns on and it sets the slider to the value I use most for my specific noise situation, and it does it for both slices. The command looks like this:

DD6NBK0:1;DD6NBK1:1;DD6NBG0:080;DD6NBG1:080;

It turns on NB0 and NB1 and sets both sliders to 80. One button press. I have this on a toggle so If I press the button again NB shuts off

Tune is like this

Tune on DD6TXL0:0;DD6TXT1;Tune off DD6TXT0;DD6TXL0:1;ZZXS0;

Tune on: turns off TX key line and turns on tune at whatever power is set on the front panelTune off: turns off tune and then resets the key line. This way I can tune my automatic antenna tuner with one button press through the amp and my tuner never see high power and I never have to switch off my amp to tune

I have another button XIT+2 that turns on the XIT and sets it to +2khz

ZZXS1;ZZXG+02000;

another button press clears and cancels XIT

ZZXS0;

You also see ZZXSO; in tune off. So if I'm going to tune up on a QSO and its clear above I first hit XIT+2 and then tune on and tune 2 khz up the band. When I hit tune off the ZZXSO; command also cancels XIT. I have some very complex macros that do many things to configure the radio exactly how I like it for given situations all with one button press. For example you can make the entire sequence to go from SSB to AFSK entirely automatic including setting and centering RTTY filters, one button.

Another advantage of this is the keypad is always in focus, which neans I can be looking at a browser and hit the NB button and NB snaps to attention without changing focus. I have macros for record on/off playback on/off I can set the pan in both slices one to the left eat the other to the right exactly as I like it, one button press.

If you don't have a Genovation but you do have a FlexControl you can create up to 9 of these custom macros for your enjoyment and the FlexContol is also independent of focus, but you have to attach your FlexControl to DDUTIL and shut off FlexControl in SSDR to get that to work.

So here is another user interface available today that is very powerful. Much of what you do with a slider is actually a set value so using a macro to set the slider is often more than adequate. It also showcases the incredible power that Flex has given us for customization of our radio thrugh the API. Steve K5FR has spent mucho time bringing much of the API functionality to those of us who can't or do not have enough experience to roll your own

I would like to know how many people here are able to do fine control tuning using a skeuomorph GUI control.When I work a DX I often have to do fine tuning of filter BW, AGT-T and Slice Volume controls.Using my fingers, in a touch screen scenario, has the effect to move the control far beyond the desired level while using the mouse, in the standard SSDR usage, forces my attention to the GUI controls and not to my main DX listening activity.During contests the issue is very similar.I did a lot of tests in this way and I found that "six" is the minimal number of knobs that can transform a usable GUI in a user friendly GUI.There will be some reason if in the newest BMW cars (just to say one) steering wheel, gear shift and other basic controls are still there.I would like to see in the next future a Flex Control like device with a Main Knob and a bunch of programmable knobs. The best would be a SmartSDR-API extension offering support for such a device. It would be a great companion also in "remote" usage.