Suppose, I have an idea and I have to put it into code quickly. And then I am presenting it to someone who is not so computer savvy. Which language should I use for quick and dirty coding? And which GUI toolkit should I use so that the the computer semi-literate find it easy to use (read shiny-eye-candy). It is a desktop application.
2
-
1Please tell us more about your prototype. Do you want to prototype a web-application or a desktop application?– FalconAug 31, 2011 at 8:21
-
It is a desktop application, more like a calculator program for a specific purpose.– KenSuvyAug 31, 2011 at 11:49
Add a comment
|
3 Answers
You could use an application to draw mockups instead of writing code. Like Balsamiq Mockups or equivalent.
Using Mockups feels like drawing, but because it’s digital, you can tweak and rearrange easily. Teams can come up with a design and iterate over it in real-time in the course of a meeting.
answered Aug 31, 2011 at 7:23
-
+1. Usually a bad idea to make a prototype/mockup that looks like a finished application, especially with a non-technical client. Chances are they'll look at the demo and think that means the application is done. Show them a sketch instead so they understand it's NOT done but this is a general idea of what it will look like. Aug 31, 2011 at 15:08
-
1Pencil is a free and open source (GPL) GUI prototyping tool that has many nice features to help you design your prototype screens and interactions. It works as a Firefox addon but standalone application builds are also available on the downloads page. Aug 31, 2011 at 16:46
-
None of these tools will ever beat pen and paper.– user4595Sep 4, 2011 at 23:40
Marco Dinacci's suggestion of using a tool to draw mockups is a good one.
However, if you do decide to implement a prototype, be sure to know if it's a throw-away prototype or an evolutionary prototype. If it's a throw-away, I would suggest using a language and toolkit that you won't be using to implement the final product. For example, if you are going to be implementing the final system in Java, string together some GUI screens using the Visual Studio GUI building tools and C# or VB.NET. This will prevent you from being able to use subpar prototype code in your final implementation. If it's evolutionary, spend the time to learn and develop the UI and evolve it with the entire application.
answered Aug 31, 2011 at 11:55
-
Using a different tech to make the prototype makes no sense. If anything, you should use the same language to test your ideas - if you use some quick and sweet reflection + lambdas + async programming on C#, you'll be really screwed up when you have to write that back on Java or C++. Different languages have different capabilities, and the choice of the language can be very much a dealbreaker for some applications.– T. SarJun 28, 2017 at 16:25
-
@T.Sar That's the point. If you aren't planning to evolve your prototype, make sure that it has to be thrown away. If you are planning on evolutionary prototyping, then you should use the same target language and platform.– Thomas Owens ♦Jun 28, 2017 at 16:26
-
Let's assume you made a C# prototype that is supposed to be throw away using reflection and async callbacks to create a plug-in thingie. How you'll even start writing that back in Java without a total reformulation?– T. SarJun 28, 2017 at 16:29
-
@T.Sar You should think about that when creating the prototype. You should pick a language that offers similar capabilities and limit your use. But don't forget that this question is explicitly about GUI prototyping - this whole answer is based on building a UI. By using a different UI framework that's similar, but needs to be thrown away, you don't end up in a trap where "it looks like it's almost done, so it must be almost done".– Thomas Owens ♦Jun 28, 2017 at 16:32
-
I don't see how. Your client still saw an almost-done UI that just lacked the programey stuff. It will force you to rewrite, sure, but it won't make the client anymore inclined to think that you were almost done when you showed the prototype. He will question you if you can't just finish the prototype instead of starting from scratch.– T. SarJun 28, 2017 at 16:49
A language you feel comfortable in and the GUI toolkit you want to use in the end product.
That way you can reuse the GUI parts in your final version. The language doesnt really matter for the prototype - if you are comfortable in it, it'll be easier and faster to write.
-
That's only true for evolutionary prototyping. In a throwaway prototype, you want to ensure two things - (1) the customer doesn't associate a prototype that demonstrates a UI with a mostly finished product and (2) you can't reuse the (most likely poorly designed) code in your final product.– Thomas Owens ♦Aug 31, 2011 at 14:34
-
2The answer is not wrong per se, but I disagree with it, vehemently. A client/non-programmer, seeing a GUI very similar to what the product should look like, will assume "it's almost complete. It just needs a few of those weird programmy thingies out back, but hey, it looks about 90% done, so it must be about 90% done". Hey presto, every meeting from then on will be "why is it not done yet? You were at 90% with the prototype, stop slacking off"; and there is no way in heaven or hell to convince such person that no, GUI != complete program. This is why Balsamiq looks like an ugly sketch. Aug 31, 2011 at 14:36
-
@Piskvor Do you know where that originally came from? I remember reading it somewhere, and I think I own that book (or a book that cites that advice), but I can't remember what it's from.– Thomas Owens ♦Aug 31, 2011 at 14:38
-
@Thomas Owens: Painful experience? ;) I, too, have seen this stated somewhere in a much more concise form; alas, I can't seem to find the source, either. Aug 31, 2011 at 14:42
-
1@Piskvor: that's true. But if you use a themeable GUI toolkit, chances are that a "mockup" theme exists precisely to avoid these problems. See napkinlaf.sourceforge.net for Java Swing.– barjakAug 31, 2011 at 16:56