Speeding up web development

Question

Situation

I have been working on a project lately where the UI development seems to be way too time consuming. In this case, the "Business Rules" on the server-side are much more complicated than the presentation aspects as far as a Computer Science or complexity perspective.

I've found myself scratching/banging my head against the wall with problems with behaviour that differs from the intuitive approach all the way to being a black hole of time waste and poor documentation, where I might be trying to get a simple UI element to line up correctly.

I'm not complaining; I understand there are complexities and a wide audience to support with web development, but I am perplexed by how long it takes to do what seems should be the easy part compared to how long it takes to write the code with complex logic, math, science, etc.

Question

What are you thoughts and personal experience to go from concept to reality with web development and to do this rapidly, or at least in a way that you can have a sense of how long it might take? I have purposefully not mentioned any frameworks or languages, because I would really like to here what web development stacks you use, what tools or best practices help you get things done faster, and how you end up with code that doesn't feel totally brittle and full of hacks.

Hyperbole, language preferences, and all thoughts welcome, I would at least like to get a sense of what is being used for web development that has a high success rate, even if it isn't the latest and greatest thing around.

Thanks for your input.

-bn

Answer 1

I use UI designers. They are excellent for that sort of thing.

Answer 2

I personally have found breaking everything up into small tasks helps.

The way I like to design web pages:

1. Draw out the design, or photoshop it.
2. Create the HTML - no CSS, no styling at all
3. Now add in your style - basic style, like positioning, save making the menu perfect for later
4. Connect to database if needed / server side code
5. Now add in any javascript, ajax needed
6. Tweak it to perfection

If you have all this broken into small tasks, when you get done with each, you feel more motivated to continue working.

Like I said, this is how I do it, and it seems to go quickly, especially since I only get about 1 to 2 hours a night to work.

Answer 3

I craft my application requirements around what is practical and sometimes easy in terms of front-end work.

Answer 4

I've been using the .NET stack for about 5 years, the ASP.NET MVC stack for about 3 months, and old ASP for 4 about years.

The key to dealing with complexity is mitigating it. In your code, always abstract away complexity to a reasonable level. For example, say there are 10 steps to placing an order. In that case, at a higher level, you would have a method 'SubmitOrder'; under it might be 10 method calls for inserting appropriate records, dealing with inventory and so on. In each of those 'business' layers, you can just deal with these business problem, and even below those layers, you would deal with data and mechanical details. The benefit to all of these layers is that you make each layer deal with a chunk of the work, and as you go up closer to the UI, you have an 'interface' that makes sense to the UI and the way the application needs to flow.

Answer 5

My companies does mostly .NET development and we have been successfully using the 'net-tiers' templates for data access layer. The templates are loaded into CodeSmith code generator and pointed against a database. The end result is anything you could possibly think of. It'll generate your DAL, webservice, winforms UI library, web UI library, a sample website and administration tool and more. A great tool to save some development time. Check it out.

As far as actually working on UI, i think it may benefit to actually hire a professional. We have a professional designer who does some contract work with us. All that we do is wire up the UI to our UI components and code.

Answer 6

I think you're a little mistaken about UI development. UI development is difficult and usually underestimated in its importance.

There's a need to know the basics - before you jump to HAML, know your HTML so you know what you're abstracting away. Before you jump into jQuery take the time to learn JavaScript basics - you don't need to be a pro, but when you need to add some numbers together you should not go looking for a plugin. Have a good understanding about how to style things with CSS. There's a lot to topics and technologies to learn to be a competent web UI dev.

That said, for greenfield development Rails is pretty sweet. Pick jQuery. And don't choose a platform that hides how the web really works.

Answer 7

To speed up getting an HTML page that looks like you want:

First, decide on a design and draw what you want it to look like using a graphics program (if you've got a UI designer they do this step). Then, write static HTML and CSS that matches what you've drawn. Once that's done, write code that outputs HTML that matches the format that you've decided on.

I did this for a pretty complex set of states for a web app, and found that first writing HTML and CSS by hand, without having to wrestle with your server program, makes it go much faster.

Answer 8

The answer to this question depends on if you are working alone or leading a group.

If you are leading a group you will want to break apart responsibilities as the following:

• Designers - These people should own the creation of graphical mockups and the creation/maintenance of CSS. They should own CSS as a responsibility so that they know not to create outrageous graphical mockups that cannot be created as a webpage without considerable code bloat.

• Markup - These people should own the authoring of HTML, accessibility, semantics, RDFa requirements, and any other aspect associated with front end data structure.

• UIT - These people should own JavaScript, efficiency requirements, content-management requirements, internal process and front-end tool/process governance, and generally own best practices for all client visible code.

• Applications - These people should own server-side application code development, content management system creation/maintenance, and database access requirements. These people are application and services programmers and provide the interface to database and services personnel.

• QA - These people test all business requirements of the final product in a certification environment. If errors are seen the bug/ticket should be updated and reassigned. The work is not finished until QA signs off as valid.

• Business Owner - The business owner is the person/team responsible for writing the initial project requirements and making a final approving decision about the deployment of the project. This person should have no interface to the technology process outside the drafting of business requirements.

• Project Manager - This person ensures that a project is continually moving forward and that milestones are completed in accordance with any deadlines. It is this person and not the business owner that is to interfere with the technology process to ensure things are getting done. This person must act independently of the business owner and must not serve as a tool to the business. The project manager must not own or recommend changes to the requirements to the technology personnel. If changes to the requirements must be made this is a one way process from technology through the project manager to the business owner.

• The flow of development should be the following:

  1) Designers create the graphic mockup and then reassign the bug/project ticket to the project business owner.

  2) Upon business approval the ticket should be reassigned to Markup staff or rejected back to design with specific change requests.

  3) Markup writes the HTML and content. Any application or database requirements should be specified by business before the project begins and the Markup team should write code for all possible scenarios. The structure of content should reflect the organization of content on the visual markup completely without regard for presentation. The ticket should be reassigned back to Design for CSS creation.

  4) Design writes the CSS to add presentation in compliance with the graphical mockup they created. The design team must have access to the HTML markup to add class attributes as necessary, but should not be allowed to make any other changes. The ticket should be reassigned to Applications to complete all server side requirements.

  5) Applications should create all necessary requirements for database access. Ticket should be reassigned to UIT if the prior requirements are satisfactory or reassigned back to Markup for changes/additions.

  6) UIT should be the final step to write the JavaScript interactions necessary for user-interface and AJAX requirements. UIT also should proof the prior completed markup for standards conformance, efficiency, and best practices. UIT should quickly reject the project if the work is less the acceptable. If additional Applications work is required reassign to Applications otherwise reassign ticket to QA.

  7) QA is the final technology stop. These people test the business and functional requirements of the final product. The project cannot be released to production without QA sign off. If a business requirement fails QA must not sign off. Upon QA sign off the ticket should be reassigned to the business owner.

  8) The business owner reviews the project and determines if all requirements are achieved. If changes/additions are required they can be submitted at this time. Changes/additions MUST NOT be submitted earlier, because frequent changes delays all projects. It is the responsibility of the business owner to ensure their initial requirements are complete and specific. If the requirements are not reviewed for fullness it is the fault of the business owner and changes can be submitted at this point. It is because of this responsibility, and other associated business responsibilities, that the business owner deserves to get paid more for being less involved.

That is the most efficient manner to get the job done. Separation of duties is extremely important and adherence to the process is extremely important. If those two things fail the entire process fails and business incurs significantly increased development costs.

If you are acting on your own and not part of a team I would still follow a similar process and push the role business owner onto the client. If the client wants to make changes/additions premature to the project completion then they can pay more money by amending a change addendum to the original requirements contract. You do not loose pay from increased labor because a client cannot make up their damn mind. If that is upsetting then the client can pay even more money for a contract cancellation. This is not mean it is business. If your time is not a valued commodity then you should not be in business as on your own.