Showing posts with label web design. Show all posts
Showing posts with label web design. Show all posts

Sunday, March 1, 2009

Resources for Rapid Web Prototypes

Alot of times, I find myself in a position where I have to put some prototype together of some bit of functionality so I can convince either myself or someone else that we should use it in an upcoming project.  Whenever I need to do one of these "Rapid Prototype" type of projects I always end up needing to put together a little website template to show off the functionality (presentation is important when trying to get a sign-off).  I've started using some free templates I found over at Smashing Magazine to help me get to the Rapid Prototyping faster, instead of sitting around making a pretty site from scratch.  

Here are a couple useful links I've found:

100 Free High-Quality XHTML/CSS Templates - Bunches of templates ready to use, most if not all are licensed either under MIT or GPL.


Company Dark Blue Template - Nice little conservative business company template.

Free CSS Layouts and Templates - These are nice if you are just looking for the scaffolding of the site without any artwork.

Jquery - Must have for most of my current web work, also see this post at Encosia for tips on having Google Host your jQuery (all the cool kids are doing it...)

Block UI Plugin - Great for modal dialogs, even has some cool support for Growl like popups.

jTemplates Plugin - Great for client side templating of JSON data.

Encosia's Posts on jQuery and .Net nuances - Great place to start if you are new to jQuery and how best to use it with .Net


Sunday, September 7, 2008

DotNetNuke Search Engine Optimizing - Step 7 Good HTML

I found an interesting post in a blog written about a year ago from Tom Kraak, owner of Seablick Consulting. The post gives a good list of SEO tips to consider when using the DotNetNuke framework which I think is helpful for all the people involved in creating a web site. Your modern day web developer simply has to be cognizant about the SEO ramifications of their implementation details.

The one that comes to mind first when thinking about my role, as developer (see previous post about "Three D's", I'm the one with the halo ), is number 7.


Write well-formed, standard compliant HTML to improve accessibility and "crawlability." Consider excessive in-page JavaScript, HTML layout tables and frames junk food for search engines spiders. I'm well aware that strict XHTML remains a challenge with DNN, but let's make an effort to move away from quirks mode by adhering at least to XHTML transitional.


Number 7 is one of several good reasons why I am an advocate of DIV's over Tables. Regardless of the fact that all the cool kids seem to be using div's these days, I still like to be able to answer the question "Why do people use div's over tables?" when occasionally asked by the seasoned developer (aka Old Fogey) and ordinary Dreamweaver adept (aka Graphic Designer). Here is my basic response: Tables were meant for tabular data, that is what they should be used for. Now to add to that, tables are incredibly helpful in some situations; I'm not an advocate of throwing them completely under the bus for all layout handling.

The problem with using tables for layouts (that I personally have found) is that they are very frequently rendered differently in every browser. As a corollary (albeit slightly contrived) to this problem, I like to also point out that it often takes more HTML to do the same layout with tables. One single 120 x 120 block of glorious green background is done in one div tag and some CSS, whereas if it were done with tables it becomes 3 tags and some CSS. The increase in the number of tags means an increased surface area for rendering problems with the browser, not to mention the increase in the amount of code to maintain.



Glorious Green


Now Playing: T.I. - Swagger Like Us

Tuesday, August 26, 2008

Your Website - The Key Players Involved

So you want/need/gotta have a new website? Maybe you're the young and feisty new marketing manager in a small/medium sized company, maybe you're the graphic designer in a small/medium sized company and you're manager wants you to put together a new website. The fact is, you're trying to figure out how to get a website up, or update your current one, without looking like an idiot to the other stake holders in the business.

The first place to start is to know who is going to be involved in the website development process. This is where we introduce the Three D's of the simplified web development life cycle.



(Sorry I couldn't make you a little WeePerson also, but you can at their website)

You may think that the first person you are going to need is a developer, but as important as we are :) you don't want us to pick what colors go on your website. This is where the uber-cool hippie designer chic... or dude... comes in. What you're looking for in a designer is someone who has done some websites before, they should ask you things like; how many pages are you going to have on your site? What do you want visitors to your site to be able to accomplish? How do you want visitors to feel? And all those softy questions that the development people aren't going to want to talk about.

In the design phase you want to get everything mapped out, drawn up, reviewed and approved. At the end of the design phase you want to come away with an approved design file. At my company, Adaptive InfoSystems, we like to have layered PhotoShop files to work with. Most of the time, the designers we work with don't like to write HTML. If you can find a designer that does HTML (Designers Should Know HTML), well I mean Good HTML, then they may be able to supply that to your developers.

At a minimum, your design file should contain all distinctive layouts you want to use on your websites pages. For example, if your home page has a different layout than your internal pages, you need to show at least 2 page designs. You can separate them into two different files, or layer one file in such a way that both designs can be viewed by hiding a group of elements related to one or the other layouts.

After you review the design and approve it, it's time to turn the design into code. Here we move from the Design Phase, to the Development Phase. Your designer delivers the design document (hopefully a layered PhotoShop file) to the developer. The developer starts by laying out the structure of your site. We like to use Div's and CSS instead of tables for layout, it makes it a little bit easier to change the site in the future because we separate the style from the layout. Once the structure is in place, we make a template of the design without content (In .Net this is called a Master Page, in DotNetNuke it's called a Skin).

After the template is made, the developers start entering content. To speed up things in this stage, it helps to have your content already approved and ready to put up on the web. To do this, we recommend you start creating copy for your pages with word documents. A one page Word Document for each page on your site is recommended, but if it has to be more the page usually will grow to accommodate the expanded content.

While the content is being entered onto the site, the other special programming tasks like "Contact Us" forms, your product search that ties into your database, and even that cool little Google Maps thing that helps your customers find out where their orders are coming from are all being created by the developers.

By the end of the development phase you should have had several reviews of the content and designs that are being created on your site. A sign that something might be going wrong with your development is when developers "Go Dark". Essentially, if you're developer doesn't do a couple different rounds of reviews to give you a little taste of what is going on and where they are at in the project, it's a bad sign. Regular updates keep you in the loop and allow you to catch small problems before they get too big and waste every one's time.

At the end of the project is the Deployment Phase. The Deployment Phase is done when your website goes live. This is usually handled by a combination of your developer and your hosting company. The hosting company is responsible for setting up the things that let people get to your site; things like servers, DNS, network connection, etc. The developer uploads your web files and maybe your database to the hosting company and verifies it still works the same as it did when it was in development.

Well, that is the Semi-Brief introduction to the Simple Web Development Life Cycle. I expect I'll elaborate a bit more on each of the roles in coming posts. What developers like to see from designers is usually a helpful topic.