Do you GUI First? [Poll & Discussion]

  • (2 Pages)
  • +
  • 1
  • 2

19 Replies - 21139 Views - Last Post: 06 August 2012 - 10:06 AM

Poll: Do you GUI First? (37 member(s) have cast votes)

Do you design the GUI First?

  1. No (Reply with Rationale) (14 votes [37.84%] - View)

    Percentage of vote: 37.84%

  2. Yes (Reply with Rationale) (23 votes [62.16%] - View)

    Percentage of vote: 62.16%

Vote Guests cannot vote

#16 Celerian  Icon User is offline

  • D.I.C Regular


Reputation: 144
  • View blog
  • Posts: 384
  • Joined: 30-March 12

Re: Do you GUI First? [Poll & Discussion]

Posted 10 May 2012 - 07:43 AM

View Postwoodjom, on 10 May 2012 - 07:13 AM, said:

And there in lies the defining reason. A well defined scope, on paper of course :), will make GUI design alot easier and less cumbersome on the development time.

In the past i have dealt with developer that make the car look like a Corvette even though when put on the road performs like a Pinto. Which means they spent 80% of their time on the GUI and 20% of their time on the content of the development. Which is "bass ackwards" and leads to developers getting a bad rapoire cause of a few "idgiots"

I just dont put alot of time or effort in developing the interface as it is fluid and can be easily changed with a few mouse clicks, drag-and-drop, or ultimately the delete. The content of the software is a different point in case and is almost always the opposite of the GUI.


This, and what Adam said above, is why I like the Visual Studio suite. When I build an application, I end up doing a little bit of both together. If its an application I need quickly, I can do nasty code and just tie functions to my display and make it work. If I need something more complicated, I can wrap it nicely like Adam's third example. Sometimes, I'll start with the quick and dirty so I can get some real working data on the form, and then after I get the project operational, I start refactoring the project as a whole to make everything cleaner.

Recently, a lot of my job has been taking Excel reports that were generated by our QA Manager running prebuilt stored procedures and plugging in data and automating them. So the GUI was already "built" because they had a layout for how the data looks. In the process of automation, I may move the report layout around a bit, sometimes to make it easier to code, and sometimes because I don't care for how they have their report laid out. This is one case where I would say the "GUI" was built first and the code tailored to it.

My other pet project is a monitoring service for multiple aspects of our production outfit. I'm not exactly sure what I want to see or what I may make it do, since there was never any scope. Most of the time, I'm sitting in my cube going, "Hmm, this might be interesting.." and then I start doing my mix of GUI and code until I figure out something I like. Once I've got a basic working concept, then I can refactor my code and adjust the GUI as necessary. But maybe my environment isn't standard, because I'm the only software engineer in the building. I have (mostly) unsupervised control over what I build, as long as what I'm doing is making the entire operation better or is solving a specific problem. I work best in this type of setup, because 99% percent of my time is spent with a whiteboard, my mind, and my compiler, and we're all pretty good friends.

I also understand the "code first, make it pretty later" train of thought, because I worked for a more standard software company several years ago. Multiple developers and a few QA personnel to try and break our software. In that environment, it was more helpful to take a problem and get the code to be as reusable as possible. Reason being: with multiple developers all working on different aspects of the same program, if you solve a problem and wrap it up, then the other devs can basically drop in the code you've written, and they don't waste their time doing it again.

All in all, the way you code is dependent on the project and the environment.
Was This Post Helpful? 1
  • +
  • -

#17 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Do you GUI First? [Poll & Discussion]

Posted 10 May 2012 - 02:54 PM

I personally have found that "a well-defined scope, on paper..." is usually a chimera. Of course, I'm more of an iterative design kind of person than a waterfall guy. (Waterfall was cool back in 1970 when the cost of manufacturing a gigabyte of RAM was around $2,000,000,000 as opposed to about $1 now; practical prototypes and multiple iterations were, well, impractical.) As Celerian says, the project and the environment affect the development methodology. However, my development philosophy leans towards getting a rough idea of the requirements, prototyping them out, showing the result to the stakeholders, getting a little less rough idea of the requirements, and so on.

This post has been edited by BobRodes: 10 May 2012 - 02:55 PM

Was This Post Helpful? 0
  • +
  • -

#18 iNihan  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 8
  • Joined: 20-June 12

Re: Do you GUI First? [Poll & Discussion]

Posted 22 June 2012 - 01:03 AM

I Feel Comfortable in coding after making GUI :gunsmilie:
Was This Post Helpful? 0
  • +
  • -

#19 lordofduct  Icon User is online

  • I'm a cheeseburger
  • member icon


Reputation: 2538
  • View blog
  • Posts: 4,639
  • Joined: 24-September 10

Re: Do you GUI First? [Poll & Discussion]

Posted 26 June 2012 - 09:09 AM

My projects seldom have to with GUI as the main part. I'm usually working on the more technical background bits while someone else takes care of the client side that hooks into my code. Personally I HATE gui's, may they be done with authoring tools, or by hand. Layout, visual design, arghhhhhh!
Was This Post Helpful? 0
  • +
  • -

#20 FusionDude  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 26-July 12

Re: Do you GUI First? [Poll & Discussion]

Posted 06 August 2012 - 10:06 AM

I am an amateur programmer but of course, everyone USES a lot of software. And I continually see junk software that forces you to do things that you don't want and don't need.
For a user, the person who pays for the program, the GUI is all there is. GUI First is the reason I use VB, first VB5 and now VB.NET.
The user will always says GUI first. If the user can't use it, what's the point? No point. No customer. Software is supposed to be soft, responsive to what the user wants it to do.
Sure you can write a great program, with the casual idea of what the customer wants. The customer may even buy it when you explain how great it is. However, if the user can't actually use it in day to day practice to do what needs to be done, your new software may actually drive a company out of business.
I'm not speaking as a programmer here. I'm speaking as a longtime user of all kinds of software, such as databases, word processors, factory processes, warehouse processes. Frequently users have to "work around" the junk they bought because it doesn't do what they wanted but they got sold on it. GUI is the Visual in Visual Basic. I would think that's why it's popular. Also I thought that's why Microsoft beat out IBM in the once-upon-a-time. IBM stuck you with something and anytime you wanted it changed you had to pay a programmer to change it. So I'm all for GUI first.
Of course, I can see by the preceding votes that the critical issue is that the customer has to know what he wants. And management may not know or may not be aware of what really needs to be done. So your project may be doomed to failure if management is out of touch with sales, warehouse, factory floor or whatever.
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2