Ask HN: I'm an experienced backend developer, but clueless about GUI app dev.
5 comments
The toolkits are really just a starting point.
Most of them work on a callback manner, similar to how you'd deal with device drivers, e.g. someone pressed a button and you'd respond with showing/hiding another panel. However, if you wrote code like that, it'd be completely spaghetti. So you are asking a very valid question here.
The second issue is most GUI tookits will only allow you to interact with the toolkits on the UI thread. Each language/tookit have their own style of queuing up some functions to be run on the UI thread. You need to figure out what is the canonical way of dealing with this up front.
The third issue is most callbacks occur on the event thread. This means that you cannot run long processes as the UI literally freezes until you hand control back to the main event loop.
Testing is another source of pain. Most GUI toolkits were not built with testing foremost in mind. However, it is not necessarily easy to shim/mock the GUI components because they can hold quite a bit of state.
Now that we got that out of the way, I'd like to say that if you have developed headless utilities, then you are actually in a better situation than people who started programming by learning GUI.
You could start off by deconstructing existing applications.
First off, enumerate all the states a UI could be in e.g: New, Dirty, Validating, Saving, Saved. Note how these states are shown on the UI. There might be labels for error messages that are normally hidden, and made visible when validation errors occurs, etc. I like to have it all centralized in one subroutine, so that when the state changes, the routine makes sure all the UI elements are in the right state. These states also govern whether you need to prompt users to "Discard, Save or Cancel" when they close the application.
Secondly, if this is your first project, stay away from data binding. I usually have a model which essentially duplicates all the UI information, and have a pair of routines pushToUi(), pullFromUi() to marshal back/forth the visual state. While this is somewhat repetitive, it allows you to make minor changes your UI - (e.g. DatePicker instead of a TextBox, move a field to a panel that is usually hidden) and your program will still work.
Thirdly, a GUI app usually has three cooperating components - Model (your data), View (the toolkit) and Controller (the glue). Limit the interaction and your application will be more easily testable. For instance, you could have the Model pushing data to the View, the View pushing events to the controller, and the controller changing state on the Model. There are probably 6 ways you can combine the interaction, but try to avoid two-way interaction between all three components - it will be difficult to figure out.
Fourthly, asynchrony is a fact of life. Don't perform database calls (and definitely not a call to a web service) on the main UI thread. Put the job on a queue, and let the background thread do it. Microsoft .NET have a BackgroundWorker and thread pools to tackle this. You can use some of their ideas if your platform doesn't have this. An application that is full of callbacks can be difficult to grok. This brings me round to my original point that if you've written device drivers before, you already know this, and probably have some techniques to tackle it in a sane manner. If you don't - judicious use of coroutines via Duff's device, or the yield statement can do wonders for your code in terms of readability.
Fifth, be aware that event handlers attached to objects will prevent those objects from being garbage collected, even though they are no longer visible. Make sure you unwire the handlers before you lose your final reference.
As far as designing the UI goes, just bear in mind most people using the app couldn't care less about the app. All they want is to use it to get their work done and go home. So your task is to figure out which is the most common thing they want to do and unclutter the UI so they can figure out how to do it quickly. This is where your program design comes into play. A well laid out application will be easy to modify when you iterate without having to tear up all the business logic.
Most of them work on a callback manner, similar to how you'd deal with device drivers, e.g. someone pressed a button and you'd respond with showing/hiding another panel. However, if you wrote code like that, it'd be completely spaghetti. So you are asking a very valid question here.
The second issue is most GUI tookits will only allow you to interact with the toolkits on the UI thread. Each language/tookit have their own style of queuing up some functions to be run on the UI thread. You need to figure out what is the canonical way of dealing with this up front.
The third issue is most callbacks occur on the event thread. This means that you cannot run long processes as the UI literally freezes until you hand control back to the main event loop.
Testing is another source of pain. Most GUI toolkits were not built with testing foremost in mind. However, it is not necessarily easy to shim/mock the GUI components because they can hold quite a bit of state.
Now that we got that out of the way, I'd like to say that if you have developed headless utilities, then you are actually in a better situation than people who started programming by learning GUI.
You could start off by deconstructing existing applications.
First off, enumerate all the states a UI could be in e.g: New, Dirty, Validating, Saving, Saved. Note how these states are shown on the UI. There might be labels for error messages that are normally hidden, and made visible when validation errors occurs, etc. I like to have it all centralized in one subroutine, so that when the state changes, the routine makes sure all the UI elements are in the right state. These states also govern whether you need to prompt users to "Discard, Save or Cancel" when they close the application.
Secondly, if this is your first project, stay away from data binding. I usually have a model which essentially duplicates all the UI information, and have a pair of routines pushToUi(), pullFromUi() to marshal back/forth the visual state. While this is somewhat repetitive, it allows you to make minor changes your UI - (e.g. DatePicker instead of a TextBox, move a field to a panel that is usually hidden) and your program will still work.
Thirdly, a GUI app usually has three cooperating components - Model (your data), View (the toolkit) and Controller (the glue). Limit the interaction and your application will be more easily testable. For instance, you could have the Model pushing data to the View, the View pushing events to the controller, and the controller changing state on the Model. There are probably 6 ways you can combine the interaction, but try to avoid two-way interaction between all three components - it will be difficult to figure out.
Fourthly, asynchrony is a fact of life. Don't perform database calls (and definitely not a call to a web service) on the main UI thread. Put the job on a queue, and let the background thread do it. Microsoft .NET have a BackgroundWorker and thread pools to tackle this. You can use some of their ideas if your platform doesn't have this. An application that is full of callbacks can be difficult to grok. This brings me round to my original point that if you've written device drivers before, you already know this, and probably have some techniques to tackle it in a sane manner. If you don't - judicious use of coroutines via Duff's device, or the yield statement can do wonders for your code in terms of readability.
Fifth, be aware that event handlers attached to objects will prevent those objects from being garbage collected, even though they are no longer visible. Make sure you unwire the handlers before you lose your final reference.
As far as designing the UI goes, just bear in mind most people using the app couldn't care less about the app. All they want is to use it to get their work done and go home. So your task is to figure out which is the most common thing they want to do and unclutter the UI so they can figure out how to do it quickly. This is where your program design comes into play. A well laid out application will be easy to modify when you iterate without having to tear up all the business logic.
The top 3 books concerning design are probably:
About Face
The Design of Everyday Things
Don't Make Me Think
As well I think you may be looking at what you are trying to achieve in the wrong way. Human Factors exist above the technology and is more of philosophical discipline. The limits of the technology constrain design and you learn to work within the constraint of the particular technology. With that said optimal workflow is achieved by taking common design principals and adapting them to the technical medium. That being said, regardless of the technology you use, you should read at least one of the above 3 books. IT will help you understand what you are trying to achieve on behalf of the user. Once you understand that, it is easy to adapt the principles to the medium of your choosing.
As for what you should implement your fist UI in, that relies on a assortment of factors. If you are not familiar with web technologies, just understanding the technology soup that is HTML/CSS/JavaScript/Backend can divert focus from learning good usability practices, but if web is your end goal then it makes sense to go ahead and invest the effort. If it is not, then IOS and Objective-C is a good candidate, it really helps you work within constraints and makes you really contemplate the design. Finally if you are only learning for learning sake, then I would say Flash or Air should be considered, not because they are great technologies, but because you can hit the ground running immediately and if learning usability for the sake of learning it is your goal, they will get you to the end of that goal in the fastest manner possible.
About Face
The Design of Everyday Things
Don't Make Me Think
As well I think you may be looking at what you are trying to achieve in the wrong way. Human Factors exist above the technology and is more of philosophical discipline. The limits of the technology constrain design and you learn to work within the constraint of the particular technology. With that said optimal workflow is achieved by taking common design principals and adapting them to the technical medium. That being said, regardless of the technology you use, you should read at least one of the above 3 books. IT will help you understand what you are trying to achieve on behalf of the user. Once you understand that, it is easy to adapt the principles to the medium of your choosing.
As for what you should implement your fist UI in, that relies on a assortment of factors. If you are not familiar with web technologies, just understanding the technology soup that is HTML/CSS/JavaScript/Backend can divert focus from learning good usability practices, but if web is your end goal then it makes sense to go ahead and invest the effort. If it is not, then IOS and Objective-C is a good candidate, it really helps you work within constraints and makes you really contemplate the design. Finally if you are only learning for learning sake, then I would say Flash or Air should be considered, not because they are great technologies, but because you can hit the ground running immediately and if learning usability for the sake of learning it is your goal, they will get you to the end of that goal in the fastest manner possible.
15 year full stack developer here with at least 8 of those years doing GUI stuff. Over the years, the two biggest things that helped boost my skills were:
1) Write a game.
It may sound cheesy, but it gives you a frame of reference to work from. Most people have played enough games to know when the interaction feels right or wrong. If, like me, you decide to write a game in the browser, it will also teach you many, many things about working with the DOM, optimizing for performance, managing memory, etc... Plus, it looks freaking fantastic on the resume. I recommend a 2D side scroller (I did Mario in JS) or top down (zelda would be cool). Be careful of anything with large numbers of moving things on the stage at once (contra, for example). Optimization can kill you with those.
2) Write in a framework.
For instance, if you write a iPhone app, the obj-c based framework tends to guide you towards a usable, responsive app. Same thing with Rails and QT. You can also find scaffolding for all of the above that will lay down the groundwork for you to expand on.
1) Write a game.
It may sound cheesy, but it gives you a frame of reference to work from. Most people have played enough games to know when the interaction feels right or wrong. If, like me, you decide to write a game in the browser, it will also teach you many, many things about working with the DOM, optimizing for performance, managing memory, etc... Plus, it looks freaking fantastic on the resume. I recommend a 2D side scroller (I did Mario in JS) or top down (zelda would be cool). Be careful of anything with large numbers of moving things on the stage at once (contra, for example). Optimization can kill you with those.
2) Write in a framework.
For instance, if you write a iPhone app, the obj-c based framework tends to guide you towards a usable, responsive app. Same thing with Rails and QT. You can also find scaffolding for all of the above that will lay down the groundwork for you to expand on.
I have a similar problem.
My first GUI experience was to maintain a massive Java Swing app (back when v < 1.2), which left me with some type of mental trauma. I've been trying to recover by re-starting from where I feel comfort (ie terminal):
https://pixbyfunc.appspot.com/pub/term/v1.html
I know it's pretty stupid but it actually helped me hunt down another personal 'white whale', which is asking contingent questions via browser:
https://pixbyfunc.appspot.com/pub/term/ask.html
I am not sure if I can ever become a good UI guy at this rate but wanted to say you are not alone.
End of my 0.0219 (CAD).
My first GUI experience was to maintain a massive Java Swing app (back when v < 1.2), which left me with some type of mental trauma. I've been trying to recover by re-starting from where I feel comfort (ie terminal):
https://pixbyfunc.appspot.com/pub/term/v1.html
I know it's pretty stupid but it actually helped me hunt down another personal 'white whale', which is asking contingent questions via browser:
https://pixbyfunc.appspot.com/pub/term/ask.html
I am not sure if I can ever become a good UI guy at this rate but wanted to say you are not alone.
End of my 0.0219 (CAD).
There is no book teaching both GUI development and "process of good design from scratch" . GUI design and GUI development are different things. You can develop graphic user interface with different languages like java, wxPython or whatever you want. But graphically designing things is a whole different area. I dont know anyone who can do both. A UI designer can be a front-end developer, but it's very hard to learn functional server-side languages at the same time. For designing things you must have also talent.
I can (and have) read API documentation, which is usually sufficient, but when it comes to GUI app development and design, I can't see the forest for the trees.
Are there any recommended books that cover a language or toolkit specifically for GUI development, but which also teach the process of good design from scratch?