I think we tend to take design for granted. Sure, when we use a product that is particularly well designed, like the Windows Phone operating system, we’ll take special notice. But generally speaking we just expect things to work well and look pretty. This applies as much to software as any other product. But it doesn’t just apply to the look of applications, it also applies to the code used to build them.
I am currently working on a number base converter for Windows Phone. It is the second application I have ever built. What I’ve learned is that building functionality is one thing, but design is a completely unique animal and can be just as difficult, if not more so. After all, what good is a method to convert one number to a bunch of other bases without a user interface to make it easy to use and to look pretty doing it? I know, obvious, but for a beginner it’s not that simple. I/you don’t have the experience yet to make it easy.
So I thought I’d share a few things I’ve learned so far that may help you along:
- Think through your design before you start coding: You don’t build a house without a blueprint, so don’t build your applications without one. Layout how would you like the user interface to look, what functionality you want your app to have, etc. You won’t think of everything during the design phase, but laying out what you think you want will save you tons of time in the end. Use whatever design tools you want, pencil and paper, Sketch, Illustrator, it doesn’t matter. Use what you’re comfortable using. And make the design process appropriate for the complexity of your app. Don’t spend 4 weeks laying out an app that does nothing more than hyperlink to your Facebook page. At some point you just have to start coding.
- Design is an iterative process: For my base converter, I thought I had figured everything out during the design phase. But as I started building I realized there were quite a few things I had never even considered. For example, I have a pop-up keyboard that allows the user to easily enter the base of the number they want to convert to another base. When this keyboard pops up the primary keyboard is hidden to give focus to the task at hand, entering a base. The “base” keyboard only disappears after the user has selected a base to convert from, which seems logical. But what if they decide not to enter a base and just want to close the keyboard? Do I add a Close button? That would disrupt the look of the keyboard. Plus, the natural thing to do in most cases with Windows Phone is to use the back key to get out of something. Users would likely press the back key before they tried anything else. Ok, fine, no problem. But my app is a single page app and pressing the back key exits the app. That’s not good. So I instead need to reprogram the back key to close the base keyboard when it is visible. Seems simple now I have thought of it, but it never even crossed my mind before. It’s likely you’ll come across all kinds of little nuances you never thought about until you go through the testing phase. “Ok, press this, that works. Press this, nope that’s not what I want. Fix that. Ok fixed. Press this. Nope, it should do this instead. You know, I think if we made this change colors instead of doing this other thing that would be better. Hmmm…which color?” You get the idea. Oh…TEST OFTEN!!!!! Don’t wait until you think you’ve finished your app to start testing. Test along the way. Build a new method, test it. Add some buttons, test them. It’s easier to build and test in pieces than it is to slap it all together and hope everything works.
- Well designed code is just as important as a well designed UI: Writing code is an interative process just like design, particularly for new programmers. Oftentimes what I do is write a method or put together a design element using my current knowledge just to see if I can get everything to work. Once I get things like I want them, then I go back and try and learn a better way to put it all together. For example, if I want 10 buttons on a screen, I might start by building a button in XAML and then duplicating that XAML code 9 times. Hmmm…but I see that all 10 buttons have the same font, and the same margins, and the same background color, etc. There has to be a better way to do this to reduce the amount of code duplication. I wonder if you can create a button template? Bing search. Yep, you can. Sweet. So then I create a style template, apply that style template to each button, and delete all of the duplicate XAML code. Hmmm…this is a pretty simple layout, I wonder if I could create these 10 buttons using a for loop in C# rather than doing all of this XAML stuff? Yep, apparently I can. So let’s try that. Awesome. Instead of having 100 lines of XAML, I now have 15 lines of C#.You’ll also want to spend time commenting your code. Yes, I know, it’s your code, you know how it works. Yeah, but by next week you’ll have forgotten. Why not spend a few minutes now making notes of how and why you did something rather than have to guess later? Certainly at some point you’ll update your app, so make things easy on yourself and use comments liberally. I don’t care if you have to write a paragraph to help you remember how a function works, just do it.
There have been hundreds, if not thousands, of books written on user interface and code design. And I can tell you to go read them all. But I just wanted to share with you a few experiences I’ve had as a beginner, demonstrating to you that, at least for a beginner, application development is a dirty, iterative process. I want you to understand that a simple, pretty end product can be a complete pain in the ass during the design and development stage. And I most importantly want you to understand that the more you design, the more you code, the easier everything will become.
Keep your chin up and happy coding!