Things that need to be keep in mind about Web Site Design

The biggest difficulty most Web developers face when building sites is that the mental processes involved in writing code, and designing graphics and layout are worlds apart. Developers who can not only write really tight, maintainable code but can also hold their own when it comes to designing company logos and laying out text are white tiger rare.

When I first started building Web sites, there were a few things I got wrong. Here's a list of what they were:

1. Not Everyone Works at 1024x768 Resolutions…

This was the first thing I got wrong.

Just because you've been using 1024x768 resolution on your desktop for the past six years, that doesn't mean other people don't use 640x480 screens.

Designing Web pages that look good at 1024x768 and 640x480 is an extremely difficult art. In short, you have to make the layout stretch and shrink in order to accommodate the user's browser size. Most public sites design for 640x480 resolution, which is why many sites seem to only take up a small region of the page In order to design for 640x480, don't make the elements that make up your page take more than 600 pixels total width. Intranets and private sites tend to have wider pages because they have a good idea of what their audience will be using.

Public sites, typically stick to the 640x480 layout. The magic number of 600 leaves space for the side of the browser and the scrollbars. Also, make sure that the important elements of the page fit into the first 400 pixels that make up the height. Allow 125 to 150 pixels for the left navigation bar (if you have one), leaving 450 pixels for the width content. Remember, you're building pages for iMacs and Linux boxes too.

2. Not Everyone Has 16 Million Colors…

You must design your graphics so they look good in 256 colors. In addition, graphics for logos and buttons, etc., should be in GIF format. In fact, the 256-color limit is not even true. When designing for the Web, you only have available to you 216 separate colors that you know will be there. This is known as the Webmaster Safety Palette and most graphic design programs, like Adobe Photoshop come with a palette that you can import into your graphics to ensure you're using the correct color spread.

3. Not Everyone Uses Internet Explorer

There are a lot of people who use Netscape. There's also a fair difference between Netscape and Internet Explorer, enough to make me have nightmares and spend hours re-engineering presentation code to make a site look cool in both.

4. Not everyone has a high speed internet connection

Luckily, I'm not alone on this one! Many Web developers forget that just because they have a high-bandwidth Internet connection, that doesn't mean everyone else does too. The issue is that if the site is not responsive, visitors to the site will grow frustrated and click out of the site and onto a competitor.

There are five tricks to enhancing the performance of your site:

   

1. Minimal use of graphics. Make sure you use just the right amount of graphics, and make sure that these graphics are as optimized as possible. 

 2. Make pages smaller. Convey just the right amount of information on a page. Don't keep the user waiting around to get all the information he or she needs. If necessary, spread information over a number of pages.   

 3. Keep URLs short. In dynamic sites, this is an interesting one. If you ever look at the URLs on Yahoo, you'll notice that instead of calling a folder "images", they'll call it just "i". The logic behind this is sound - there's no need to write "images" in full if the browser can understand "i". Wherever possible, keep the names of ASP pages and folders as short as possible.   

 4. Avoid the use of ActiveX controls or Java applets. Additional components that need to be downloaded and installed in order for your visitors to get the full benefit of site functionality can frustrate users both through the speed it takes to download the components, and possible problems they may encounter once they have been downloaded.

Designing the Model for E-Commerce Application in Classic ASP

In developing the business tier for our application we are going to build a series of objects that we can classify as belonging to one of three distinct groups

• Infrastructure
• Service
• Data

Before we look at the precise objects we'll be building, let's discuss these general groupings.

Infrastructure Objects

Infrastructure objects provide access to the resources that an application will use. In our case, we only need to actively manage one resource - the connection to the database. The application will use more resources, like memory, disk drives, and so on, but the application framework provided by Visual Basic and the Web server (IIS) will do this for us.

One sure way of ensuring the presentation layer code is not allowed to circumvent the business rules is to never allow the ASP code direct access to any of the infrastructure objects. In our case, we do this by creating an object that is only accessible to objects in the model. In other words, this object is private to the model as a whole and the ASP code will not be able to directly access or call methods on it.

