Why is Drag-and-Drop programming rarely used?

Question

There are currently several applications Open Source, including Brazilian projects. However, what I realize is that the function of Drag-and-Drop that the IDEs provide.

I notice that many projects are made using the Netbeans, for example, however the user interface was assembled in its entirety by the programmers without the use of the Drag-and-Drop (it is possible to notice by the structure of the folders among other things).

For my knowledge only language Object Pascal that a good part of the applications is made taking advantage of the tools available, in this case the Embarcadero.

What I would like to know is why this occurs, whether it is due to leaving the application faster, less susceptible to errors, or whether it is for some reason.

Answer 1

Your question is somewhat broad in the sense that drag-and-drop can mean a lot in the context of system development.

For me, for example, what comes to mind in the very first place is the pattern of interaction where the user needs to click the mouse pointer to select an object, hold the mouse button pressed to "hold" such an object and "drag" it to some other place of interest (the such drag), and then release the mouse button to let the object "fall" in the new location (the such drop). But your question can also be interpreted as why programming tools and languages (specifically in the construction of graphical interfaces) use little of this feature through building more WYSIWYG, where the programmer builds the graphical interface literally by drawing it instead of programming with textual commands.

I think its original intention with the question is more in the sense of the second interpretation, but this is unclear. It would be nice to improve the issue. Anyway, I still think the question has potential for useful content according to the two interpretations, so I’ll try to provide an answer.

1. The Interaction Pattern Drag-and-Drop

Actually the pattern of interaction drag-and-drop is widely used, simply because it makes a lot of sense in worktable metaphor (desktop) that most modern operating systems use. In fact, it makes so much sense that this is the second major interaction in virtually any mobile app (the first, of course, is click/tap). This type of interaction with the hands (or the equivalent, considering the mouse almost as an "avatar of your hand"), is very natural to the point that babies try to use magazines the same way they use tablets. So in a computer system, if the metaphor is from a book or magazine you use your finger to "drag" the pages; if it’s from a physical game, you use your finger to "kick" a ball; and so on. All can be considered variations of this type of interaction originally used with the mouse pointer.

Of course there may be problems depending on the construction of the interface, especially when the elements that allow this type of interaction do not make that option clear for the user (I suggest reading the item 3. No Perceived Affordance of this great article). This is why on Pcs it is common to use that mouse pointer that simulates an open and closed hand (the latter, literally "loading" something) to indicate that something can be loaded/is being loaded:

_{Image source: http://www.shutterstock.com/pic.mhtml?id=156119834&language=pt}

2. Use in Programming and Interface Building

Nor do I think that this type of interaction is little used in programming. As colleagues have mentioned in comments, proprietary tools like Delphi and Visual Studio have very good features in this regard. Some others might leave something to be desired. Qt Designer, for example, which I often use, allows you to just draw the interface (dragging the components and defining their properties in appropriate dialogs) with more basic things: creating toolbars, adding buttons, menus, texts, organizing layouts, etc. However, when I needed to put a toolbar in a dockable window (dock area) I had to do it manually because the tool simply won’t allow it. I think it should happen in a very similar way with Netbeans, for example (I don’t know, I haven’t used it for a long time).

However, it should be noted that the purpose of these tools is precisely to support the development of software. Since they are tools used by programmers, it eventually becomes so much easier and trivial to simply textually program the construction of the graphical interface than to draw it, to the point of making it seem that this feature is little used.

ADDENDUM: It was not always so. In a past fairly recent, in which there were (or were not used) construction standards for graphical interfaces called Layout Managers, the programmers needed literlamente describe in the text of the programming screen coordinates where the components should be positioned. By example, the code in Advpl below, reproduced from blog siga0984, does just that (and the @Maniero will remember this heritage of Fivewin! hehehe):

#include 'protheus.ch'
User Function APPINT01()
Local oDlg
Local oBtn1, oSay1

DEFINE DIALOG oDlg TITLE "Exemplo" FROM 0,0 TO 150,300 COLOR CLR_BLACK,CLR_WHITE PIXEL
@ 25,05 SAY oSay1 PROMPT "Apenas uma mensagem" SIZE 60,12 OF oDlg PIXEL 

@ 50,05 BUTTON oBtn1 PROMPT 'Sair' ACTION ( oDlg:End() ) SIZE 40, 013 OF oDlg PIXEL
ACTIVATE DIALOG oDlg CENTER
Return

It should be easy to imagine that, under these conditions, a visual construction tool of interfaces would be greatly welcomed (however basic it was).

I say that just "it seems" that this feature is little used because my understanding is that it exists in many of the tools we use, only that generally as a support in the construction of graphical interfaces. Less experienced users with a tool/language most likely make great use of these features, perhaps decreasing their dependency on it as they become more experienced. You’re probably more experienced with the languages/tools you use, and simply don’t miss the feature much.

This is not the case for most users (I’m using the term in general, since we programmers are users of development tools). Actually, I think there is a strong trend to move more and more away from text input as the main way of constructing scripts, defining behaviors and even pure programming (whether for work, leisure or education). The intention is clearly to make the task easier for a wider audience. There are numerous examples of this trend, among which I think worth mentioning:

• Fungus in Unity 3D. Unity 3D is a tool for game programming that already makes a lot easier for developers. Still, it is necessary to build code (using C# or Javascript). A add-on popular enough called Fungus allows programming the narrative flow in a graphic and visual way. Especially for programming narratives (dialogue sequences) it makes much more sense to have a graphic flow than a block of code text, and that’s where the popularity of this tool comes from.
• Nodes in the Blender. Blender is a software for open source and very complete 3D modeling. Texture building and object rendering order, for example, are complicated processes that used to be executed/automated by action sequences in multiple properties windows (hard to memorize, you might say!) or Python code (generally not accessible to the target audience of this tool). An existing resource called Nodes allows you to configure these actions through a graph of us with properties and input and output plugs, in a much easier way for the general public.
• Scratch. Scratch is a mit project to essentially facilitate programming learning. In it the logical flow is constructed in the same way as with any algorithm in the structured approach (flow control instructions, repetitions, etc.). However, this is done using visual blocks that are - look at this - dragged and combined with the mouse pointer! : ) This interface became so famous that it was used in several tools, among them the Stencyl (an engine for building games).

_{Example of a program piece (an event, in an object), "written" in Scratch.}

Answer 2

The reason is quite simple actually.

The act of programming itself does not consist in "positioning elements", but in defining functionalities. Most of what needs to be done has to be described with high level of detail.

Simple example: It’s easy to position a "button" using Dreamweaver, but it’s virtually impossible to make it work without typing.

The more complex the features available (regardless of how many you will use), the more difficult it is to create a tool with fields that meet all possibilities.

Considering the difficulty of creating a suitable interface, the number of languages, the speed of updating of the main languages and the number of different "levels of abstraction" that each project uses, it is practically impossible to define a standard.

If you do something like this, you get something along the lines of a Visual Basic, or worse, a Frontpage or a Wix. The "simplicity" of the interface "costs" the possibility to expand the program, because even if you open both options (as in Dreamweaver) and even if you can fully replicate the functioning of the "other side" (Dreamweaver does not perfectly replicate a browser, as a curiosity), the generated code will be "polluted" because it is virtually impossible for a program performing visual tasks to define where that code should be, hierarchically speaking, and how best to structure it.

A last important point to be raised is "tradition". Programmers work with text, so they specialize to work with text. Mechanical keyboards, powerful text editors (like VIM and Emacs for the more "hardcore" and Sublime Text and Atom.IO for the more "modern"). It is difficult for a new program to "compensate" for these older users, and when you need more advanced features you invariably end up abandoning the more "complex" IDE in exchange for those features. This does not justify abandoning ideas, but sets a high level of demand, which makes it difficult for Ides with more complex graphical interface.

Answer 3

I had the same doubt and after a while I realized I need to ask three basic questions to decide whether I should use Drag-and-Drop or not.

1 - I know how this code works ?

When you know how the copied code works you do not worry about possible problems, because you have already done once and saw that everything is fine and if something happens you will be able to maintain.

2 - The IDE I use accompanies and implements all new language rules and methods?

This question closely affects performance, For example Netbeans, I use a lot to code in C++ and PHP, always releases updates along with the company that maintains the language.

3 - What is my deadline to develop ?

If the answers to questions 1 and 2 are positive and your time is short, use Drag-and-Drop if you have too much time Don’t do POG, always think about the future.

Answer 4

Nowadays people are used to touch screens, notice that the movement is actually a slide, where it is possible to unlock the screen, switch between screens, etc. The movement, swipe your finger on mobile phones and tablets is not a complete movement, as happens with Drag-and-drop, which is necessary to touch fixed point, drag and drop at another fixed point. Therefore, it should be noted that the concept of Drag-and-drop can be adaptive.

Answer 5

This occurs by:

• Ease of standardization of the interface by the designers, ensuring the same design for all components used in the view/screen. This way you just nest the objects and the designer implements the whole aesthetic part of the components (Ex: button, panel, pop-up and etc).

• Ease of maintenance and interface change, as you only need to change the design of one component so that the other components used reflect this change/maintenance.

I believe the drag-and-drop you refer to is the visual part of the program.

To build a web application you have hundreds of ways to structure your program, you can make an API to allow access to your data.

Use this data API in a web program with JSF doing the front end (screen, view and etc), use the same API on an Android or IOS and so on.

Finally you will always develop in layers, making it easier to maintain your code and decreasing the interdependence between layers.

Hugs.

Answer 6

I think this is somewhat relative, depends on the application, the technology and the company’s policies. See the Xcode for example and the development for IOS, I believe that a good job is using drag 'n drop tools, now also see the Dreamweaver, I do not know if many people use these features (in a company I worked for did not allow the use of Dreamweaver drag'n drop because of the generated code), in Unity3d there are some dran'g drop plugins widely used and if I am not mistaken with C# it is also widely used drag'n drop features. I particularly don’t like to use drag'n drop because I prefer to mecher directly in the code because it gives me more intimacy and control over the code and its style.