At my very first job, we had a weekly meeting to assign tickets and estimates.
Our non-technical PM wrote "drag-and-drop" on a whiteboard, and then my name.
"Gavin, how long do you think this will take?"
"All week. At least. Maybe longer?"
PM laughed, then realized I wasn't making a joke.
"What do you mean 'all week'? That's ridiculous, do I need to give this to someone else?"
"Well, you could, but I wouldn't count on you getting it any sooner."
Appalled, he exclaims: "It's just drag-and-drop!"
After 10-15 minutes of a room full of engineers trying to explain the difficulty, he gave up with an unhappy "Fine."
The phrase "it's just drag-and-drop" became an inside joke for the rest of my time there...
It was crazy complicated.
Simple is not simple.
If said this way he was a jerk. So good on em for making a joke.
"Why would this take so long?" would be better.
My guess like most things "you wanna retrofit audio and data cabling to your house. Find an electrician who can do that in an hour. Yes it is just wires".
Could mean "I didn't know you had so much stuff on your plate that takes precedence". You're giving 0 benefit of doubt to a PM who in my opinion was right to push back because for a non-technical person it's not easy to grasp why drag and drop should be so much harder than other similar impact features.
Ah and there's the rub. Why should a PM of a software project even be a 'non-technical person' (because tbh what's even the point, how would a 'non-technical' person even be able to evaluate technical decisions and their implementation?). And even for multi-disciplinary projects like videogames it's not too much to expect that the project manager has at least a basic understanding of all crafts that work on a game.
E.g.. there's nothing more useless than a PM that's just pushing task bars around in JIRA to make them fit into the next sprint.
...and also: would you fly in a plane, or drive over a bridge that was built under supervision of a 'non-technical' PM? (I know I know... since the Boeing disasters that question is rhetorical, most people don't seem to care)
The head of a space program doesn't need to be an astronaut. An admiral doesn't have to know how to swim. A PM doesn't have to know all the various engineering disciplines the project may touch.
The comment was derisive, and therefore poor leadership. Period.
Nowadays you would just "npm install drag-and-drop" but back then you often had to hand-roll solutions.
If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long, not to mention the absolute nightmare that testing something like this with a proper framework and accompanying testing library.
It's not insurmountable by any means, but it does have enormous inherent complexity compared to almost every other UI action there is.
> If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long,
I bet, the JS devs who do write code overcompensate for the ones who can only stitch together libraries. I suppose because the expectation is that the library consumer is incapable of writing their own code extending it, so the library itself must support every possible combination of use cases for a million different users, even though the code any individual consumer actually needs is more like 100 loc.
> What the hell do you need a library for?
On the frontend, you have to re-calculate the display state for all the possible drop positions, in-between transitions, and drop-end-snap-back.Think of a grid of cards, and all the possible drag, hover, and drop state transitions it can be in with any other card, and the animations required to make it look nice
Now also consider that you need to persist the final state on the backend, and handle things like rejection, cancellation, failed updates/errors.
It becomes a massive state chart and web of complexity
If you are dragging within the page, then the draggable “ghost” is your problem too (it’s not automatic). As is deciding whether the ghost should affirmatively snap out of and into the source and target containers (that is, whether the destination container should appear to “make room” for the ghost at some transitional point), whether there’s a transition on that, etc.
Drag and drop in desktop non-web GUIs have all sorts of visual affordances that users expect for consistency that are your job in HTML.
I was once quite up-to-date with raw frontend work and I tried to implement this; it’s actually not trivial.
If you want to splash up the "drop here" thing it's a frickin nightmare. The events don't fire when they should (e.g. mouse leave doesn't fire so it gets stuck, or you get duplicate events or missing events) so you get a bunch of flicker unless you do a bunch of debouncing and fail safes to cover all the browser quirkiness. And this is the easy drop-a-file scenario.
Doing all the stuff shown in https://www.youtube.com/watch?v=l7v-UwpsEbk I'm not sure I'd even know where to begin.