I started, like many others, with console-based (as in terminal, not Playstation) programming. But sooner or later, one needs to touch upon GUI-based programming, whether you want to or not. This transition holds many changes in how you need to think about the frontend (and possibly also the backend).

So, what are the major differences when moving from console-based programming to GUI-based programming?

  • 1
    You mean Console as in Terminal, right? Not Console as in Playstation.. Commented Oct 8, 2010 at 16:08
  • @JBRWilkinson: Yes. I'll clarify the question.
    – gablin
    Commented Oct 9, 2010 at 8:25

8 Answers 8


The biggest difference is the design of the UI. A good GUI can make or break an application. Mac fans would draw attention to the beautifully designed GUI's of the average Mac OS X app and they've got a point, but this isn't a technology issue - it's a design/ethos/usability issue.

As for technical issues, in no particular order:

  1. The user can do anything they want in any order at any time, unlike console program in which you're either asking for input or telling them the output. You cannot assume that they'll follow the order you hope, unless you enforce the workflow Wizard-stylee.

  2. As already mentioned, events play a big part in this, and you can get multiple events happen while you're servicing the last one, so you can't really construct your state based on the 'current event'. Use closures or a similar mechanism to maintain context across different events. In a console app, your FSM is usually self-contained around the 'get input, process input, update output' loop. There isn't the same kind of structure in GUI programming - the 'main' is a re-entrant event-driven thing, often a ginormous switch() statement.

  3. You need to consider different screen sizes/resolutions and allow the GUI to resize from 800x600 up to the users' monitor maximum.

  4. You need to consider different input strategies - mouse, keyboard, touch, etc. Some technologies come for free (Mouse-wheel scrolling), others require some integration work (Ink).

  5. Accessibility - a GUI is much more suitable for less able users who have restricted vision, hearing, motor skills or cognitive skills. A 'ding' noise is nice and obvious compared to a cryptic error message on the console.

  6. Internationalization - i'm assuming your console app is US/ANSI only, but when you get into GUI, you can have language/resource packages that can target other languages and regions with no change to the coding, if you prepared for it from the start. For example, no hard-coded language strings in the code - everything as resource lookups.

  7. You have lots more options for implementation technology - web-based, various GUI kits, Flash/WPF, etc.

  8. Use of colour and animation. Console programs are generally monochromatic and don't animate much. Many modern GUI frameworks provide themed widgets and have move/size/show/hide animation effects, often for free.

  9. Graphics. Console apps sometimes use ASCII art for diagrams, but a GUI app gives you full graphical ability. Lovely art can make a big difference too.

  • 1
    While I see your point in general, I kinda disagree with a false dichotomy here. I mean, you need to pay attention to UI for console apps as well, you can have event-based console apps, you can have a terminal apps that's actually displaying a GUI and not just linear text and needs to pay attention to resizes (and may work with a mouse), you can do accessible cli apps, you internationalize cli apps the same way as gui ones, you can use colors and animate things. I'll grant you that 7 and 9 are more limited.
    – haylem
    Commented Feb 22, 2013 at 9:03

For me it would be getting used to event-driven programming. It can still apply to console-based software but I find its mostly used with GUI. Once you grasp it, its a very powerful tool.

  • Agree. The thing you need to learn is that your code is not fully in control of what the user may do next.
    – user1249
    Commented Oct 9, 2010 at 9:22
  • With the eception of dialogues.
    – user3792
    Commented May 27, 2011 at 22:21

I would say the multi-threading and it's implication with the UI (if you want to do non blocking UIs)

  • +1, as threading is a really tedious technical issue to cope with. Commented Feb 22, 2013 at 9:31

Consideration for the flow of control on the UI and validation of user input become very important.


A console program tends to be refined over time while a GUI program tends to be screwed.


Usually I think of console-based program as the Model, whereas GUI-based program is the View/Controller that embeds the Model.


For me designing a good GUI has always been way more challenging that the technical details of implementing it.

It's easy to say "make it simple and clear, like a Mac". It's incredibly hard to make it such; there are always so many details that should be there available, but at the same time, they should be out of sight.

simplicity http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png

  • 1
    Have one look at Google Wave or iMovie and you know these images are misleading.
    – Ivo Flipse
    Commented Mar 30, 2011 at 16:28

In some (many?) languages the major difference for me is, that now, you have to choice a library. Doing “console” programming the backbone (and much more, with some luck all) of your application use the standard resources of your language. Adding a GUI you can (hopefully) still have your “model” in standard idioms, but now a huge part, the “view” will depend on some extern library (and, unhopefully, you will stick with it “forever”). The choice of this library is a huge responsibility for a beginner as is your (my) case (not to mention the additional learning-step curve).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.