[GH-ISSUE #1060 ] [Feature]: Structured Printer Card UX Refresh #753

Author

Owner

@Keybored02 commented on GitHub (Apr 21, 2026):

Right now the pills are inconsistent in both meaning and priority. Similar colours can mean different things, and the user has to read each pill to work out whether it matters.

This is not solved by aggregation. The fast visual cue remains: all green is ok, one warning is immediately spotted among the others. Also, the fact that for the compact view an open door or a firmware update would both have the same effect on health does not convey useful info. Again, single icon would still mask constant warnings.

Keeping the individual indicators visible optimizes more for diagnosing exceptions immediately.

I think this is the main point of Bambuddy. Closing the gap between what the user needs and what Bambulab makes available. Loosing it would bear no benefit to the user.

My thinking was that if the space is already there, using it to improve hit area and clarity is a net positive, especially on touch devices

Space is there sometimes, and for now. The layout has to work across multiple printers and with future items in mind. Since the overall card size is important in a grid view, you still have to account for a possible compression of the items to fit more in the same space.

Could you expand on this a bit? From my perspective, the more consistent widths, clearer grouping, and stronger separation between status, telemetry, and controls and the clear one stop shop for health makes the card easier to scan.

If you have very large buttons that span horizontally, they need to be scanned by your brain in multiple passes. Sometimes you also tend to ignore them or deprioritize them (banner blindness). Text is also dispersed in away too large area, which makes it less of a button and more a structure (Gestalt). It's also harder to read as you always read from the right side, and go on until you find text.
Buttons should fit their text exactly, or with minimal padding. They should be compacted in a layout that is consistent across models, but that includes all info in a single visual pass, not multiples. Division is helpful, but we still have to account how the brain sees stuff.

I don't think that the overall approach is the right fit for the use cases we see most often. While the intention is good and segmentation and division can be helpful, the way it is implemented here just strips important information without giving anything meaningful back. I would probably suggest to try and tackle the problem from a workflow perspective, and see if there are any obstacles that can be removed.

@Keybored02 commented on GitHub (Apr 21, 2026): > Right now the pills are inconsistent in both meaning and priority. Similar colours can mean different things, and the user has to read each pill to work out whether it matters. This is not solved by aggregation. The fast visual cue remains: all green is ok, one warning is immediately spotted among the others. Also, the fact that for the compact view an open door or a firmware update would both have the same effect on health does not convey useful info. Again, single icon would still mask constant warnings. > Keeping the individual indicators visible optimizes more for diagnosing exceptions immediately. I think this is the main point of Bambuddy. Closing the gap between what the user needs and what Bambulab makes available. Loosing it would bear no benefit to the user. > My thinking was that if the space is already there, using it to improve hit area and clarity is a net positive, especially on touch devices Space is there _sometimes_, and for now. The layout has to work across multiple printers and with future items in mind. Since the overall card size is important in a grid view, you still have to account for a possible compression of the items to fit more in the same space. > Could you expand on this a bit? From my perspective, the more consistent widths, clearer grouping, and stronger separation between status, telemetry, and controls and the clear one stop shop for health makes the card easier to scan. If you have very large buttons that span horizontally, they need to be scanned by your brain in multiple passes. Sometimes you also tend to ignore them or deprioritize them (banner blindness). Text is also dispersed in away too large area, which makes it less of a button and more a structure (Gestalt). It's also harder to read as you always read from the right side, and go on until you find text. Buttons should fit their text exactly, or with minimal padding. They should be compacted in a layout that is consistent across models, but that includes all info in a single visual pass, not multiples. Division is helpful, but we still have to account how the brain sees stuff. I don't think that the overall approach is the right fit for the use cases we see most often. While the intention is good and segmentation and division can be helpful, the way it is implemented here just strips important information without giving anything meaningful back. I would probably suggest to try and tackle the problem from a workflow perspective, and see if there are any obstacles that can be removed.

BreizhHardware commented

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 21, 2026):

Thanks for expanding. This feels less like a disagreement about one specific component and more like a difference in what we think the top-level card should optimise for.

the fact that for the compact view an open door or a firmware update would both have the same effect on health does not convey useful info.

I agree with the underlying point, but to me that actually reinforces the need for a more clearly defined signalling system - something I have tried to solve here by enforcing “health” rather than “status”.

What I am pushing for is not aggregation for its own sake, but better distinction between state, notice, warning, and action required.

At the moment, too many things are given similar visual importance. A firmware update, an open door, and an actionable condition can all end up competing for attention in similar ways. Once that happens, warning colours start to lose meaning and you get the banner blindness problem. My concern is not that there is too much information, but that the semantics are too flat.

I think amber and red should be used much more intentionally. If something is just a notice or an alternative state, it should not visually compete with something that actually needs user intervention. Otherwise the user still has to read everything to work out whether it matters.

So I am not really arguing for hiding information, I am arguing for stronger prioritisation of information. The compact health concept was only one possible expression of that, by delegating the current scan burden to a single top-level indicator and then exposing detail when needed. But the key thing is intentional messaging.

I think this is the main point of Bambuddy. Closing the gap between what the user needs and what Bambulab makes available.

I see that as part of the value, but not the primary goal. My reading of Bambuddy is more that it is a self-hosted printer management system built around ownership, independence, and managing printers outside the Bambu cloud, rather than primarily an additional diagnostics layer and a way to more information.

From that perspective, I think the top-level view should bias more toward management: helping the user quickly tell which printers are healthy, which are progressing normally, and which need intervention, without having to inspect every individual status item on every card.

The detailed status still needs to be available, of course, but I do not think every top-level signal needs equal visual weight all the time.

Space is there sometimes, and for now. The layout has to work across multiple printers and with future items in mind.

That is fair, and I agree flexibility matters.

My point on the buttons was not that everything should always be large, but that when a control is present it should use the available space cleanly rather than feeling tucked away arbitrarily. If the concern is scalability across models and future controls, I think that argues for a more deliberate responsive control layout rather than preserving the current sizing and simply stacking more elements end-to-end.

