Oh yeah that is 100% not the intended behavior
Thanks for catching that!
This should have the alert and also stop the movement
index.html.gz (158.8 KB)
Oh yeah that is 100% not the intended behavior
Thanks for catching that!
This should have the alert and also stop the movement
index.html.gz (158.8 KB)
This just seemed like the best place to drop this suggestion (felt like overkill to have a whole thread just to put this forward) for a slight UI rearrangement to the recent update that groups a few things better while also keeping the two set-home buttons separated so it’s not easy to accidentally press the wrong one.
Oooo I like that!
Anyone opposed?
Maybe put a separate z number in-between the z arrows? It looks like it is begging to be there.
Same thing with the home icon, swap where the number is with the home icon, that way you have numbers surrounded by arrows, could get ride of the Distance to move text completely. if that makes sense. Also, have the number look/be like a text box so it is obvious you can edit them and the mm just be a dropdown.
I would heavily advise against this, both as a former graphic-designer-turned-workflow-consultant with a heavy focus on making training documentation, and as a current IT professional and hobby game developer. It introduces ambiguity, which should always be snuffed out as soon as it’s noticed.
That text could be part of the same “cell”, though, and it would be more cohesive. Only issue is it needing to be clear that you need to be able to click both the 100 and the mm to change them.
As for moving the home button, I wouldn’t take it out of the “D pad”, that 3x3 are all buttons that do the same thing (move the sled around). I would just reduce the height of the cells and have that text all on one line.
To be clear, this would be reducing the height of that lowest row by half, and then shrinking the leftmost column’s cells evenly to line up with the bottom of the bottom row.
Don’t get me wrong, I like condensing. I’d really like something like this to be workable:
Only issue is that this makes it unclear if the distance is for Z, XY, or both. I haven’t had my Maslow on in almost 2 weeks, but I remember being able to set Z travel distance, separately and it isn’t even present in this bit. I’m hoping I’m just second guessing myself there, though, and that it makes sense somewhere deep down in the gaps of my memory.
All that said, if you wanted to condense, I would suggest adding some padding between certain buttons so they can be rearranged to look nicer without hugely increasing the risk of misclicks and introduce separation from the D-pad/dist-to-move and the up/down-z buttons to show that the set distance only applies to XY movement.
If that worked out, we’d have that whole “row” under the D-pad where dist-to-move currently is freed up for other buttons. If it were for adding extend/retract, though, I’d put them above this set of buttons.
I think you need to have the Z distance distinct from the XY distance and both available on this menu. Inches or mm would not need to be differentiated as they will always(?) be the same for all axis.
Not as such but I’m going to really pitch not having to change distance all the time. 100mm or more is generally fine for x/y and never for Z so constantly changing this is not a good UX either.
Most other CNC jogger controls are similar to the one on the first tab, which I like, but is not as “touch friendly” as the maslow one. Since I now have a computer out in the garage, personally not important to ME, but I think that in general it is important so people can use smaller devices like phones and small tablets. Maybe a column or row of distances starting 1, 5, 10, 100, 200?
Another thing to consider is that some buttons are only relevant in certain states.
When the Maslow first starts up, retract all is relevant, but calibrate and extend all are not. After using extend all, take slack/calibrate become relevant, and retract all stops being relevant. After taking slack, give slack becomes relevant.
These don’t need to be on the screen in states where they aren’t relevant, so many of them could occupy the same space.
Calibrate could still be tucked away in setup, and all of the rest could live happily in the main menu above the DPad for immediate access.
I really think the Dist to move should be changed to just Move, and should be in the middle between the arrows and xy vs z distances should be different, and all Z actions should be moved together, although less sure about that since defining and moving are different things for sure.
Also, much prefer the simple dark buttons with white text (or vice versa) to the purple, sorry, I know it is company colors, but looks way cleaner.
It is only color that because I made a very quick draft in an online whiteboard that would be easy for me to edit.
I’d like to plan for the future with a “Z touch” and a few macro buttons like in Webcontrol.
Macros could be used for manual router on/off when we incorporate a relay mod.
I like it, but need to keep the home button to simplify getting back to a known place.
Probably put it in the upper right corner, move setup and define xy down, or something like that.
I haven’t tried to tackle any of the big UI changes suggested above (although I think there are lots of great ideas!) because making changes right before going offline seems like a bad idea so I’m going to work on those as soon as I get back.
Here are just a couple fixes to last week’s update. The “Calibration Complete” popup won’t show up until calibration is ACTUALLY complete and the Define XY Home now has a hover text to let you know that you need to press and hold to unlock that button.
index.html.gz (158.8 KB)
Thanks for your prompt response, I will run the calibration again with this version and let you know. Enjoy your break.
Here’s my take. I moved things so that “Units” would be adjacent to both the “Z Move Dist.” and “XY Move Dist.” buttons. I tried to use color to delineate XY functions (purple), Z functions (lavender), XYZ function “Units” (kinda between purple and lavender) and not specifically tied to XY or Z “Setup” (grey)
I like to color idea to help group buttons together based on their function, that will be helpful if we are adding more buttons to the main panel
Layout
I do like the button layout and font used. You can also save some space by using Emojis for the graphics. CSS also supports rounded corners, line weight, shadows, and other stylings. You’ll want to make sure any CSS stylings are “off-grid” friendly as folk might be solar only in the sticks trying to make a cabin with their maslow (using a pocket router or their phone as a hotspot).
Colors
I’m indifferent to the colors so long as they are not garish (like hospital-wall-toothpaste-blue that’s really got green to it – robins egg is a different blue. XD)
Anyway, many times folks who are working with colors tend to overlook all the different kinds of color blindness that’s out there. I have at least a half dozen immediate co-workers each with a different color blindness.
So as much as I like the gentle fuchsia purple (which may work), please make sure not to make the Maslow’s operation harder (or ugly) for a percentage of its community – by something easily avoidable.
If folks want to really go wild, maybe have a default theme that’s colorblind friendly or a classic B&W. Then use a simple stylesheet color changer for the base color of the theme that saved (fg, bg, font) … at least for the widgets (buttons, checkboxes, etc.) Then the settings only needs to store 3 hex RGB values. The style sheet can take care of any gradients.
(And if there’s DANGER button, don’t forget HTML still has the <blink>
tag. XD
Cheers.
Good point about color blindness. I just checked my design using Coblis — Color Blindness Simulator – Colblindor and because my design doesn’t rely on hue differences (just lightness and saturation) it seems to work for a variety of color perceptions. While looking at it, I realized that I should have made “Define XY Home” and “XY Move Dist. 100” white for consistency.
(I’ve made a new thread so this doesn’t continue to derail this one)