Email or username:

Password:

Forgot your password?
Doc Edward Morbius ⭕​'s posts Post Back to profile
Top-level
Doc Edward Morbius ⭕​

@zens Interfaces are one possible exception.

Even there, unless you're looking simply at inputs (such as keyboards), probably not.

And there are almost always better options, e.g., using the goddamned system keyboard. Whether that's hardware or a soft keyboard.

I swear to His Noodliness, if I ever find an app substituting for my default keyboard I'll set a flamethrower on it.

I'm already mad as hell over the Death of the Scrollbar.

ello.co/dredmorbius/post/0hgfs

Also congratulations: immediately after my tooting that I'd refrain from comment, you've provoked / incited me to comment 😺

5 Jul 2022 at 6:42 | Open on toot.cat
15 comments
Luci ‘O Lantern

@dredmorbius i mean, i don’t see how system keyboard is an option for desmos or pico8 but knock yourself out i guess.
unless you’re of the opinion we shouldn’t have game engines or graphing calculators on the web. or any other kind of app. you’re welcome to that long departed boat

5 Jul 2022 at 6:45 | Open on merveilles.town
Doc Edward Morbius ⭕​

@zens There are some instances, yes, in which that's defensible, but it's still really fraught territory, particularly in Web (as opposed to App) space.

If you want to provide a keyboard that is NOT standard alphanumerics, perhaps. Providing additional or unavailable functionality is defensible. Replacing existing functionality with the same but in an unfamiliar manner is NOT.

If you're simply replacing the standard keyboard with equivalent functionality, then you'd better have a really good reason for doing so. And the answer is still probably "no".

A calculator app might be an example of legitimate use. Games effectively are interfaces in many respects, and likewise.

(Implementing either as websites rather than apps is ... somewhat problematic, but that's another story.)

1/4-ish

@zens There are some instances, yes, in which that's defensible, but it's still really fraught territory, particularly in Web (as opposed to App) space.

If you want to provide a keyboard that is NOT standard alphanumerics, perhaps. Providing additional or unavailable functionality is defensible. Replacing existing functionality with the same but in an unfamiliar manner is NOT.

5 Jul 2022 at 14:39 | Open on toot.cat
Doc Edward Morbius ⭕​

@zens

A further challenge is that if you are providing a specific input mechanism in an environment in which display characteristics very tremendously (in size, colour rendition, persistence, contrast, position relative to the operator, etc., etc.) you'd best be taking all of that into account. Static assumptions have a strong tendency to be violated.

There's an example of this I've created myself: my "Motherfucking Website" variant tends to work extremely well on emissive colour displays from 3" to 40" --- it handles size variation well. It's not unreadable on e-ink by any means, but the variance from strict #000 on #FFF colour theme means that contrast is reduced, and I really should address that (@media queries are an option, they're cussedly unreliable).

codepen.io/dredmorbius/full/Kp

2/4

@zens

A further challenge is that if you are providing a specific input mechanism in an environment in which display characteristics very tremendously (in size, colour rendition, persistence, contrast, position relative to the operator, etc., etc.) you'd best be taking all of that into account. Static assumptions have a strong tendency to be violated.

5 Jul 2022 at 14:39 | Open on toot.cat
Doc Edward Morbius ⭕​

@zens

It seems to me that apps handle this far more consistently than websites, and even apps often don't do all that well in the smartphone (small, colour, bright, fast) to e-book (large, B&W, reflective, low-contrast, slow) transition. Even just smartphone (3--6") to tablet (8--13") shows many warts with respect to sizing and positioning.

One trend that works poorly, e.g., dark vs. light modes. Apps which insist / default to a dark-mode display, which incidentally includes tools such as keyboard apps (e.g., Hacker's Keyboard, which I use), and command-line tools (Termux), are really hard to see and use. Fortunately, both have light modes which can be toggled.

3/4

@zens

It seems to me that apps handle this far more consistently than websites, and even apps often don't do all that well in the smartphone (small, colour, bright, fast) to e-book (large, B&W, reflective, low-contrast, slow) transition. Even just smartphone (3--6") to tablet (8--13") shows many warts with respect to sizing and positioning.

5 Jul 2022 at 14:40 | Open on toot.cat
Doc Edward Morbius ⭕​

@zens

Two of the amusingly non-cooperative tools are Dark Reader, a Firefox extension which can be used to change website themes (including having a light mode), and Mastodon. Both tools / sites themselves cannot be toggled to a light mode in many cases (e.g., when viewing a Mastodon site whilst logged out / to which you're not a member). This is endlessly frustrating.

Not zoom-related, but a case of designer failing to consider the user and their hardware capabilities / visual limitations.

4/end/

@zens

Two of the amusingly non-cooperative tools are Dark Reader, a Firefox extension which can be used to change website themes (including having a light mode), and Mastodon. Both tools / sites themselves cannot be toggled to a light mode in many cases (e.g., when viewing a Mastodon site whilst logged out / to which you're not a member). This is endlessly frustrating.

5 Jul 2022 at 14:40 | Open on toot.cat
Doc Edward Morbius ⭕​

@zens Oh, and for my preferred e-ink browser, EinkBro, which has an integrated "light mode" toggle for websites .... Mastodon fails to cooperated. It remains dark mode.

Fortunately, I can use Dark Reader to make Mastodon and GlitchSoc sites light-themed on my e-ink tablet, when reading w/o being logged in. But that's only available on the Firefox / Fennec Fox browser.

(I've been meaning to raise the issue with both Gargron and EinkBro.)

5 Jul 2022 at 14:54 | Open on toot.cat
Luci ‘O Lantern

@dredmorbius is it at all possible to install a tampermonkey extension ? a lot of this sounds correctable with user css.
not that it absolves the site designers of course

5 Jul 2022 at 14:56 | Open on merveilles.town
Doc Edward Morbius ⭕​

@zens Keep in mind that the two browsers with greatest use today, Safari/iOS and Chrome/Android do not support extensions at all.

Firefox/Android (or Fennec/Android) do support LIMITED extensions. This includes DarkReader (previously mentioned), but not either Stylus (CSS manager) or Tampermonkey (Javascript manager).

My strongly preferred e-ink browser, EinkBro, does not support extensions at all, though it has some integrated tools: font zoom, White Background, JS toggle, and a few others.

(It also defaults to having a touch-area based page-based navigation, which is the real killer feature, as scroll and e-ink play very, very, very poorly. Yes, you can still scroll, but it's not necessary much of the time, and there are other options.)

So no, Tampermonkey or similar CSS/JS managers really doesn't address the problem here. I'd love it if they did.

@zens Keep in mind that the two browsers with greatest use today, Safari/iOS and Chrome/Android do not support extensions at all.

Firefox/Android (or Fennec/Android) do support LIMITED extensions. This includes DarkReader (previously mentioned), but not either Stylus (CSS manager) or Tampermonkey (Javascript manager).

5 Jul 2022 at 15:04 | Open on toot.cat
Luci ‘O Lantern replied to Doc Edward Morbius ⭕​

@dredmorbius do bookmarklets work?

5 Jul 2022 at 15:07 | Open on merveilles.town
Doc Edward Morbius ⭕​ replied to Luci ‘O Lantern

@zens No.

(It's your job to know these things.)

(That's a really difficult job.)

(Endpoint / device / combinatorials / usage-domain anticipation turn out to be complicated.)

(Yes, I've worked in testing / QA, amongst other roles. Not my favourite by a long shot. But I've done it.)

5 Jul 2022 at 15:14 | Open on toot.cat
Luci ‘O Lantern replied to Doc Edward Morbius ⭕​

@dredmorbius e-ink devices isn’t one of the things we usually consider, and i have never had one, so i don’t know how featured the browsers are

5 Jul 2022 at 15:16 | Open on merveilles.town
Doc Edward Morbius ⭕​ replied to Luci ‘O Lantern

@zens Well, I'm here to tell you that this is your job now ;-)

5 Jul 2022 at 15:18 | Open on toot.cat
Luci ‘O Lantern replied to Doc Edward Morbius ⭕​

@dredmorbius i’ll add it to the list

5 Jul 2022 at 15:19 | Open on merveilles.town
Doc Edward Morbius ⭕​ replied to Luci ‘O Lantern

@zens NB: I've just looked to see if I can find numbers for e-ink market share / sales volume, w/o success.

The best I can find is a very dodgey SEO-scented page giving volumes in the "millions". Who is buying e-ink might make a stronger argument than how many (e.g., market segmentation rather than strictly size).

I'm aware that those questions and their answers have value in making arguments regarding spending cycles and capital including such devices in testing.

Daniel Kao (developer of EinkBro) has some design principles he advocates which are a good start, see:
medium.com/einkbro/web-browser

I've got my own list which has a few other elements.

There are some @media queries which may help in detecting e-ink (colour depth is a key one), but nothing that specifically says "this is an e-ink device and you should plot your course accordingly). @media seems to greatly lag actual media developments.

1/

@zens NB: I've just looked to see if I can find numbers for e-ink market share / sales volume, w/o success.

The best I can find is a very dodgey SEO-scented page giving volumes in the "millions". Who is buying e-ink might make a stronger argument than how many (e.g., market segmentation rather than strictly size).

5 Jul 2022 at 15:27 | Open on toot.cat
Doc Edward Morbius ⭕​ replied to Doc Edward Morbius ⭕​

@zens My own set of e-ink design principles:

1. Persistence is free. Once set, the display will continue to show specific static content indefinitely, with no power applied.

2. Pixels are cheap. DPI is typically 200 or higher, devices well over 300 DPI are available, though not precisely common. This is equivalent to many laserprinter's dot resolution.

3. Paints are expensive. In terms of energy use (battery life), time, and disruption (display ghosting / flickering, varying with display mode), any screen changes impose technical or cognitive costs.

4. Refreshes are slow. Rather than 60--120 Hz, you're operating in the range of 0.5 -- 10 Hz. Most devices / modes can accomplish fairly rapid (> 4 Hz) updates, but that's not guaranteed.

5. Colors are very limited or nonexistent. There are colour devices, they're a small subset of the total, palettes are limited, and display characteristics worse than B&W (1/4 pixel density, slower refresh). Many devices offer a limited greyscale palette, ranging from 1--16 shades (1-4 bits). Line art works well, most raster images require dithering or halftones for best effect.

6. Pagination navigation is strongly preferred to scroll. Change the entire page in one fell swoop. It's much harder to regain reading point when scrolling in e-ink than it is with emissive displays. This means providing interfaces for paginated movement. Regions work better than gestures.

7. Reflective rather than emissive. You can't pour light into portions of your display, you can only remove it. Colour mixing is pigment, not light (if it exists at all). Readability increases with direct sunlight / bright ambient light. Many devices do have illumination (backlight / frontlight).

8. Touch / wacom may exist. Many devices incorporate a wacom layer and can use a stylus. Do with this what you can / may.

@zens My own set of e-ink design principles:

1. Persistence is free. Once set, the display will continue to show specific static content indefinitely, with no power applied.

2. Pixels are cheap. DPI is typically 200 or higher, devices well over 300 DPI are available, though not precisely common. This is equivalent to many laserprinter's dot resolution.

5 Jul 2022 at 15:36 | Open on toot.cat
Go Up