One sure way of ensuring the presentation layer code is not allowed to circumvent the business rules is to never allow the ASP code direct access to any of the infrastructure objects. In our case, we do this by creating an object that is only accessible to objects in the model. In other words, this object is private to the model as a whole and the ASP code will not be able to directly access or call methods on it.

Service Objects

Service objects provide access to application services. An application service is defined to be anything that an application can actually do. So, in our case we might have an object that can carry out operations like creating customers, deleting customers, viewing orders placed by a customer, etc. The activities outlined (for example the operation of creating a new customer) will have to conform to certain criteria - business rules.

We may decide that any object in our model can create a customer by calling the appropriate object; additionally we may decide that not only can another object call this object to create a customer but ASP code can as well. It is through these service objects that the presentation layer code can get to the business rules. We'll see more service objects in a little while.

Data Objects

Data objects define single instances of some entity in the system somewhere. This is a deliberately broad description, but in our case it nearly always refers to rows in the database. So, we may have an object to describe a single customer, or a single order, and so on. The advantage of this approach is that it lets you add a great degree of detail to the data objects.

Now we've seen the classifications, let's move on to see how we choose the actual objects we are going to put into our object model.

Choosing the Objects

Now we know what kinds of objects we are going to have in our model, we need to decide what objects will actually make up that model. To do this, we have to go through a process of deciding how the various users of the system will flow through the application. By that we mean that a user on the system will create some form of event (not the Visual Basic type) - they will do something that requires some action.

The Full Object Model for Ecommerce application

Infrastructure objects

Database - This object has a number of uses; it simplifies our database communications (which are subsequently achieved via the ADO Connection object) it provides a couple of extra functions to aid the ordering process, and allows direct access to the ADO Connection object. This object is not directly available to the ASP code.

Service objects

Catalog - This object provides access to the product catalogue. It enables creation of departments and products, and can query manufacturers, suppliers, departments, and products. It can also create instances of the Product data object.

Customers - This object manages customers. It can log a customer into the customers only areas of the site and can create new customers in the database and manage their address and credit card information.

Orders - This object manages orders. It can take a shopping basket and turn it into an order, and it can move an order through the order-processing pipeline It can also return audit trail information.

Search - This object provides a way of searching the product catalogue.

FireAndForget - This object provides a way of sending e-mails to customers and visitors at a given date and time

XML - This object provides a way of publishing data in our database as XML, and importing XML data into our system.

Data objects

Product - This object represents a single product stored in the database. It can return information about itself, get and set dynamic attribute data, and add and return up-sell/cross-sell recommendations.

Customer - This object represents a single customer stored in the database. It can return information about itself, along with stored address and credit card information and orders that have been placed.

Order - This object represents a single order stored in the database. It can return all of its information, including customer, addresses and credit cards, and the data that makes up the order.

Basket - This object represents a single cart (basket) stored in the database. Most often, this object is used to represent the current visitor's basket. It can return its contents and summary information (total price and total quantity), and it can add and remove items from itself.

Objects vs Components

This article is in continuation with my previous article dated 27 Feb 2012

Components

Building on the idea of object-oriented programming comes component-oriented design, which facilitates even better reuse of the objects we design and build.

Objects vs Components

Objects are created from classes and classes are made up of source code - which is language specific and thus can only be used, easily, in one environment. In contrast components are pre-compiled units of binary code - thus they are language independent.

A component may consist of one object or a collection of objects.

A component based approach to software design enhances the OO approach we first looked at - in the case that a component consists of a group of objects, we can actually define which objects are accessible outside the component (and hence keep some objects restricted to being accessed by other objects inside the component) by defining the interface of the component.

COM

Of course the above section rather glosses over at least one very important topic; how do we get all these components talking to each other? That's where the Component Object Model (COM) comes in - it's Microsoft's standard for allowing objects and components to interact irrespective of the language in which the components were first built. So, using COM technology we can call up a component, and providing we know what interface it has, we can get it to go away and do things for us.

