Hacker Newsnew | past | comments | ask | show | jobs | submit | the_florist's commentslogin

I’m building an e-book reader for the web and PWA platforms:

https://flowery.app/books

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.

Obligatory landing page for the paid product:

https://flowery.app/vocabulary-building


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:

https://flowery.app/books/edgar-allan-poe/short-fiction

Once the business achieves ramen profitability, the next milestone will be to give back with a corporate sponsorship.


Looks good! One minor point: it looks like some of your conversion isn’t keeping accurate styling. For example, if you look at the letter in https://standardebooks.org/ebooks/edgar-allan-poe/short-fict... that starts with “In conformity with an order” you’ll see (in Firefox and Chrome, Safari’s in the process of adding the styling) that the address is 90º as per the original scans. The same in https://flowery.app/books/edgar-allan-poe/short-fiction/thou... falls back to normal display, which is fine but perhaps a little bit of a shame.


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.”


The dictionary preview is limited to the nth letter of the alphabet, where n is the day of the month, as hinted by the search box’s placeholder.

Try looking up any word that starts with S, assuming it’s June 19th in your time zone.


The timeless elegance of Caslon.

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:

https://flowery.app/words/a%2E%2E%2E

The ellipsis is a general operator that searches by prefix.


Okay, thanks a bunch. I work a lot with students studying for the SAT and GRE, and something like this could be very useful for them.


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.


Makes sense but I think the main issue with the workflow is that the user is having to type words out? As a vocab builder it would be nice to do more suggestive words or something that does not force me to type in words.


You can quickly populate the search box by tapping any word (or highlighting on desktop) in the hybrid dictionary/thesaurus.

As I mentioned in another comment though, the ideal workflow would be an integrated ebook reader that lets you tap words without context switching.


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.


Personally, I think this should have been a nice to have (if at all). There are other areas of the product which could have been refined which would have had a bigger impact (intro and sign up journey).


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.


Nice! Good luck anyway and congrats getting this out of the door. I know how difficult it can be to get to this stage. With some UX refinement then I think you'll have a nice proposition. As you said, pricing can evolve.


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.


Thanks for sharing. The app functions really well and is beautiful. It took me quite a while to figure out what it does and I'm still not 100% sure I understand completely. Is the app profitable? How do people find out about it?


I find your experience rather relatable.

I did figure out there is some sort of spaced repetition component to it, but that’s probably because I’m already an Anki user and aware of the concept.

I quite like the eccentricity of it, although I’m sure it could be toned down a notch for wider appeal.

Feature-wise, having thesaurus definitions immediately accessible is very useful.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: