Elgato Stream Deck Support As A Hard Button Remote Option?

Hello, still me here looking for hard button remote options. Been a couple years since I asked about more advanced REST API support, but it doesn’t look like that is a priority for the team.

I have recently discovered Stream Deck devices. In particular I have purchased a Stream Deck +, which includes eight assignable push buttons, four multi-level assignable dials, and a touch screen.

Stream Deck + | Elgato

There is a lot of market uptake of their products, and they have a flourishing plugin market.

I am sure you can see how this could be a great hard button remote at an affordable price. It can work through one of the existing HTTP API call plugins, or a custom Roomie plugin could be created if you were so inclined. The only downside is it requires Windows or Mac to connect to via USB. This is disappointing, but at least on the Windows side it could be solved inexpensively with a Raspberry Pi.

That device is dramatically unappealing to me. But anyway, just my opinion. The USB issue with it is laughable. I remain 100% a user of apps for controlling everything and am mystified (probably more so as each year goes by) at the occasional user that seems to have bought into the idea of a multi button device that offers so much less. But regardless, we offer the Harmony integration that still works great for such cases if needed and certainly seems like a superior solution to the device in your post.

Broadly, don’t know what you’re asking here and don’t recall offhand whatever feature you wanted for the REST API (not mentioned in your post) and I assume that is the real point of your post. The way to request features is to post them (once) in the Features forum. The way to enhance support for said feature is to click the like icon at the bottom of such a post.

Hello Will. Thanks for the reply.

The ask of this post is nothing more than a continuation of my advocacy for better hard button remote options in Roomie.

Over the years I have made a variety of suggestions from the very, very simple to the very costly:

  • Expose to the user community the APIs you already have in place to support Alexa (pause, play, volume, etc.). Let the users figure out how they incorporate these APIs into their systems to get hard button remote support.
  • Add support for inexpensive Bluetooth media remotes that are well-supported in iOS.
  • Let’s partner on building a WiFi remote control similar to what is available from Control4 and URC.

This post was just one more possible option. I guess my specific ask for this piece of hardware would be for Roomie to write a plugin for the Sound Deck catalog. I also mentioned REST API here since that would be much easier for your team and would also work with this device if writing a plugin was out of the question - as it seems to be based on your reply.

About two years ago you ran a poll asking what the most desired use features were. The second most desired feature was better hard button remote support. Something like 40% of users wanted that. I believe that was pre-Harmony integration, so you probably did solve some user’s needs when you introduced that feature. But I wonder what the percentage would be now if you ran that poll again and simply asked “would you like better hard button support in Roomie, or are you happy with it as is?”

The Harmony feature is probably the best option Roomie offers, but it has numerous downsides:

  • It only works for people with an investment in Harmony
  • People who didn’t have an investment in Harmony are out of luck since the product is no longer produced so, outside of used equipment, a new investment is not even possible
  • Harmony is an entire second system to maintain. Roomie only offers activity synching. Devices that are desired on the Harmony remotes have to be maintained in both Harmony and Roomie.

I have tried on several occasions to demystify for you why hard button remotes are - in the opinion of some of your users - better than an app for certain activities:

  • It’s faster to perform frequent functions like volume control, muting, pause, play, and shuttle with a hard button remote. There is a physical, tactile device that you can grab without looking and rely on muscle memory to carry out the controls that represent 80% of what most users do with their systems. Please note I have your suggested ideal configuration in my theater: Roomie running on an always-on dedicated device (iPad) with the app in the foreground and I still find it much, much faster to pause and control volume with a physical hard button remote.
  • Wives, kids, and guests have a much higher uptake of physical hard button remotes than an app. Every person in a first world country knows how to use a physical hard button remote. And it is natural for them. As beautiful as Roomie is there is still a learning curve.
  • The ideal Roomie configuration - a dedicated device with Roomie running in the foreground and plugged into power - adds up pretty quickly in price even if buying the lowest cost iOS device. In my house I would need about 8 dedicated iOS devices to have ideal coverage (2 users in three viewing rooms, 1 guest user device, 1 “whole house” device to control things like whole house audio, lighting, etc.)

None of this takes away from the greatness and beauty of Roomie. I see a good hard button option as something that extends and adds value to Roomie and would make it even better.

As for your opinion that this device is “dramatically unappealing” to you. Is it really any worse than game controllers and Pico remotes?

The device - and they have a variety of models - is widely praised by a large user community. Their Reddit forum gets dozens of new topics each day with active responses from the community and the company. They have hundreds of plugins available. They must be doing something right.

Of course, home theater is not their primary target use case, so I totally agree with you that Roomie is superior in many, many ways for the home theater use case. But I do see value in something like this being able to interact - not replace - Roomie. As I indicated in the OP the USB requirement is pretty lame. But I can still see a “one wire” solution for it that isn’t any uglier than a “one wire” Roomie solution.

Honestly, I don’t really care how it gets solved. I am just asking for some better hard button options that meet some of the concerns and needs I have outlined above - and that I have explained in numerous ways for years here.

Thanks for the consideration.

1 Like

Hard button remote is almost a must have for kids, wife’s, guests etc…for those who have Harmony are in luck as long as the h/w works and they keep the server live, for new users and sooner or later we all will feel the compelling need for a hard remote support. But then it’s not up to RR, there is a need for a good remote and an open API for RR to sync with…appeal to forum members is to suggest most popular hard Remote out in the market and willingness to work with RR


Here is one that comes the closest

I’ve tried a Sofabaton, it’s okay but pretty limited in functionality when it comes to any kind of custom IP devices. It’s more of a Harmony replacement and designed primarily for IR control, IMO. There is another remote on Kickstarter that I have hopes for, but they’re very late getting the product to market. I hope to have one by mid-May and will report back at that time. The one has a real, programmable API that could make it easier to integrate with Roomie. https://www.kickstarter.com/projects/marton/remote-two/posts/3754887?ref=ksr_email_backer_project_update_registered_users

My wife and I are both comfortable using the iPad for most things but I can tell you that for device set-up, password entry, and search functionality, I often get out the device hard remote because it is just so much easier to operate in a dark theater while trying to navigate an on-screen menu or virtual keyboard.

But I wonder what the percentage would be now if you ran that poll again and simply asked “would you like better hard button support in Roomie, or are you happy with it as is?”

Seems like a rat race. At some point (begin analogy that I will use throughout this message), I’m starting to believe there are people for whom combustion engine cars will simply be what they buy for the rest of their life and no amount of sitting in a Tesla and seeing how much better it is will matter. They will vaguely mention things like feeling the engine and some kind of classic look and that’s as far as the discussion goes.

I don’t know what I can do about those people. Every year or two we add some kind of hard button remote feature and then every year or two the same people come around and talk about it again even soon after we add the biggest and most important one ever in our Harmony integration. So it’s not like we have not tried, but I’m obviously just not able to satisfy that group so I’m not sure it’s worth trying anymore.

We’re an app that has moved beyond that kind of stuff. The argument that goes “Hard button remote is almost a must have for kids, wife’s, guests etc” makes no sense. We handled those concerns ages ago. The app is now free so Guests can download it. Anyone with an iPhone can use Instant Home Sharing to control things in literally under a minute you can go from “I’ve never seen this app” to installed and controlling a home. The only rub is that you trade off some tactile feel of a channel button in return for a huge litany of features like Media Guides, gesture control, voice control, and countless others not possible or imaged with hard button remotes. Volume control has hard buttons on the iPhone.

As beautiful as Roomie is there is still a learning curve

I’ve used countless hard button remotes and it is safe to say there is a learning curve to each of them equal to or greater than Roomie.

Roomie running on an always-on dedicated device (iPad) with the app in the foreground and I still find it much, much faster to pause and control volume with a physical hard button remote

Something isn’t right with the analysis or the specific device you’re using then. The volume dial is invariably superior to holding down or up on a hard button imo. Perhaps it’s an ergonomic issue in your case, a stand issue, brightness, etc. Lots of factors here, but the generic claim doesn’t translate.

The ideal Roomie configuration - a dedicated device with Roomie running in the foreground and plugged into power - adds up pretty quickly in price even if buying the lowest cost iOS device. In my house I would need about 8 dedicated iOS devices to have ideal coverage (2 users in three viewing rooms, 1 guest user device, 1 “whole house” device to control things like whole house audio, lighting, etc.)

Apparently you have not priced out the actual competitive universal remotes. A new iPad mini is $499 (obviously it can be cheaper and there are many cheaper options, but for the sake of this, let’s max things out for fairness). Roomie is generically lets go Maximum Price at $249. Your example has 8 rooms. Your full Roomie deployment with a new iPad mini 6 in every room is therefore $4,241. I have done this experiment many times and priced out C4 and others and they are orders of magnitude more than that. I would estimate for a C4 system with remotes in 8 rooms (which has to include programming as well since they don’t let you do that), you’re looking at well over $10K. There is just no comparison here. To claim “adds up pretty quickly” in the face of the actual facts on the ground here indicates you have not actually looked at the comparable items.


I’ve seen this one before and so many like it. Honestly, after doing this for 13 years, these things are out of business before I have time to establish relations with them. I can name at least 5 of these over the years that looked exactly like this one, none of which are around anymore. (Which is also a side indicator that perhaps making hardbutton remotes is a pretty poor business when everyone controls this stuff with apps these days.)

I’ve mentioned before that I have in my own home a parallel installation of Savant. Everything Roomie controls, Savant also controls (mostly) and vice versa. There are cases where only Roomie can handle something, and then cases specifically with Savant’s proprietary IP video switcher where I have to launch SSH commands on the Savant server from Roomie. Regardless, the point is I am always trying to reset my opinion of the market based on the reality of what I see in other systems, and I am constantly up close and personal with some of these other systems.

In our Guest Room, we do indeed have an X2 remote. Why did I do that? It seems so silly to me now. Basically I was brainwashed by this forum to try it feeling like I must surely be missing something. I have tried to train guests how to use the X2, it takes time and effort, and it’s the usual type of hard button remote with countless useless buttons everywhere half of which do nothing at any given time as is COMPLETELY NORMAL for hard button remotes. They were and are a user interface disaster, even to this very day. Instead, these days, I just tell guests to install Roomie for free and then I tap them into Single Room Mode for the Guest Room – the X2 goes unused. Now they don’t need to learn the remote, they get Media Guides, it’s all on their phone they already have and they already keep charged, they have Media Feedback with every device here, just a better experience in every way.

Anyway, I’ve said before essentially that (1) I don’t like hard button remotes. In part, I created Roomie specifically because I thought the concept of hard buttons had become absurd in the presence of two-way devices that were just starting to become ubiquitous at the time and now are at least 90% of devices. So fundamentally, there is an old adage that goes something like build the things you’d actually use as a customer. I definitely will never use a hard button remote, so I am not going to build that. (2) But, I do also listen to users, and I know some number of users are Combustion Forever die-hards, and so every year or two we do something in this area. What it comes down to is that if someone else builds a nice hard button remote, their business model, their problem, and we have an easy way to talk to that remote, and it doesn’t look like they’re going to go out of business 5 months later like every one of the others in the last 13 years, then great please let me know and pass along the info.

Until that time, which I assume may never come, it’s more productive to reference specific usability issues like those just mentioned by @ksalno in the context of usability instead of as something even related to the old world of hard buttons. For example, you might say “the usability experience of entering a password with this media player and needing to manually bring up the keyboard is very low and could use some kind of improvement as this is a common activity” –– or something in that vein. The point is that we can iterate and evolve virtually any of these areas. The solution is not to go back to Combustion, but rather to move forward and improve the software in whatever area wasn’t up to par.

Agree to most of Will’s analysis/explanations on why we all need to move away from hard button remotes, Harmony was an absolutely fantastic addition, I just hope someone can buy them out and continue for ever. Also agree the newer ones will need a lot of investment from RR for a user base which is wife’s kids and for most of us for use cases when one doesn’t want to get back to the phone and iPads…(oh no phone again as is we spend so much screen time on social media these days). Having said this, as outlined before unless we have a big stable company making these remotes, it’s hard for RR or anyone to think of supporting them, as Will Price say they can come and go even before we have support for them.

Let’s hope for a big new Remote player comes into the market until then status quo.

Will, I don’t think your analogy is accurate and I also think you are whacking down strawmen.

I do not in any way, shape, or form think a hard button remote is better than Roomie. It is not possible for that to be true in my mind.

But, at the same time I do not believe Roomie is perfect for every single use case. I hope you don’t either.

My view is that hard button remotes for common functions - play, pause, volume - serve to enhance or extend the capabilities of Roomie for certain use cases that I have previously described.

My specific ask is for you to do one of these two things:

  1. Please open up the API that already exists to support Alexa to the user community so we can implement hard button remotes in any manner we choose - or in no way at all. I do not see why you are opposed to this. The coding is done. You simply need to expose it to us through an appropriate wrapper.

  2. Add support for simple Bluetooth media remotes that are widely supported in iOS. There are many on the market including ones from Apple. I have this one (since replaced by a newer model) and it has worked great for controlling Amazon Music on iPad I have dedicated to whole house audio. Satechi Aluminum Wireless Multi-Media & Presenter Remote Control.

Your consideration is appreciated.

I’ve heard the germ of this many times – that a hard button is better for a couple of very specific use cases which seem to get narrower and narrower each time. There was a concerted effort to brainwash people into that idea, a sort of misinformation that occurred during the early 2010s, and basically was Harmony marketing directly or indirectly. You can go back and follow the articles week by week. First the narrative is “so much for hard button remotes, apps are taking over” and then within a few months like dominoes several members of the mainstream tech press start writing concerted defenses of hard button remotes and this became the new narrative periodically reinforced. When you have been in the industry long enough, you know there was no coincidence there. Of course, it didn’t stop Harmony from declaring death not once but twice, but it was probably good marketing anyway. Misinformation lasts unless you actually work to correct it, and we didn’t have enough marketing to even begin to counter that.

Basically, it’s like people saying that Blackberries were better than iPhones because they had physical keyboards. As each year has passed, the truth of that has become less and less valid until now we can look around and laugh that people once thought such an absurd thing when so many improvements have occurred like the swipe keyboard that people are “typing” much faster on screens than they ever did. Replace the brand names here and you have the exact same scenario. I suspect a lot of money was put in to make some people believe in hard buttons and it still hasn’t quite fallen away, but inevitably it will given how wrong it is technologically in the long run.

The missing piece here that the creator of the iPhone knew in ~2008 was that any of the usability issues along the way can be solved and iterated. He couldn’t see exactly what it would look like in 2023, but he knew that the possibilities were basically endless and that the benefits far outweighed the cons going to a touchscreen.

My issue for really the entirety of 13 years so far is simply getting users to express usability issues not in terms of their imagined solutions but simply in terms of the actual usability issue. This is why our usability designer over the years has always tried to get us to setup real usability tests with real humans using devices so we can bypass human translation factors and focus on what’s really going on. It’s difficult though because we’re an app that varies so much in different home environments and setting that up with hired users is a challenge.

Similarly, you request two things in your note that are your personal solutions to your personal imagining of the mostly unstated real problem. But as far as I can tell, there is nothing in your note about the usability issues driving your decisions and thus I come away from your message uninformed about what we can do, but I also know that either or both of your suggestions are not the way things work (the way the Alexa API works is not related to anything that would provide useful functionality to things other than Alexa and since you don’t state the actual issue, I don’t know what you’re missing) or already added (we already support all iOS gaming controllers that work exactly like that) or not feasible on iOS (Sonos’ app tried to override Apple’s media controls and they gave up on it, it’s a huge mess, better to use the gaming controllers as it’s clear Apple doesn’t like this.) Regardless, the important missing piece is the actual usability scenario. In an offline note or in previous discussions with others, I am fairly sure I know some of the usability factors.

For example, here is a clip from a recent message I received offline:

Doing any kind of device setup that requires navigating through several layers of a nested menu (e.g., Settings>Audio/Video>Display>Screen Resolution) is also much easier with a hard remote where you can keep your eyes on the screen while navigating up/down and left/right with Enter/OK multiple times to get to the Setting.

Aha! Now that is the original issue for somebody. It’s polluted by hard button claims, and arguably proper use of gesture control should be far superior, but the essence of the problem as they experience it is there. We’d need a real usability test to film the user’s hands to get a full picture of their issue, but putting that aside: now in software design we can ask the real question: how should that function actually work? Obviously, you’d want direct navigation from the app. Navigating with up/down/left/right is always the last option (which begs the question of the absurdity of thinking a hard button would have been a solution here!) Just as we offer direct app launching on tvOS, one way to solve that issue right there would be launching into specific pages of the tvOS Settings app. Apple offers just such an API on iOS, and thus either finding or lobbying Apple to add such an API is well within the bounds of possibility.

That solution was no doubt not even on the list of things that might be possible for that user. So that user thought Problem A exists, they are only aware of potential Solution A, and therefore they request Solution A. But actually, there are solutions B-Z only known in this case to me, but figuring that out requires full knowledge down to the movements of the user’s hand, and Problem A is actually problems A-Z after you define the various incarnations of it on different devices, different apps, etc. A lot of the same issues actually are things we work on regularly. App launching and Siri Voice Control are examples of things we offer on Apple TV today for these exact reasons.

Anyway, haughty feature request messages that seek to dismiss any error checking on my part and suggest immediate implementation of presumed solutions to unstated problems are how apps become bad apps. Needs a design philosophy and the strong ability to say yes or most importantly no to an incorrect architectural direction. I do certainly want to fully understand the nuances of exact usability issues as invariably we can adjust these things over time.


I have been leading software development teams for a long time. I fully appreciate your desire to understand what it is your customers are trying to do as opposed to your customers providing solutions.

Here is what I would like from a capabilities perspective:

I would like the ability to perform the most frequently used functions (play, pause, volume, mute, FF, REW) in a very fast and very reliable way. I would like it to be as fast and as accurate as if I were using a hard button remote. Further, I do not wish to have an “always on” iOS device in every location in my home where I interact with media.

Here are some example user stories:

  • As a user I want to be able to quickly and accurately pause the TV so that if the doorbell rings I can get there as quickly as possible to answer the door
  • As a user I want to be able to quickly and accurately control media volume and playback controls so that if my phone is being charged or otherwise out of reach I am able to still control my media system
  • As a home owner I want to be able to meet my household member and guest expectations about ease of use for controlling media so that their user experience is optimal with a minimal learning curve

Non-functional requirements:

  • Common media control actions should be achievable within < 2 seconds from recognition of desire to control media to the start of the media control operation
  • Common media control actions should be achievable with > 95% accuracy as measured by correctly engaging the appropriate UI element on the first try
  • Common media control actions should require only a single UI operation to engage the desired action
  • Teaching common media control actions to a non-technical user or a guest should require < 3 minutes of training
  • Assume there are no more than two user control points desired in each viewing location
  • Assume there are four viewing locations
  • Assume that each viewing location will generally, but not always, have at least one iOS device available, though do not assume that this iOS device is “always on” with Roomie in the foreground. Assume the device may be locked, the user of the device may not be the owner, or the device may be at a different control point than the control point where the user is currently located in the viewing location.
  • An “always on” iOS device should not be required for every user control point in every viewing location

The only thing I will comment on is you mention you don’t believe the Alexa API will add value to end users. Roomie has code that can pause in response to a user utterance to Alexa. This request flows from Alexa to the Roomie skill and then from the Roomie skill to the primary controller in my house. The code running on the primary controller is aware of the activity running and is able to pause the appropriate device in the activity. There is code in Roomie to figure out which activity is running, which device is the media device, and which command to send to the media device to pause it. We can call that the control logic. There is also code in Roomie that knows how to accept an incoming request from the Roomie skill and return a response to the Roomie skill. We can call that the skill endpoint logic. Those are logically two separate concerns. I am pretty confident that you have also written the code in a way that separates the code for these two concerns. My thinking is to take the control logic and expose it through new user-facing endpoint logic in addition to the existing skill endpoint logic. Same underlying control logic. Two different endpoints. One endpoint facing the skill. The other endpoint facing the user.


For me the biggest reason not to to use the phone as remote is “no more screen time” the moment you pick the phone as easy it might be with all the UI, swipe etc…you do get distracted into seeing other stuff, also in a HT environment it’s certainly not welcome by others who get the screen glare. Hard button remotes will play an important role in future and will never go away, but l can understand RR side of things when big companies like Logitech is moving away, if there is no stable company how can they support.

Having said that, if there is a simple few buttons remote for most common things we should be fine.


  • RR for majority of the pre startup activities, environment setup
  • Once in the watch mode hard button remote

Enjoy watching !!!

For context, that message is how I define the “Combustion Forever” people I can’t satisfy. When someone’s primary issues are:

  • Brightness. There is a brightness control on iOS that brings this down to acceptable levels in any context.
  • Unrelated notifications. There are countless solutions to this. The new Focus system in iOS 16 is probably the best one. Personally, I have a dedicated Apple ID just for house devices, and those devices are locked with Guided Access so this is simply impossible.

Anyway, I will agree to disagree to anyone who believes in hard button remotes for any reason even if small these days. I have been meaning to make a video that goes over the whole topic in great detail, but it’s time consuming. Perhaps things have moved on enough now and the paid misinformation is no longer being paid so it feels like perhaps the topic can be properly covered now.

With regards to the previous post, requirements documents are multiple levels above usability research. We can’t have requirements without the research first or we’re just guessing. The whole essence of my point is that we have only fragments of the usability information here. Instead of usability, I think this thread is primarily driven by nostalgia and emotion. Only a couple of ephemeral comments here have actually been usability.

WRT the API, you’re caught up in the Alexa wording. What you want to say is “please add a contextual pause to the REST API” I guess. Still begs the question of what/how that would be useful, but regardless that’s what you’re asking. No need to add APIs without a target device that actually satisfies the needs here broadly for the remaining Combustion Forever people.

Excellent description. I would like contextual media controls exposed through the REST API similar to how they are expose to the Roomie skill: play, pause, FF, RW, volume up, volume down, mute.

As for “target device” I don’t see why that matters. It need not solve all the needs of every user. It will definitely solve the needs of some (many?) users who are technical and have a desire for hard buttons. I can think of 20 ways to take advantage of that API. I, and others, just need to pick the one that has the right set of capabilities for our use case and preferences. That’s the beauty of an API. For example, the device that started this topic can certainly be a solution. You may hate it, others may hate it, and I may think it is okay. Someone else mentioned SofaBaton (sp?) in this thread. That could work as well. URC makes a remote that can send HTTP commands. That could work. I can use a plain old IR remote to send commands to a GlobalCache iTach which can then receive IR, convert it to hex, and send it to a connected client, which could then transmit API commands to Roomie.

I truly hope you will consider the API option. It has the lowest effort for your team, gives an option to everyone, and means you always have something that will solve the problem while either A) your vision of no more hard buttons ever comes to fruition or B) a better option comes along that you feel is worth a deeper integration with Roomie.

As for your combustion engine analogy . . . are you into Formula One racing at all? I think an F1 car should be your target model. It uses a hybrid engine. It generates electricity in a couple different ways (braking and exhaust heat). It’s controls are all drive by wire except steering. The steering wheel has a display screen that is an LCD, but all of the controls for the screen and the car are hard button. In others words, and F1 car tries to use the best of both words - electronic and physical to make the best performing car on the planet.

One more thing. If you expose the APIs, I will write a beautiful integration that I will open source and give to the Roomie community. I’ll make it complete enough that even non-technical users can take advantage of it. I have done this before - I wrote the first open source user interface and TCP/IP integration with Denon receivers way back in 2006. It was widely beloved amongst the AVS Forum community. This was pre-iPhone, so it was written as a Windows desktop application.

I’d like to chime in here as well… Using Will’s car analogy, as follows:

Initially, electric vehicles and many NON electric new vehicles were designed without hard buttons for controls, using touchscreens instead. You can pretty much use any Cadillac made in the last several years as an example. Customer’s complained about said vehicles, stating that touch screens, without hard/tactile buttons ended up being a distraction while driving because your eyes were taken off the road and directed to a touchscreen to process where, specifically, you needed to press in order to engage a function. Cadillac lost a bunch of customers over this, but then gained others who preferred the touch screen only - for aesthetics, not safety. Recently, however, manufacturers like Kia, Hyundai, BMW and Mercedes, to name a few, scrapped 100% touchscreen interfaces and introduced hard buttons again for controls that are frequently used, leaving the touch screen for information and initial set up purposes, with minimal real-time integrated controls that were SOLELY touchscreen… In other words, things that were frequently used while driving went hard button and others remained touch screen. Every mode in the car has a hard button: Nav, Climate, Media, etc. Things that could not be replicated with hard buttons at all, like keyboards for NAV, etc., remained touch screen.

I have consulted on a significant number of UI’s while I was working, even provided counsel to Lexus in the days where cell phones were being built-into cars, before bluetooth. No - I’m not that old… My goal has always been to separate too different use cases and use a more Japanese style approach to design - in other words, Japan developed a very efficient way of manufacturing vehicles by looking at the specific steps and movements a manufacturing line worker would use to assemble vehicles, and then designed the steps around groupings - with the goal of minimizing movement… Even going so far was to minimize things that took seconds, because after you can consolidate steps and remove 100 things that each took 3 seconds, you’ve saved time, money and likely improved overall quality in-so-doing.

I believe the same applies here and I don’t believe it should be on Will/Roomie staff to design for every hard button, fly by night hard button remote company. I think it should be on them and take the Roomie folks out of it - Will and team would only need to expose the required elements ONCE, and let whomever wanted to integrate with Roomie, versus the other way around, do so…

The use case to justify a hard button remote of any type, bluetooth keyboard, home automation triggers, etc., would also then be irrelevant. However, it would maximize the flexibility of Roomie and enhance Roomie’s user base with completely open configuration for whatever user is in whatever home - who cares if it’s the wife acceptance factor, kids or an adult enthusiast.

bjs point, above, is good in many ways… as he explained it - sometimes there’s no substitute for a hard button remote, but there’s really no disagreement that everyone wants to maintain the Roomie core experience.

For me, and I assume many others, who like to replicate the real movie experience, akin to dark room, I cannot help but agree - I would use a hard button remote, using Roomie as the core, any day… In fact, I have been looking at this model for years, but the Harmony fell short for me for a number of reasons that Roomie did so much better. Therefore, I gave up the search until reading this thread…

Just my .02c (adjusted for inflation): I think both a touchscreen and hard button user interface could and should exist simultaneously, just like cars… cars have moved back a 1/2 step away from complete touchscreen in order to facilitate a better user experience.

Ramble - powered down.

1 Like

Just a side note, not necessarily invalidating any of your points and I think we’re probably too deep into analogies at this point, but: Whatever any other manufacturer may have done, Tesla itself which is arguably crushing every other car company these days has almost completely discarded hard buttons, increasingly so year after year. The latest models remove even the sticks used for turn signals/wipers, etc. If it can be on the touchscreen, it is. For now, it’s pretty much just the steering wheel and a couple of things on the front of the Yoke wheel that remain. But of course, the idea is to remove all of that as well with FSD. Eventually, it’s going to be all touchscreen.

I think you quoted one of the use cases I mentioned. Another, similar one, is when some streaming service requires entering an id and password to validate your subscription or authorization to use their service.

For example, I am a DirecTV Stream customer, which authorizes me to access a number of streaming apps on Roku or Apple TV, such as TCM. While many streaming services make this pretty easy by simply displaying a 4-6 digit code and then letting you do everything else from their website, some, like TCM, require entering the id (usually an email address) and password (with letters, numbers, caps, and special characters) in the app interface which requires using an onscreen virtual keyboard. Trying to navigate an onscreen keyboard using virtual up/down/left/right arrows on an iPad, while at the same time keeping an eye on the TV screen so you know where you are on the virtual keyboard takes about 3x longer than simply picking up the Apple Remote and using the control pad which can be done by touch, without ever looking at the remote itself. You are correct that I’m assuming that option A - a hard remote - is the best answer. If there are options B - Z that solve my problem and are better than a hard remote, I’m all ears, please tell me what they are. I am more then willing to participate in any sort of test program, beta, or UX testing process you’d like to conduct. But if you already have a solution, please share, as this is a consistent pain for me.

This is exactly what I’m talking about. So here you say “I type better with a a hard button than a touch screen.” While that alone is debatable and could be improved in many ways, the more obvious answer is to say that it’s absurd to use anything but a keyboard to type such information. To take it all the way, your password manager also needs to be integrated to the extent you don’t need to do either of those. Regardless, what you definitely should never have to do is try to type letters with a DPad. No matter how you use a DPad or Gesture Control DPad or anything like that, it’s never going to be a keyboard, and the gulf between them is quite vast. There is perhaps no greater user interface disaster in the 20+ years than trying to type passwords with a DPad (hard, soft, whatever).

So in this case the next step is just making sure we have the exact device/data/protocol location that isn’t presenting as such for you so we can record that as a feature request.

Post of the century! Nothing worse.

I think the challenge with DirecTV specifically, and not to your broader point, is the devices are so ancient I’d be surprised if they expose that level of integration.