I love drawing on whiteboards. I’m very visual, and most times, can’t think through a problem, nor plan a problem without drawing it out. I’m terrible at drawing, so its not about drawing something that looks visually interesting, simply about using visuals to organize concepts, data, and flow.

I use the same technique when planning out a new web site. I like to draw a box for each page, and use lines to link them together. I also design the basic idea of each page, either on a white board, or on paper. In the past, I’ve mocked up my pages using HTML/CSS, and at other times done it in Photoshop or Gimp. The problem is, I waste so much time fooling around with the tools, or trying to get that CSS to look just right, that it takes longer than it should to come up with my basic design.
Thankfully, I’ve found a solution to all that, which I’ve already used to design my next project. With the new tool I’ll introduce you to in this article, you can sketch out which pages you need, and the linkings between them, as well as sketch out the look of each page, all with the ease of using a pencil and paper, yet, save it for later use and editing, and turn it into a functional mockup, perfect for handing to a HTML/CSS developer and a graphic designer.

Read More »

I don’t usually post much about laying out web pages, but this tip was one I just couldn’t pass on . I can’t wait until the next time I have to layout a web page to use this. The tip is to use a background image, which is a grid. You apply it as the background, and then use it to position all your elements. Take a look over at Smiley Cat, which provides a background image and an example.

After further thought and consideration, I retract my statement that HTML should never be sent back to an AJAX request. There was a reason I made that statement, however I can’t fill you in on it yet (hint: I have to wait for a future software release). But, even with that reason, I have no issue with using HTML in an AJAX response. I wrongly applied a wise and fully correct architectural principle, which I will elaborate on in a future post, to the AJAX situation.

Hopefully at some point in the future, I can go into more detail on why I first wrongly concluded that this should never be done. Until then, rest assured, I will use whatever format fits the circumstance (JSON, HTML, XML).

Brad Neuberg has a good post that discusses further the pros and cons of returning data to your Ajax requests, with out without markup.

This is a good post on The Ajax Response, discussing if it should be XML, HTML, or JSON. I personally think under no circumstances should it be HTML, or anything that includes markup. That violates the principle of separating the content from the style and it prevents reuse, by yourself and others.

I think deciding between JSON and XML is going to depend on your situation. XML is much more universal. With XML, you can create Web Services from your back end, and call them for display in PHP, JSP, and with Ajax. That Ajax call you are making today maybe a non-Ajax call you make later.

Google Suggest is a prime example of silliness. That data response is completely unusable in any other scenario. Perhaps, knowing Google, they have done this on purpose to prevent others from using that feed as freely, but it could be a handy service to offer and implement in other locations. The way Google has chosen to implement it, would require Google to have many versions of that response, for multiple uses.

With the rare exception, when you serve up data from your back end, think in big picture terms of making that data available to all your front end applications, and then apply style (HTML, CSS, etc) to it, once the data is in the front end.

UPDATE: Ignore my reservations about HTML in AJAX responses and see my followup post: AJAX Returning HTML (change of opinion).