111–120 of 262 posts
Background gradient makes me dizzy after reading a single paragraph
(author here) sorry to hear that! Out of curiosity, what screen size are you reading on? Anyone else have similar problems? Sounds like I should add a button to disable the gradient.
fight for open file formats for common things
Reminds me of this:
Earlier quoted context omitted.
And this works both ways. Like the Postgres standard API you mention: Not only does it allow you to bring your own client, you can swap the underlying implementation and still use all the clients that speak the protocol. Like the author I would really like to see some open protocols (and adoption) for todo's and calendars. I mention adoption because for calendars there are some standards but popular software like Goo…
Calendaring is a huge embarrassment and a mess, and it is super annoying if you have to deal with anyone “outside” your group. Emailed ical files seems to be the norm but only work over email. :(
I'm in medicine, and I desperately want this model for electronic health records. The current state of lock-in has been effectively maintained by the entrenched players, and it's really bad.
I really like their documentation. My team has moved a lot of our stuff to produce FHIR (or something close to it), for interoperating with other teams and clients.
I think a major omission from the authors' wishlist of BYOC-capable applications is chat. Maybe in their case they are lucky enough to have a choice in the matter, but I think overall the walled gardens and closed APIs for the major chat programs is a shame. Every day that I have to use Microsoft Teams in an attempt to communicate with coworkers is an exercise in patience. Basic chat functionality should be open and…
> Today we generally think about BYOC at the “app” level. But can we go finer-grained than that, picking individual interface elements? Reminds me of this: https://en.wikipedia.org/wiki/OpenDoc
Even then, you have to fight the default ui/ux.
Really, a good API is all that is necessary. Also, maybe an SDK, but I am not particularly enthused by some of the SDKs I encounter, these days. If a service can be exposed by a good, basic API that doesn't require (but also affords) an SDK, then this allows development of connectors. Many client packages, these days, are written to allow connectors to be developed.
For data-only applications. But if an application wants or needs to promise pixel-perfect results, at the very least, there would need to be a single standard rendering engine.
If it is necessary for a team to be "all on the same page," then the management needs to require that everyone use the same rendering client.