A lightweight a page design as I've been able to keep; simple, clean, fast. No commercial features or aspirations - this is a passion project, something I've been fooling around with on and off for decades.
There's a "Top" view too with an LLM edited front page & summary, and categorized views for a large number of topics - see the Directory. A few more buried features to explore, but the fundamental use case is pop in, scan, exit - fast and concise.
Your feedback would be appreciated!
What is the purpose of having summaries for "Recent", "Incoming", and "Outgoing" all at the top? Seems like all content from the later two are in the first, right?
Where they're (more) relevant is in the "Top" view where the LLM editor has picked a subset of stories to be categorized as top and incoming/outgoing are the ones that didn't make the cut, organized by timeliness.
Definitely a gap in design!
I should also add - please post any recommendations re: sources to cover.
- how often do their stories become members of clusters? - how "fast" are they to publish on a topic vs. other competitors - i.e.: who "breaks" the news? - what tags (people, companies, topics) does a given source stick close? Which do they shy away from?
Thanks very much for a really interesting set of ideas to explore!
Note that the top news breaker is: The Verge, having broken about 10% of stories on my site; TechCrunch is next at 8, followed by ... MacRumours at 7.
At a high level, it reads RSS feeds from a number of sources, and uses LLMs to identify clusters of stories about the same thing, group them, tag them, and designate them a "top" story or not. That's it.
The biggest thing I've learned in all of this is that o3-mini is far and away the best at following instructions (for this use case). Periodically I'll cycle through the models available on Groq, and always come back to o3-mini.
So I decided to write web crawlers, but then you run into CAPTCHA stuff. So I instead used Selenium to automate my browser to fetch the news articles. That worked well, but I haven't worked on it since.
Now I'm thinking that with all these AI browsers around these days, maybe that's actually easier than doing it with Selenium. But haven't researched it properly yet.
In any case, the LLM work of detecting whether two articles are reporting the same news, and summarizing the story, is the same in your project. So in case your project is open source, I would be interested in that part.
The one subtlety is setting up the LLM to understand whether a new story belongs in an existing cluster, or with > 1 neighbors, constitutes a new cluster. The challenge there is scoping the clustering window (hours of stories for consideration) and topic breadth to avoid creating Katamari-super-clusters that just end up with every story associated to them.
At this point I seem to have found a sweet spot re: the hours window, the frequency of processing, and the design of the prompt such that its working consistently.
Very few false positives in terms of spurious clusters being created, or potential clusters being missed.
You're right --- incoming & outgoing end up being redundant on the "Recent" view. Where they're (more) relevant is in the "Top" view where the LLM editor has picked a subset of stories to be categorized as top and incoming/outgoing are the ones that didn't make the cut, organized by timeliness.
Definitely a gap in design!
Sort of a combo of "in case you missed it" and "the next new big stories".
That threshold is a function of day of the week - on weekends when the news cycle is quiet, it lowers the bar --- tuesday to thursday its at its most restrictive.
Thanks so much for the kind words - its 100% o3-mini for clustering. I have zero editorial input as to what constitutes a cluster, what's "top" news, etc.
The one subtlety is setting up the LLM to understand whether a new story belongs in an existing cluster, or with > 1 neighbors, constitutes a new cluster. The challenge there is scoping the clustering window (hours of stories for consideration) and topic breadth to avoid creating Katamari-super-clusters that just end up with every story associated to them.
At this point I seem to have found a sweet spot re: the hours window, the frequency of processing, and the design of the prompt such that its working consistently.
Very few false positives in terms of spurious clusters being created, or potential clusters being missed.
In my case we went with embeddings and clustering to find close papers to each other because llm were allucinating.
My "Stack" ---- LAMP + o3-mini for editorial tasks + Bootstrap for responsive front end. That is to say: Its old school, and painfully functional. But, light & fast.
It's creating a "wall of text" effect to me and I'm not able to quickly skim and allow my eye to catch the bits that are interesting to me.
As a comparison, the HN homepage is very accessible to me for skimming and finding things to click into (like this entry).
UI is often quite subjective, understood. But I can't really "scan" the first view fast enough. It's all blending together and causes extra processing on my mind.
Thank you for the feedback!
The links are blue design from early HTML was meant to highlight links in the context of a paragraph of prose, not a list of link items. "Blue" means something special about the text in the context of the text around it.
In this case, the blue font is distracting because the links are the content. You don't need the blue to help your links "stand out". Because the links are normal text, using a normal palette would be appropriate.
I don't mind some subtle clues that these are links. Underlines, slight grey text. Or even a subtle hover effect. Two cents.
It's quite scannable, but obviously you're doing reverse chrono order so up to you how best to solve the UI issue.
I admit that straight black is not quite the right answer either. A slightly toned down dark grey would be nice. And again, subjectively, I like how HN has a row of non-link smaller (lighter shaded) text under each listing, which I think plays nice for the white space between each item.
Noting also that this text is #000000 black, per the CSS. Maybe the background color helps soften it a little? Like contrast white/black is hard on the eyes, but HN is not?
There's no reason for both the story count and the story summary to be clickable. It's confusing because:
(a) It's not clear what the number in parentheses even means (until you click and infer)
(b) Separate links makes you think they lead to different pages
Also, echoing another comment, it's not really clear what "incoming" and "outgoing" stories mean. Maybe "new" vs. "stale"?
And - did you actually see the time machine at the bottom of the right hand column? Or - was that just a wish list item of yours?
Distinguishing characteristics - personally I get value from the unambiguous timeline (no editorializing in /recent), and (as nice as the visual is) the non-visual, super simplistic presentation & the curated sources (...which I value b/c I curated them myself haha).
So bottom line is that DS will appeal to a certain kind of obsessive compulsive news consumer and synthesizer that wants the right balance of signal to noise ands a streamlined presentation that doesn't slow them down. I count myself among that group!
I also use it's sister aggregator site for political news every day - https://www.memeorandum.com/
An extension of Fear of Missing Out, basically. And yes, I think it causes mental exhaustion and might be directly related to some mental disorders that we have really yet to understand.
https://github.com/facundoolano/feedi
I did try to build a public facing news aggregator with a similar ux but I couldn’t pull it off purely based on client side state (and I didn’t want to do user management)
Cheers!
wmeredith•3mo ago
dreadsword•3mo ago