Hi, I noticed today that the reboot and restart service menus are no longer available on the balena dashboard. Is this by design or is there currently an outage for those options?
Thank you
-Chris
Hi @cmorones15 , As per the new update many things are changed on the UI and you can find the reboot and restart action buttons under the Action tab .
Personally, I donāt like the new UI update as we need to navigate and load another tab to do these reboots, restart and toggle the public URL frequently using works. The old one works best and most of the daily using things are on one page. @mpous Please consider this as feedback 
.
5 Likes
Yes, +1 for bringing back all the actions to the device summary. This is causing a lot of extra efforts and frustration.
Bring the Restart/Reboot buttons as well as the Action Dropdown menu back, please! 
Thanks
4 Likes
Thanks @fritz @salmanfarisvp @cmorones15 for sharing your feedback and comments here.
We are taking notes about all the feedback received and we will keep you updated.
Let us know if we can help you more!
1 Like
I have to agree that the way it was with the public URL, updates etc. was so much better than where they are now after the update. Please consider moving them back or duplicating them if you want them in a drop down menu or there in front of you.
Thank You.
1 Like
Hello @Wayne welcome to the balena community!
Thank you for sharing your comments. Is there any specifics that you use that doesnāt work now?
1 Like
I too was a bit confused by this. The restart and version pin settings now require some extra clicking around and navigation to access/view
1 Like
Already provided this feedback via the support chat widget, +1 for the features being restored to the previous a dropdown on the main page for the device.
Many of these features (pin to release, toggle local mode, restart/shutdown) are context-sensitive tools that depend on seeing the state of the device. Moving them to a separate page breaks that connection: If Iām changing the state of a device I want context around the current state when I perform a potentially destructive change.
The single-page layout for the device UI was actually one of the best features of balena and one of the selling points for us choosing your service; it provided an ability to rapidly manage all of the state for a device intuitively.
Additionally, this seems to have a few bugs that made me think it was an outage ā We now have a device stuck in āLocal modeā where the change to the local mode switch being on a separate page has broken the ability to switch in and out of local mode.
4 Likes
Hello,
Thank you everyone for your feedback, as Marc has mentioned we are taking it all into consideration. If anyone is comfortable with sharing more information about their usecase and workflow, and how your workflow has been affected by this change, please tell us about it so that we can get a better understanding for the ways in which workflows have been affected by this change.
Many of these features (pin to release, toggle local mode, restart/shutdown) are context-sensitive tools that depend on seeing the state of the device. Moving them to a separate page breaks that connection: If Iām changing the state of a device I want context around the current state when I perform a potentially destructive change.
Are there any examples you can provide of context you need to view in order to change the state of a device in your workflow?
We now have a device stuck in āLocal modeā where the change to the local mode switch being on a separate page has broken the ability to switch in and out of local mode.
Regarding the local mode switch not working, that bug has been patched in dashboard version 15.0.6, thank you for reporting it. Are there any other bugs you are aware of? If so please let us know and we will look into them
I need to add again, that with this update the normal workflows in the balena dashboard were made completely unusable.
Ususally you open a few devices (e.g. out of our internal monitoring, etc.) and you land on the Summary page (because e.g. something is not going well). There you might monitor the logfiles. If you see an issue, you would normally issue a service restart or device reboot and continue monitoring the behaviour.
Now, you need additional clicks to the to the device actions page, where you completely loose focus on what is happening on the device (no more log output / command line).
This is really unsuable if you are managing devices right now.
Please bring back the actions to the device summary page as soon as possible!
Thanks
1 Like
Just to add +1 that the updated UI isnāt intuitive or helpful at all.
3 Likes
Regarding the question from @myarmolinsky
I donāt see many reasons that I would navigate to the page of one of these devices and not want to do something with them. The āDevicesā listing page exposes all the same info, so if I was just grabbing an IP address or version number, I would do it from there.
Typically I would nav to that page to either:
- Reboot a device
- Pin a version
- Look at logs
- Restart a service
About half of these now require diving into a sub-menu that used to be a very quick modalā¦
4 Likes
I noticed yesterday that the documentation was not updated with this UI change. Specifically the release pinning documentation which I link to in the balenaRancher app. I forked the docs and will try my best to update that specific document. But Iām wondering if drastic UI changes like this might warrant doing a documentation scrub/update prior to shipping the changes.
And in addition to that, I will check the public URL in my workflow too. and right it needs additional clicks.
1 Like
@fritz stated it well:
Ususally you open a few devices (e.g. out of our internal monitoring, etc.) and you land on the Summary page (because e.g. something is not going well). There you might monitor the logfiles. If you see an issue, you would normally issue a service restart or device reboot and continue monitoring the behaviour.
Weāre usually using these actions in response to something going wrong shown in logging, network status, storage etc. Often this comes from an internal tool or discussion, and the dashboard is a central place to triage and fix the problem. Moving the buttons to a separate page makes that workflow very difficult because previously these operations, and the dashboard, were used together as one debugging and recovery tool.
Contextual questions we use before (and during) each action:
-
Restart services:
Are there errors in the log?
Does a particular service look unhealthy?
Is the device connected to the VPN?
After pressing: Are the services restarting?
After pressing: When has the restart services operation finished? -
Purge data:
Is the device disk full?
Is a configuration invalid (based on error in the log)?
Is the device connected to the VPN?
After pressing: Has clearing the data resolved an issue (based on error in logs)? -
Reboot device, shutdown device:
Is there a failure in a service that would require restart?
Is there a pending configuration change requiring restart, eg. a network setting that has not shown up yet?
Is the device connected to the VPN?
If I run this command will the device immediately restart?
After pressing: is the operation running?
After pressing: Which services are currently shutting down?
After pressing: Has the shutdown/restart operation finished? -
Pin to Release:
What is the current release?
Is the device connected to the VPN?
If I run this command will the device immediately apply the new release?
After usage: Is the download progressing?
After usage: When has the upgrade finished? -
Local Mode:
Is the device already in local mode?
Is the device connected to the VPN?
After entering local mode: What is the deviceās IP to push code?
More context around why there is a lot of pushback on this change despite how minor it seems:
For our team, Balena is equally important as AWS: Itās a core piece of deployment infrastructure that we rely on completely. It causes a lot of disruption when something breaks, and we had no indication that this change would be made, or any reasoning behind why it would be made.
This change has started conversations about moving off Balena ā Because in order to use this platform in production contexts we need trust that the tools are not going to break/change underneath us (Or at least that changes will largely be perceived as positive workflow improvements).
At a minimum it would be very valuable to have an option to āopt inā to new UI changes so users can provide feedback on this before itās globally available.
4 Likes
@cmorones15 @fritz @Wayne @mattyg @cdalke @luandro @puccaso
Hello everyone, I just wanted to chime in here to thank you all for taking the time to give us your feedback about this change. We appreciate the difficulty this change has caused and so wanted to also thank you for your patience whilst we figure out the way forward.
The changes we make to the dashboard are not done on a whim, and in this case are part of wider changes to increase consistency across the dashboard. Weāre aiming to make sure everything has a logical reasoning behind it and remove arbitrary decisions, so that the interface works in a predictable way regardless of which part youāre working with.
In this case, itās clear that in the interests of consistency we made a change which had a negative effect on the usability of the device summary page, when in actual fact we should have been looking at the device summary page as an example we could apply elsewhere. As a result weāre planning to re-implement the functionality that was removed, but weāll make sure we do so in a repeatable, consistent manner that we can share with other resources elsewhere in the dashboard. Weāre also hoping that we can deliver more functionality on the device summary page than was present previously.
Thanks again for your feedback and patience. I hope youāll agree that situations like this are a rare occurrence and that we as a team are receptive and responsive to your concerns in the event that they do come up. We take pride in capturing all feedback and identifying patterns common amongst them to best inform our work.
4 Likes
Hello @chrisys ,
Thank you for your time and attention.
As Iāve caught you =]
- balena action localmode enable [fleet] [device]
- balena action update-os [fleet] [device]
- balena action update-sup [fleet] [device]
- balena action fqdn/public-url [fleet] [device]
- balena action [etcā¦]
if the cli were able to do this, personally speaking, the changes to the UI would not have been so impactful.
Kindly,
puc =]
2 Likes
Hey @puccaso in addition to consistency within the dashboard, weāre also working on consistency between interfaces. This means that if an action exists in one interface (e.g. the dashboard), it should exist in the others, e.g. the CLI 
I canāt promise this is going to happen immediately, but itās in the roadmap.
3 Likes
:greatminds
I understand why those actions were moved to another area, thatās a minor inconvenience for our workflows.
The bigger issue for me is that the Notes section is hidden under the āSettingsā area now. We use that for some important long-form notes that are too big to be a tag. When they were on the main device summary page you would see them at a glance. Now we need to re-train ourselves and support staff to proactively look for them which increases the risk we might miss something important.
1 Like