User Interface First??
Okay gotta question. I'm learning about developing the user interface of a program now. But my question is: When generating the metadata of the entire program, is it best to start thinking about the construction of the user interface first?? Or the code behind it(classes, functions etc.)??
IMO, construction.
Its like if you were a painter, and you wanted to paint something. First you figure out what you want the painting to look like, then you figure out what tools, what colors, etc.
Its like if you were a painter, and you wanted to paint something. First you figure out what you want the painting to look like, then you figure out what tools, what colors, etc.
I'm unclear about what you mean by:
Before development proper starts, someone will have come up with a product concept:
- what is the app for/going to do/enable the user to do
- how will the user interact with the app
- what will the app will look like
- what technologies do we need to/can we use
- how much will it cost (time/money/...)
- ...
This might be a marketing team, after months of product research, a tutor/prof setting an assignment, or a solo developer coming up with a cool idea.
At the end of this phase there is usually at least a provisional feature set and some provisional art work for the UI.
The first thing that happens in development is to analyze the feature set to extract the requirements and produce an initial design (just for key features). At this stage it makes sense to "mock up" the GUI (prob simplified) but also to prototype any key functionality (basically, enough code to test that any functionality that the app really relies on actually works!)
But I think it's more appropriate to think in terms for modules/subsystems rather than classes. Even when they small scale.
A complicated app will be implemented in phases. So you don't have to finish the requirements to start the design, or the design to start the implementation. In the first iteration you focus on a small set of the key requirements.
So, to go back and aswer your original question, it is better to do a bit of both (to start with).
Andy
| generating the metadata of the entire program |
Before development proper starts, someone will have come up with a product concept:
- what is the app for/going to do/enable the user to do
- how will the user interact with the app
- what will the app will look like
- what technologies do we need to/can we use
- how much will it cost (time/money/...)
- ...
This might be a marketing team, after months of product research, a tutor/prof setting an assignment, or a solo developer coming up with a cool idea.
At the end of this phase there is usually at least a provisional feature set and some provisional art work for the UI.
The first thing that happens in development is to analyze the feature set to extract the requirements and produce an initial design (just for key features). At this stage it makes sense to "mock up" the GUI (prob simplified) but also to prototype any key functionality (basically, enough code to test that any functionality that the app really relies on actually works!)
But I think it's more appropriate to think in terms for modules/subsystems rather than classes. Even when they small scale.
A complicated app will be implemented in phases. So you don't have to finish the requirements to start the design, or the design to start the implementation. In the first iteration you focus on a small set of the key requirements.
So, to go back and aswer your original question, it is better to do a bit of both (to start with).
Andy
| IMO, construction. |
| Always design from the outside and work your way in. |
The goal of a good UI is to do what the user thinks it should do.
How that goal is accomplished may differ radially from how things actually work under the hood -- or, it may be very similar.
When planning your program, you must consider both the UI and the internals. This is where the requirements that andywestken mentioned come in. You need an idea of what your program does, and how the user will get your program to do it.
Hope this helps.
Sorry, for clearance, metadata was referring to the overall brainstorming process of programming.
And thank you guys so much. So the gist of it is: Design from the highest levels of abstraction(modules/subsystems), and work your way into the internal working of the program(functions, etc.)?
once again thanks everyone. Just a young kidd trying to learn. Im always open for any advice and help
And thank you guys so much. So the gist of it is: Design from the highest levels of abstraction(modules/subsystems), and work your way into the internal working of the program(functions, etc.)?
once again thanks everyone. Just a young kidd trying to learn. Im always open for any advice and help
Topic archived. No new replies allowed.