So I do not see full-width or half-width controls as inherently incompatible with denser cards. It just needs a clearer layout system. This styling of button is very common across UI now.

If you have very large buttons that span horizontally, they need to be scanned by your brain in multiple passes.

I understand the concern, although I do not think that is universally true in this context.

For me, in this implementation, large inactive controls fade away quickly, while active or relevant states stand out more clearly through intentional use of colour and emphasis. The current UI often has the opposite problem, where many similarly weighted items compete for attention at once, so I end up having to inspect more of the card, not less.

That said, I do take the broader point that controls should not dominate the card or break a single-pass scan. I think there is probably a better middle ground here with tighter, clearly grouped controls rather than either extreme.

I don't think that the overall approach is the right fit for the use cases we see most often.

That may be true for some workflows, but I do think workflow is exactly the right lens to use here.

My own workflow is much more about monitoring a stable farm and quickly spotting exceptions. In that context, consistency, prioritisation, and horizontal scanability matter a lot. I want to be able to glance across several printers and immediately understand health and progress without reading through a stack of mixed-status pills on every card.

It sounds like you may be weighting immediate diagnosis more heavily, which is also a valid use case. That is why I suspect the real problem is not simply "compact vs detailed", but that the UI is currently trying to serve both without a clear hierarchy of what matters first.

For what it is worth, I have had this version open in a tab alongside my main branch install for about a week now, and I keep finding myself preferring it for day-to-day use. Main still feels very cluttered to me, with too many elements competing for attention at once. That is obviously subjective, but I think it does point to a real usability issue worth addressing when we step out of our “dev and diagnostic” shoes and into a workflow that is printing first.

A few concrete examples of what I mean, that I have haphazardly thrown here at the end:

A firmware update is not a warning in the same sense as a blocked printer. It is more of a maintenance notice. Treating both as “amber” pills weakens scan value.
An open door may be relevant or irrelevant depending on printer state. If the machine is idle, it should not necessarily compete with true fault states.
“At a glance” should not only mean “show more things”. It should also mean “make the important things easier to distinguish from the unimportant ones”.

If there are genuinely two dominant workflows here, one possible answer may be a density toggle or a more diagnostic-focused detailed mode, rather than forcing a single interpretation of the card onto every user.

To me, the real goal here is to “show me what I need to know”, not “show me everything” and to focus on what should the default card should help the user decide in the first second of looking at it?

@EdwardChamberlain commented on GitHub (Apr 21, 2026): Thanks for expanding. This feels less like a disagreement about one specific component and more like a difference in what we think the top-level card should optimise for. > the fact that for the compact view an open door or a firmware update would both have the same effect on health does not convey useful info. I agree with the underlying point, but to me that actually reinforces the need for a more clearly defined signalling system - something I have tried to solve here by enforcing “health” rather than “status”. What I am pushing for is not aggregation for its own sake, but better distinction between state, notice, warning, and action required. At the moment, too many things are given similar visual importance. A firmware update, an open door, and an actionable condition can all end up competing for attention in similar ways. Once that happens, warning colours start to lose meaning and you get the banner blindness problem. My concern is not that there is too much information, but that the semantics are too flat. I think amber and red should be used much more intentionally. If something is just a notice or an alternative state, it should not visually compete with something that actually needs user intervention. Otherwise the user still has to read everything to work out whether it matters. So I am not really arguing for hiding information, I am arguing for stronger prioritisation of information. The compact health concept was only one possible expression of that, by delegating the current scan burden to a single top-level indicator and then exposing detail when needed. But the key thing is intentional messaging. > I think this is the main point of Bambuddy. Closing the gap between what the user needs and what Bambulab makes available. I see that as part of the value, but not the primary goal. My reading of Bambuddy is more that it is a self-hosted printer management system built around ownership, independence, and managing printers outside the Bambu cloud, rather than primarily an additional diagnostics layer and a way to more information. From that perspective, I think the top-level view should bias more toward management: helping the user quickly tell which printers are healthy, which are progressing normally, and which need intervention, without having to inspect every individual status item on every card. The detailed status still needs to be available, of course, but I do not think every top-level signal needs equal visual weight all the time. > Space is there sometimes, and for now. The layout has to work across multiple printers and with future items in mind. That is fair, and I agree flexibility matters. My point on the buttons was not that everything should always be large, but that when a control is present it should use the available space cleanly rather than feeling tucked away arbitrarily. If the concern is scalability across models and future controls, I think that argues for a more deliberate responsive control layout rather than preserving the current sizing and simply stacking more elements end-to-end. So I do not see full-width or half-width controls as inherently incompatible with denser cards. It just needs a clearer layout system. This styling of button is very common across UI now. > If you have very large buttons that span horizontally, they need to be scanned by your brain in multiple passes. I understand the concern, although I do not think that is universally true in this context. For me, in this implementation, large inactive controls fade away quickly, while active or relevant states stand out more clearly through intentional use of colour and emphasis. The current UI often has the opposite problem, where many similarly weighted items compete for attention at once, so I end up having to inspect more of the card, not less. That said, I do take the broader point that controls should not dominate the card or break a single-pass scan. I think there is probably a better middle ground here with tighter, clearly grouped controls rather than either extreme. > I don't think that the overall approach is the right fit for the use cases we see most often. That may be true for some workflows, but I do think workflow is exactly the right lens to use here. My own workflow is much more about monitoring a stable farm and quickly spotting exceptions. In that context, consistency, prioritisation, and horizontal scanability matter a lot. I want to be able to glance across several printers and immediately understand health and progress without reading through a stack of mixed-status pills on every card. It sounds like you may be weighting immediate diagnosis more heavily, which is also a valid use case. That is why I suspect the real problem is not simply "compact vs detailed", but that the UI is currently trying to serve both without a clear hierarchy of what matters first. For what it is worth, I have had this version open in a tab alongside my main branch install for about a week now, and I keep finding myself preferring it for day-to-day use. Main still feels very cluttered to me, with too many elements competing for attention at once. That is obviously subjective, but I think it does point to a real usability issue worth addressing when we step out of our “dev and diagnostic” shoes and into a workflow that is printing first. A few concrete examples of what I mean, that I have haphazardly thrown here at the end: - A firmware update is not a warning in the same sense as a blocked printer. It is more of a maintenance notice. Treating both as “amber” pills weakens scan value. - An open door may be relevant or irrelevant depending on printer state. If the machine is idle, it should not necessarily compete with true fault states. - “At a glance” should not only mean “show more things”. It should also mean “make the important things easier to distinguish from the unimportant ones”. If there are genuinely two dominant workflows here, one possible answer may be a density toggle or a more diagnostic-focused detailed mode, rather than forcing a single interpretation of the card onto every user. To me, the real goal here is to “show me what I need to know”, not “show me everything” and to focus on what should the default card should help the user decide in the first second of looking at it?

BreizhHardware commented

Author

Owner

@Keybored02 commented on GitHub (Apr 21, 2026):

What I am pushing for is not aggregation for its own sake, but better distinction between state, notice, warning, and action required.

I agree in principle, but I'd prefer a diverse approach. E.g., the firmware updater is mostly not working, and the user does not want to see rapidly which version he currently is on, but rather if an update is available. So relocating or gating the FW item would be the better option here. Same goes for the Connected item (which is redundant IMO). Then, you can leave errors, signal strength and maintenance behind a health icon. Door indicator and eco mode can stay outside of the submenu.

I see that as part of the value, but not the primary goal.

A lot of the userbase migrated from Bambulab HA and similar integrations that are heavily data-based, both in presentation and function. So while it might not be the sole and unique goal, or affect the totality of the userbase, I would be cautious when speaking broadly. Plenty of other OS management app have very pretty and compact UIs. Bambuddy has a really good MQTT parser, which means plenty of info to expose. The UI has to reflect that. Excessive reduction will put the tool on par with what Bambu Studio offers.

From that perspective, I think the top-level view should bias more toward management

A really important topic that hasn't been addressed so far: this layout rework should not substitute a "farm manager view". High machine counts and farm overview should have their own view, be it S or something dedicated that needs to be reworked. This has been asked often (recently too) and is part of the overall "Bambuddy as a farm management tool" discussion going on, which for now is mostly backend stuff.

This layout rework should focus on M, L, and XL sizes, with small machine counts (1-3). This is both for practical and design philosophy matters.

I think there is probably a better middle ground here with tighter, clearly grouped controls rather than either extreme.

I agree.

It just needs a clearer layout system.

I agree.

That is obviously subjective, but I think it does point to a real usability issue worth addressing when we step out of our “dev and diagnostic” shoes and into a workflow that is printing first.

A workflow that is printing first is often one that involves manual spool assignment, drying start, and other UI centric tasks that your proposal hinders. More data is not simply "diagnostics". For example on the H2C, seeing what material is preloaded into the R nozzle is crucial to correctly map them in the slicer and avoid clogs, as Bambu Studio matches per color only. Gating or hiding this info would affect the user way more than having a denser card. There was plenty of popular feature requests to add X or Y item to the card, so it's in the current state not without reason.

If there are genuinely two dominant workflows here, one possible answer may be a density toggle or a more diagnostic-focused detailed mode, rather than forcing a single interpretation of the card onto every user.

That's effectively another design to maintain across 3 card sizes, 7+ machine types, and all display sizes. That's really not an viable option.

To me, the real goal here is to “show me what I need to know”, not “show me everything” and to focus on what should the default card should help the user decide in the first second of looking at it?

You have designed a UI that works for you use case. Getting it to a state that would benefit a wider audience will require compromises.

@Keybored02 commented on GitHub (Apr 21, 2026): > What I am pushing for is not aggregation for its own sake, but better distinction between state, notice, warning, and action required. I agree in principle, but I'd prefer a diverse approach. E.g., the firmware updater is mostly not working, and the user does not want to see rapidly which version he currently is on, but rather if an update is available. So relocating or gating the FW item would be the better option here. Same goes for the Connected item (which is redundant IMO). Then, you can leave errors, signal strength and maintenance behind a health icon. Door indicator and eco mode can stay outside of the submenu. > I see that as part of the value, but not the primary goal. A lot of the userbase migrated from Bambulab HA and similar integrations that are heavily data-based, both in presentation and function. So while it might not be the sole and unique goal, or affect the totality of the userbase, I would be cautious when speaking broadly. Plenty of other OS management app have very pretty and compact UIs. Bambuddy has a really good MQTT parser, which means plenty of info to expose. The UI has to reflect that. Excessive reduction will put the tool on par with what Bambu Studio offers. > From that perspective, I think the top-level view should bias more toward management A really important topic that hasn't been addressed so far: this layout rework should not substitute a "farm manager view". High machine counts and farm overview should have their own view, be it S or something dedicated that needs to be reworked. This has been asked often (recently too) and is part of the overall "Bambuddy as a farm management tool" discussion going on, which for now is mostly backend stuff. This layout rework should focus on M, L, and XL sizes, with small machine counts (1-3). This is both for practical and design philosophy matters. > I think there is probably a better middle ground here with tighter, clearly grouped controls rather than either extreme. I agree. > It just needs a clearer layout system. I agree. > That is obviously subjective, but I think it does point to a real usability issue worth addressing when we step out of our “dev and diagnostic” shoes and into a workflow that is printing first. A workflow that is printing first is often one that involves manual spool assignment, drying start, and other UI centric tasks that your proposal hinders. More data is not simply "diagnostics". For example on the H2C, seeing what material is preloaded into the R nozzle is crucial to correctly map them in the slicer and avoid clogs, as Bambu Studio matches per color only. Gating or hiding this info would affect the user way more than having a denser card. There was plenty of popular feature requests to add X or Y item to the card, so it's in the current state not without reason. > If there are genuinely two dominant workflows here, one possible answer may be a density toggle or a more diagnostic-focused detailed mode, rather than forcing a single interpretation of the card onto every user. That's effectively another design to maintain across 3 card sizes, 7+ machine types, and all display sizes. That's really not an viable option. > To me, the real goal here is to “show me what I need to know”, not “show me everything” and to focus on what should the default card should help the user decide in the first second of looking at it? You have designed a UI that works for you use case. Getting it to a state that would benefit a wider audience will require compromises.

