The index.html.gz file gets served up automatically by FluidNC…I’m sure that there is a way to make it serve up a folder too, but that involves more digging into how FluidNC works than I’ve done
The esp32’s web server is limited. I think the thought here was to just have a single asset only since the asyncwebserver implementation has some issues serving many requests / files like a traditional server based web server.
I think one that that would help is moving the critical info and controls (position, status, start, pause, and stop) to a floating panel on phones so they are always accessible. I dug into the html a bit and came up with this, ignore the placement of other icons as I was picking apart the HTML and CSS.
I like that idea a lot!
Does it impact the desktop version too?
It’s built in bootstrap which is a responsive framework so it has the ability to adapt to mobile devices; however, when I dug into the code the inline images and styles made it very messy and difficult to update so I stopped there. Also, testing locally was not really an option, so you’d have to change some code, upload it to maslow, fire it up, then test on maslow.local so the workflow was a major pain as well.
I’ve built a ton of stuff on bootstrap and it certainly has the ability to have a really clean layout on all devices, but editing the file was a major blocker for me.
Also, to add on here, the gcode preview doesn’t work very well on my iPad or phone. That could use an update as well.
Again, ignore the icons, but the layout is almost the same. This is just a rough test.
I also did an experiment with matching the resolution of the preview area to the browser width while also taking into account the device pixel ratio (standard vs HiDPI) Makes it easier to see the fine details of some things. I have a habit of using my phone to pinch and zoom into the area being worked on to see which depth cut it is on.
I ended up ripping out all the inline styles, reworking the HTML to move things into divs that represented the major areas (preview, gcode, controls, serial), and then applying css grid on all of it to place things as needed.
For local dev, I temporarily removed the connection dialog include from index.html
<file-include w3-include-html="'sub/connectdlg.html'"></file-include>
Then I could build the UI files and then load /dist/index.html in my browser and have enough of the JS working so I can select the Maslow tab and then style things.
Do you want to tag-team a UI refresh on this? I can create figma designs if you can build it.
I run product at a fintech startup and have a background in design and frontend eng. so I’m very well versed in product UI/UX but don’t have the time to refactor the code as well.
I could help with that.
I think that @Carson_Barry had some good ideas to start with:
Yeah, Carson’s suggestion there of rearranging some of the commonly used operations out of a pop-up would be helpful. Counter to that, some protections around define home so it’s not accidentally set somewhere weird would be great. I can’t remember which setting has some sort of double click protection, but that doesn’t really work at all on tablet or mobile devices.
You are thinking of the set XY home position, yeah it is still a struggle on mobile, But better than in the past when you could accidentally tap that when trying to hit something else… which I did several times after swapping a bit mid project.
Exactly. A confirmation modal would make a lot more sense.
@bar I dropped a PR on GitHub with the higher resolution preview if you want to take a look: Use the browser size to determin the preview resolution by tryonegg · Pull Request #49 · BarbourSmith/ESP3D-WEBUI · GitHub
Actually you can do this… I set up some npm scripts to run the python proxy and you can run it on your dev machine on a port and connect to that ip/port from your phone to test (or use a browser with phone emulation…) npm run start
will build and run it. *(not hot-reload, have to restart on each change)
Ha yeah, I said not really since it seemed like a big pain.
FANTASTIC!! I’m sorry for the slow response, I was manning our booth at Maker Faire. This looks great!
After some of the other ideas put forward, I would modify this a bit.
Move distance (both for xy and z) and mm/inch buttons would be on a single line as their own concern, a home button would be added between the Z arrows for the Z axis, and the define home buttons would be on a single line just below the move distance row.
I would also add more padding between all of the buttons to make fat-fingering on a touch screen less of an issue, and double that padding between separated concerns to create a clearer visual hierarchy without relying on color, because colorblindness is not as uncommon as those without it often realize.
Can you mock it up visually so I can work out the code for it? Figma, XD… whatever as long as I can get access to the SVGs, colors, spacing, and such.
The original mock-up I did was in Miro, which doesn’t quite provide that level of UX data, but I can at least quickly modify my previous example to match what I was getting at just now. I’m strapped for time lately, so I’m not in a position to reacquaint myself with Figma and create something from scratch using that tool. That said, the exact spacing I might come up with might not be ideal, so I’d expect it to need adjustment anyway and the extra effort of getting exact values on the “idea-side” of the equation might have been wasted.
I’ll see what I can do about at least getting a visual of what I was saying shared by this afternoon.
What a weirdly long and eventful afternoon…feels like It’s been more than a week…
I actually rethought part of what I said while putting this together, thanks to the top row being 5 buttons.
Just adding some dead zone padding between each button and making some bigger and some smaller.
Ideally, I’d say the Define XY Home and Define Z Home buttons could display the value on a second line and it would give the user feedback when changes are made, as well as let them confidently see what it’s set to at any time.