Allow printing longer labels

[sabeechen]

I often find myself wanting to print labels longer than the maximum 18 or 20 characters enforced by the printer website, so I'm making this issue a starting point to discuss how to implement that. To me it looks like there are two main things that would need to be changed to accomodate this:

1. The "PRINTING" screen on the microcontroller would need to be changed to indicate the progress of a label that doesn't entirely fit on the little oled screen.
2. The label-dependent-jingle should shorten itself somehow for very long labels. Otherwise it just kind of drones on for an uncomfortably long time and doesn't feel "fun".
3. The website would need to be changed to also render its textbox in a way that doesn't choke for longer strings. This should be done in a way that doesn't impede its currently very mobile-friendly sizing.

[sabeechen]

To handle (1), here is what I've come up with for changes to the PRINTING screen:

• Add a thin border to the label text, to clearly indicate where the start and stop of the label is.
• As the label prints, scroll the label left when necessary to keep the current point of printing progress in frame.
• When the label text bleeds off either side of the screen, render a "jagged edge" as a visual indication that the label doesn't end there.
• Increase the character spacing by 1px for readability and to better replicate the final print spacing.

Here is a demo I've made that shows this in practice for a long label:
https://photos.app.goo.gl/2bAFpN6qahmURqno8

And here is a demo showing how it looks with a shorter label.
Bonus enhancement: I also made it render glyphs for the special characters (♡☆♪€) instead of the ASCII replacement characters.
https://photos.app.goo.gl/mQt8DijTwiNLRGek8

In addition to allowing longer labels to be printed, I think this makes the screen feel like its "simulating" the physical label being printed a bit better. @andreisperid, what do you think?

[andreisperid]

Hi @sabeechen 👋

That's an interesting demand and I understand that sometimes we just need longer labels :)

---

1 — device

Your solution works very well. Maybe for the visual indication we could use "..." instead of the jagged edge, because the latter might lead the user to think that's a cutting point.

Maybe something (schematically) like this:

PS: notice the "..." are aligned vertically to the middle and outside the borders, to make sure they are not part of the label's content.

We'd loose some space, but it makes for clarity... What do you think?

The overall readability is much better!

... and about the glyphs, AMAZING 🎉 ! That clunky characters really bothered me! How did you deal with the data transfer through network? Did you keep the characters transfer and just re-converted them for the display?

---

2 — music

Perhaps we could clamp the music to the first N characters. Do you think the way it is right now it too long already?

---

3 — web app

This is what concerns me the most, as we'd need a way to easily pan sideways... I tend to think a tridimensional or skeuomorphic approach might work, this way we could compress the extremities. Check out this ref (ingenious!) https://youtu.be/mNow_mqMSRI?t=197 (more here if you want 🤓 https://jackrusher.com/classic-ux/)

[sabeechen]

I'll give a shot at putting ellipses on the oled screen and see how it looks. Maybe they only need to be on the right, to save space? I don't think that would introduce ambiguity about whats going on. I made the glyphs work by making the webserver multicharacter unicode-aware, which was simpler than it sounds. The hard part was getting everything to display correctly using different glyphs from different fonts with different heights and widths. I'll probably put this into a separate PR and check it in, since its useful separately.

For the music, I think maybe 15 notes should be the max? that makes the jingle a couple seconds. I think the song should always be the same for the same label and always different for different labels, so I'm thinking something that compresses multiple characters into a single note (with some kind of deterministic hashing) for longer labels makes sense. I'll try out a few algorithms and try to keep it simple.

In the web app, I don't think you can do much to visually distorts the label textbox without writing a completely custom control. Browsers seem to be pretty limited in how you can style a textbox, though I don't have a lot of in-depth knowledge about it, input elements are deceptively complex.

[sabeechen]

How about like this (with some dramatic shaky cam!):

[sabeechen]

Although I like the jagged edges a little bit more, I don't feel very strongly about it and think both are clear and work well. I kind of like only having one side show a continuation indicator ("..." or a jagged edge) since it conveys there is work to be done to the right and none to the left.

[andreisperid]

Amazing @sabeechen

The visual solution is neat!

Regarding the music: what about 16 notes total instead of 15? My amateur musician background is screaming to have four 4/4 measures :P

The idea to create a compressed music is nice. Perhaps we could create a seed from the hash to distribute the time measures inside these four 4/4 measures. Pretty modular...

About the longer label, maybe a horizontal scrollbar will do it, what do you think? Or any other kind of cue that shows that there is more content than visible, at the same time allowing for easily knowing what you are seeing and navigating laterally.

[sabeechen]

For the screen: sounds good to me. I'll make a PR that combines the symbol support and "..." scrolling (its pretty tedious to separate them).

16 notes sounds fine to me. I'm afraid I don't understand what you mean by distributing the time measures. Do you mean make some notes longer, producing a more varied melody? Or perhaps that the jingles would always be in multiples of 4 notes?

A scrollbar would probably be easiest :) Although each browser engine handles scrollbar customization in a frustratingly different way, I'll play around with some CSS to see if I can make it consistent across platforms without using one of those bulky libraries. I'll handle this last I think, CSS is the devil.

[andreisperid]

No problem for combining both issues together.

For the time measures, perhaps for now we can just clip the tones beyond 16 characters, what do you think?

Regarding the scrollbar, all right! If you want, in this case we might collaborate in a separate branch to experiment a few solutions together. For instance: where should be the bar (above or below), the visual aspect, the size, etc... Then after we find out a nice combination, we can merge back in the master branch.

[sabeechen]

This sounds good to me. I'll make a branch we can both edit at will, when we land on a solution we can just squash merge the changes into main.

I've done a little experimenting with whats possible. It seems like there are a couple different paths we could take:

• Use the native scrollbar: This is the simplest solution, but the limiting factor will be Firefox, which only allows very limited customization of the scrollbar. It lets you choose between two widths (thick and thin), choose the track and thumb colors, and is always anchored to the bottom for horizontal scrolling. To have a consistent appearance across browsers, we would need to style chrome/safari to match firefox's style.
• Use a custom scrollbar library (eg simplebar). I haven't tried it out, but seem to be how most websites do it to get browser consistent scrollbars. Its just a 5kb javascript file, so maybe that would end up being easier?

To make iterating on the javascript/html/css easier I wrote a little python server that emulates the E-TKT so I can test changes without having to upload it to the device every time, all you have to do then is edit the file and refresh the page. I'll include that in the branch I make.

[sabeechen]

Here is the branch: https://github.com/sabeechen/E-TKT/tree/textbox-scroll
I've added you as a collaborator.

To run the little python server (assuming you have python already installed):

pip install aiohttp
python -m src.simulator

And the open up https://localhost in a browser. I haven't made any UI changes in the branch yet, but I'll start soon. The simulator also simulates printing progress, settings, etc so we can get all of that UI right too.

[andreisperid]

I think the custom scrollbar might work, 5kb doesn't seem a problem at all...

I'm curious to see if we might need a thicker scrollbar on mobile (in case there is ambiguity between placing the caret and actually scrolling)

Good idea about the branch and python server, I'll set it up here and will definitely ease the process :)

[andreisperid]

@sabeechen I've just pushed a proposal to your branch, take a look at 08a94f3

• centered text when smaller than width;
• automatically aligns to the right when bigger;
• improved overall matching of helpers (yellow and blue) and the actual input text;
• while printing progress, automatically scroll the bar to keep up with it;
• removed full length margin mode (dropdown);
• adjusted the size preview to fit three digits (maybe there should be still a max label size?);
• using a webkit styling for the scrollbar (not sure if will be cross compatible, lets see);

PS: still not taking in account different browsers, I've tested on chrome for now

Thank you again for creating up the python server script, super useful!

[sabeechen]

I'm glad the server worked! I'm always worried about wearing out the flash on microcontrollers, even if I'd have to upload thousands of times and never realistically hit it. I'm probably just neurotic.

I like the changes, I think it looks cleaner overall and the margin options are much clearer. My wife was always confused about what the margin options did even when I explain it :) She loves the little label maker more than I do, by the way.

Browser compatibility is still a problem but solveable think. Safari desktop and chrome both respect the scrollbar styling, but:

• Safari iOS doesn't display a horizontal scrollbar, ever, as far as I can tell in my testing. You can still swipe to scroll horizontally, so maybe its just how apple does things? If its the UI paradigm users expect on iOS maybe its a non-issue.
• Firefox does its whole own thing for scrollbar styling. They only give you control over the thumb and track colors but insist on rendering it as an overlay on top of the textbox, which makes it clumsy to click the text on an element this vertically thin. I suspect they give less control over the styling to prevent abusive websites from making unusable scrollbars, which is a hard reason to hate. I think it could be fixed by adding an element that pads out the scroll area a little below the text input, so the scrollbar has space to breath when it appears.

I'll see if I can check in something that makes it render consistently on firefox at least. Its surprising to me that making a scroll area work well is such a hard problem.

Sorry about not checking in anything else to the branch recently like I said I would, I've been swamped lately with IRL. I'm glad to have an idea of what you'd like it to look like to work from, that'll help me get traction.

[andreisperid]

Happy to know that your wife has been using it! And also that you find it better now :)

Regarding the browser's tower of babel, I did a quick test here with what I've got in hand:

Desktop (win10)

• Chrome: alright;
• Firefox: shows the scrollbar perfectly and with the right color, but on the other hand shows the arrows;

Macbook (OS X)

• Chrome: alright;
• Firefox: didn't test, but expect not much different than the desktop;
• Safari: alright (but I've noticed the dropdown menu is fugly with some old "aero" style, will check that later);

Mobile (android12)

• Chrome: alright
• Firefox: shows no scrollbar at all (which is better than what happened to you)

---

It wasn't clear if your experience with Firefox was on mobile, but I guess so. Do you think it might be outdated? Strange to have a different behavior than mine, even with different platforms..

As mine is updated and expect it to be the de facto expected bahavior, I will try to add a clue to reinforce that there is content overflowing (affordance to scroll).

I've thought about something similar to the "...", that might appear in on side and/or another to indicate the user might scroll. Pretty easy to script that.

PS: don't worry about the rhythm, this has been really enjoyable, I've been learning a lot throughout the process!

[sabeechen]

I'm using Firefox desktop, though I've been testing on mobile too.

Firefox verifiably doesn't support the -webkit-scrollbar styles, though I think firefox will use them as a hint if they're present, which is probably why the colors look right.

The overlay scrollbars on desktop I'm seeing are a windows 11 thing (users can disable it), here is what they look like for me:

Its only that big if you mouse over, still not great though. you're right that on windows 10 firefox renders traditional scrollbars by default. Who knew all this was so complicated?

On firefox mobile, I can see the scrollbar but it looks like it picked up the lower alpha values you have configured so its almost invisible. Surprised they let that happen, I put some arrows on the start and end in this screenshot:

I'm very close to having a combination of css and javascript that works everywhere, but I had to change around a bunch of stuff to get there (in a good way I think). I've got a set of changes I'll submit today, I think you'll like it.

[andreisperid]

So the difference is between win10 and 11...

For mobile, great, exactly as in mine. You might see there is a small extra padding below the bottom yellow bar, it is intended to give an extra space to the scrollbar (could be bigger in mobile perhaps, to encompass this thinner bar inside?)

Meanwhile, I'm working on that helper ... | TEXT INPUT | ... that is modular and will not conflict with yours.

[andreisperid]

Its working 279271d

Whenever the tag is bigger than the input, when the scroll is not exactly at ends, it shows a "..." at each side accordingly.

I think that helps with the scroll affordance and perhaps we can try to hide the scrollbar on mobile (but keep the "..." on all platforms).

What do you think?

[sabeechen]

What do you mean what do I think? I fucking love it.

[sabeechen]

I've added a bunch of logic to handle different browser eccentricities:

• I've verified that iOS never displays a scrollbar, which I suppose iOS users are comfortable with.
• I've added lots of fancy CSS selectors to make the scrollbars as visually consistent on firefox desktop and mobile as possible. This is accomplished by adding a position: sticky element inside the scroll container that reserves space for the firefox scrollbar to render instead of on top of the textbox like it wants to by default. Mobile and desktop are handled according to different amounts of space they require.

I also made a number of other quality-of-life changes that handle a bunch of "jank" someone could run in to by messing with the UI:

• refactored some javascript to use consistent naming
• Fixed a bug that prevented "enter" from starting a label print
• Made the textbox always have a set minimum width instead of resizing on odd/even characters for short labels. In the future, I'd like to make the margin size a parameter passed in to the API (which the device computes) so it becomes impossible to ask the printer to make a label to short to grab and tear off from the machine.
• Changed inputmode="search" to enterkeyhint="send" to make mobile keyboards show a meaningful alteternative to "Enter" or "Search".
• Simplified the layout of elements near the label textbox (I got frustrated tryign to sort out all the margins and different container alignments). I'm pretty sure its nearly pixel-perfect to the way it was previously rendered.
• Used javascript to compute the needed textbox size instead of an invisible helper element.
• Fixed some jankiness that happens when you write a very long label and then delete it.
• Anchored the scroll window to the left or right margin if you move the caret position to the beginning or end.
• When changing the label text, the scroll window now anchors to the starting or ending margin depending on where you're editing (instead of always at the end)
• Automatically hide the scrollbars when they aren't needed to accomodate a larger label.
• Synchronized the progress bar to always increment on character boundaries.
• Synchronized scrolling of the progress bar while printing to center on the progress bar boundary (similar to how the E-TKT OLED shows it)
• Disable scrolling (by the user) and hide the scrollbar while printing is in progress.
• Changed the start-up splash animation to give it a little more "ker-chunk"

Here are examples of how each scrollbar renders on each platform. True consistency could only be achieved by someone truly mad, but I think the scrollbars renders useable and well across the board.

Android Chrome

Android Firefox

iOS chrome

iOS Safari

MacOS Chrome

MacOS Firefox

MacOS Safari

Win10 Chrome

Win10 Firefox

Win11 Chrome

Win11 Firefox

[andreisperid]

Wow, impressive @sabeechen ! It is really neat and your attention to details is amazing!

Just thinking here about how we could keep everything below the text box in the same place independently if there is a scrollbar or not. Right now everything is pushed below.

Maybe compute the height for the "text-form-scroll", then recalculate it's own margin (or the top margin from the element below)?

[sabeechen]

Done here, though I accomplished it by setting the margin of #text-form-border instead. I also got rid of the height shifting when printing starts/finishes.

[andreisperid]

That's great Stephen, thank you!

I was reviewing our whole discussion and the music (max 16 tones) was left to be done - a65b424

And I felt maybe it would be a good idea to limit the number of chars input to 247 per round, which falls just below 1 meter (helps keep the length preview under under 999, avoid the extra digit that breaks the layout) - ad83a29

Do you want to create a pull request for me to merge? Or is there anything else you would like to do before closing the issue?

[andreisperid]

While testing here I thought that it would be a nice idea to add a click functionality to the "..." so they jump to the extremities. It might be useful with super lengthy labels.

[sabeechen]

Its a nice convenience feature, I think. Mind if I add a slight highlight to the "..." background shadow on hover?

I completely forgot about the music! I see you already submitted the change to limit to 16 characters, but I want something more fun! Some options I've been considering:

• Idea 1: Any label under 10 characters is unchanged.
  For longer labels the length of each note gradually shortens from 50ms/note to 5 ms/note starting at the 5th character/note. The idea would be to make a very longer label (30-50 ish character) play for less than a second and cescendo into a caucaphony. I'd need to experiment to see if it actually sounds good naturally.
• Idea 2: "Compress" anything longer than 16 notes into 16 notes. Id iterate through the label, alternating forwards and backwards, and re-hash each character into a different note. so for a 17 char label (vs 16), only the last note would be different, for 18 characters, the last two would be different and so on. This would have the advantage of sounding very similar to the way notes play now.

[sabeechen]

Oh and naturally:

• Option 3: Leave as is, 16 note cutoff works fine.

[sabeechen]

I've got some samples of speeding up the music (audio only). I played around with different speeds and feel like this matched what I had in my head initially:

• Longest note is 100 ms
• Shortest note is 20ms
• After the 16th note, each note is 2ms shorter
• Pause is always 1/2 the note duration

Label: "Short Label"

short.mp4

Label: "longcat can be really long but only if you scratch his belly" (62 chars)

long.mp4

I think its kind of fun but I'm not married to it. Hearing the crescendo and then the ker-chunk of the machine kind of fits together well, imho. What do you think?

[andreisperid]

Nice idea about the background shadow, go for it!

About the music: I love it!

And even before reading your point on the continuity between sound and the stepper, I had the same impression. That's a nice conceptual connection!

[sabeechen]

Both are done. I also configured the scroll tips to hide while printing, since the UI manages scrolling while printing.

You feel like there is anything left? I'm eager to merge.

[andreisperid]

Let's do it!

[andreisperid]

Nice job @sabeechen ! 😃