BreizhHardware commented

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 21, 2026):

Thanks, this is helpful, and I think we have probably reached the point where the differences are mostly about priorities and workflow rather than whether the current UI has room for improvement.

E.g., the firmware updater is mostly not working, and the user does not want to see rapidly which version he currently is on, but rather if an update is available. So relocating or gating the FW item would be the better option here.

I agree with that. In an ideal implementation the firmware item would communicate update availability rather than just surfacing the current version, and being able to dismiss or decline an update so the state returns to neutral would also help. My only concern is avoiding too much fragmentation in how status has to be tracked.

Same goes for the Connected item (which is redundant IMO).

I am less convinced on this one. Connection state is pretty fundamental because if Bambuddy is no longer connected to the printer that directly affects what the user can do from the UI. I agree it does not need to be visually loud all the time, but I do think it needs to remain clearly available.

Then, you can leave errors, signal strength and maintenance behind a health icon. Door indicator and eco mode can stay outside of the submenu.

That feels closer to a workable middle ground. Door state could live in the indicator area if it is kept, although I still question how actionable it really is. On top of that, the current door indicator behaviour is not especially reliable as it appears on machines that do not actually have a door sensor.

Excessive reduction will put the tool on par with what Bambu Studio offers.

I think it is important to clarify that I am not really advocating reduction. If anything, I am arguing for better layering and hierarchy so the UI can carry more information without everything competing at the same level. My goal is not to strip data out, but to make it easier to parse and locate.

this layout rework should not substitute a "farm manager view".

I agree that a dedicated farm-oriented view is a separate discussion and probably the right answer for higher machine counts. That feels a bit out of scope for this specific layout discussion.

That said, I do still think Bambuddy is fundamentally a multi-machine tool based on the way it currently presents its UI, so it is difficult to ignore entirely. Even if M, L, and XL are the focus here, the way cards read side by side still matters.

A workflow that is printing first is often one that involves manual spool assignment, drying start, and other UI centric tasks that your proposal hinders.

This is a fair criticism, especially around the AMS treatment. I agree the tabbed/paginated approach makes spool assignment and drying workflows worse, and that part would need to change back toward a more visible list or grid approach. I will also admit that, not owning an H2C or regularly using multi-AMS workflows (and using RFID spools), I am less exposed to some of those cases. So that feedback is really useful.

Beyond the AMS area though, I am not sure I see the same level of regression elsewhere, since all the existing controls are still present. If there are other specific workflows that feel materially worse outside the AMS section, those would be useful to call out.

That's effectively another design to maintain across 3 card sizes, 7+ machine types, and all display sizes. That's really not a viable option.

Agreed. I do not think multiple parallel designs are the answer either.

Getting it to a state that would benefit a wider audience will require compromises.

Definitely, and that is exactly why I opened the discussion. Bambuddy is not just for my workflow, so hearing from users with different printers and different usage patterns is valuable.

I think the most useful takeaways for me from your comments are:

improve semantic prioritisation so not every notice competes equally
retain high-information AMS presentation rather than paginating it
preserve dense top-level visibility where it directly supports common printing workflows

Thanks for taking the time to go through your thoughts in detail. 😊

@EdwardChamberlain commented on GitHub (Apr 21, 2026): Thanks, this is helpful, and I think we have probably reached the point where the differences are mostly about priorities and workflow rather than whether the current UI has room for improvement. > E.g., the firmware updater is mostly not working, and the user does not want to see rapidly which version he currently is on, but rather if an update is available. So relocating or gating the FW item would be the better option here. I agree with that. In an ideal implementation the firmware item would communicate update availability rather than just surfacing the current version, and being able to dismiss or decline an update so the state returns to neutral would also help. My only concern is avoiding too much fragmentation in how status has to be tracked. > Same goes for the Connected item (which is redundant IMO). I am less convinced on this one. Connection state is pretty fundamental because if Bambuddy is no longer connected to the printer that directly affects what the user can do from the UI. I agree it does not need to be visually loud all the time, but I do think it needs to remain clearly available. > Then, you can leave errors, signal strength and maintenance behind a health icon. Door indicator and eco mode can stay outside of the submenu. That feels closer to a workable middle ground. Door state could live in the indicator area if it is kept, although I still question how actionable it really is. On top of that, the current door indicator behaviour is not especially reliable as it appears on machines that do not actually have a door sensor. > Excessive reduction will put the tool on par with what Bambu Studio offers. I think it is important to clarify that I am not really advocating reduction. If anything, I am arguing for better layering and hierarchy so the UI can carry more information without everything competing at the same level. My goal is not to strip data out, but to make it easier to parse and locate. > this layout rework should not substitute a "farm manager view". I agree that a dedicated farm-oriented view is a separate discussion and probably the right answer for higher machine counts. That feels a bit out of scope for this specific layout discussion. That said, I do still think Bambuddy is fundamentally a multi-machine tool based on the way it currently presents its UI, so it is difficult to ignore entirely. Even if M, L, and XL are the focus here, the way cards read side by side still matters. > A workflow that is printing first is often one that involves manual spool assignment, drying start, and other UI centric tasks that your proposal hinders. This is a fair criticism, especially around the AMS treatment. I agree the tabbed/paginated approach makes spool assignment and drying workflows worse, and that part would need to change back toward a more visible list or grid approach. I will also admit that, not owning an H2C or regularly using multi-AMS workflows (and using RFID spools), I am less exposed to some of those cases. So that feedback is really useful. Beyond the AMS area though, I am not sure I see the same level of regression elsewhere, since all the existing controls are still present. If there are other specific workflows that feel materially worse outside the AMS section, those would be useful to call out. > That's effectively another design to maintain across 3 card sizes, 7+ machine types, and all display sizes. That's really not a viable option. Agreed. I do not think multiple parallel designs are the answer either. > Getting it to a state that would benefit a wider audience will require compromises. Definitely, and that is exactly why I opened the discussion. Bambuddy is not just for my workflow, so hearing from users with different printers and different usage patterns is valuable. I think the most useful takeaways for me from your comments are: - improve semantic prioritisation so not every notice competes equally - retain high-information AMS presentation rather than paginating it - preserve dense top-level visibility where it directly supports common printing workflows Thanks for taking the time to go through your thoughts in detail. 😊

BreizhHardware commented

Author

Owner

@aneopsy commented on GitHub (Apr 22, 2026):

The Printer UI/UX card needs an update, but we should approach it thoughtfully rather than rushing into changes, perhaps by creating a few mockups first. Since design is subjective and everyone has different preferences when it comes to size, colors, and layout, it’s important to have a proper discussion and focus on UX/UI principles instead of personal taste. Otherwise, we risk ending up with another proposal to change the UI in a month.

@aneopsy commented on GitHub (Apr 22, 2026): The Printer UI/UX card needs an update, but we should approach it thoughtfully rather than rushing into changes, perhaps by creating a few mockups first. Since design is subjective and everyone has different preferences when it comes to size, colors, and layout, it’s important to have a proper discussion and focus on UX/UI principles instead of personal taste. Otherwise, we risk ending up with another proposal to change the UI in a month.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 22, 2026):

Before we are going to decide things, I would definitely like to see mockups. I personally always need to see it before taking decisions.

@maziggy commented on GitHub (Apr 22, 2026): Before we are going to decide things, I would definitely like to see mockups. I personally always need to see it before taking decisions.

BreizhHardware commented

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 22, 2026):

Strongly agree. I think with these things you have to interact with it and see it to get a feel.

I've mocked up what I feel is a good direction and used that for the screenshots above but I’m not strongly opinionated on implementation so I really want to invite suggestions. If you have an idea of direction and can describe it I'd be really keen to put together a mock up and explore it.

I think the best thing is to scatter some ideas and mockups and pluck the best elements from each to form a final design.

If you're interested in playing with the design I have posted above to get a feel for things an untested rendition can be found on my fork on the feature branch.

@EdwardChamberlain commented on GitHub (Apr 22, 2026): Strongly agree. I think with these things you have to interact with it and see it to get a feel. I've mocked up what I feel is a good direction and used that for the screenshots above but I’m not strongly opinionated on implementation so I really want to invite suggestions. If you have an idea of direction and can describe it I'd be really keen to put together a mock up and explore it. I think the best thing is to scatter some ideas and mockups and pluck the best elements from each to form a final design. If you're interested in playing with the design I have posted above to get a feel for things an untested rendition can be found on my fork on the feature branch.

BreizhHardware commented

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 22, 2026):

Reviewing my initial proposal I think it would be good to break down into elements and try to group these by complexity.

Minor

Things I think are minor and exclusively UI tightening without change to workflow:

1. Addition of a header icon to match the queue page:
Proposed:

Current:

2. Filters and Search alignment and consistency

Consistent buttons heights
Expand search bar to use space
Use consistent button styles
Group filtering buttons with filter drop downs.

Current:

Proposed:

3. Print Job Status tile changes:

Tighten layout so that the card feels designed by making the print image the height of the card and tighten spacing.
Include a job placeholder so UI elements have a consistent position - top line status, second line job name.
Current:

Proposed:

4. Move indicators (fan status) out of controls and into indicators + match style
Current:

Proposed:

5. Move chamber light and plate check to the controls area
Ignoring Button style, only position
Current: In the footer.

Proposed:

It could be debated about moving the camera viewer up into controls - it's not a "control" and more of a view so debatable where it lives.

6. Strengthen Divider Lines
Bring visual separation between sections to help define belonging

Current:

Proposed:

7. Bring Kebab Menu to the footer
Bring the kebab down to the footer

8. Add visual structure and alignment to AMS card
Bring visual structure with defined buttons and sizing to make use of UI space:

Current:

Proposed:

Somewhat Subjective

Some changes that are I think more controversial based on comments here but still limited to style and shouldnt affect workflow, but maybe accessibility / interaction.

9. Update Interact-Able Button Style

Make button hit box bigger for touch UI by marginally increasing button height and font size.
Spanning elements 100% of the card to make them feel more intentionally placed.

Current:

Proposed:

Personally I feel this looks visually tighter on M and L cards but it falls apart on XL cards as everything gets super wide and the old view is better in terms of positioning. I think this can be solved by single lining the controls on XL to keep it closer to the older layout but with the benefit of the newer visual buttons.

Current:

Proposed:

It does feel like this highlights an opportunity to make better use of the XL card - especially for users running a single machine.

Broader UX Changes

Stuff that directly affects workflow (hopefully for the better)

10. Transition from "Status" reporting to "Health" reporting
Currently indicators are very mixed in their use of colours. Currently the status indicators are good for communicating the status of various machine elements but looking at it from a workflow perspective I believe a user is more interested in health which means consistent implementation of colour based on user requirement. So enforce:

Green = healthy
Amber = Requires user attention
Red = Error State
(roughly inline with ISO 3864)

11. Collapse status pills into a single indicator with sub menu
Create a single checkpoint for quickly understanding machine state. Reduce scanning by delegating to a single icon. Im not sure how I feel about this - its good for monitoring but when something is wrong it makes it harder so this certainly needs work.

I feel like this conversation is becoming a little unwieldily. Hopefully numbering the ideas helps with discussion but I appreciate we might want to break this down further. I feel like the health monitoring should be its own discussion and we should focus strictly on UI tightening here rather than more broad workflow / backend changes.

Id also really like to explore some competing options as well and create some mockups of that.

@EdwardChamberlain commented on GitHub (Apr 22, 2026): Reviewing my initial proposal I think it would be good to break down into elements and try to group these by complexity. ## Minor Things I think are **minor** and exclusively UI tightening without change to workflow: **1. Addition of a header icon to match the queue page:** Proposed: <img width="195" height="68" alt="Image" src="https://github.com/user-attachments/assets/17d02378-448a-44fe-acb4-30326ebcce51" /> Current: <img width="215" height="56" alt="Image" src="https://github.com/user-attachments/assets/55880e4b-2d86-4d6a-9e13-ef89ba62dd60" /> **2. Filters and Search alignment and consistency** - Consistent buttons heights - Expand search bar to use space - Use consistent button styles - Group filtering buttons with filter drop downs. Current: <img width="1410" height="133" alt="Image" src="https://github.com/user-attachments/assets/7b5bfc6e-c93b-4f89-b242-c3f79da917e2" /> Proposed: <img width="1440" height="148" alt="Image" src="https://github.com/user-attachments/assets/8ee13ea5-9357-4f08-aab8-9160838ebebc" /> **3. Print Job Status tile changes:** - Tighten layout so that the card feels designed by making the print image the height of the card and tighten spacing. - Include a job placeholder so UI elements have a consistent position - top line status, second line job name. Current: <img width="1364" height="138" alt="Image" src="https://github.com/user-attachments/assets/6926252c-59cf-4781-8cb4-d204782d2478" /> Proposed: <img width="1353" height="127" alt="Image" src="https://github.com/user-attachments/assets/d46e70bd-45ae-4f6b-97cc-9c80c1620bd0" /> **4. Move indicators (fan status) out of controls and into indicators + match style** Current: <img width="1413" height="178" alt="Image" src="https://github.com/user-attachments/assets/83b6b6e9-de50-4b53-a5d1-1af04574521d" /> Proposed: <img width="1416" height="102" alt="Image" src="https://github.com/user-attachments/assets/87a0565d-348e-47b2-af0a-11c4b60d7621" /> **5. Move chamber light and plate check to the controls area** Ignoring Button style, only position Current: In the footer. Proposed: <img width="423" height="117" alt="Image" src="https://github.com/user-attachments/assets/a94a8670-d705-4f97-9fa0-11403bdaa306" /> It could be debated about moving the camera viewer up into controls - it's not a "control" and more of a view so debatable where it lives. **6. Strengthen Divider Lines** Bring visual separation between sections to help define belonging Current: <img width="424" height="30" alt="Image" src="https://github.com/user-attachments/assets/80943755-302d-481b-880a-4919d595898a" /> Proposed: <img width="439" height="30" alt="Image" src="https://github.com/user-attachments/assets/ae3878b8-f237-4d31-bf8e-c7ffd7c7f188" /> **7. Bring Kebab Menu to the footer** Bring the kebab down to the footer **8. Add visual structure and alignment to AMS card** Bring visual structure with defined buttons and sizing to make use of UI space: Current: <img width="441" height="240" alt="Image" src="https://github.com/user-attachments/assets/9a21dc7a-edf3-46d1-913d-c2e5b20561a7" /> Proposed: <img width="419" height="249" alt="Image" src="https://github.com/user-attachments/assets/c63b406d-edda-4a7a-8691-7c1f475c998f" /> ## Somewhat Subjective Some changes that are I think more controversial based on comments here but still limited to style and shouldnt affect workflow, but maybe accessibility / interaction. **9. Update Interact-Able Button Style** - Make button hit box bigger for touch UI by marginally increasing button height and font size. - Spanning elements 100% of the card to make them feel more intentionally placed. Current: <img width="432" height="128" alt="Image" src="https://github.com/user-attachments/assets/fa613dcc-32c7-4c12-bb95-4de42aeb6289" /> Proposed: <img width="424" height="114" alt="Image" src="https://github.com/user-attachments/assets/824a01e8-b996-48ba-9022-0c180ebbed4c" /> Personally I feel this looks visually tighter on M and L cards but it falls apart on XL cards as everything gets super wide and the old view is better in terms of positioning. I think this can be solved by single lining the controls on XL to keep it closer to the older layout but with the benefit of the newer visual buttons. Current: <img width="1366" height="74" alt="Image" src="https://github.com/user-attachments/assets/c4000d7b-0186-44eb-be26-2d6bf8018646" /> Proposed: <img width="1361" height="77" alt="Image" src="https://github.com/user-attachments/assets/6bde70df-6225-4711-baa5-1a628128f58b" /> It does feel like this highlights an opportunity to make better use of the XL card - especially for users running a single machine. ## Broader UX Changes Stuff that directly affects workflow (hopefully for the better) **10. Transition from "Status" reporting to "Health" reporting** Currently indicators are very mixed in their use of colours. Currently the status indicators are good for communicating the status of various machine elements but looking at it from a workflow perspective I believe a user is more interested in health which means consistent implementation of colour based on user requirement. So enforce: - Green = healthy - Amber = Requires user attention - Red = Error State (roughly inline with ISO 3864) **11. Collapse status pills into a single indicator with sub menu** Create a single checkpoint for quickly understanding machine state. Reduce scanning by delegating to a single icon. Im not sure how I feel about this - its good for monitoring but when something is wrong it makes it harder so this certainly needs work. I feel like this conversation is becoming a little unwieldily. Hopefully numbering the ideas helps with discussion but I appreciate we might want to break this down further. I feel like the health monitoring should be its own discussion and we should focus strictly on UI tightening here rather than more broad workflow / backend changes. Id also really like to explore some competing options as well and create some mockups of that.

BreizhHardware commented

Author

Owner

@Keybored02 commented on GitHub (Apr 26, 2026):

Sorry for the very late response @EdwardChamberlain.

I like the direction, very thoughtful. Point 1-3 are good.
The 4th proposal is text-heavy, and the items are not much visually distinguished from each other. I'm okay with it as I pretty much never need to know those, but I would still look into possible ways to make it more visually appealing. Now it's a big block of grey shades.
Point 5-7: good, but would really appreciate a full old vs new of the card. Especially for point 7.
Point 8: I do not see how the fit-to-width AMS card improves the layout. It makes the external spool on the same visual level as the AMS, which isn't helpful, as it needs to convey less info. I would also like to see a mockup with multiples AMS and AMS HT (dummy one are ok ofc).
I like point 9, but I would try with not moving the pause/stop buttons all the way to the right in the XL view. Maybe try keeping the column layout as the M and L?
10 and 11, same as before.

@Keybored02 commented on GitHub (Apr 26, 2026): Sorry for the very late response @EdwardChamberlain. I like the direction, very thoughtful. Point 1-3 are good. The 4th proposal is text-heavy, and the items are not much visually distinguished from each other. I'm okay with it as I pretty much never need to know those, but I would still look into possible ways to make it more visually appealing. Now it's a big block of grey shades. Point 5-7: good, but would really appreciate a full old vs new of the card. Especially for point 7. Point 8: I do not see how the fit-to-width AMS card improves the layout. It makes the external spool on the same visual level as the AMS, which isn't helpful, as it needs to convey less info. I would also like to see a mockup with multiples AMS and AMS HT (dummy one are ok ofc). I like point 9, but I would try with not moving the pause/stop buttons all the way to the right in the XL view. Maybe try keeping the column layout as the M and L? 10 and 11, same as before.

BreizhHardware commented

Author

Owner

@EdwardChamberlain commented on GitHub (Apr 26, 2026):

Point 8: I do not see how the fit-to-width AMS card improves the layout. It makes the external spool on the same visual level as the AMS, which isn't helpful, as it needs to convey less info. I would also like to see a mockup with multiples AMS and AMS HT (dummy one are ok ofc).

There are probably two changes in here so 8: the change of layout and (lets call it) 8.5: the change of card design.

I think 8.5 - the card design change is pretty positive as it gives weight to the clickable elements.

8: Im not sure it actually needs to be full width per AMS - they could be listed like they are currently but done more intentionally - 100% wide per row but fit as many as possible per row based on a minimum width consistent with current implementation?

So for M (since there isnt width for both the AMS and external it expands to 100%):

But for L (since you can fit them side by side without breaking their minimum width:

Here is a dummy H2C with a bunch of AMS units

H2C with a bunch of AMS:

Obviously would require some tuning etc to get the right min widths etc.

Point 5-7: good, but would really appreciate a full old vs new of the card. Especially for point 7.

10 and 11, same as before.

Im fairly sure I would move 10 and 11 out of scope here. It's a much more serious overhaul of monitoring that is best in its own comment.

@EdwardChamberlain commented on GitHub (Apr 26, 2026): > Point 8: I do not see how the fit-to-width AMS card improves the layout. It makes the external spool on the same visual level as the AMS, which isn't helpful, as it needs to convey less info. I would also like to see a mockup with multiples AMS and AMS HT (dummy one are ok ofc). There are probably two changes in here so 8: the change of layout and (lets call it) 8.5: the change of card design. I think 8.5 - the card design change is pretty positive as it gives weight to the clickable elements. 8: Im not sure it actually needs to be full width per AMS - they could be listed like they are currently but done more intentionally - 100% wide per row but fit as many as possible per row based on a minimum width consistent with current implementation? So for M (since there isnt width for both the AMS and external it expands to 100%): <img width="428" height="270" alt="Image" src="https://github.com/user-attachments/assets/bee631aa-552b-41aa-a4eb-d2552efd3717" /> But for L (since you can fit them side by side without breaking their minimum width: <img width="663" height="149" alt="Image" src="https://github.com/user-attachments/assets/596ee349-9412-4d21-9142-18950ec2e811" /> Here is a dummy H2C with a bunch of AMS units H2C with a bunch of AMS: <img width="428" height="748" alt="Image" src="https://github.com/user-attachments/assets/91dd36aa-624a-4980-9755-94b1a692e7aa" /> <img width="661" height="388" alt="Image" src="https://github.com/user-attachments/assets/9be26678-5ff2-4f09-8c51-09a6deb80fcc" /> <img width="1356" height="266" alt="Image" src="https://github.com/user-attachments/assets/c1fbee45-1aec-4a18-b94c-45c77f2940c1" /> Obviously would require some tuning etc to get the right min widths etc. > Point 5-7: good, but would really appreciate a full old vs new of the card. Especially for point 7. <img width="479" height="731" alt="Image" src="https://github.com/user-attachments/assets/767eae99-502e-4025-a5be-db1273265fa1" /> > 10 and 11, same as before. Im fairly sure I would move 10 and 11 out of scope here. It's a much more serious overhaul of monitoring that is best in its own comment.

BreizhHardware commented

Author

Owner

@Keybored02 commented on GitHub (Apr 26, 2026):

Im fairly sure I would move 10 and 11 out of scope here. It's a much more serious overhaul of monitoring that is best in its own comment.

Agree, but add 8 and 8.5 to the waitlist too. It's a lot of vertical space for a mainly-landscape view. And while it does make the individual tray heavier, it might be worth gating to mobile screens only.

@Keybored02 commented on GitHub (Apr 26, 2026): > Im fairly sure I would move 10 and 11 out of scope here. It's a much more serious overhaul of monitoring that is best in its own comment. Agree, but add 8 and 8.5 to the waitlist too. It's a lot of vertical space for a mainly-landscape view. And while it does make the individual tray heavier, it might be worth gating to mobile screens only.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

Whats about splitting all printer items into separate modules, so that the user can design his own dashboard layout? That would be the real deal!

@maziggy commented on GitHub (May 2, 2026): Whats about splitting all printer items into separate modules, so that the user can design his own dashboard layout? That would be the real deal!

BreizhHardware commented

Author

Owner

@Keybored02 commented on GitHub (May 2, 2026):

Users could rearrange the layout and/or hide items. That's nice. It wouldn't address the point of UX though, as what is inside the modules still needs to be decided. A bit outside scope here.

I really like the mockups and discussion so far (with the aforementioned exceptions). Maybe lets move this to a PR and test what sticks?

@Keybored02 commented on GitHub (May 2, 2026): Users could rearrange the layout and/or hide items. That's nice. It wouldn't address the point of UX though, as what is inside the modules still needs to be decided. A bit outside scope here. I really like the mockups and discussion so far (with the aforementioned exceptions). Maybe lets move this to a PR and test what sticks?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

That's nice. It wouldn't address the point of UX though,

I don't agree. If a user can build his own dashbard, for example we wouldn't need nested items because the user can simply hide things he don't want to see.

I personally would perfer this way:

definition of modules (e.g. temps, controls, etc.)
definition of global Bambuddy status colors (green, yellow, red) for all modules and nested items
build the new custom dashboard
produce 2-3 dashboard layouts as a base - one as default which should match the need of most users (tbd)

I don't see, that we are moving forward with a static version. As you both could see in your discussion, everyone has adifferent opinion. If you ask someone else (for example me :) ) you have a thied opinion. And so on....that doesn't makes sense to me.

@maziggy commented on GitHub (May 2, 2026): > That's nice. It wouldn't address the point of UX though, I don't agree. If a user can build his own dashbard, for example we wouldn't need nested items because the user can simply hide things he don't want to see. I personally would perfer this way: 1. definition of modules (e.g. temps, controls, etc.) 2. definition of global Bambuddy status colors (green, yellow, red) for all modules and nested items 3. build the new custom dashboard 3. produce 2-3 dashboard layouts as a base - one as default which should match the need of most users (tbd) I don't see, that we are moving forward with a static version. As you both could see in your discussion, everyone has adifferent opinion. If you ask someone else (for example me :) ) you have a thied opinion. And so on....that doesn't makes sense to me.

BreizhHardware commented

Author

Owner

@Keybored02 commented on GitHub (May 2, 2026):

I agree with your take, but it's not really about what needs to hidden or not as a module, but rather what that module contains.
E.g., the proposed AMS reworks would render a different view to what exists now. With modularity, I can decide if it's shown or not, but I can't decide how it's shown. If I want a more expanded view, or compact, or different button arrangement inside the module, I'm always redirected to the same view.

Modularity is the right way. We could add all sorts of modules to it (macros, jog controls, statistics, etc.).

@Keybored02 commented on GitHub (May 2, 2026): I agree with your take, but it's not really about what needs to hidden or not as a module, but rather what that module contains. E.g., the proposed AMS reworks would render a different view to what exists now. With modularity, I can decide if it's shown or not, but I can't decide _how_ it's shown. If I want a more expanded view, or compact, or different button arrangement inside the module, I'm always redirected to the same view. Modularity is the right way. We could add all sorts of modules to it (macros, jog controls, statistics, etc.).

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

With modularity, I can decide if it's shown or not, but I can't decide how it's shown.

Yes, sure. For example the AMS. Let's say you have a module that contains an AMS view and can be switched between different views. I have a module for every single AMS and can show them or hide them.

BTW: I'm not a fan of hiding printer details. I don't want to switch anything or open a submenu to change the view.

@maziggy commented on GitHub (May 2, 2026): > With modularity, I can decide if it's shown or not, but I can't decide how it's shown. Yes, sure. For example the AMS. Let's say you have a module that contains an AMS view and can be switched between different views. I have a module for every single AMS and can show them or hide them. BTW: I'm not a fan of hiding printer details. I don't want to switch anything or open a submenu to change the view.

BreizhHardware commented

Author

Owner

@Keybored02 commented on GitHub (May 2, 2026):

That's essentially the original discourse of "let's add different views and let the people choose" which was shelved due to the exponentially higher maintenance requirements. If you're ok with multiple designs per item to maintain across 3 card sizes, 7+ machine types, and all display sizes, then it's definitely the most user-friendly option.

@Keybored02 commented on GitHub (May 2, 2026): That's essentially the original discourse of "let's add different views and let the people choose" which was shelved due to the exponentially higher maintenance requirements. If you're ok with multiple designs per item to maintain across 3 card sizes, 7+ machine types, and all display sizes, then it's definitely the most user-friendly option.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

Should be a template based system.

Let me think about it a little.....as long as I have the time :P

@maziggy commented on GitHub (May 2, 2026): Should be a template based system. Let me think about it a little.....as long as I have the time :P

BreizhHardware commented

Author

Owner

@EdwardChamberlain commented on GitHub (May 2, 2026):

Whats about splitting all printer items into separate modules, so that the user can design his own dashboard layout? That would be the real deal!

That would be awesome. The added complexity will be significant though so will need to be managed carefully otherwise we risk introducing a vast sea of UI bugs. it also spurs the question about a custom dash (HA style) that lets you bring in non-printer items like queue status, stats, etc. to give users a "home" view that encapsulates everything they want to know in one hit.

In the mean time:
@maziggy Would you be happy with me raising a PR for items 1 and 2 (the header clean up) as a baby step? I think these changes are probably isolated enough that we should make them regardless of how we evolve the printer cards.

@EdwardChamberlain commented on GitHub (May 2, 2026): > Whats about splitting all printer items into separate modules, so that the user can design his own dashboard layout? That would be the real deal! That would be awesome. The added complexity will be significant though so will need to be managed carefully otherwise we risk introducing a vast sea of UI bugs. it also spurs the question about a custom dash (HA style) that lets you bring in non-printer items like queue status, stats, etc. to give users a "home" view that encapsulates everything they want to know in one hit. In the mean time: @maziggy Would you be happy with me raising a PR for items 1 and 2 (the header clean up) as a baby step? I think these changes are probably isolated enough that we should make them regardless of how we evolve the printer cards.

BreizhHardware commented