[baddox]

> then why does everyone sketch a picture when trying to convey an idea?

Does everyone do that? I think I very rarely do. When I need to convey an idea on a whiteboard, it's still almost completely text, with a few extra symbols like directional arrows that I think are still effectively just symbolic written language.

Literally the only time I can remember sketching a picture to convey an idea is while playing Pictionary. The entire premise of that game is that it is much more difficult to get someone to say a specific word by drawing a picture than by simply writing down the word.

[analog31]

Sometimes they do. In my view the most prominent example is documentation for installing computer hardware and software on Windows computers. The instructions will be a series of pictures, with circles and arrows, and a paragraph on the back of each one (sic). This goes on for page after page. And when the OS is updated and the dialogs all change a bit, the documentation becomes confusing or even obsolete.

In contrast, the instructions for the Linux version of the same thing will be something like:

    sudo apt-get install this
    sudo bing bam boom
    ...

[PhasmaFelis]

I also hate that, but I always felt it was more a failure of the documentation writer than the GUI. "Click File -> Settings -> Whatever, open the Something tab, and click the "Do It" button under the Stuff subheading" can easily replace half a dozen unnecessary images.

[Too]

GUI is documentation. If you have to document how to use your GUI you are doing it wrong.

[PhasmaFelis]

It's not practical in a modern operating system to put every possible function at your fingertips and intuitively discoverable. There are better and worse ways to organize things, but there's just too much stuff to put all off it front and center.

GUIs are still much better than a command line in this respect, since with a GUI it's actually possible to find what you're looking for by randomly exploring, even if it's not always quick or practical.

[analog31]

One issue with GUI's is that you're sometimes stuck telling someone how to use a GUI that you didn't develop, for instance having a user manipulate settings in the device manager, which was created by Microsoft.

One thing that's rapidly improving on the command line side is Search. On my modern Windows computers (8 and 10), I don't search for things by hand in the dialogs any more. I press the Start button and start typing text.

For instance, Start plus "device manager" brings up the device manager, whereas I have no idea how to find it in the menus.

[gregmac]

I quite often use UI mockups to show an example of the end result (or ask others to do the same). It doesn't even matter if it's correct, but it's a useful way to start a discussion. I've tried to do this in words but often different people have different interpretations and it simply doesn't work without a picture.

I've also found it very useful when people are asking for things that don't entirely make sense, such as a chart/report that would require 3+ dimensions. By asking them to draw an example, they realize the challenge and we can make progress.

[nextlevelwizard]

"Picture is worth thousand words", but if you just need ten words, maybe it's not worth the effort to make a picture?

It depends on context. If you want to show how and UI looks, then it's probably faster and better to just draw it, but if you want to show how function transforms a string, then it's unnecessary to draw bunch of stuff.

[killin_dan]

I consider UI mockups the perfect usage for visual programming environments. Obviously a visual product compliments a visual development interface. However, it's a very narrow realm compared to the rest of the programming universe.

It's the same as saying that drawing a picture is easier for most people than programming a picture, and it doesn't really have to do with the topic of visual programming, but rather visual design.

[gregmac]

> I consider UI mockups the perfect usage for visual programming environments.

It can be, though the type of mockup I find more useful for discussion is much lower fidelity than that.

The feedback and discussion around a mockup is related to the fidelity.

Low fidelity, such as whiteboard or large sharpie drawings, will garner feedback that discusses whether this UI even makes sense at all, if there's a different approach, or how feasible it is to present everything this way.

Mid-fidelity, such as digital mockups, will often focus more on the actual layout, text labels and contents.

High-fidelity, such as a working prototype or something done in the actual environment (visual programming environment, or even as working HTML+Javascript+CSS), will often get into a discussion about font sizes and icon choice.

If you build a high-fidelity mockup when you really want to have the low-fidelity discussion you're doing everyone a disservice. Even if your team can see past it and still has the appropriate discussion, it's a waste of time.

For that reason, even when my mockup is basically a small modification to something that exists already, I'll often screenshot it, and then freehand draw (MS Paint style) overtop of it with my modifications, using ugly 2-4px wide lines. I've tried both, but consistently found the feedback is better that way -- even when the target audience is a bunch of developers that should be able to see past it.

[killin_dan]

Ah, I see what you're saying.

Seems like you've done quite a bit of this type of work, I've the exact opposite. I guess it makes sense that the fewer data points the clients are given, the more they focus on the broader picture.

Would you often start with a napkin drawing-esque mockup, and add detail to it while cooperating with the client, or would you sometimes start with a finished HTML+JS+CSS prototype and change things up as they request?

[gregmac]

I'm not a graphic designer, so I generally try not to do things that focus on the design -- which means I tend to start on the whiteboard/sharpie/napkin side of things.

That said, some people just can't picture how things look unless you show them how it looks, and in the past I've worked with clients that would think it's literally a joke (and probably fire me when they found out it wasn't) if I come to them with a sharpie drawing.

I think the only times I've gone to a more high-fidelity version up front is when the client/stakeholders had no idea what they really wanted. A "finalized" mockup can start the discussion (even if it turns out to be entirely wrong) and then be used to get into the low-fidelity whiteboard/sharpie mockups. The important thing is to keep the discussion focused on the right thing, and don't stray into fonts/images/icons if you want to talk about the overall structure and what pages even should exist.

[fsloth]

Pictures are a mission critical for my thinking and my communication in software engineering.

I would be hard pressed to discus the operation of any sort of datastructure beyond a linked list without sketching. For example a binary tree and it's traversal routines are (at least to me) much easier to understand with a picture along side the exact state.

[PhasmaFelis]

It depends on what kind of idea you're conveying. For many things, yes, text-heavy diagrams are the best way to go. If you're trying to, say, explain what a claw hammer is shaped like, that is much easier to do with a simple picture.

[ekimekim]

I find it's useful for sketching out high level designs, particularly showing how different components interact, or the flow of data through a system. Visual information in this context trades off specifics for a birds-eye view.

[killin_dan]

Godel, Escher, Bach covers this in great detail. Symbols are a weird idea in the human brain, and there are multiple pseudo languages throughout the book that when you really sit down and think about it, aren't any less ridiculous than the notation we use for mathematics outside of that book.

My idea-book (is that a crazy person thing?) is probably a lot like what you're talking about. I use words for my main data, different arrows going in between each sub-idea, and then sometimes more words attached to each arrow ("pub/subs", "queries", "happens once/happens always", etc)

I think that people who think visual programming could be a thing ought to sit down with APL for a few weekends, until they have the epiphany of "oh, the code is the same as the notation for what I'm actually doing" and suddenly they realize that notation and code are interlinked, and each are basically useless without the other, in the same sort of way that x--p--p---- is exactly as valid as 2 + 2 = 4, without context.

I get the allure of NOT having to write code, but it shouldn't be so difficult for people to realize that it's a ridiculous fantasy.

Write fibonacci(N) in ANY visual language, and tell me you couldn't have done it easier, faster, and more coherently in python or whatever. It's obvious.

[TuringTest]

> Write fibonacci(N) in ANY visual language, and tell me you couldn't have done it easier, faster, and more coherently in python or whatever. It's obvious.

  [0]   [1]    [x]
   |_____|(+)___↑ ...