As part of the COM mechanism, components that we create in VB actually have a number of interfaces that are provided as part of the standard architecture in addition to any interfaces we define. We'll discuss this further at the appropriate time, but the important thing to note is that VB fits seamlessly into COM and as VB developers we are insulated from a great deal of complexity.

ActiveX

An ActiveX component is an application that stands alone and lets other applications use the classes and objects it contains.

Active Scripting

ASP pages are able to access ActiveX components through a technology called Active Scripting. We've skated over the previous general theory pretty quickly (as we alluded to, there are whole books written on the subject) but it's probably worth lingering over this particular aspect.

Active Scripting is a reusable scripting engine that, if you want, you can use in your own application. It can be found in use in Active Server Pages (ASP) and Windows Script Host (WSH). Active Scripting is capable of supporting many languages by allowing developers to write supporting language plug-ins.

Active Scripting ships with VBScript (a cut down version of Visual Basic) and JScript. Other vendors have developed PERL plug-ins, as well as support for other languages. Broadly, this means that you can write ASP code in whatever language plug-in you have available, as Active Scripting and the plug-in work together to make the call into the component and, through that call, tell Visual Basic to execute the code contained within the method or property.

ASP works (as illustrated below) by stripping out all of the VBScript code, creating an instance of Active Scripting, and asking it to execute the code on its behalf. ASP presents a set of its own ActiveX components to the context of the script (the environment that the script runs in). So, the Response object we call in ASP is actually an ActiveX component that ships with ASP, and when ASP fires up Active Scripting to run your code, it passes a reference to this component to Active Scripting and asks for it to be made available to your code as Response.

At this point we need to bring in the idea of a type library. A type library is a file that describes an object (here meaning component or control) in a standard format such that anything wanting to make use of that object can find out which classes are accessible (or supported). This type library is actually embedded into ActiveX DLL files created via Visual Basic; however, it's still available to programs interacting with it using COM.

So, when our ASP page attempts to call a method on the Response object, Active Scripting looks at the type information in the type library and determines if the method or property name is valid and, if it is valid, what parameters it takes (the type library is not just a list of the names of the methods and properties - it also includes the parameters that any call has and the possible types of value that can be returned). This inspection of the published information is part of the technology that makes up ActiveX, not Active Scripting.

Building the Object Model (concepts behind object oriented programming, COM and ActiveX)

Most modern software can be controlled programmatically through its exposed object models. In fact, most of the applications you use everyday on your Windows PC have an object model, including Microsoft Word, Excel, and Internet

Explorer.

The careful design of these object models is the key to building good software. We're now going to embark on the design, and start the construction, of the business tier for Ecommerce application. This business tier will consist of a number of objects whose interrelationships are defined by their position in the object model. Implementing the object model will define what we can do within the application.

There are going to be three basic parts to this article - we're going to start off with the theory (concepts behind object oriented programming, COM and ActiveX) then we'll move onto see how that theory influences our design of the object model for Ecommerce application . Finally we'll begin to implement the design in VB project.

More specifically our path through the chapter will involve:

• Looking at object-oriented programming
• Understanding a little about components
• Creating a project in Visual Basic
• Building the Database object
• Building the Catalog object

Let's start by looking at object-oriented programming.

Object-Oriented Programming

Object-oriented programming (OOP) is based on the idea that real-world entities or relationships can be represented in code as objects. These code objects have associated with them data and behave in certain ways when asked to. Objects Can be linked together to form programs and applications.

Objects may be regarded as black-boxes - the user of an object may know what information needs to be input to the object to get a certain result out, but does not need to know what process goes on inside the object.

OK, let's step back from that rather terse summary and use the metaphor of a television set to explain this concept. We're all pretty conversant with televisions in so much as we know if we input a signal (from aerial, cable, video or wherever) and we use the control set properly we'll get sound and vision. Pushing the buttons allows us to vary the channel we watch, raise or lower the volume, alter the picture brightness, and so on. Most of us don't know the precise workings of the electronics that control the TV, and neither do we care, because we know enough to be able to control it.

