The e-commerce sites have the unfortunate habit of separating the appearance identity / entertainment from the functional aspect of a procurement service. Forget a little large dinosaurs such as Amazon, Ebay ... Today the best innovations are also in the mini-shopping Web who do not hesitate to develop unique interactive interfaces where pleasure purchase fits perfectly into the e-commerce world.
The online stores have enormous potential. The percentage of customers are still wary of this form of purchase becomes increasingly weak, the trend shows that e-commerce has a bright future. But the image of physical shops if your electronic platform is not friendly, the customers will avoid. Only sites practices can be effective and have a commercial success. The handling and use of the shop should be intuitive and easy, simple navigation structure for the customer quickly found his product.
By avoiding anecdotal gadgets that are not innovations which could distract the customer of the product, the visual impact of the latter should dominate that of any other component of the site. The product is the star, not merely an element integrated with the rest. In addition to the purchase, the opportunity to examine the product can be a decisive act. The customer wants to see pictures and all information related to the product. To compensate for the lack of touch, visualization functions must therefore be adapted and original.
For an online store, the interaction between design and function is very important because measurable. The challenge is to find the right balance and why the ego designers should not take precedence over the concept of traditional paramount: the customer is king.
Here are some examples of e-commerce sites which we may never have heard of but which by their approach to online commerce, can inspire and give good ideas for mounting or improve its own online store. For today, thanks to the democratization of the Internet and the development of open source solutions (CMS with complete and high-performance such as joomla, typo3, and e-commerce solutions ocscss, or VirtueMart OsCommerce ...), the doors online commerce are open to everyone, and even more to Webdesigners:)
Wednesday, March 19, 2008
Monday, March 10, 2008
Ten Recommendations
The development of integrated software systems pose significant difficulties arising from the need to:
a) rapid prototype system,
b) to ensure the quality of its model and source code,
c) changes in the life system.
Here are ten recommendations that will help developers in their difficult journey for integrated systems.
1. Use the power of modern software development platforms
Not oriented development platform on which at the time of the creation of your system obsolete or tend to obsolescence. And even if you do not need to re scares to new languages and API. Serious system must be properly trained developers. You are more than repay the time spent on training Dubin use more powerful tools and libraries of classes. Progress is not at a standstill…
2. Take very seriously the design application
Creation of a future architecture of the system - a mixture of experience and intuition. It is difficult to select a set of rules, which ensures adherence to the establishment of quality systems model. The main thing is that the prerequisites of your system architecture is not unnatural way reflect the subject area.
On the future success of the project can be indirectly measured by the number of times when, during the design and implementation were spoken phrase "now will do so, and then, if that remodel" (more - worse), and "functionality of this unit then as we want, and sell "(more - better). Why? Because in the first case was made clear suggestion on how to work a block of functionality, and a work in the mode of "crutches". And in the second case, the decision on the concrete implementation has been postponed at the stage when it is understandable how it should look.
3. Use inheritance of objects subject area and the user interface
Using inheritance, you can ask "in one place" general behaviour for a group of objects on your system.
For the inheritance subject area will help you in determining the common attributes and functionality of objects.
For user interface inheritance will be useful in determining the common components screens (either win or web forms).
As an example, consider the form of inheritance representations of abstract archive (ie, a list of) documents. In accordance with the hierarchy of inheritance business objects, abstract paper is 2 predefined attribute "number" and "DataDocument". Then an abstract form of archive documents and put a table ( "grid"), with two columns: "Number" and "Data". Mention at the top of the form of governance component depth view archive (original selection of records by the date the document), and customize button context menu table.
Next, identify the "object" Personnel Document, which is inherited from the abstract "Document". In addition to the number of fields "and" Data "document" from the new facility will be "field officer." In doing so, you do not need to "draw" screen format for the new archive. You specify the abstract form of the archive as a base to form a new archive, adding to an existing table column "Officer" and linking this column with the data. All the functionality of forms (for example, the depth of view) will be inherited and automatically implemented in the files of personnel documents. Reducing the time of the obvious.
4. Separate application business logic and user interface
Implementation of the conditions actually means the emergence of "contract" between the GUI interface and business logic. In doing so, you will be able not only to provide your system more user interfaces (such as web and win), but also realize secure and simple interfaces for business logic classes.
"" This contract will help you in the future in making significant changes in the model system.
5. Your system should be a set of objects interacting with each business level, unless it is not modelled through nuclear explosions, of course
This is a basic principle of object-oriented approach to software development. You write for the classes of objects subject area and their exchange messages (causing public methods from each other). Thus obtained the necessary functionality of the system.
For example you need in the form of the screen when you click "OK" to retain edited object in the database. Code clicking your handlers should look like:
(
RedaktiruemyyObekt.Sohranit ();
)
Save Method () will do all the necessary validations facility, generating appropriate events facility and the transfer of management of a database manager options. That is the object of screen forms sends business object associated with the signature "message" Save.
And if in this example, you put an object in checking the correctness of the method of screen forms, such a code in the future, you will be difficult to control. Especially if the facility will be several forms of editing.
6. Encapsulate functionality of your system as objects, components and subsystems
A set of classes, working together to achieve clearly defined functionality, it is necessary to encapsulate and declare component interface (ie, a set of agreements and signatures sending messages) interaction with him.
In the future, if you make changes in your interface remains the same, you can perfectly safe to reorganize the internal behavior of the component without affecting the other components of the system. However, to achieve such benefits, it is necessary to seriously work on model systems (see Tip 2).
7. Use a clear, understandable and natural interfaces to describe the possibilities of interaction between the components and subsystems of your application.
Interfaces are the link between the components of the system. Further development of components that do not change his interfacial interactions, do not affect the system as a whole and do not require complex integration testing system.
Thus, the main objective of the developer - it is to provide its component interface so that it remains unchanged as long as possible in the process of refining the system. If the interface is not clear, understandable and natural, it is likely it will be changed as soon as possible (see Tip 2).
8. Write automated tests to check the accuracy of the implementation of system functionality
Automated tests are helping the developer to understand whether it is a component. Each scenario is a test responsible for verifying a component interface component (the so-called unit test). For writing such tests, there is an open development of NUnit.
Tests are divided into positive and negative. Positive tests are aimed at checking to determine whether works in the correct set of component inputs. Negative tests to track the correct response to a set of unacceptable component inputs. As you know, both types of tests should be represented in your test driver component.
In some cases, a test driver components are encouraged to write to the development of the very component functionality (for a set of use). This will help in the development of a "correct" interface component.
In case you were able to write to your system a set of test driver with a good coating of test cases, the phase changes in the code system, you will save a lot of time.
9. Use the tools for automatic generation of code
In larger systems, the proportion of code that can be obtained without the participation of a qualified developer, is large enough to write their own or use existing means of automatically generating code.
This will rid themselves of extra unnecessary mistakes when writing code, and this will allow you to concentrate on the implementation of a nontrivial system functionality.
10. Remember that the database - this is not a goal but a means
When selecting the type of database server to use for your system, it is necessary to evaluate the ease of writing code to interact with him and his safety, speed work, data and other parameters. At least, the "wrapper" to perform operations interact with your DBMS, you can write, but to change the behaviour of the server itself - no.
So, we need to approach the issue of writing stored procedures to perform operations with the server DBMS. There is no point in all the business logic of the system of writing in the form of stored procedures. In this case you will not be able to effectively use an object-oriented approach to the development of distributed computing systems and power between computers LAN. In stored procedures only makes sense to make really "heavy" treatment involving large amounts of data.
a) rapid prototype system,
b) to ensure the quality of its model and source code,
c) changes in the life system.
Here are ten recommendations that will help developers in their difficult journey for integrated systems.
1. Use the power of modern software development platforms
Not oriented development platform on which at the time of the creation of your system obsolete or tend to obsolescence. And even if you do not need to re scares to new languages and API. Serious system must be properly trained developers. You are more than repay the time spent on training Dubin use more powerful tools and libraries of classes. Progress is not at a standstill…
2. Take very seriously the design application
Creation of a future architecture of the system - a mixture of experience and intuition. It is difficult to select a set of rules, which ensures adherence to the establishment of quality systems model. The main thing is that the prerequisites of your system architecture is not unnatural way reflect the subject area.
On the future success of the project can be indirectly measured by the number of times when, during the design and implementation were spoken phrase "now will do so, and then, if that remodel" (more - worse), and "functionality of this unit then as we want, and sell "(more - better). Why? Because in the first case was made clear suggestion on how to work a block of functionality, and a work in the mode of "crutches". And in the second case, the decision on the concrete implementation has been postponed at the stage when it is understandable how it should look.
3. Use inheritance of objects subject area and the user interface
Using inheritance, you can ask "in one place" general behaviour for a group of objects on your system.
For the inheritance subject area will help you in determining the common attributes and functionality of objects.
For user interface inheritance will be useful in determining the common components screens (either win or web forms).
As an example, consider the form of inheritance representations of abstract archive (ie, a list of) documents. In accordance with the hierarchy of inheritance business objects, abstract paper is 2 predefined attribute "number" and "DataDocument". Then an abstract form of archive documents and put a table ( "grid"), with two columns: "Number" and "Data". Mention at the top of the form of governance component depth view archive (original selection of records by the date the document), and customize button context menu table.
Next, identify the "object" Personnel Document, which is inherited from the abstract "Document". In addition to the number of fields "and" Data "document" from the new facility will be "field officer." In doing so, you do not need to "draw" screen format for the new archive. You specify the abstract form of the archive as a base to form a new archive, adding to an existing table column "Officer" and linking this column with the data. All the functionality of forms (for example, the depth of view) will be inherited and automatically implemented in the files of personnel documents. Reducing the time of the obvious.
4. Separate application business logic and user interface
Implementation of the conditions actually means the emergence of "contract" between the GUI interface and business logic. In doing so, you will be able not only to provide your system more user interfaces (such as web and win), but also realize secure and simple interfaces for business logic classes.
"" This contract will help you in the future in making significant changes in the model system.
5. Your system should be a set of objects interacting with each business level, unless it is not modelled through nuclear explosions, of course
This is a basic principle of object-oriented approach to software development. You write for the classes of objects subject area and their exchange messages (causing public methods from each other). Thus obtained the necessary functionality of the system.
For example you need in the form of the screen when you click "OK" to retain edited object in the database. Code clicking your handlers should look like:
(
RedaktiruemyyObekt.Sohranit ();
)
Save Method () will do all the necessary validations facility, generating appropriate events facility and the transfer of management of a database manager options. That is the object of screen forms sends business object associated with the signature "message" Save.
And if in this example, you put an object in checking the correctness of the method of screen forms, such a code in the future, you will be difficult to control. Especially if the facility will be several forms of editing.
6. Encapsulate functionality of your system as objects, components and subsystems
A set of classes, working together to achieve clearly defined functionality, it is necessary to encapsulate and declare component interface (ie, a set of agreements and signatures sending messages) interaction with him.
In the future, if you make changes in your interface remains the same, you can perfectly safe to reorganize the internal behavior of the component without affecting the other components of the system. However, to achieve such benefits, it is necessary to seriously work on model systems (see Tip 2).
7. Use a clear, understandable and natural interfaces to describe the possibilities of interaction between the components and subsystems of your application.
Interfaces are the link between the components of the system. Further development of components that do not change his interfacial interactions, do not affect the system as a whole and do not require complex integration testing system.
Thus, the main objective of the developer - it is to provide its component interface so that it remains unchanged as long as possible in the process of refining the system. If the interface is not clear, understandable and natural, it is likely it will be changed as soon as possible (see Tip 2).
8. Write automated tests to check the accuracy of the implementation of system functionality
Automated tests are helping the developer to understand whether it is a component. Each scenario is a test responsible for verifying a component interface component (the so-called unit test). For writing such tests, there is an open development of NUnit.
Tests are divided into positive and negative. Positive tests are aimed at checking to determine whether works in the correct set of component inputs. Negative tests to track the correct response to a set of unacceptable component inputs. As you know, both types of tests should be represented in your test driver component.
In some cases, a test driver components are encouraged to write to the development of the very component functionality (for a set of use). This will help in the development of a "correct" interface component.
In case you were able to write to your system a set of test driver with a good coating of test cases, the phase changes in the code system, you will save a lot of time.
9. Use the tools for automatic generation of code
In larger systems, the proportion of code that can be obtained without the participation of a qualified developer, is large enough to write their own or use existing means of automatically generating code.
This will rid themselves of extra unnecessary mistakes when writing code, and this will allow you to concentrate on the implementation of a nontrivial system functionality.
10. Remember that the database - this is not a goal but a means
When selecting the type of database server to use for your system, it is necessary to evaluate the ease of writing code to interact with him and his safety, speed work, data and other parameters. At least, the "wrapper" to perform operations interact with your DBMS, you can write, but to change the behaviour of the server itself - no.
So, we need to approach the issue of writing stored procedures to perform operations with the server DBMS. There is no point in all the business logic of the system of writing in the form of stored procedures. In this case you will not be able to effectively use an object-oriented approach to the development of distributed computing systems and power between computers LAN. In stored procedures only makes sense to make really "heavy" treatment involving large amounts of data.
Subscribe to:
Posts (Atom)