I’m working on the table-stakes feature of persistence for the bookmark widget, which currently appears after navigating away from a chapter (notably when looking up words in the dictionary on mobile), but is lost upon closing the app. Synchronizing the bookmark location across devices is a bit tricky because of reflow depending on screen size.
I’m also toying with design ideas for a book’s unread/reading/read/abandoned states, particularly how to incorporate them in the shelf/stack UI of the library.
The library of public domain classics is courtesy of Standard Ebooks. I publish a book every Saturday, and refine the EPUB parser and styler whenever they choke on a book. I’m currently putting the finishing touches to endnote rendering (pop-up or margin notes depending on screen width) so that next Saturday’s publication of “The Federalist Papers” does justice to the punctilious Publius.
Good catch! I am still fleshing out the EPUB parser, so loading of CSS and images (other than the SE logo) is not yet supported. I hard-coded the styling for now, which works well enough thanks to the books’ consistent markup.
I also overlooked the diary styling of “Mellonta Tauta.”
Many thanks to each of you editors for the sterling work!
I was recently inspired to embark on a project to mirror the Standard Ebooks library, starting with a book that you produced, which happens to be my favorite:
Thanks! I take the “eccentric” label as a compliment.
I may have gone overboard with the minimalism. Users had been all the more baffled before I added the tooltips hinting to tap the hearts, so I should probably double down on some sort of tutorial.
I appreciate the kind words. A lot of painstaking work went into aesthetics.
The Stripe integration launched a few days ago, so the app is very much in the red. Paid advertising since the initial release six months ago has shown promising signs from prospective customers though.
Features to discover vocabulary are on the drawing board. In the short term, a “word-a-day” feature will recommend five words per week, but the time-tested method for a rich vocabulary is reading, so the long-term ambition is a built-in ebook reader, where saving words would be frictionless and context-aware.
In the meantime, you can browse the index, which is biased toward uncommon words:
You look up a word in the dictionary and tap the heart next to its definition (as the tooltip suggests) to save it. The Hearts page (https://flowery.app/hearts) is your personal vocabulary list, and the Cards page (https://flowery.app/cards) generates cloze deletion flashcards for your hearts, which is where the LLM steps in.
I decided to roll my own virtual keyboard after a protracted battle with inconsistencies and quirks across mobile browsers. The glaring difference is that the native keyboard slides the viewport upward on iOS (pushing the fixed header off screen), whereas it shrinks it on Android (causing relayout that repositions any UI element fixed to the bottom).
Also, notice how the search box is anchored to (and animates with) the virtual keyboard. This effect cannot even be achieved with the experimental VirtualKeyboard API, which is not supported by WebKit anyway.
Thanks for the constructive criticism! There’s definitely room for improvement.
The design was intended to be minimalistic, but perhaps overly so. The preview could indeed be clarified: The letter corresponds to the day of the month, so the A headwords are unlocked on the 1st. Today’s the 19th, hence S.
The cards in the login/signup sheet are notifications, but I agree that the (non-dismissible) signup notification should be clickable. It’s not obvious that the padlock and key icons are buttons. As for passkeys, I do think they are ready for prime time, but password-less login will require user-friendly onboarding. The terse explanation on the Help page doesn’t cut it.
The five words sliding across the home page are currently hard-coded, but will soon cycle every weekday. You can turn off this upcoming “word-a-day” feature at https://flowery.app/settings.
I’m delighted that someone caught the Shakespeare reference! The product’s value should converge to its price as it evolves.
https://flowery.app is exclusively a PWA. It was designed from the ground up to prioritize the “Add to Home Screen” experience on iOS. The web is the ideal platform given the app’s emphasis on text and typography, and a native replica would be reinventing the wheel for no tangible benefit to the user.
WebKit and Safari have come a long way. Flowery puts browser engines through their paces with its UI animation, which is smoothest on WebKit. Safari’s OS integration (e.g., elastic scroll, Sonoma’s “Add to Dock”) is more polished than Chrome’s.
It wasn’t a walk in the park though. An early decision, after maddening attempts to circumvent browser quirks five years ago, was to build substitutes for common building blocks of the browser on mobile, notably the virtual keyboard, textboxes, and text selection. This wouldn’t have been possible without web components and Google’s excellent Lit library.
I’m working on the table-stakes feature of persistence for the bookmark widget, which currently appears after navigating away from a chapter (notably when looking up words in the dictionary on mobile), but is lost upon closing the app. Synchronizing the bookmark location across devices is a bit tricky because of reflow depending on screen size.
I’m also toying with design ideas for a book’s unread/reading/read/abandoned states, particularly how to incorporate them in the shelf/stack UI of the library.