Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 GUI vs programming, the unfortunate truth
Index -> General Programming
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
mirhagk




PostPosted: Mon Jul 30, 2012 3:49 pm   Post subject: GUI vs programming, the unfortunate truth

I'm sure most of us are in the same boat here. We're programmers, not designers. We're comfortable with creating a program with complex text based input, and thousands of command line parameters, or complex keyboard shortcuts, but once you ask for a button we're stumped.

I've read a lot of great articles lately
[url="http://www.oreillynet.com/onjava/blog/2004/04/gui_programming_is_hard.html"]link[/url]
[url="http://blogs.msdn.com/b/rick_schaut/archive/2004/04/02/106929.aspx"]link[/url]
that try to emphasize how difficult making a GUI can be.

I believe the biggest pitfall for failed open source projects (and some commercial ones, especially smaller ones) is that they were made by programmers. Programmers can make amazing programs, and the technology is mind-blowing, and perfect in the eyes of other programmers. But just try and give a command line program to a non-program, or demo your awesome program using pseudo-graphics. By contrast most commercial programs (and the most popular open source ones as well) have many failing points with the software, but the GUI looks sexy, and that's what matters to users.

I recently competed in a competition to create a film/app/video game in 48 hours that would fit a topic/theme (it was education, which is hard btw). After some hard work we came up with, and designed a game. The programming was beautiful, built to be easy to port to any platform, the gameplay was nearly flawless, with fast collision detection, and many other difficult concepts. After the 48 hours we had to show our project off to a panel of judges, and some people in the education/science/"technology" fields (The quotes around technology are there because technology does not include programming, it includes making youtube videos). This is when we realized our fatal mistake. Our GUI was not sexy, it was not complete. We worked on making a game that was nearly complete (to the point where after the competition it would have required less than 8 hours of extra work to get it working, minus time to draw the GUI) instead of making a tiny portion of the game look sexy. This I feel is the reason why many smaller companies (especially game companies) fail, and why many other companies succeed even with crappy programs and video games. You have only a few minutes to impress the judges (in the competition as well as in trying to get funding). This is the most important thing to remember when trying to show something off (a final project for school, competition or trying to get funding):

A program can't be shown off in 5 minutes. You can't describe the algorithms or how it does what it does, or even show off advanced features in 5 minutes. What you can show is a completely fictional representation of what you have, with sexy GUI, explosions, fireworks and a bunch of crap.

So I suggest making the sexy looking representation, essentially lying about our program until you get your approval (funding, marks, winning a competition). After that, throw out everything you have in terms of code, and make a program to work with that sexy GUI. Here's a few examples:
-Collision detection. Do the most basic collision detection you can possibly get. Circle to circle. You can even fake it if you want. You're going to control the demo (especially if you can get it in a video) so you don't have to make it work in any case but the very limited one you show.
-Menus, screens, HUD etc: Put the GUI up there for it. DON'T WORRY ABOUT MAKING IT WORK. If your showing off a video, and your showing off one of the options in the main menu, because your pressed for time (always) then throw in buttons for features that sound cool. You ever watch a demo and look at the little details and then speculate the awesomeness even without seeing it? Put any features, or ideas that you will eventually include as fake buttons and graphics in the demo, that way people can assume it works without you even having to show it (a great example is including health and mana bars in games, and not having it actually work, just showing different levels of health and mana at different points in the demo. Viewers will assume it's functional)
-AI: You shouldn't even worry about this in the slightest for the demo. AI is necessary in final products, and a lot of work, but in a video demo you don't really get a chance to show it off. You don't even have to have the enemies move to show off the demo, and even if you do, it's the most basic logic (just head towards the character, or location X, ignoring obstacles). You control obstacles in the demo, so just make sure there are none.
-Networking/Multiplayer: Put in a multiplayer option in your main menu, maybe even a fake lobby, and then either create a local multiplayer, or just fake AI code other players (bonus, overlay the audio with other people talking and you can show off the online teamwork that doesn't yet exist).

When coding a project for a demo, make sure you pre-compile the perfect video demo, and every feature you implement will be located at some point in the demo. Design what you will show off in the video first, then make the short software segments to match. You won't have a project, but you will have a hell of a demo, and in the real world that matters more.

This is why commercial software usually has sexy GUI, but crap behind the scenes logic. Investors see a sexy GUI, invest in it without even looking at the back end. The back end is most important to a good program, but the front end is most important to a good application (things that people will buy/use).

What are your thoughts, experiences, tips and tricks on this subject?
Sponsor
Sponsor
Sponsor
sponsor
Sur_real




PostPosted: Mon Jul 30, 2012 8:09 pm   Post subject: RE:GUI vs programming, the unfortunate truth

haha wow that's sort of exactly what I'm going through for my coop position right now.

I'm doing android dev right now and working at a small startup means I'm the only android developer on the team. So I'm mostly done the backend and I also have a decent frontend GUI working but to be honest, it's not google+ or gmail UI material lol (although you gotta give me credit since they probably got a team of top engineers working together).
So yeah designing for a good UI is just as hard since a programming question is just one search away lol (hint: stackoverflow).

There is ux.stackexchange.com but it's mostly theoretical help so you still gotta design/make it yourself (which is equally hard...for me at least...I'm not very artistic haha)
2goto1




