Prototyping Apps --- do you?

[AndyP]

I came across this great illustration of the power of prototyping

https://youtu.be/LXZNHCv2xQk
Nice sequence about the value of prototyping during the design phase of the Apollo Lunar Module. From HBO's "From the Earth to the Moon" miniseries.

This got me thinking (yes I do occasionally) about how I prototype LiveCode apps.
Looking around at dedicated prototyping apps quickly illustrates how near to a perfect prototype/build tool LiveCode is.

Drag and Drop components
Add interactions
Demonstrate / Share / Print

But wait... I still start off a new project by penciling out a paper layout/prototype....why, when its so simple in LiveCode?
Am I just set in my ways?
No I think its the tactile nature of paper and in this technology driven world having something that does not rely on anything other than pencil and paper to achieve a result.

So I was wondering ... how do other LiveCode developers (you) prototype your creations?

[dunbarx]

I think about a project for three seconds, drag a few controls onto a new card, and start writing handlers. Works fine, always did, going back to 1987 HC.

But the lack of a written functional spec, the complete refusal to make a flowchart, always means that, as the project gets inevitably larger and more complex, I have to kluge and patch constantly.

For example, I have a 5000 lines-of-code stack I have been using in my company for years. It is constantly being upgraded with new functionality. When I started, a string was built up during user interaction that I simply parsed by hand into useful components. That string is now so unwieldy that I had to rewrite a good portion of that aspect of the stack to use a table field instead (I bet this is standard practice for most grown-ups). Tables are automatically parsed, so that I can insert and extract data as needed.

So easy and so right. I must grow up.

Craig Newman

[Mikey]

VERY seldom I use a whiteboard, but it is far more useful to do it in LC itself. Fonts, colors, behaviors, shapes, workflows all need work, and a RAD tool is like a CAD tool for that purpose.

[richmond62]

(I bet this is standard practice for most grown-ups)

Having rejigged my Devawriter from ground zero twice I am doing my damnedest to
retreat into a second childhood.

[richmond62]

VERY seldom I use a whiteboard

1. I tend to build toys out of LEGO, kids' building blocks, beads, jam jars, whatever that is 3D, coloured and tangible.

2. Then I move to paper and coloured pencils.

3. Then I move to Livecode.

Increasingly I tend to leave out stages 1 and 2.

The only problem leaving out stages 1 and 2 is if I am mocking stuff up for clients
who tend to feel more confident if they can see some sort of physical model and/or flowcharty-thing
before waving computer code at them.

[AndyP]

Ha. I tried retreating into a second childhood but always got stuck on the way in or just fell out the otherside and just ended up trying to be an adult again.


..and why havn't I got any of these lovely badges..i'supported all of the KickStarters, LiveCode lnfinity etc: -(

[mwieder]

Andy-

Ping Heather - she'll get it sorted out for you.
(the badges at any rate... dunno about the second childhood)

[FourthWorld]

I do a LOT of prototyping. For early-stage design work I think it's no accident everyone loves paper. It's a great part of one's toolkit.

We can make things with high fidelity in LC very easily, but I find that the higher the fidelity of the UI rendering the lower the quality of the brainstorming that happens around it.

When we're kicking around ideas, if a UI looks too finished stakeholders tend to think of it in more finished terms, and become less free in coming up with alternative ways of solving the problem. A hand-drawn sketch keeps the conversation light and fluid, open to all possibilities.

Simple hand sketches passed around the table become wireframes, sometimes used in paper prototyping. Eventually those become higher-fidelity UIs we can craft easily in LC. And of course one of the great things about LC is we get to move from late-stage protyping directly through functional prototypes and on into development, all in the same tool.

But for early-stage design paper is the best tool, mechanically and cognitively.

[richmond62]

of course one of the great things about LC is we get to move from late-stage prototyping directly through functional prototypes and on into development, all in the same tool.

I wonder why Livecode are not shouting about that constantly: it is probably the best selling point about Livecode?

[dunbarx]

Richard.

You are speaking mainly of look and feel. I was talking mainly about structural and programming issues.

In the example I made earlier, the current stack is twice the physical size of the original, due to lots of new controls required to support all the new features. I think this has always been an issue with me; I cannot anticipate what any application will eventually "need" to look like.

I am sure this is not news to anyone. But I have always just built as needed, never having, except in the most basic gadgetry, any idea of what would one day be considered utterly essential, having no inkling of that in the beginning.

Craig

[richmond62]

any idea of what would one day be considered utterly essential, having no inkling of that in the beginning

Well, like you, and, obviously unlike Richard Gaskin, I do find that what I end up with seems almost totally unlike
any initial conception I had: but as that has happened so many times I've stopped panicking, and, like Dr. Strangelove,
learnt to "love the bomb."

As long as one realises and accepts that any plasticine, paper, cookie-dough prototypes are prototypes, with a very
heavy emphasis on 'PROTO', and that the thing will necessarily evolve as one gets into development, unless one
is some type of programming fundamentalist [ The computer program burst forth, fully formed, from Lord Brahma's
mind ], this should not be seen as a problem.

[dunbarx]

Richmond.

All true.

I assume, though, that when they envisioned Photoshop, say, they had a fully formed written functional specification. And I bet all subsequent bloating at least had additional written specs.

The beauty, and danger, of LC is that it is so easy to just jump in.

Craig

[richmond62]

The beauty, and danger

Indeed: that's why I often go and have a long soak in a hot bath with a large cup of coffee first.

And, as I have stated, build a LEGO model to mimic some of the functionality of the thing I envisage.

Certainly I do find that when I build a model I find myself pruning a lot of unnecessary stuff that would
result in bloat once in Livecode.

I remember a lecturer at SIUC explaining how languages tended to go in for "double encoding", that is to say,
an utterance tended to signal things twice: consider: "It eats hay." The fact that that utterance refers to the third-person
singular is coded twice; once by "It" and once by the 's' on the end of "eats". I believe a valuable trick with coding is to try to
avoid a lot of that extra fluff. Another way of putting things is to try to code like a RISC chip not like a CISC chip.

I have also learnt that the idea of reusable modules saves one hell of a lot of bloat: so, for instance, instead of having
57 buttons all containing virtually the same code, I have one button containing somewhat universal code and then
from my 57 buttons all I have to do is "call George" and save an awful lot of space.

But, a long, long time ago, at the University of Durham, a programming instructor who did not like me because
I preferred to do my own programming rather than attend his tedious lectures, mockingly called me "Dr SubRoutine";
personally I rather like that epithet!

[FourthWorld]

Richard.

You are speaking mainly of look and feel. I was talking mainly about structural and programming issues.

I see, thanks. I was replying to the OP, but even with structural things I spend of a lot of time with paper.

Even before UI sketches I tend to start on paper with the User Journey so I can begin to outline how the user conceptualizes their workflow. From that I sketch out descriptions of the data structures needed to support the features that fit that conceptualization. And by the time I have the data structures outlined the code often writes itself.

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
- Eric Raymond, The Cathedral and The Bazaar

[FourthWorld]

Well, like you, and, obviously unlike Richard Gaskin, I do find that what I end up with seems almost totally unlike
any initial conception I had: but as that has happened so many times I've stopped panicking, and, like Dr. Strangelove,
learnt to "love the bomb."

This one area where I feel LC has a strong leg up over HC: HC encouraged us to store code, data, and UI together. LC allows that, but also allows us to factor them separately if we want. And if we do, by having code, data, and UI maintained with minimal connection points we can often change any one of them without affecting the other two.