Hacker Newsnew | past | comments | ask | show | jobs | submit | scary-size's commentslogin

This reminds me about this old gist for generating Firebase-like "push IDs" [1]. Those have some nicer properties.

[1] https://gist.github.com/mikelehen/3596a30bd69384624c11


I love just how non-intrusive an e-ink dashboard is sitting in a room. Definitely can recommend it as a base device that gets you display, wonky Linux, a battery and networking in neat little package.

Also recently showed my dashboard here: https://franz.hamburg/writing/kindling-e-ink-dashboard.html


You don't need to ball out on eink for that.

An old oled android phone is even easier to mod for that.

Eink is like the Rust of displays for hobby projects. Everyone defaults to it even when it's not necessary.


That's an unfair criticism. Kindles and their eInk setup provide the perfect low-fi hacking experience that developers love. It's minimal, slow and barebones linux base makes it easier to hack für such fun projects.


> low-fi hacking experience that developers love

Well I'm a hacker too and I don't really prefer low-fi hacking experiences, or at least not that flavor. I prefer getting stuff done since my free time after work is limited.

Oh and I used to work with eink displays for a living, but they always end up gathering dust for my hobby projects because it's only good for very few niche use cases that most of the time are better served by the more flexible and practical available solutions, unless of course, your uses case is showing it off on the internet for clout because this time what makes it special is it uses eink even though it adds no benefit.

Like I said, the Rust of displays.


Fair enough. We all have enough eInk devices in our cabinets. To each their own .

What do you mean by “Rust for displays”? Bikeshedding?


What are you talking about, e-ink is much nicer for things like this. An OLED produces actual light, and uses way more power. I wouldn't want an oled display on 24/7 in my living room.

Everyone defaults to it because it's really nice actually.


>An OLED produces actual light

Actual light? As opposed to producing fake light?


I think they mean that even an OLED display will actively emit light. When, in contrast, the e-ink displays shown in the linked posts are unlit. That, for me, is the key advantage making the device blend in.


Turn down the brightness of the OLED and it also just "blends in".


Actually used it for a desktop blogging app a few years ago. It was great! I could set up a blog skeleton, send the file to a family member. They could focus on writing content and hitting deploy.

https://blog.project-daily.com/pages/file-format_3705.html


Building a little dashboard for our solar system. Running on a mini PC in the office closest. Bun, React, DuckDB

https://solar.franz.hamburg/


... solar power system.

Though a dashboard for the Solar system would've been neat to see too :)


Thanks, yes it’s obviously for a power system.


For engineers doing UIs once in a while, I can recommend Refactoring UI [1]. It has a bunch of practical tips for making your life easier: Picking a color palette, font sizes, margins/padding etc.

[1] https://www.refactoringui.com/


I came to suggest this (also mentioned in the article). Not just engineers, I would suggest this to designers and managers too. A few of the books I always suggest to people involved in Product (the manager, engineers, and designers) are “Good Enough Design” (List Apart), “Refactoring UI” (this is actually a pretty recent addition), and the classic “Don’t Make Me Think.”

For anyone in the trenches long enough will know that most of the facts, such as the ones from “Refactoring UI” are common sense. Unfortunately, I’ve realized that it is NOT, even for many designers.


This stuff is of course subjective, but a lot of the "improvements" on that page involve adding a bunch of extra whitespace everywhere, the exact trend a lot of people are complaining about nowadays. I'm not saying it's bad per se, but I would not present the design choices on that site as broadly good either.


It's fascinating, since I don't get the impression that UI elements needing room to "breathe" was an ironclad rule during for example the era of Windows 95. It sounds like folk wisdom for everyone on the same bandwagon of mobile-first. So much creative design potential (and admittedly some inaccessible ones) is lost when these opinions are passed down as the rule of law.

Another bugbear for me personally: rounded corners. Ask online and it feels like people just parrot the idea that rounding is "more friendly and pleasing" over and over, as if blind repetition of an ideal makes it true. But I've never looked at a picture of old webpages or UI frameworks with sharp corners from 20 years ago and go "that's unfriendly." It feels like with this one, a couple research papers came out a while back showing that rounding makes users spend less energy on element identification, and then used that outcome to conclude "well, I guess a huge swathe of UI design is now a solved problem."

Subjectivity died with the need to squeeze out every last drop of "efficiency" out of every UI design. And no, I don't think that rounded corners are friendlier and more pleasing than all alternatives. In fact, I believe they are a staple of the web and modern UI design in general homogenizing into a bland, unremarkable mess, and are thus irritating. I just border-radius: 0; everything globally and call it a day.


The first example on that page ("Contacts" box) looks way better in the "before" style. Turns me off their entire proposition because it's obviously incredibly subjective.


Love it! Not an iOS dev, but have built a personal app that I want to publish for macOS too. I built on top of SQLite, but didn’t want to tackle the synchronisation yet. That should solve it.

It employs a „last edit wins“ strategy for conflict resolution, which is fine in my case. Obviously could be too basic for collaborative apps.


You’d be surprised; it depends on the scope of the last write wins register. If you do it granularly attribute by attribute, last write wins is fine for mostly-online mostly-realtime collaborative apps. The exception is (rich) text where you really want CRDT/OT/similar intention preserving merges of concurrent edits.


SQLiteData does do it granularly by attribute


Agreed. Thinking about lifecycle, side effects and state doesn’t just go away. It’s inherent to the system you are building. Hooks is a way to address that, class lifecycle methods are another. None of these tools will magically let you ignore proper design.


Meta: Refreshing to see the actual advice in headline and the reasoning in first paragraph of the article. Not somewhere buried three pages down.


Meta?


Meta to the data.


Noticed a similar slowdown when opening the GCP console in Safari. Especially the BigQuery editor. It's completely unusable.


The GCP tools are a performance disaster in both Chrome and Safari in my experience. It can be actively painful at times on some screen like the log viewer.


We recently installed a solar system on the roof, battery included. The app it comes with is okay to answer most questions. But that wont prevent me from shipping my own dashboard based on locally scraped data. Just for the sake of it. Also my homelab machine is bored.


fully custom made? Or Grafana?


Fully custom made, scratching my frontend/UX itch!


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

Search: