How / When to develop an interface?

I’m trying to get used to the interface design on my sites at the very beginning, before I really do the encoding. I read "Getting Reality" on 37 signals, and they recommend that you first run the interface before any real code is created.

What exactly is meant by this? Does this mean using pure HTML and CSS to develop the site and add php, js logic to the page later, or is it normal to sprinkle php, js from the very beginning?

What if you use the framework, should I install empty controllers that just call views, or should there be only html, css in the early stages?

Also, what do you guys think of design first and later?

EDIT I'm talking about AFTER I drew everything with a pen and paper. I'm just talking about html layouts. And I'm not too sure about using additional tools that I will need to learn how to do.

+4
source share
4 answers

I think that most of the benefits of developing an interface were primarily achieved after you made your paper sketches. Basically, you simply guarantee that you have a design in mind and that your coding process is somewhat end-user oriented. You also try not to waste time on unnecessary documentation.

Getting HTML in place (or representation skeletons in an MVC application) makes sense, and this is the basic idea of ​​what 37signals says. Of course, I would have done nothing but this, which would simply be thrown away.

I think that if you have the right design, it doesn’t matter if you move on to writing back-end code after HTML or if you execute CSS and JavaScript. CSS and code do not even need to know about each other.

Do everything that excites and motivates you. Do something that makes you think more deeply about how the application really works so that you can catch any flaws in your original thinking. I like the code before CSS, but it's just me. It may be important for you to get the CSS further before the application takes shape in your head.

Joel Spolsky loves Balsamiq as a mocking tool. I think 37signals uses Draft (iPhone app). I am using Sharpie. The key is not too detailed.

Opinions change, but I believe JavaScript should be the last. I believe that most sites should be designed so that they work 100% without JavaScript, and then add JavaScript for polishing.

Read more about Unobtrusive JavaScript

So (for me):

  • Quick and dirty thumbnails views
  • Get HTML in place
  • Maybe some basic CSS for the layout (or more if I need to do something earlier on someone)
  • Write the basic logic
  • Add support for web services and AJAx calls
  • Pretty all with stylish CSS
  • Javascript to add sizzle
+5
source

Let me ask you this. Do you draw a car before or after you made the working parts? You may have chosen the paint, but in the end, it cannot continue until the car is finished. You may not agree with this analogy, but I think coding will cause problems that cannot be understood before the site is developed. First code, second.

+2
source

Get a notepad. Each page represents one page of your site.

Draw an interface. What controls are displayed on each page? Which controls are the same on every page? What forms exist and on which pages? What happens when a user clicks on an x ​​element? Point y?

This will help you strengthen your plan for both the content and the behavior of your site.

If you are just starting blind coding, you will end up in burnt spaghetti.

+1
source

The user interface is what website users see. Before coding, you probably start with very simple site sketches, which are not code, to identify page navigation, general placement of content and interaction with the site.

But the sooner you can show and discuss the working interface, the easier it is for users / customers to get an idea about the final product. Therefore, quickly go to HTML, CSS, JavaScript, and similar images to determine:

  • The data presented on the page (HTML)
  • Data Presentation (CSS)
  • Data Interaction (JavaScript)

This helps to gradually develop the actual working interface that you can discuss with the client. This makes them participate from the very beginning of the project. This makes them think about the site and make decisions about the content, appearance and interaction.

Getting this feedback early in the project reduces the risk of creating a product that needs to be changed later. And making changes early in the project is easier / cheaper, and then in the project.

While the user interface is being developed, you can already start searching for data structures, software components and integration with other systems for managing the site. But this is not what users / customers are interested in; they want to see and use the product.

+1
source

All Articles