Cocoa (
momijizukamori) wrote2021-06-20 05:00 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Entry tags:
More Ao3Reader things
I figured out how to take screenshots within the app without having a menu in the way! First off, some aesthetic tweaks to the reader overlay:
View for a work with chapters:

View for a work without chapters:

Mostly because it seemed silly to pop up an empty chapter overlay. I could remove the greyed-out chapter button when it has none but the UI math is easier if I keep it there.
Aaaaand I got the first step of the 'about work' overlay done, which is to take a list of tags and turn them into clickable elements, with wrapping. Which is actually kind of complicated when you have to manually set breakpoints and define locations absolutely!

Example of a taglist - ignore the bit where it's overlapping other elements, that's because I was maximizing the space the taglist used for testing.

And then visual feedback on toggle, before the view is replaced - at the moment the hooks to load the new views don't work so it doesn't actually replace yet.
I'd really appreciate feedback on the element size - on one hand they feel REALLY big, but on the other, the touch resolution on eink screens are not great, and you can't pinch-zoom to get around it like you can on a phone etc. On the OTHER other hand, I'm on a Kobo Glo, which is like, the second-oldest series that's still supported, and the second-lowest resolution available out of these devices - it's 1024 x 758/4 3/4" x 3.5" for 212ppi, so it's possible that 'barely okay' on the Glo is plenty acceptable on all the other models.
View for a work with chapters:

View for a work without chapters:

Mostly because it seemed silly to pop up an empty chapter overlay. I could remove the greyed-out chapter button when it has none but the UI math is easier if I keep it there.
Aaaaand I got the first step of the 'about work' overlay done, which is to take a list of tags and turn them into clickable elements, with wrapping. Which is actually kind of complicated when you have to manually set breakpoints and define locations absolutely!

Example of a taglist - ignore the bit where it's overlapping other elements, that's because I was maximizing the space the taglist used for testing.

And then visual feedback on toggle, before the view is replaced - at the moment the hooks to load the new views don't work so it doesn't actually replace yet.
I'd really appreciate feedback on the element size - on one hand they feel REALLY big, but on the other, the touch resolution on eink screens are not great, and you can't pinch-zoom to get around it like you can on a phone etc. On the OTHER other hand, I'm on a Kobo Glo, which is like, the second-oldest series that's still supported, and the second-lowest resolution available out of these devices - it's 1024 x 758/4 3/4" x 3.5" for 212ppi, so it's possible that 'barely okay' on the Glo is plenty acceptable on all the other models.
no subject
no subject
Honestly I feel kind of like a wizard every time I make something work
no subject
no subject
That's me but with like, traditional art and music. I know with practice it is possible to go from 'no skills' to skills! Unfortunately I have yet to convince my brain to actually do said practice, lol.
no subject
And then I don't.
no subject
I think those buttons are a reasonable size. (I tend to be generous with buttons on touch devices even if screens have high touch resolution, because thumbs do not.) If UI doesn’t get directly scaled up on bigger devices, and instead is relayouted, that size looks about right for other models as well.
no subject
Yeah, idk how it's going to behave on other models - may be time to build a test file so people can get feedback to me. And absolutely true about thumbs, that's part of the reason I erred on the side of 'larger'.
no subject
I also can't tell the difference between the work with chapters and the one without, but the reading interface looks very good.
no subject
The differences are slightly more pronounced on the eink screen, I think, but you're right, the inactive one could stand to be lighter, I think.
no subject
no subject
Yeah, it's a little tricky because the screenshots are like, the raw buffer dump, which aren't 100% accurate to the actual rendering because of the nature of technology/ambient lighting/etc