I agree with everything above, except this one:
"they want drag and drop."
In my experience users hate to drag and drop. And they never drag and drop, with an exception of very few Apple old-timers, because Apple GUIs historically have been using drag&drop more heavily, as opposed to Windows users who are more conditioned to right-click on everything.
Drag&drop never works in user interfaces because 99% objects in everyday software are not draggable and users are not conditioned to even try. Buttons plus menu is what people are used to.
P.S.
This opinion comes from reading hundreds of support emails and replying "have you tried dragging it?" over and over and over again.
They hate D&D on the systems you've seen them use. I've seen them use it for many years on an OS called RISC OS, written by Acorn, designers of the ARM chip. There, users loved it. Everything supported it on the desktop. You had `filer' windows, and to save an application would just pop up a little window with a file icon and a text box for the leafname. Enter `foo' and drop it on the filer window where you wanted it.
But better than that, you could drop it on another application. Consequently, you could create and edit a pixmap, and drop it into a vector drawing program where it would become an embedded object. Want to edit it again? Drag it from there back to the pixmap editing program's icon on the icon bar. Neither of these touched the disc; it was in memory transfers. And the program code didn't need to know the difference between saving to another app., or saving to disc through a filer window.
Other aspects of the desktop were also novel and worked well. It had a three button mouse. A proper one. No silly scroll wheel. The right button did what the left button did, but altered in some way. So you'd pop up a context sensitive menu with the middle button. Select an item with L and the menu would disappear. With R the menu would stay there. Great for when you want to do several menu items in a row, e.g. adjusting an object's attributes.
Scrollbars worked better. Firstly, the mouse cursor on the screen only moved in one dimension once a drag with L was started. None of this cancel the drag if you wander off orthogonally a bit. But if there were two scrollbars, dragging with R would control both; an instant `pan' widget.
Hold the `up' arrow with L and it would scroll up. Switch to R and it would scroll down. No need to move to the other end of the scroll bar. Same with `paging' by clicking either side of the thumb.
Drag a window by it's title bar with L and it'll come to the front of the stack at the same time. Use R and its depth is unaltered.
Double-click a folder icon in a filer window with L and a new window opens with its contents. Use R, the current window switches to show that directory. Close a filer window with R and it becomes the parent folder.
Note, you didn't need to know all these uses of R to use the system. You could manage with L. But the paper User Guide it was shipped with explained it and you soon got used to the productivity gains.
This was back in the 1980s and 1990s. Today, you can find remnants of it in the ROX (RISC OS on X) Desktop. http://roscidus.com/desktop/
Acorn did some smart stuff. Today, the main vestige is the ARM chip and its instruction set, designed by Sophie Wilson.
In my experience users hate to drag and drop. And they never drag and drop, with an exception of very few Apple old-timers, because Apple GUIs historically have been using drag&drop more heavily, as opposed to Windows users who are more conditioned to right-click on everything.
Drag&drop never works in user interfaces because 99% objects in everyday software are not draggable and users are not conditioned to even try. Buttons plus menu is what people are used to.
P.S. This opinion comes from reading hundreds of support emails and replying "have you tried dragging it?" over and over and over again.