Designing IT Project Using Diagram

Hi again all~

Come again with some knowledge about diagram which often used for designing an IT project. As we know that before developing an IT project, it will be better if we can design the application using diagram first before developing the application directly. Why is it important? As we all know that most of IT applications meet many changes happening along the way when those applications are being built. Those changes actually are the cause of many projects being delayed in delivery, also the cause of many bugs happening along the way. Those changes are unavoidable, I know. But they can be minimized if we analyzed first what kind of application should we built. This analysis process will result in designing the application, in form of IT diagram. And why do the diagram have to do with the importance of building a project?

See, if when analyzing the application carefully, you’ll realize many other things related to the project which can cause issues later on, or you can also find something which maybe related to the project you build. These realizations will make you design a good, reliable, and extendable project without having much effort later on if many development happen. Nah, you can design the diagram using those IT diagrams, which are so many of them. I think I shouldn’t explain the detail of each diagram because I myself isn’t the expert. I’ll just share about which kind of diagram should be used in which kind of need. Let’s begin then~

I believe that many of you have already heard the term UML diagram, ER diagram, Business Process diagram, Flow Chart diagram, Data flow diagram, etc. What are the difference between them all? You know that an application always built by the system itself and the database as the storage of the data processing in the application. We can use UML diagram, Business Process diagram, Flow chart diagram as the diagram to design the system, while ER diagram and Data flow diagram are used to design the database. Let’s get to know the briefing of each diagram first then. Let’s go to the system diagram discussion first:

Business Process Diagram

This diagram depicts the flow of business rule in application. You design this diagram using flowchart, but you picture the thing in bigger process than usual flowchart. You also use the role which is related with the process. It kinds of similar with use case diagram of UML diagram, but you can see the flow well from this diagram. It’ll be hard to imagine my description above so I should give the example of simple business process diagram. Here it is:

Flow Chart Diagram

Flow chart diagram usually used to describe the simple process. For different process, usually flow chart will be divided into smaller part so the main flowchart can be kept simple to make people easier to understand the process. It usually also includes the validation happening in a process. People who reads flowchart usually can understand the process easily rather than reading it in a description paragraph type. The functionality of flow chart diagram is similar to UML diagram, but it is usually used for simpler application. People with procedural programming language type will use flow chart diagram to design

Here is the simple flowchart of login process:

 

UML Diagram 

I believe that UML diagram is the most famous type of designing diagram for an IT project. It is used widely by many application. Usually project which is very large and expendable will use UML as the method to design the application. UML consists of many diagrams:

• Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram.
• Behavior Diagrams include the Use Case Diagram (used by some methodologies during requirements gathering); Activity Diagram, and State Machine Diagram.
• Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram.

Each diagram above has different functionality to the system. For example, use case diagram can be used to describe the features available in a system, which features can be used by whom, which features dependent to each other, etc. This diagram is usually made first between the other diagrams. But in this diagram, we can’t get what kind of functionalities of a feature can be used for which role. What I mean is, role admin and officer both can access officer features, but which functionalities are restricted only for which roles can’t be described in a use case diagram. Class diagram can be used to design what kind of class will exist in a system, what relationship each class has with each other, what attributes and methods available in each class. While sequence diagram can be used to depicts the interaction happen between each class, what type of attributes and methods will be exchanged between classes, etc.

It’ll be too wide if UML diagram should be described here. I also don’t have enough confident about these diagrams anyway, so you should look for other resources about UML diagram. There are many of them too so it won’t be difficult for you to find some reliable resources about UML diagram.

The next is database diagram:

ER Diagram

ER diagram depicts the entity relationship diagram which is the database design diagram. It consists of available entities, available attributes in each entities, and relationship cardinality between each entities. In terms of concept, it kind of similar with class diagram from UML. The difference is that class diagram is used for the system, while ER diagram is used for the database.

Data Flow Diagram

Similar with ER diagram, data flow diagram is used to design the database. The difference between data flow diagram and ER diagram is usually, data flow diagram is used for simpler project which use procedural programming language method, while ER diagram is used for bigger project which use object-oriented programming language method. Data flow diagram depicts the flow of data in the system. Unlike ER diagram, it doesn’t capture the entity available in a project and the relationship exist between entities.

I think that’s it for now, my brain is divided into different part of my life right now so I can’t really concentrate on this topic. I’ll update this post as soon as possible by the way.. Thanks a lot for coming~

Read Full Post »

SOP document vs User Guide document

Hi again~

Finally I get an idea to post about it documentation. After being so occupied to the documents, phew~

This time I’ll try to share about the difference between SOP documentation and user guide documentation. This posting maybe seems unuseful but I believe that there still are some of us who still don’t fully understand yet about the difference between SOP and user guide documentations.

As the document’s name depict, SOP is the document which describes the standard procedure in doing something, in this term, using some functionalities available in a project. It’ll serve you as a guide so you won’t meet any difficulties in using the functionalities later. You’ll find the steps to do something in SOP, and the picture of application screen shoot following the action that you do based on the step. SOP tells you to do the right steps so later you’ll get the supposed respond from the application. Hence, SOP document will only consists of the steps in using available functionalities in an application. You won’t find any detail description of the functionalities available. SOP for similar functionalities should differ depend on the role who uses the application, hence if you have role as administrator and your friend has role as staff, SOP document that both of you accept will be different. Imagine if your companies have employee management application. You act as one of HR executive, while one of your friend, let’s called her A, works as an employee. As HR executive, you can manage all employees data, including payment, position, etc. While A as an employee, can only manage her own personal data. Thus, SOP for both of you should be different.

Let’s move on to the next topic, user guide documentation. As the name’s depict, user guide documentation describes the complete guide to the user of the application. Because it is the complete version guide of an application, there should also steps in using functionalities. Thus, user guide documentation consists of SOP, glossary of an application, complete description of available functionalities in an application. Different from SOP, user guide consists of functionalities available for each roles, that’s why several SOP can be a user guide. User guide documentation will also describes about the failure options of available functionality, and any other possible scenarios for each functionality.

Then, when should we use SOP and when should we use user guide? I think the answer will depend on the requirements of the application. In my point of view, SOP will be enough for smaller application, while user guide will be necessary for larger and wider application.

I think that’s it for now, I’ll update the post if there’s something came up to my mind later~

Cha ^^

 

Read Full Post »

IT Project Kick Off Meeting

Meet again with me~

Some days ago I did kick off meeting with the development team, which reminds me that I also can share about it here.

I believe that some of you have been familiar with kick off meeting term by now. Kick off meeting is the beginning of the development of an IT project. Kick off meeting means the project will be introduced to team member and shareholder. By conducting kick off meeting, smooth and deep understanding about the project is expected. Kick off meeting shouldn’t describe about the project in very detailed manner. Kick off meeting attendant will only describe what is the project all about, the project scope, project purpose, team member if it has been decided before, the responsibilities of each team member, etc.  Kick off meeting can discuss about the module as a whole, attendant can also make the scope clearer by discussing with each other.

The attendant of kick off meeting is the shareholder of the project. This way, the shareholder can get to know each other better so latter the communication needed when developing the project can be executed smoothly. Each shareholder will also know which function is whose responsibilities, this way the communication of each team member should be more effective and efficient.

Kick off meeting will also discuss about the timeline of the project as a whole, so later each shareholder can remind each other when the project goes near the deadline.

I believe that not all project team member do kick off meeting before the project is started. It’s not mandatory so the project with less scale don’t have to do the kick off meeting first. But I think it’s necessary for the project with bigger scale to large scale to do this kick off meeting. Beside the functions above, project kick off meeting will also make the shareholder feel as the owner of the project, thus they’ll do better to finish the project which is regarded as their own.

Read Full Post »

Application Security vs Application Simpleness

Let me get back to my right track that is IT world first. Huf, such a hard time to share something if u don’t have enough experience ><

I get this idea to bring out the topic about Application simpleness vs Application security. Why should we tandem these two different things? Because these two are rival which influence each other. How come? Let’s get started to the main topic then~

Should get to the understanding of each terms first to compare them, so you’ll get the reasons why these things above is head to head in an application.

Application simpleness often comes along with the term usability. It’s the usability of the application, the simpleness of user interface of an application which makes common people can use the application easily. Its simpleness makes it possible for common people not to undergo any training in using the application. I choose the term common people here to describe people who not related at all to the application, or people who don’t know much about the application, or people who don’t have any or only have less knowledge in the ability and usability of the application. As the additional, I believe that the simpleness of an application can’t be significant enough if the application’s complexity is still low. You know, you can’t get the simpleness of the application only by using search engine, email, messenger, word processor, etc. You’ll know the meaning of application simpleness when using complicated applications such as ERP modules like financial, human resource, asset management, etc. You’ll realize that without having enough knowledge about the application, you can’t use the application to the fullest. I wish this explanation is good enough to make you all understand the meaning of application simpleness.

Move on to the next topic, application security. You should have understood the terms well because  almost all of us had used the application at least once. Usually, term application security gets tightly related with application data. Imagine when we have really important data to be saved in an application, unfortunately the application can be accessed worldwide through the internet. How can the application ensures that our really important data won’t be taken by some irresponsible parties? Or how can our important data not to be exchanged between another user? This is what application security all about.

So, how can application security be compared to application simpleness? You see, when using a simple application, you don’t have to go through many procedure to insert your data to the application. But of course, for the application to ensure your data security, there should be some procedures for you to insert the data. The easy example where simpleness is go head to head with the security is, when you insert many types of data to an application. Simple application will take whatever data you’ve inserted, while secure application ensures that the data you’ve inserted is correct. For example for phone number, to make it easy for the user (in relation with application simpleness), an application can take whatever value you’ll insert, but a secure application should ensure that the application should only accept number value. For higher example, we can take user’s phone number field. For simple application, whatever phone number inserted shouldn’t be processed longer, application should only save it to the database. For secure application, phone number inserted will be processed longer to the provider of phone number to check the availability and validity of inserted phone number.

Building a simple application is really important, as we can’t avoid common people who will use our application, while building a secure application is other story which like a wall that should be broken by all applications. That’s why building a simple application is good enough, but you shouldn’t forget about the security of the application. Go back to your original purpose to know which one should be higher priority, because as I described before, these two things can’t stand in the same terms.

I hope this description can be useful as usual~

Read Full Post »

IT Project Proposal

Oh well, while opening the files of my previous material when I was still university student, I found this material and it’s interesting. I think I want to share a lil bit about this matter, before my knowledge become forgettable again so.. I wish that this sharing again, can be useful for anyone who read this.

I reopen this matter because one of my friend ask me to make his project proposal while I definitely forget what the content covering the proposal. Just can remember a bit that there is of course a background, purpose, issue, but I completely forget that I ever learnt it before and of course, there were some additional parts that should be included in project proposal. Oh I forget, I talk about IT project proposal here friends~

Well, I got the material when I learnt about ITPM. It was really interesting and my lecturer was a completely clever man. He wasn’t going to give his explanation at all before we learnt the book by our own self. Such a great methods for me because that way I read my book well.. Reminiscence was such a good thing~

Following is the draft of project proposal which you can see clearly:

Ok let’s start. As I learn, there will be 2 main parts of the proposal. First is of course introduction which contains background, issues, purposes, existing and envisioned system. The second is feasibility study which contains executive summary, audience impacted, financial obligation, recommended action, general description of project which contains requirement project, project border, license, used technology, member project qualifications, member project contract, steps in making the project, WBS (Work Breakdown Structure), ganchart, project budget, issues which cause project budget to be increased. I know that it seems really complicated when you make the proposal as complete as the mentioned draft above but you can get the grasp of the project really well from whole aspects of the project itself. Especially for the budget plan, you can make a good judgement of the project if you make your proposal like the draft before.  Also you can make good estimation about the time to finish the project. I’ll try describing each parts of the proposal here. I hope my explanation can be accepted well.

In the first part, you’ll see introduction, which is a must in every formal documentation. It kinds of unuseful but really, it’s not. You can make good judgement of your own project if you make this part well. See, you can get which requirement is needed and isn’t, you can also get which part should be made easily for user, you can understand well why the functionality is needed that’s why you’ll try to develop the functionality as best as you can. I believe that many or even all of you have made the introduction part before, whether it is for your assignment or anything else so I think there is no need for me to describe this part as clear as possible.

• In background, you should give good explanation about the background as to why the project wants to be made. You can take existing environment and fact around you to make this part.
• In issues, you describe existing issues which can be solved by developing the project.
• In purposes, you describe what kind of advantages which can be obtained by developing the project.
• In existing and envisioned system, you describe the existing and envisioned system of the project which you want to develop later.

In the second part, feasibility study, you’ll cover some important matters of the project like:

• Executive summary, here you can describe the important summary of which material should be displayed in the project, which user interface is good enough for the audience of the project, which programming language will be chosen to cover the requirements of the project well, which feature should be available, etc. There is no need for you to describe each points widely, you can take only the summary of each point.
• Audience impacted, here you can describe which and how audience will be impacted with the using of the application later when the project is done.
• Financial obligation, here you can describe which component of the project that needs money, how much the money needed, so reader can understand that you give the right amount of money for the project.
• Recommended action, here you can describe what action which will be taken in accordance to agreement of the proposal.
• general description of project which contains
  • Requirement project, you can describe the requirement summary of the project which wants to be developed.
  • Project border, you can describe the border of the project in order to avoid any unnecessary enhancements later when the project is being built.
  • License, you can describe the license the tools which is used when developing the project, whether it is for documentation, language programming, database server, etc, whether the license will be paid by client or by yourself or by other parts.
  • Used technology, here you describe which technology will be used in the project like programming language, database server, user interface designer, development program tools (documentation, repository, testing tools, etc).
  • Member project qualifications, here you describe what qualifications that are needed for member of the development team, including PM, developer, tester, etc.
  • Member project contract, here you describe which contract will be done for which member in which project phase. For example, you need to contract the PM for all phases available in the project, while for tester you can contract them only for the design phase and testing phase, etc.
  • Steps in making the project, here you describe which phases will be done in developing the project, and what kind of activities will be done in each phases,
  • WBS (Work Breakdown Structure), here you display WBS diagram which contains the menu structure of the application.
  • Ganchart, here you display ganchart which describes the activities happen in each phases of the development, how many days each activities need to be completed, and dependency of each activities in the project. You can make the ganchart easily using Ms.Project.
  • Project budget, here you describes the budget needed to develop the project. You should show how much the budget needed when the project meets the expected timeline and how much the budget needed when the project is delayed. This way you know better how much the estimation of your project budget.
  • Issues which cause project budget to be increased, here you describe which activities or issues that can cause the project to be delayed.

I think that’s it my share about IT project proposal. I again hope that this article can be useful for anyone who need this. And again, my explanation above is based on my previous experience when studying only, so if you want to use the proposal for formal need, you need additional resource. Of course if there is something wrong with the share, forgive me and tell me so I can fix it~

Thanks~

 

Read Full Post »

Stakeholder of an application

Stakeholder in a project means the parties which are included in developing a project. As we know there are many stakeholders here, like project owner, PM, analyst, developer, tester, management, etc. Each stakeholder has their own role in the project. I’ll try explaining things here. See, I try to explaining things based on my own experience, and this article also one of them. If you see anything wrong about this article, please let me know so I can fix it. Thanks before~

Okay, let me divide stakeholder of IT project like following:

1. Developer team

     As the name, developer team is the stakeholder team which build the project to be an existing application. Developer team usually consists of PM, analyst, developer, tester, and support. Not all developer team has complete member, it will depend on the scale of the project and also depend on the budget of the project. We can call the developer team as the bottom line of the stakeholder, because they will build the application using programming language and etc.

2. Bridge team

     Bridge team usually consist of consultant and a representation from organization to manage the project, This representation will have role to be the bridge between the managerial and client team. While consultant will be the bridge between client team and developer team. Bridge team will fully responsible in opening and closing project phase.

3. Client team

      Client team usually consist of PIC of client who represents the client as a whole. Client team can have more than one person to conduct the communication with developer team and bridge team.

4. Managerial team

        Managerial team consists of managerial people from developer team and from client team. These managerial people mostly will only involved in the opening and closing of the project. In the middle of developing the application, managerial team will be the one who monitor the development.

5. User team

         User team is team who will use the application in the end, also called by end user. Usually user team is involved in gathering the requirement and testing the application.

I think that’s all for now about stakeholder. Share your thought here~?

Thanks~

Read Full Post »

SDLC vs RUP

I just finished writing about SDLC and RUP. Before forgetting things which I always tend to do, I should write about the difference between the two terms. I won’t explain the definition of each terms anymore here, so please check out the definition of each terms directly to related article.

1. SDLC is a software life cycle, while RUP is one of the method to develop software. So basically, in RUP there will be SDLC phases.
2. To implement SDLC, there will be many methodology used. They are waterfall, spiral, iteration, W method, V method, RUP. So basically, we can use RUP to implement SDLC.
3. There is 7 main phases in SDLC, while in RUP there is only 4 main phases.

Well, I think it’s quite clear though about the difference between both terms. I don’t know whether I can compare both of them anymore because they are totally different. I feel stupid here~ >< But I still want to share this article, because it’s possible for some people out there who still also wonder what the difference between the two. Well, I’ll try comparing methodology to build an application later then~ I should learn more..

Hope this article can be useful for all of us though, so thanks a lot for reading~

Read Full Post »

RUP ( Rational Unified Process )

Well I’m back~

After reading some article related with RUP, because actually I learned this thing in my previous university which is why I’ve forgot almost all of it. It’s kind of old though to discuss about RUP at this time but whatever, I also need to know and understand what is RUP actually. I myself often ask, what is exactly RUP, and what the difference exist between RUP and SDLC? Here is the result of my brainstorming today about RUP (hahaha, doesn’t make any sense because I don’t actually read many article about it). Well, I’ll try my best to explain this thing in my language..

RUP phases

RUP, as the acronym states, is a Rational Unified Process which is originally developed by Rational developer as a software development methodology

Based on UML, RUP organizes the development of software into four phases like appears in picture above. Each consisting of one or more executable iterations of the software at that stage of development.

• inception — where the project’s business case is stated and the team decides if the project is worth doing or if it is even possible. It is important to the process to first formulate the scope of the project and also determine what resources will be needed.
• elaboration — where the developers take a closer look at the project to determine its architecture foundation and to evaluate the architecture in relation to the project. This stage is important to the RUP because it is here that developers analyze the risks associated with changing the scope of the project or adding new technologies along the way.
• construction — where the development of the project is completed. The application design is finished and the source code is written. It is in this stage that the software is tested to determine if the project has met its goal laid out in the inception phase.
• transition — where any fine-tuning is performed. Any final adjustments can be based on user feedback, usability or installation issues.

RUP is similar in concept to Extreme Programming in that only what is useful and required is produced and the development plan is updated throughout the process. Both methods seek to develop a system of best practices in software development.

RUP represents an iterative approach that is superior for a number of reasons:

• It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project.
• Integration is not one “big bang” at the end; instead, elements are integrated progressively.
• Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
• Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
• Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
• When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
• Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
• The development process itself can be improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or schedule perspective,
  but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.

For more comprehensive reading about Unified Process itself, you can read it here.

Let’s learn together, should we~

References: many articles from google, wikipedia,

Philippe Kruchten, What Is the Rational Unified Process?
Philippe Kruchten and Kurt Bittner, How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering

Read Full Post »

Software Development Life Cycle (SDLC)

I believe that almost all IT people have heard this term at least once in their life. Software Development Life Cycle or usually called SDLC actually describe about the life cycle of an IT application. There will be some phases in building IT application. In each phase, the result from the phase before will be the resource/input for the next phase. There are 7 main phases in SDLC, they are:

• Requirement Gathering

As the name, in this phase we gather the requirements needed to build the application. How to gather them? There are many options, we can do ask the people in the field directly, gather the data that is usually used, googling, etc. We should gather as many requirements as we can so that later we can have as complete data as possible to do the next phase, that is analysis.

• Analysis

This phase includes doing the analysis for the application from the data that has been gathered in the first phase. Here we’ll get the specification of the application in detail. What module will be needed, what roles will be exist in using the application, what function needed in each module, etc. 

• Design

From requirement specification above, we should create the design of the application. Common design method that is used is UML (Unified Modelling Language) and RDD (Relational Database Design). Although the implementation of this phase is often neglected but this phase holds an important meaning in building an application. This phase can define the requirements in detailed way and therefore we can ensure that the requirements that have been defined before are really needed or not. If we make the design first, it’ll make developer build the code easier, they won’t need to think what attribute needed in an entity, what functions needed in each module, etc. A good design will determine that the application will be reliable and easy to maintain.  You should imagine an application without design. A design can act as documentation and the guideline for the development team. If there is bug later, we can also see the design documentation for easier way to fix the bugs.

• Code

In this phase we build the application by making the code. We should choose the best programming language that is matched with the application requirements. If we build web-based application, almost all programming language has had framework now, so we can choose one of the best suited framework to build the application.  The advantages if we use framework, we don’t need to build our own architecture of the application. We also can use some useful libraries that have been prepared to handle common method needed in application (connect and modify database, authentication method, validation method, etc). Later if we need additional libraries, we can directly search on the framework portal and if available we can download it directly. 

• Testing 

This phase will be done once the code has been finished. We need to do the testing as a unit/module based testing and as a whole application/requirements based testing and integration testing. Why? Because it is possible that the function which is built separately can be working well in each, but can’t be working at all when they are integrated. There are many tests that can be done once the application has been finished. You can refer here.

• Deploy

This phase includes deploying the application in client server, or in web server, whichever needed. There will be configuration and final testing activities in this phase.

• Maintenance 

This phase includes maintain the application that has been deployed. It’s also impossible that there will be bug fixing activities in this phase.

I think that’s all my share about SDLC. I may update this post later. So, hope this post can be useful for us~

Read Full Post »

Building a good user interface for IT application

Building a good user interface for IT application is easy-hard task to do. Well, for some people who is technical minded, it’s sure a hard task. For people who use the application/end-user, it’s an easy task. I’m sure that almost all of us are technical minded people since we build the application, don’t we? ^^

Build a good user interface is an important task actually, I just realized this recently. A good user interface determines the easiness of an application to use. What components are included in a user interface? Here are the list:

1. UI form component. This means the field used for each attributes in a user interface, like a textfield, combo box, radio button etc. Which field used for which component can help both the developer to ensure the possible value for each attributes. A simple guideline for choosing the best field for components for example:
   • Use textfield if an attribute can accept one simple value without limitation of possible answers (ex: name, phone number, email, etc).
   • Use text area field if an attribute can accept one long value without limitation of possible answers (ex: description, address, etc).
   • Use radio button if an attribute can accept only one value from some possible answers (ex: gender, religion, etc).
   • Use combo box if an attribute can accept some values from some possible answers (ex: hobby, specialization, etc).
2. Label of an attributes. This represents the label which will be followed by field where user can enter/choose the value of its attribute. From label, user will know what value they should enter in a field (example: name, address, phone number, email, etc). This also represent what text should be displayed in a button (save button, cancel button, print button, etc.) Deciding what text should be used to represent a field is an easy-hard task to do if the label is kind of hard to explain in short term (ex: how to represent whether a premium is added to payroll or not, whether leave will affect in leave ration or not, etc.) The easy thing to do if we find this situation is, ask others who doesn’t really know/understand what kind of application you are building. They’ll surely give nice input to you.. ^^
3. Title and description of a page. There aren’t many applications which use description to describe the functionality anymore, but either way there is still few applications which use it. In case a page doesn’t have any description, then we should choose a wise title to represent what kind of information will a user get/give in related page. Once user read the title, they’ll understand directly what kind of information they should get/give. In case a page has description, we can use it to help describing what page it is.
4. Positioning. This represent the overall layout of a page.
5. Color. This represent the overall color used in a page. We should be wise to choose what color can be used in order to make sure a page is displayed nicely and easy to use.
6. Consistency of word used. This represent choosing exact same word to describe the same thing, and also what language is used in a page. We shouldn’t use different word in displaying the same thing. We also shouldn’t use different languages in an application.

Above are some components consisting a user interface of application. Below are some best practices in making a good user interface design:

1. Make sure user interface is simple and easy to use.
2. Make it as interesting as possible without losing the functionality meaning.
3. Make sure user understand the information given/needed by the application. You can test this by asking beta user’s opinion and feedback.

I think that’s it my share about making a good user interface.

Comments, questions, feedback, critics are welcomed.. ^^

Read Full Post »