Classes

The vast majority of object-oriented programming work is concerned with building objects that have no user interface. These objects provide some function to an application. Imagine you are working on a development project in a team and you need access to a billing system that your company owns. One of your colleagues has built a set of objects for talking to this billing system, but it is used on another application. In an object-oriented world, if your colleague has done their job properly, they can give you a copy of the objects, you can plug them into your application and now your application code has access to a billing system through those objects. You haven't had to learn anything about how the billing system works; you've just plugged the objects in.

Let's say our colleague gives us their class module called BillingSystem, (and provides us with information about its properties, methods, and events) in VB we can create instances of it like this:

Dim MyBillingSystem

Set MyBillingSystem = New BillingSystem

Once we've created a billing system object, we can use it:

MyBillingSystem.BillCustomer "Neil", "Mcevoy", "$500", "1/27/2012"

What's happening there is that we know that the BillingSystem object supports a method called BillCustomer. We also know that the code that drives the BillCustomer object is something that we don't understand the internals of – our colleague has been through all that hard work, so we are reusing their efforts. The term reuse is something that comes up time and time again in software development and is an important facet of object-oriented programming. It means that the cost of the time and money we put into developing something can be offset by the fact that whatever original work we come up with can be reused in other applications. This is one of the reasons why people actually sell objects for use in other applications.

I will cover rest of the bullet points in next article 

Software Required for Developing our ASP Ecommerce Application

• IIS
• Microsoft Transaction Server (MTS)
• Dreamweaver
• Microsoft SQL Server 2008
• Microsoft Visual Basic 6.0

IIS

Formerly called Internet Information Server – is a web server application and set of feature extension modules created by Microsoft for use with Microsoft Windows. IIS 7.5 supports HTTP, HTTPS, FTP, FTPS,SMTP and NNTP. It is an integral part of Windows Server family of products, as well as certain editions of Windows XP,Windows Vista and Windows 7. IIS is not turned on by default when Windows is installed.

MTS

Microsoft Transaction Server (MTS) was software that provided services to Component Object Model (COM) software components, to make it easier to create large distributed applications. The major services provided by MTS were  automated transaction management, instance management (or just-in-time activation) and role-based security. MTS is considered to be the first major software to implement aspect-oriented programming

For more details please read my previous article on MTS dated, Monday, January 10, 2011

Microsoft SQL Server 2008:

This database product, rather than Microsoft Access, was chosen since it's a great product for use in building both small, but scalable, solutions and in the development of large distributed applications, like an e-commerce site. We use this database both for development and on the production server.

Microsoft Visual Basic 6.0

This will be used for building our business objects for the business tier of our application.

Dreamweaver

Macromedia Dreamweaver 8 is a professional HTML editor for designing, coding, and developing websites, web pages, and web applications. Whether you enjoy the control of hand-coding HTML or prefer to work in a visual editing environment, Dreamweaver provides you with helpful tools to enhance your web creation experience.

Dreamweaver also provides a full-featured coding environment that includes code-editing tools (such as code coloring and tag completion) and language reference material on Cascading Style Sheets (CSS), JavaScript, and ColdFusion Markup Language (CFML), among others. Macromedia Roundtrip HTML technology imports your hand-coded HTML documents without reformatting the code; you can then reformat code with your preferred formatting style.

Dreamweaver also enables you to build dynamic database-backed web applications using server technologies such as CFML, ASP.NET, ASP, JSP, and PHP.

Designing a scalable application

Imagine your traditional non-Web-based distributed application has ten users. Chances are your application works just fine in this environment - responses to queries are fast, print jobs run on time, etc. Now imagine your company gets absorbed into a much, much larger one and now your distributed application has 10,000 users. Will your application run just as fast and will your users be just as happy?

Well, no. Not without, at the very least, hardware upgrades. But, even after you redo all the server hardware, will your application still perform to specification?

If it doesn't (and chances are it won't), we say that the application does not scale well; in other words the application is not capable of adapting itself to fit into a new environment where there are more users. If the application copes, then we say it does scale well.

Scalability is important in many areas, but the consequences of ignoring it can be particularly acutely felt if you suddenly find yourself with a successful Web-based distributed application, like an e-commerce site, where the original traffic of

1,000 visits a day suddenly jumps to 10,000,000. How do you design your application in such a way that increases of that magnitude are manageable?

Luckily, you're half way there. The first step in managing that kind of increase is to adopt a 3-tier architecture. In short, by separating the business tier away from presentation and database roles, you can build business objects that work smarter

and scale better. The trick with managing scale is to think about the perceived number of users concurrently working on the system at any one time. Say you do have 10,000,000 visits a day. At any given second, 116 users are on that system.

Imagine all of these users are using the same page. How many database connections do you need? The answer: 116. Now, how many database connections will be required at the same time? The answer: less than 116.

The trick to designing business objects to scale well is to understand that the resources you have are limited. Say your installation of SQL Server can handle only 500 simultaneous connections. If a user needs a database connection and all

500 are in use, that user will have to wait in a queue for one to become available. That is why we often see such a reduction in performance when we start to increase the load on distributed applications - the demand for resources

outstrips supply.

Imagine I write a business object that takes 5 seconds to walk through a list of 100 invoices and performs a complex calculation on each one. If I connect to the database as I enter the CalculateRefund method and close it just before I leave, chances are I've wasted a lot of the database's time as I read one record, process it for a little while, get the next record, and so on. If I, instead, design my object to open the database, read and cache all the records, and close the Database, the database resource is being used efficiently. Now, as the resource is being used more efficiently, other pages servicing other users can obtain database connections more readily, reducing the performance lag we were previously feeling.

Coming back to our 10,000,000 visits example: if we can build our business objects to use the database efficiently, we may be able to reduce the number of simultaneous database connections required to always be below 500, and our application won't feel a performance hit when we scale.

Now that we understand the online business model we're after and we have an understanding of what a 3-tier distributed application is, we can move on to designing the software we'll need to make our site a reality.

Architecture model for E- commerce application

Let’s start considering the practical aspects of Ecommerce site construction. Let’s first discuss about the model we are going to use for our Ecommerce application. I found Three Tire model to be an extremely efficient development approach and is the one we'll be following in developing our ecommerce application

Let’s have a brief description of Three Tire model

The three-tier architecture model, which is the fundamental framework for the logical design model, segments an application's components into three tiers of services. These tiers do not necessarily correspond to physical locations on various computers on a network, but rather to logical layers of the application. How the pieces of an application are distributed in a physical topology can change, depending on the system requirements

·             The presentation tier, or user services layer, gives a user access to the application. This layer presents data to the user and optionally permits data manipulation and data entry. The two main types of user interface for this layer are the traditional application and the Web-based application. Web-based applications now often contain most of the data manipulation features that traditional applications use. This is accomplished through use of Dynamic HTML and client-side data sources and data cursors.

·             The middle tier, or business services layer, consists of business and data rules. Also referred to as the business logic tier, the middle tier is where COM+ developers can solve mission-critical business problems and achieve major productivity advantages. The components that make up this layer can exist on a server machine, to assist in resource sharing. These components can be used to enforce business rules, such as business algorithms and legal or governmental regulations, and data rules, which are designed to keep the data structures consistent within either specific or multiple databases. Because these middle-tier components are not tied to a specific client, they can be used by all applications and can be moved to different locations, as response time and other rules require. For example, simple edits can be placed on the client side to minimize network round-trips, or data rules can be placed in stored procedures.

·             The data tier, or data services layer, interacts with persistent data usually stored in a database or in permanent storage. This is the actual DBMS access layer. It can be accessed through the business services layer and on occasion by the user services layer. This layer consists of data access components (rather than raw DBMS connections) to aid in resource sharing and to allow clients to be configured without installing the DBMS libraries and ODBC drivers on each client

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases