11–19 of 19 posts
Slightly API related rant: I just wanted to get my free/busy info from office 365. I wanted to control a "do not disturb" light without using a phone app. There doesn't seem to be any straightforward method to "generate a token, save it in Bruno or Postman etc, then POST to a specific endpoint". The docs I saw talk about registering an app, and all sorts of heavyweight stuff in Azure. Why can't I just call some URL,…
Earlier quoted context omitted.
> but now and into the future. That's tough. The context is always changing. The future looks different every week or two. Worth considering but it's also easy to go down the rabbit hole of over anticipating, over planning, etc. Be wise. Be thorough. But be aware you'll be wrong often (when it comes to predicting the future).
The best predictors don’t scout all roads, they instead avoid decisions that cut them off. We still have a legacy of bad design we were chasing in the 00’s and well into the 10’s of trying to future proof things when what we should have been doing was hedging by putting off decisions we cannot change as long as we possibly can: the Last Responsible Moment is too often conflated with YAGNI - things like building infra…
Brilliant. I agree with everything you said. Present me has no idea what future me needs. Let future me decide. Keep things simple and flexible as long as possible.
Not to jump off topic, but my takeaway from Norman's "The Design of Everyday Things" was that design is of process of compromises. Could be time, could be budget, could be other factors within the company, etc. But there are almost always unseen forces the public isn't aware of that impacts the design they do see. I would presume APIs are no different. There is no objective and absolute perfect API. Instead there are…
Not to jump off topic, but my takeaway from Norman's "The Design of Everyday Things" was that design is of process of compromises. Could be time, could be budget, could be other factors within the company, etc. But there are almost always unseen forces the public isn't aware of that impacts the design they do see. I would presume APIs are no different. There is no objective and absolute perfect API. Instead there are…
https://www.hermanmiller.com/stories/why-magazine/design-q-a...
Regarding compromise, he said:
> Have you been forced to accept compromises?
> > I don’t remember ever being forced to accept compromises, but I have willingly accepted constraints.
Not to jump off topic, but my takeaway from Norman's "The Design of Everyday Things" was that design is of process of compromises. Could be time, could be budget, could be other factors within the company, etc. But there are almost always unseen forces the public isn't aware of that impacts the design they do see. I would presume APIs are no different. There is no objective and absolute perfect API. Instead there are…
1. Why do everyday things end up being designed the way they are 2. What makes one thing designed well and another not?
Normann definitely goes out of his way to say that some things are poorly designed and other are not.
One of my favourite bits is on stove tops. He argues why basically every stovetops knob-layout is wrong and then goes on to explain why we end up with a "wrong" layout: It is because stovetops are designed to be sold in the showroom, more than they are designed to be used in the kitchen. It looks nice to have the knobs in a row (the book is from before touch controls) and that's why they are in a row and not in a square configuration.
I don't think the takeaway here is "it's a compromise, and it is what it is", I think the point Norman wants to make is more along the lines of "This is why we can't have nice things".
Earlier quoted context omitted.
You can sign into Graph Explorer and get an access token there: https://developer.microsoft.com/en-us/graph/graph-explorer No clue how long it lasts.
Oh, that is cool! But corporate IT has apparently blocked being able to use graph-explorer. Thank you anyway! :)
[1] https://learn.microsoft.com/en-us/office/vba/api/outlook.cal...
[2] https://github.com/TomSmeets/export-outlook-to-ics/blob/mast...
OP kind of messed that part up.
On other counts: I don't know... a lot of this seems true, but also very simple, to the point that I don't know if it needs a special mention. In other words, maybe, to get a better insight into how to make better API one needs to keep looking for "deeper" answers.
Also, a lot of practices and techniques this presentation argues against have their merits (eg. having explicit close() method is right out of "Zen of Python" which tells to use explicit over implicit).
Perhaps, a better analysis would try to defend the given approach in the light of the justification for the opposite, or, at least, try to assign weights to different approaches (eg. "if explicit code makes user code more prone to error, then implicit should be preferred").
Not to jump off topic, but my takeaway from Norman's "The Design of Everyday Things" was that design is of process of compromises. Could be time, could be budget, could be other factors within the company, etc. But there are almost always unseen forces the public isn't aware of that impacts the design they do see. I would presume APIs are no different. There is no objective and absolute perfect API. Instead there are…