Some notes from a cutting session I had last night

[roel-v]

So I cut the majority of the parts of some shorts in preparation for summer last night. It was the first time in a week or so I used PP as I (again) haven't been able to keep up with development. I tried to use this session as a dogfooding session, I tried to approach it going in with no preconceived ideas and see how things work out for me. This was my first time cutting a pattern that is both multi page and multi layer. Overall, it was a rather frustrating experience, partly because of projector connection issues and partly with the PP software. I'm posting this in 'discussion' as I don't really have concrete ideas on 'solutions', these are not 'fix this specific shortcut not working on Chrome' style issues, more a complete experience. Anyway so (each point is not necessarily one single separate issue):

• It started with the site not loading for me, or only very slowly and intermittently, after repeated hard reloads. This was about 14 hours ago from the time of this post, I don't know if there were any known hosting issues, and maybe it even had to do with the wifi connectivity in my sewing room (although it works fine now), but it reinforced the notion in me that a standalone Electron build is a useful thing. I tried several browsers and the app wasn't cached on Chrome, so it didn't work there, and it was quite frustrating that a bunch of things had changed since the last release leaving me not knowing what is what. A locally installed version at least gives me the option to decide for myself when to expect changes in behavior of the app.

• This loading problem was exacerbated by the language switching not being really offline; it seems a bunch of things are reloaded when you switch language causing the 'loading' spinner in the browser tab to keep going and it's not quite clear to me what of those things are important and what not (like, I don't mind the Youtube vid not loading, but I do want to know if I'm getting the latest version of the app or am I using a cached version?) Switching between Firefox and Chrome in an attempt to see if that was a source of my issues only made it worse, as I have no idea about and not really a way of knowing (without going deep into MDN) to what extent each browser works as a PWA 'container'.

• Then I got to calibration. I'm not a fan of the selected corner now being in the same color as the grid. It made it harder to see what I had selected and what is moving when I press a key; especially during the first half of my cutting session where I was still wrangling my Miracast and Chromecast dongles and had serious lag between screen- and tabletop/projection movement. Them not being rainbow colored is fine, but the dashed-is-selected is (to me) an aesthetic progression but usability regression.

• The edges of the calibration raster can now be moved but only by mouse it seems? I understand why this person wanted this, and maybe it's a useful feature for other use cases too, but the edges then not being included in the keyboard tabbing sequence feels incoherent. Now I'm not saying either that they should be included because that would mess with the efficient 'set the corner markers and done' workflow, but it's one of the several issues that, combined, makes things feel half baked. Again of of those 'don't have a solution' issues.

• (There were two small features I missed but I filed those as separate issues/feature requests)

• Increasing the line thickness was really wonky. I was using two A0 pages that were joined by PP. When I clicked on the 'up' arrow in the spin control that controls the line thickness, it took between 5 and 10 seconds (quite a lot of variation) before something actually changed on the screen. The text changed very fast, the lines took a long time. I haven't investigated - could it be that all layers are processed regardless of whether they're showing or not? Turning layers on and off also caused the same delay. Or that my PDF has all dashes of the dashed lines as separate objects instead of one curve with a certain line style? I also think that clicking 'up' several times does this long calculation several times, instead of aborting earlier ones? Again didn't investigate in detail because I wanted to get on but had I been a first time user, I'd have thrown in the towel here. The laptop I was doing this on isn't very recent, but it's no potato either, and even the 16 core Ryzen 9 I'm typing this on has considerable lag doing these operations.

• Related: turning multiple layers off (say you have S, M, L, XL etc and you quickly want to turn everything except one off) doesn't work well because the UI blocks while turning one off, so you have to click, wait for the UI to become responsive (which you don't know when that happens and if you're too fast to try, you trigger a longer wait) and then do the next one.

• The layers, overlay options and stitch menu all are essentially the same 'class' of user interface element but they all work differently, and it looks and feels very janky. There is an option to hide the menu which hides the stitch but not the layers menu for no discernible reason, likewise the 'overlay options' can't be pinned (not that I wanted to, but why is it different from the others?), the layers menu has scroll bars but without scrolling area so it's just grey bars, the menu hierarchy is visually incomprehensible,

This is about what I remember and the few quick notes I took. If I would look at this as a new user, who happens to be unlucky and starts out with a multi page multi layer PDF, and if I weren't quite tech savvy, I would have have several points where I would have given up. Even as someone who knows how things work and what's happening under the hood, it was quite frustrating at times. Again I don't have a simple fix, and it's not that things should cater to my personal issues, but I did think this would be worthwhile to write up like this because the users you lose because of issues like this are unlikely to be sufficiently invested to report upon them.

The good news is though that I did get most of my shorts cut so that's at least a start to actually finishing a garment for once. Glass half full!

[roel-v]

PS if someone wants to replicate the perf issues email me and I can get you the PDF I was having them with.

[courtneypattison]

Thank you so much for the thorough review! I'm sorry the process was so frustrating. PP has a long way to go.

• It started with the site not loading for me, or only very slowly and intermittently, after repeated hard reloads. This was about 14 hours ago from the time of this post, I don't know if there were any known hosting issues, and maybe it even had to do with the wifi connectivity in my sewing room (although it works fine now), but it reinforced the notion in me that a standalone Electron build is a useful thing. I tried several browsers and the app wasn't cached on Chrome, so it didn't work there, and it was quite frustrating that a bunch of things had changed since the last release leaving me not knowing what is what. A locally installed version at least gives me the option to decide for myself when to expect changes in behavior of the app.

There were a lot of pushes to the beta branch last night around the time you would have been working on it, that perhaps caused some issues. One of the pushes was to fix a performance issue with line thickness being reapplied for every offset change so they may have been relevant as well. Electron apps unfortunately make installation more difficult for users, requiring them to bypass security warnings and managing multiple versions adds quite a bit of overhead to debugging and the release process. It would be great to target a single platform though, e.g. Chrome because many of the lag issues are from pollyfills added for features supported in Chrome/Edge only.

• This loading problem was exacerbated by the language switching not being really offline; it seems a bunch of things are reloaded when you switch language causing the 'loading' spinner in the browser tab to keep going and it's not quite clear to me what of those things are important and what not (like, I don't mind the Youtube vid not loading, but I do want to know if I'm getting the latest version of the app or am I using a cached version?) Switching between Firefox and Chrome in an attempt to see if that was a source of my issues only made it worse, as I have no idea about and not really a way of knowing (without going deep into MDN) to what extent each browser works as a PWA 'container'.

Maybe we should put the version number on the main page now? I'm starting to setup releases that are documented in the CHANGELOG. Also, I'll add an issue for adding better offline support. Only visited pages are cached. I should be able to precache the whole site, it's just a matter of learning how to do it.

• Then I got to calibration. I'm not a fan of the selected corner now being in the same color as the grid. It made it harder to see what I had selected and what is moving when I press a key; especially during the first half of my cutting session where I was still wrangling my Miracast and Chromecast dongles and had serious lag between screen- and tabletop/projection movement. Them not being rainbow colored is fine, but the dashed-is-selected is (to me) an aesthetic progression but usability regression.

We can change the color (along with size) to indicate which corners are selected. I plan on supporting chromecast natively for desktop chrome users which will eliminate the lag issues but it requires a lot of refactoring in the codebase first.

• The edges of the calibration raster can now be moved but only by mouse it seems? I understand why this person wanted this, and maybe it's a useful feature for other use cases too, but the edges then not being included in the keyboard tabbing sequence feels incoherent. Now I'm not saying either that they should be included because that would mess with the efficient 'set the corner markers and done' workflow, but it's one of the several issues that, combined, makes things feel half baked. Again of of those 'don't have a solution' issues.

Edges can be moved by keys as long as they are selected, which is only possible using the mouse/touch. After an edge is selected, tabbing will select the next edge. Should we add a way to move from corner to edge via a key combination, like ctrl+tab? I didn't want tab to go corner -> edge -> corner for people who don't want to adjust edges.

• Increasing the line thickness was really wonky. I was using two A0 pages that were joined by PP. When I clicked on the 'up' arrow in the spin control that controls the line thickness, it took between 5 and 10 seconds (quite a lot of variation) before something actually changed on the screen. The text changed very fast, the lines took a long time. I haven't investigated - could it be that all layers are processed regardless of whether they're showing or not? Turning layers on and off also caused the same delay. Or that my PDF has all dashes of the dashed lines as separate objects instead of one curve with a certain line style? I also think that clicking 'up' several times does this long calculation several times, instead of aborting earlier ones? Again didn't investigate in detail because I wanted to get on but had I been a first time user, I'd have thrown in the towel here. The laptop I was doing this on isn't very recent, but it's no potato either, and even the 16 core Ryzen 9 I'm typing this on has considerable lag doing these operations.

The performance issues were caused by adding line thickness. Line thickening is done in Javascript by manipulating the rendered pixels and is super slow and locks up the UI, but works everywhere; it could be improved by moving off the main thread but it's still expensive to do any pixel manipulation in Javascript. Desktop Chrome supports SVG filters on CSS which massively improves the performance hit so I've pushed that change this morning to main/beta. The varying levels of support for SVG filters and mix-blend modes in the various browsers/device combinations has been a pain point this week. In the future, a WebGL implementation may be the implementation that is performant everywhere.

• Related: turning multiple layers off (say you have S, M, L, XL etc and you quickly want to turn everything except one off) doesn't work well because the UI blocks while turning one off, so you have to click, wait for the UI to become responsive (which you don't know when that happens and if you're too fast to try, you trigger a longer wait) and then do the next one.

Changing layers cause the pdf page to rerender and reapply the line-thickness which is again locking up the UI; it should be fixed on Chrome in main with the SVG filter now, but will remain slow in Firefox/Safari for now.

• The layers, overlay options and stitch menu all are essentially the same 'class' of user interface element but they all work differently, and it looks and feels very janky. There is an option to hide the menu which hides the stitch but not the layers menu for no discernible reason, likewise the 'overlay options' can't be pinned (not that I wanted to, but why is it different from the others?), the layers menu has scroll bars but without scrolling area so it's just grey bars, the menu hierarchy is visually incomprehensible,

I'd like to defer to @hluedeke on this one, but she's crazy busy right now though so I would be very surprised if she has time to work on this. I suck a UX/UI stuff so I'm not sure what would make more sense. The scrolling in the layers is for when there are lots of layers. We could conditionally make it scrollable if there are an overflowing amount of layers. Or if you have any menu redesign ideas, I'd be happy to make the changes if you have the design ideas.

Going forward, I'm trying to do around a weekly release that's a bit more structured. Would you be ok with me tagging you when I think the release is ready to see if you have time to look it over before I push to main? I'd like to slow down to less frequent releases in the future but there are a lot of fixes that I don't want just sitting in beta. E.g. this week, moving the PDF with the arrow keys had a bug where it was moving 1/16 of a pixel on press. Also line thickness didn't work on coloured lines and annotations were blocked.

[hluedeke]

I'd like to defer to @hluedeke on this one, but she's crazy busy right now though so I would be very surprised if she has time to work on this.

Unfortunately, this is accurate right now. I would love to help make this cohesive, but it will probably be a few weeks before I can get to it! But, as I’ve said before, don’t let me hold you up!

[roel-v]

PP has a long way to go.

PP in any state is obviously such an enormous improvement over the state of the art of just two months ago, that all issues now are bikeshedding in comparison; I just didn't feel the need anymore to preface my laundry list of whining with that, as I think that by now you know that I'm coming from a place of trying to help out rather than criticize, so please do see it in that light :)

Electron apps unfortunately make installation more difficult for users,

Yeah we talked about that before, I mostly put that in as a note to myself to pick this up, even if just semi-hidden somewhere for more technically adept users.

I plan on supporting chromecast natively for desktop chrome users which will eliminate the lag issues but it requires a lot of refactoring in the codebase first.

The lag wasn't even the worse for me, to me it seemed that the rendering on the projected screen was done differently from on my main screen, i.e. my tab or screen content wasn't just being mirrored 1:1, it tries to do all sorts of 'optimizations' which just cause rendering artifacts (when using a real Chromecast, with an Anycast/generic Miracast I had connection problems). Maybe the changes you have in mind cater to that different rendering path as well.

Should we add a way to move from corner to edge via a key combination, like ctrl+tab?

I don't think so. I don't have any suggestion for improving my experience on that point either, I don't think I/another user would find out about or remember additional shortcuts for seldomly used features like this. It just felt weird and maybe it's an artifact of me being used to the old behavior and it's just a matter of adapting mentally, which any new user wouldn't have to do.

_Line thickening is done in Javascript by manipulating the rendered pixels and is super slow and locks up the UI, but works everywhere; _

Oh right for some reason I was under the impression it rendered PDF to SVG first, I thought this was something idiosyncratic with my particular PDF. Never mind then.

I'd like to defer to @hluedeke on this one, but she's crazy busy right now

Oh I understand, it's a tough problem that can't be solved quickly, and related to the other discussion point on menu organization.

Would you be ok with me tagging you when I think the release is ready to see if you have time to look it over before I push to main?

Yeah sure, but I'll already warn you in advance that I'll be away quite a bit next 4/5 weeks so I'm not reliable like that. It would give the translators a chance to catch up, too, so that any new release has updated translations too.

[courtneypattison]

Okie doke, I'll tag you in case you have time! Maybe I'll let it sit for a day and then push to main if you folks are too busy to review. I could make a stable branch stable.patternprojector.com if you want to maintain something that moves a bit slower.