PostPosted: Mon Jul 30, 2012 8:54 pm   Post subject: RE:GUI vs programming, the unfortunate truth

Without knowing much about your competition, there are lessons for you to learn. First, make sure that you understand what you're competing in - look at past winners, talk to the organizers, and find out what you can about the judging criteria. Since the contest was open to film submissions, it should have been an "aha" moment to realize that it wasn't going to just be about how good your programming was. Still it was good for you to go through the process.

Keep in mind what you've learned for next time. Sometimes a smoke and mirrors demo is all you need. Sometimes a prototype with just one very directed path is all you need. Sometimes you need something else, every situation can be different.

Re commercial software - one thing that students don't understand is that scale and time both introduce ugly complexities. But that's a good thing because it allows students to focus on creativity and well designed little programs.
mirhagk




PostPosted: Mon Jul 30, 2012 10:08 pm   Post subject: RE:GUI vs programming, the unfortunate truth

I've been working on commercial software for about a year now, I know that complexities that can arise. However I have been VERY fortunate that the job has been for clinical surgeons, and the GUI isn't as important as it is for public applications. (well except for the fact that it needs to be quick to navigate, and randomize patients).

In terms of demo-ing a program, I have found through many competitions, showing programs off to others, school projects and others that smoke and mirrors is generally the best. Usually you don't get a chance to pass off the controller to the other person, so you have to show them what you have, and a smoke and mirrors video is the best thing to do that.

Also I was pointing out the difference between open source and commercial software. Commercial software is not always better (and usually isn't when there's a big open source alternative), but it's usually a lot prettier, because programmers like to make programs first, and GUI 2nd.

@sur_real I have had that problem so much with designing video games on the side. The game engine can be amazing, but without any artwork, the game looks like I haven't done anything.
Amarylis




PostPosted: Mon Jul 30, 2012 10:45 pm   Post subject: RE:GUI vs programming, the unfortunate truth

Personally, I suck at making anything look nice Razz it's an ongoing battle for me, but I'm generally quite proud of my programs and how the run, etc. That being said, the majority of the people I converse with are bit programmers, and when I show them what I've done, I often get weird looks and have to tell them that I "promise it's cool"
Insectoid




PostPosted: Mon Jul 30, 2012 10:51 pm   Post subject: RE:GUI vs programming, the unfortunate truth

I agree with all points in this thread. They take forever to make, even in a WYSIWYG editor, whereas a TUI can be coded very quickly, and even more quickly with a TUI template.
mirhagk




PostPosted: Tue Jul 31, 2012 11:54 am   Post subject: RE:GUI vs programming, the unfortunate truth

The creator of stack overflow suggest making your UI in powerpoint (or something similar) so that you don't think about coding the UI until you actually start coding. I often find UI's very programmer friendly, but less user-friendly.

Users are morons and it's hard catering to morons. If you don't think users are morons, offer to help others out. You will literally have to repeat the following phrases over and over:

"Did you turn it off and on again?"
"Is it plugged in?"
"Is it on?"
"Try closing the window and opening it again."
"Use a different browser" 'What's that' "A browser is what you use to browse the internet" 'you mean google?' "No. What do you click to go to the internet?" 'the little icon on my computer' "Does the icon look like an e, a world with a fox around it, or a circle that's yellow green and red?"
Display posts from previous:   
   Index -> General Programming
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 1 of 1  [ 7 Posts ]
Jump to:   


Style:  
Search: