Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
You mean Console as in Terminal, right? Not Console as in Playstation.. –  JBRWilkinson Oct 8 '10 at 16:08
    
@JBRWilkinson: Yes. I'll clarify the question. –  gablin Oct 9 '10 at 8:25
add comment

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.

share|improve this answer
    
+1 for the comprehensiveness –  mumtaz Oct 25 '10 at 22:55
    
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 Feb 22 '13 at 9:03
add comment

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.

share|improve this answer
    
Agree. The thing you need to learn is that your code is not fully in control of what the user may do next. –  user1249 Oct 9 '10 at 9:22
    
With the eception of dialogues. –  Morgan Herlocker May 27 '11 at 22:21
add comment

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

share|improve this answer
    
+1, as threading is a really tedious technical issue to cope with. –  Clement Herreman Feb 22 '13 at 9:31
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
1  
Have one look at Google Wave or iMovie and you know these images are misleading. –  Ivo Flipse Mar 30 '11 at 16:28
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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