A-Naogaon.Com

Sunday, 12 August 2012

Naogaon District Map of Bangladesh

Free Mobile Software Download Sites

Naogaon District Map of Bangladesh

Free Mobile Software Download Sites

Hospitals in Bangladesh

Al-Raji Hospital Ltd.

12, Farmgate
Dhaka.
Phone:329186, 326033, 8119229

Plot: 81, Block: E, Bashundhara R/A
Dhaka.
Tel : 880 2 9891661-2
Mobile: 88 01713 046684, 88 01713 046685
Fax : 880 2 9896139

Zia Colloni, Dhaka Cantonment, Dhaka.

Bangabandhu Sheikh Mujib Medical University(BSMMU)

Shahbag, Dhaka.
PHONE : 88 02 9661051-6, 88 02 8614545-9, 88 02 8612550-4

House # 19/1, Road # 6, Dhanmondi, Dhaka - 1205,
Bangladesh.
Phone:+880 2 8651950, 8651951, 8651952, 8651953

Bangladesh Institute of Research and Rehabilitation for Diabetes, Endocrine and Metabolic Disorders (BIRDEM)

Shahbag, Dhaka, Bangladesh

Phone: 9661551-60, 8616641

Bangladesh Medical College Hospital(BMC)

Road No: 14/A, House No: 33&35
Dhanmondi R/A, Dhaka-1209, Bangladesh
Tel: 880-2-9118202, 9120792-3, 9124619, 8115843
Fax: 880-2-9125655
E-mail: bmch@bangla.net

Bangladesh Railway Hospital

Phone:502220

Barisal Medical College Hospital

Barisal.

BDR (Bangladesh Rifles) Hospital

Dhaka.

CENTRAL HOSPITAL LTD

House # 2, Road # 5, Green Road, Dhanmondi
Dhaka
Phone: +880-2-9660015-19, 017523400
Fax: +880-2-8619321
Email: chl@bol-online.com

Center for the rehabilitation of the paralysed(CRF)

Post CRP Chapin, Savar
Dhaka
Phone: +880-2-7710464-5, 7711766
Fax: +880-2-7110069
Email: crp@bangla.net

China-Bangla (JV) Ltd.

Plot# 1, Road # 7,Sector # 1, Uttara
Dhaka
Phone: 8913674, 8913606

Chittagong Medical College Hospital

Chittagong, Bangladesh.

Chittagong Metropolitan Hospital (Pvt.) Ltd

948, OR. Nizam Road
Chittagong.
Phone: 031-651242

Cholera Hospital

Mohakhali, Dhaka
Phone:8802600171-8

CMH (Combined Military Hospital)

Dhaka Cantonment

Continental Hospital Ltd.

10, Gulshan
Dhaka, Dhaka 1212
Bangladesh

City Dental College & Hospital

1085 / 1, Malibagh Chowdhury Para
Dhaka - 1219
Bangladesh.
E-mail :cdcdoza@accesstel.net
Phone : 880-2-9341662 - 4 880-2-8313305
Fax :880-2-9338470

Crescent Gastro-liver & General Hospital

22/2, Babar Road (Mirpur Road)
Dhaka
Phone: 8119775, 9117524

Crescent Hospital & Diagnostic Complex Ltd

22/2, Babar Road (Mirpur Road)
Dhaka
Phone: 8119775, 9117524

190/1, Baro Moghbazar, Wireless Railgate
Dhaka-1217, Bangladesh.
Phone : (+880-2) 9351190-1, 8314887
Fax : (+ 880-2) 9338706
E-mail : dch@bangla.net

DHAKA GENERAL HOSPITAL (PVT) LTD.

17,Hatkhola Lane, Swamibagh New Road
Dhaka
Phone: 235351, 246708
Fax : 880-2-9569455

Dhaka Medical College Hospital

Phone: 500121-6 505025-29, 502529

100 Ramna, Dhaka 1000

Dhaka National Medical Institute Hospital

53 Johnson Road,
Dhaka 1100
Tel: +880 2 233 469

Dhaka Shishu Hospital

Dhaka

Dinajpur Medical College

Dinajpur

Faridpur
Bangladesh
7800
Telephone: +880-631-62744
Fax: +880-631-62744

House # 14/E, Road-6,
Dhanmondi
Dhaka
Phone: +880-2-8617208, 9673512, 8617383
Fax: +880-2-8613567
Email: gk@citechco.net

Green Hospital

Green road
Dhaka

Ibne Sina Hospital

House # 68, Road-15/A, Dhanmondi R/A
Dhaka
Phone: +880-2-8113709, 8119513-5

Islami Bank Hospital

34-B, Outer Circular Road, South Shajahanpur
Dhaka
Phone: +880-2-8317090
Fax: +880-2-8318715
Email: ibhdhaka@aitlbd.net

Farmgate, Dhaka, Bangladesh
Tel : 8112856, 9119315

Bhagalpur, Bajitpur, Kishoregonj
Bangladesh.
Phone : 880-9423-64202 64315
Fax : 880-9423-64207

Jalalabad Ragib-Rabeya Medical College

Sunamgonj Road, Sylhet - 3100
Bangladesh
Phone: 0821 - 719096
Fax: 0821 - 719096
e-mail: office@jrrmc.edu.bd

Japan-Bangladesh Friendship Hospital

House=27, Road=114, Gulshan=2
Dhaka
Phone: 8828855, 8827575
Fax: 88-02-8826497

Jessore Medical College

Jessore, Bangladesh.

House # 1, Road # 4, Dhanmondi, Dhaka - 1205
Phone: +880-2-8610793-8, 9670210-3,
8631177, 01819-215890
E-mail: admin_lch@labaidgroup.com
marketing_lch@labaidgroup.com
hospitalcoordinator_lch@labaidgroup.com

Agargaon ( Near IDB), Dhaka.

Medinova Hospital

House # 71/A Road # 5/A, Dhanmondi R/A
Dhaka
Phone: +880-2-8620353-7, 8624907-10
Email: medinova@accesstel.net

Mitford Hospital

Mitford, Dhaka
Phone:7319002-6

METROPOLITAN MEDICAL CENTER LTD.

Mohakhali
Dhaka
Phone: 606364, 601477

Mojibunnessa Eye Hospital

House-11, Road-15(New), Dhanmondi RA
Dhaka
Phone: 9113057, 9130638

Monowara Hospital (Pvt) Ltd.

54, Siddheswari Road
Dhaka.
Phone: +880-2-8318135, 8318529
Fax: +880-2-9336595
Email: monowara@citechco.net

Mymensingh Medical College Hospital

Mymensingh, Bangladesh.

Nibedita Shishu Hospital Ltd.

111. Hair Street, Wari
Dhaka
Phone: 239473

North Bengal Medical College

JC Road, Dhanbandhi, Sirajgong
Phone: 0751-65633

People's University - Gono Bishwabiddyaloy, Institute of Health Sciences

P.O. Mirzanagar
Savar Cantonment.
Dhaka-1344, Bangladesh
E-mail : gbidyala@bdonline.com,
Fax : 880-2-7708316
Vice-Chancellor: 7708002
Registrar : 7708230

Rajshahi Medical College Hospital

Rajshahi, Bangladesh.

Rangpur Medical College

Rangpur, Bangladesh

Red Crescent Holy Famiy Hospital

Eskaton, Dhaka.
Phone: 8311721-25

Royal Hospital (Pvt) Ltd.

31, Eskaton Road
Dhaka
Phone: 8313096

Salimullah medical College Hospital

Mitford, Dhaka-1100
Bangladesh.
Tel: 7315076, 7314786
Fax: 880-2-7314786
E-mail: info@ssmc.edu

Samorita Hospital Ltd.

89/1, Panthapath
Dhaka
Phone: +880-2-9131901
Fax: +880-2-9129971
Email: samorita@bangla.net

Shahid Suhrawardi Hospital

Ser-e-Banglanagar, Collegegate
Dhaka
Phone: 9122560

Shahid Ziaur Rahman Medical College (SZMC)

Bogra, Bangladesh

25 Green Road, Pantahpath
Dhaka-1205, Phone: 8616565, 9665852

18/F West Panthapath, Dhaka - 1205, Bangladesh.
Phone No: 8159457 (10 Numbers), 8142431 (10 Numbers),
8141522(10 Numbers), 8144400(10 Numbers),
8142333(10Numbers), Operator Help -9,

Sylhet MAG Osmani Medical College

Sylhet, Bangladesh.

Plot 15, Road 71, Gulshan
Dhaka-1212.
Bangladesh
Phone:+88 2 8836444
+88 2 8836000
+88 2 8836446
Webmail:info@uhlbd.com

Universal Medical Hospital

Nurer Chala, Besides Kolotan Public School
Notun Bazar, Dhaka
Phone: 8813375

Uttara Central Hospital

Sector : 1, Uttara, Dhaka
Phone: 8911551

YAMAGATA DHAKA FRIENDSHIP HOSPITAL

6/7 Black-A, Lalmatia
Dhaka
Phone: 9129354
Fax: 880-2-9129354

Z.H. Sikder Women’s Medical Collage & Hospital (Pvt.) Ltd.

Monica Estate, Western Dhanmondi,
Dhaka-1209, Bangladesh
Telephone:(880-2) 811-5951
(880-2) 811-3313
Fax: (880-2) 811-5965
Email: Info@SikderHospital.com
Admission@SikderHospital.com

Bangladesh Government

10:56 No comments

Bangladesh Ministry

Professional css tutorial

The Planning and Development of Your Site

18:25 No comments

The Planning and Development of Your Site

In the past few years, the design community has seen an explosion of sites powered by cascading

style sheets (CSS). Highly visible brands such as Fast Company, ESPN.com, PGA, and Blogger have

all adopted CSS for the layout of their sites, delivering their compelling content through this excel-

lent Web technology. Their pages have become lighter and more accessible, while a few style sheet

files provide them with global control over the user interface of their entire site. The potential of CSS

has been well established by these mainstream sites, and the technology (which languished since its

introduction in 1996) is quickly becoming the de facto means by which a site’s design is built.

However, while CSS has been elevated to near-buzzword status, it’s important to remember that
style sheets are simply a tool to be used in the overall design and development of your Web site.
Granted, that tool is an incredibly powerful one, but it can only facilitate high-powered, profes-
sional-looking Web sites. Although using style sheets can afford you an unprecedented level of
control over your site’s design, no technology is a silver bullet. Despite what technology evange-
lists might tell you, adopting CSS won’t inherently make your site more usable, your design more
compelling, or your breath more wintergreen-fresh.

So, if we put aside the buzz for a moment, we can see that although CSS is an incredibly important
aspect of a Web site’s development, it should be viewed in the context of that site’s entire lifecycle.
In this chapter, we’ll discuss the following topics:

Understanding your project’s scope
Establishing the goals for your project
The fundamentals of information architecture
How to begin your site’s design

Establish the Scope

If we were asked to build a house, there are a few questions we’d want answered before agreeing to do
the work. How large will the house be? How many rooms? What kind of budget is allocated for this pro-
ject? All of these questions are meant to establish the scope of the construction project. It’s a means of
gathering information about the project, so that you can more intelligently assess its needs. By establish-
ing the scope of the project, we can better understand exactly how involved the project is, how long it
will take to complete, and how much it will cost — all items that are integral to any formal contract.

If you can’t tell by now, our construction metaphors aren’t exactly our strongest point. But while we
might have been snoozing through those episodes of This Old House, the parallels to the start of a Web
project are uncanny. Before firing up Photoshop or slinging one line of code, you and your client should
work together to produce a well-reasoned scope statement. This aptly named document not only deter-
mines what work will be performed throughout the duration of the project, but also implicitly defines
what work is outside the scope of the project. This is an incredibly important point. When the deadlines
are tight and the expectations high, knowing exactly what is expected of you throughout the course of
the project will keep your budget in check, and both you and your client focused.

Most frequently, the scope statement contains the following information:

Strategy. This contains some information about the goals and business needs behind the project.
Is the site you’re designing supposed to increase advertising revenue, or shore up readership
numbers? Is the project supposed to increase a site’s accessibility, or its search engine ranking?
Deliverables. These are the products that will be created over the course of the project. If your
project involves some level of site planning, will you be building a site map, or providing wire-
frames? When the project is finished, will you provide the client with all the Photoshop files
used in your designs?
Assumptions. This is all of the conditions and constraints that were used to establish the scope
and upon which all other timelines and goals are founded. Should any of these initial assump-
tions change, the scope of the project should be revised accordingly. For example, if initial client
meetings uncover only 30 pages on the site that need to be built, then the landscape (and your
estimated budget) can change rather drastically when the client informs you two weeks into the
project that it has another 300 pages it would like you to redesign.
Scope management. No matter how extensively you document your assumptions and time-

lines, someone will invariably request changes during the course of your project. Whether it’s
Murphy’s Law or bad karma, it doesn’t matter — you and your client need to acknowledge that
this change will likely occur and mutually agree upon some process for handling it. Some devel-
opers will write a separate document detailing how these changes are managed, and how the
client approves the resulting changes in schedule and budget.

This isn’t an exhaustive list, nor should it be seen as definitive. As we’ll no doubt harp at you through-
out the remainder of this book, each project has its own needs, its own goals. Because of this, each scope
statement should be tailored to reflect this.

However, it is important to remember that it is the project scope that forms the basis for whatever contract
you and your client establish. Because of this, the gathering of the requirements should be a highly collab-
orative process. You and your client should work closely together to flesh out exactly what information
should go into the scope statement. Otherwise, if you and your client have differing expectations as to
what work falls under the auspices of the project scope, then problems may arise as deadlines approach.

The Planning and Development of Your Site

Determining Roles and Responsibilities
No person is an island, and the same is especially true of Web contractors. Every project requires some
level of coordination with additional people, whether they are members of your team, or stakeholders
from the client’s company. As such, a successful project becomes less about providing a set of deliver-
ables at a specific time, and more about managing the different members of the project team. Clearly
communicating the expectations placed on every member of the project will help ensure that deadlines
are met on time, on budget, and above the client’s expectations.

At some point in your professional career, you’ll be staffed on a project where its requirements exceed
your abilities as an individual. This isn’t something to dread, however. Rather, discuss with your client
that their project’s scope requires additional resources to meet the deadlines, so that you can plan your
budget accordingly.

In either scenario, it might be helpful to sketch out a table that outlines not only the various roles dis-
tributed throughout your team, but their responsibilities as well. In the following table, we’ve banged
out a rough sketch of what the average project team might look like. Even if you’re the sole resource
working on a project, this exercise can be quite helpful. Acting in multiple roles can be quite a juggling
act throughout the duration of a contract, and a table such as this can help you identify exactly what is
required of you, and with whom you’ll need to interact.

Role

Project manager

Project sponsor

Information architect

Web designer

Web developer

Database developer

Responsibilities

The overall traffic manager,

overseeing the project’s

progress from gathering

requirements to delivery.

Works with the client sponsor

to define the scope and

requirements of the project.

This primary point-of-contact

at the client company defines

business requirements, and

provides sign-off at various

stages of the project.

Develops the site’s infrastruc-

ture and establishes interface

guidelines that are both intuitive

and scalable.

Establishes the site’s visual

design, or “look-and-feel.”

Responsible for any server-side

programming when building a

dynamic, database-driven Web site.

Builds the database that will

house the Web site’s content,

Deliverables

Scope statement (co-author); timelines.

Scope statement (co-author); creative

brief; any additional materials deemed

necessary for gathering of requirements.

Site map; wireframes.

Graphic mockups; static HTML

templates (as well as necessary

CSS/image assets); style guide.

Functional specification; application

server installation/configuration.

Data model; database installation/

configuration.

and drive other dynamic aspects

of the site.

In the first column, we’ve identified the different roles that are distributed throughout our project team.
From there, we’ve outlined a brief overview of the expectations that will be placed upon them over the
course of the project lifecycle. While it’s nearly impossible to accurately capture everything that a Web
designer is responsible for in fewer than 12 words, this brief synopsis should at least convey the most
important aspects of the role. Additionally, we’ve outlined the specific items each member will deliver
over the course of the project. These deliverables should be drawn directly from the scope of the project
and matched up to the individual best equipped to deliver them.

Also, you may notice that we’ve included a “project sponsor” on this table, which is a member of the
client organization that shepherds the project from inception to completion. While perhaps not as inte-
grated into the day-to-day execution of project goals and requirements as the rest of your team, this per-
son exercises veto power in critical decisions, defines the business needs that drive the project’s goals, and
ultimately facilitates communication between your team and other stakeholders from the client company.
As a result, this person is integral to the success of your project. Any additional information for which
they are responsible should be tracked closely, as though they were a part of your project team.

Budgeting Time and Expectations

After you’ve assessed the different needs of your project, you will be in a better position to determine

how long it will take, and exactly how much it will cost. “Time is money,” of course, but that’s rarely
more true than within the bounds of a consulting engagement. Granted, it’s a fine thing to discuss strat-
egy, scope, and staffing, but it’s your project’s budget that will determine whether or not any of those
things actually come to fruition. With a properly established budget, you can begin to add people and
technical resources to your project plan, as well as any other expenses that your project might require.

Furthermore, the amount of money allocated to a given project can limit the size of your team. Perhaps
our project plan requires two developers and one designer but funds exist only for two full-time
resources. As a result, something must go: either reduce the number of staff on our project, or reduce the
scope of the project to the point at which two people can easily handle it.

Conversely, the budget could affect the quality of our team: if the funds are not available to hire an expe-
rienced application developer, then we might need to hire a less-expensive (and perhaps less-seasoned)
resource instead. Or, if the budget is especially tight, we just might need to pick up that Perl book and
start skimming. Therefore, a solid understanding of any budgetary constraints will help us understand
the extent to which we’ll need to bootstrap our own skills or those of our team members, and how that
preparation will affect timelines.

Managing Change

Let’s say that we’re nervously eyeing the clock two hours from site launch. We’re looking at the last few
items on our to-do list and are feeling a bit pressed for time before the site’s go-live. Just then, our client
sponsor strolls up to say that his boss wants some holiday e-cards designed, and that they should go live
with the newly rebranded site (this has never happened to us, we swear). Just like that, our priorities
have been told to shift, but the project’s timelines haven’t budged an inch.

This is what is known as “scope creep” and is a part of almost every project. At some point, the require-
ments outlined at the beginning of the contract may need to be updated to reflect some new or updated
business requirement. If our project can’t adapt to our client’s needs, then we’re likely working on the

The Planning and Development of Your Site

best product they’ll never be able to use. So, while this kind of change is expected, it is very important to
know how to manage it effectively. No designer wants his or her timelines in a constant state of flux,
especially when the budget isn’t. How, then, do we manage scope creep within a project? There is no
easy answer to this question, but there are a few strategies that might be useful to keep in mind.

Introducing Sign-Off

Once a particular deliverable has been finished and presented to a client, it is usually a good idea to ask the
client to formally “sign off” on the work. This sign-off can take the form of an e-mail from the client, min-
utes from meeting notes, or preferably a physical signed document. No matter the form it takes, it should
formally document the client’s approval of what has just been delivered. By securing the client’s sign-off on
a given deliverable, the client confirms that our work meets the requirements that the client set before us.
In effect, the client is telling us, “Yes, this is what we asked you to provide for us — let’s move on.”

Some designers might call this “blazing a paper trail.” The rationale frequently is one of offloading
accountability onto our client’s shoulders: that if any future changes must occur, the fault — and
incurred cost — lies not with us as consultants, but upon the client’s revised requirements. And, on the
face of it, this thinking has a lot of appeal. Whenever possible, we should toe a hard line with the estab-
lished scope, and ensure that the agreed-upon requirements change as little as possible before the pro-
ject’s completion. Sign-off is one way to help ensure this, enabling us to point to completed work should
we ever be asked to undertake time-consuming revisions.

Viewed in a more positive (and somewhat less mercenary) note, sign-off can be a valuable means to
increase the level of collaboration between consultant and client. Sign-off provides a scheduled touchpoint
for our clients, allowing them to check in on progress made to date. In this, the client almost becomes
another member of the project team. Formalizing the approval process integrates the client’s decisions into
the project lifecycle, and increases the level of interest the client has vested in maintaining the project’s
momentum.

And on the subject of momentum, sign-off is in itself a valuable device for maintaining a sense of progress
from project inception to final delivery. Over the course of a given project, you may find that most deliver-
ables cannot be built unless another has been completed. For example, it isn’t possible to begin building
HTML templates of our designs if the mockups haven’t been finalized — or rather, the template process
becomes extremely lengthy and expensive if the design is still undergoing revision. By requiring sign-off
on a particular phase of work before the next phase can begin, you can help ensure that your work is deliv-
ered on-time and on-budget. That should make parties on both sides of the negotiating table quite happy.

Refer Frequently to the Project Scope

While the scope statement enables us to define the requirements for our project, it also implicitly estab-
lishes what is not in the agreed-upon scope — a critical point when deadlines are tight and client expec-
tations high. It’s important to have established this baseline with your client.

This is where the collaboratively authored aspect of the scope document becomes most important. By
working closely with the client at the outset of the project to define its scope, the client has a more con-
crete understanding of how that scope (and any changes to it) will affect both pricing and timelines.
That’s not to say that this will mitigate any and all potential scope changes. Rather, it will help facilitate
any later reviews of the original proposal and allow both sides of the contract to more intelligently and
openly discuss how the new changes will affect schedule and pricing.

Frame the Work Within Your Budget
From this, it’s important to remember that the project’s budget can be a valuable tool in mitigating scope
creep. Just as our scope statement helps us understand what is out of our project’s jurisdiction, so, too,
can our budget help us mitigate unnecessary changes. If there are insufficient funds for a requested
change, then the issue is quickly rendered moot.

Failing that, it’s worth discussing with our client just exactly how this change will impact the budget
and the project timelines. Frequently, the relationship between additional work and additional time or
cost is forgotten in the heat of a fast-paced project. By demonstrating that X amount of work will require
Y additional dollars at Z billable hours, we can work with our client to assess exactly how much of a pri-
ority the scope change actually is. (We were never especially good at algebra, but please bear with us.)

This might sound as though we’re trying to get out of additional work — quite the opposite, in fact (after
all, we must pay for those plane tickets to Bali). Rather, it’s our responsibility as contractors to help our
clients attach a quantitative measure of importance to that work; namely, does the amount of additional
time and funds justify the importance of this new project? Weighed in this manner, this latest work can
be assessed by our clients against the other parts of the project scope. If the scope change is ultimately
decided to be a must-have, then we can work with our client to decide how to proceed — should the
timeline and budget for the project be revised, or should some other aspect of the project be foregone to
usher in this new task.

Moving Forward

Of course, if the client is willing to alter the scope and the budget to accommodate a vital change, then we
need to be equally flexible. Much as we did before beginning the project, we need to establish the scope
for the requested change. What kind of work will it entail? How long will it take? How many resources
will it require? Once these questions have been answered, we can more accurately estimate exactly how
this scope creep will affect the project as a whole. If designing those holiday cards will require three days
of design and review, then that needs to be communicated to our client. While we might not be able to
produce what they’re asking for in the requested time, an open and frank discussion about how long this
request will take — and how it will therefore impact the larger project — will often follow.

While discussions of pricing and process are no doubt difficult ones to have with your clients, it is
extremely important to remain firm on these issues. If it helps, try not to see these discussions as a
means to protect the bottom line. Rather, every client will try to test the limits of the project’s scope; the
more you capitulate to out-of-scope requests on short notice, the more they will anticipate and expect
this behavior. This can quickly lead to projects that fly wildly off of the original specification and sched-
ule, which will in turn push back delivery dates. Neither the designer nor the client will be pleased with
this result. Therefore, maintaining a firm (but fair) line on these issues will help you meet the project
goals — and your client’s expectations — successfully.

Constant Communication
Not to sound too much like a greeting card, but communication is quite possibly the element that deter-
mines a project’s success. Conversely, the lack of effective communication can run an otherwise well-
planned project aground. As the project manager, you must remain in constant touch with your clients
about the status of the project, potential shifts in scope, upcoming delivery dates, and milestones. In
short, the more touchpoints you can maintain with your client about how the project is progressing, the
better. We’ve never been on a project that ran off-track because of too much communication. However,
we’ve definitely seen instances where insufficient contact met with disaster.

The Planning and Development of Your Site

Designer, Know Thy Goals

There’s an implied “All of Them” at the end of this section’s heading because any project carries with it a
small army of distinct (and, at times, competing) goals. The Rational Unified Process, a software project
management methodology (http://ibm.com/software/awdtools/rup/), establishes the goals for a
project by defining the Critical Success Factors, often referred to as CSFs. These factors are something like
a laundry list that will help you determine when the project has completed. Some sample CSFs might
include:

Build for-pay subscription newsletter service into site.
Increase traffic by 40 percent over 6 months.
Redesign home page to allow for rotation of 728 60 banner ads above the company logo.

There’s nothing especially surprising here, and it is, in fact, a rather modest list of business requirements
that are key to the success of the project.

Of course, things become complicated when we try to establish whose factors define a successful site. In
other words, who are the project’s “stakeholders”? Who can benefit from the project’s successful com-
pletion? Conversely, who would be affected by a less-than-successful Web site?

While a client might undertake a redesign to gain more space for advertising on a site (and therefore shore
up the company’s advertising revenue), this requirement could conflict with users that are just trying to
find a particular article buried beneath the banner ads. So, while your redesign might meet the established
business goals with flying colors, the site’s users might consider the project an unmitigated failure.

So, if business and user needs are in competition, exactly to whom are we supposed to listen? As much as
we’d like to, we can’t give you an easy answer to that question. Obviously, we can’t treat business and
user needs as an “either/or” scenario. Rather, it is our responsibility to perform a rather delicate balanc-
ing act between business and user goals, and ensure (somehow) that both are represented in the work
we ultimately produce.

Your Client’s Goals

If your project is to be of any value to the client, it must advance the client’s business objectives.
Frequently, our clients are outside of our own industry. Whether the client comes from the print indus-
try, the automotive industry, or has a small business looking to establish an online presence, they often
have little experience with the how of Web design. After all, that’s why they’re talking to us. We have
been tasked to take their particular business requirements and goals and realize them online. Of course,
the lack of industry understanding works both ways. We often have as little experience with our clients’
industries as they do with ours.

Therefore, it’s important that both sides of the equation get to know each other. When gathering require-
ments for your project, find out everything you can about the client, and the context in which the client
company operates. It’s not possible for us to know too much about the client’s industry, business, and
goals (both short- and long-term). No question is too basic. We must find out as much as we can about
the client’s industry, potential sales markets, marketing strategies, and competitors. This knowledge will
only help us as we plan and execute a project that will meet the client’s needs.

Of course, as we’re gathering this information, we should explain our own work as thoroughly and
clearly as possible. We should tell our client a story about what this Web project might look like, from

beginning to end. We can explain what we’ll be building, and what kinds of deliverables we will pro-
duce at different stages of the project. But more than explaining what we produce, we should explain
why our projects are structured as they are — we can describe why a site map is important, or why
design mockups must be finalized before any HTML can be coded. In doing so, we can demystify the
project lifecycle for our clients, and help them better understand the sequence of events that lead them to
a successful project end.

Your Audience’s Needs

If you were building a house for yourself, you could immediately dive into the planning without taking
anyone else’s goals into account. Because you’re the only person who will be living in your little shack de
résistance, you can take wild liberties with the structure, layout, and aesthetic of your house. Go on, put
the bathroom in the middle of the kitchen — we won’t tell anyone, honest. Of course, if you ever have
any guests over for dinner, you can bet that you’ll get some puzzled glances, and more than a couple
questions about what you were thinking.

However, when designing a Web site, our own needs and preferences are the last that we should con-
sider. Rather, we design for others, for our users. If we build a site supplied with world-class content,
but the user can’t figure out how to navigate beyond the home page, then we’ve failed not only our
users, but in our design as well. A successful, user-centered design can yield high traffic, a flourishing
community of satisfied users; an unusable site nets you a high degree of dissatisfaction, the size of which
will likely be inversely proportionate to the size of your audience.

Of course, unlike the guests at that ill-fated dinner party, it’s a bit more difficult to figure out what your
users want. As a result, it’s far too easy to leave them out of the equation entirely when we make plans
for our sites. Instead, we discuss our pages as a collection of features, areas of functionality, or disparate
areas of content. That can easily be a rather cold way of assessing your site — and you can bet that your
users will give you the cold shoulder, hurrying off to find a site that helps them achieve their goals,
rather than hindering them.

Creating Personas: Putting a Face to Your Audience

So, how do we make a site more usable when we’ve never met a single one of our users? Given just how
virtual our little medium is, our users are often invisible to us. So, instead of thinking of them as a face-
less mass of surfers clicking through page after page of our site, we can create personas (or user profiles)
that give our users a face. Personas are model users who can help you better understand the needs,
behavior, and goals of your users. In creating these fictitious profiles, you can better understand and
anticipate the behavior patterns of the people who will actually use your site.

Figure 1-1 shows a sample persona.

While Frank is a fabricated user, his usefulness derives from the fact that he is strategically fictitious: his
biography, aspirations, and professional goals are all drawn from trends sampled from your site’s users.
By doing so, a persona becomes a valuable guide through the planning, design, and development pro-
cess. It allows you to put a face to the otherwise faceless people who will be visiting your site, and
allows you to avoid the pitfall of basing design decisions on technical or personal biases. Rather than
asking yourself how you might navigate a certain page, you can ask yourself how your persona might do
so. It’s a tactic meant to humanize the design process, yes — but ultimately, the quality of your site will
improve, as will your users’ satisfaction with it.

The Planning and Development of Your Site

Figure 1-1: A sample persona. (We didn’t say it was going to be pretty.)

So, how do we actually create a persona? There are a number of ways to begin this process. The one you
pick will ultimately depend on the scope of the project, and the amount of energy you’re able to commit
to it.

The first (and least “time-expensive”) option is to assess what you know of your audience from various
internal sources. Examining your site’s server logs isn’t a bad place to start. These files can give you
valuable technical information about your users. At the base of it, this research will yield some impor-
tant technical demographics: you’ll be able to assess what kind of browser landscape exists in your audi-
ence and on what operating systems they view the Web. As you’ll see in later chapters, each browser has
a number of CSS bugs and rendering idiosyncrasies. Knowing what browsers you must support will
play a critical role in the development and testing of your site.

Furthermore, you might be able to glean some valuable geographic data as well. As they troll through
your site’s pages, each visitor will leave their IP address in their wake. From this bit of information, vari-
ous log analysis tools can tell you from what parts of the world your users originate. Why is this impor-
tant? If you’re building a site for an international audience, your design should be able to speak to
people of multiple languages and cultures. For example, will your site’s icons convey the same meaning
to an American audience as they would to a German one, or even to a user from Singapore? Knowing
from where your site’s audience comes is as important as knowing what your audience wants.

There are a number of log analysis tools available to you in conducting this research. AW Stats
(http://awstats.sourceforge.net) is a freely available log analyzer that can analyze log
formats for such popular Web servers as Apache’s httpd and Microsoft’s IIS. Webalizer

(www.mrunix.net/webalizer/) is a similar package, but works only with Apache log formats.
ShortStat (www.shauninman.com/mentary/past/shortstat_maintenance.php) is a PHP
application that can track various kinds of user data. These are only three such packages, and there are
dozens, if not hundreds, of alternatives available. Each has its own strengths and weaknesses, which
should be assessed according to your needs and technical requirements.

In addition to analyzing server logs, you should interview the site’s stakeholders. These are the decision
makers, the people who drive the direction of not only the site, but also the business behind it. These
people will have a strong bead on the site’s audience, and ideally have had close contact with them. As
such, they can provide valuable insight into your users’ needs, and into which areas of the site would be
most relevant to them.

Of course, the best method of creating effective personas is setting aside internal statistics and assumptions,
and actually meeting some of your users — after all, facts and figures can go only so far in identifying just
what it is that your users value. At some point, you need to set aside quantitative data for qualitative inter-
views; there is no substitute for sitting down with people who will (or currently do) use the pages you’re
designing. Talking with them about their needs and goals not only creates a vital feedback loop for you as
the site’s designer, but also helps you put real-life anecdotes and experiences behind the design decisions
you’ll be making. For example, you might poll your users on any of the following points:

Technical information. What kind of browser do they use, and on what kind of computer? How
do they use the Web? Why do they use the Web?
Customer information. How do they view the site of your company or client? Do they use it?
What do they think of the site’s competitors?
Personal information. This might include such information as age, gender, and location (for
example, urban or rural).
Design preferences. How would they define a “good” site design? While you might not ask

them to leap into an art school–esque dissection of a given site’s design, you might ask them to
tell you some of their favorite sites. Try to find out why those sites are their favorites.
Additionally, you could try to uncover what sites they like least, and why.

Of course, this isn’t a comprehensive list — the goal of any user sampling is to get as much data as possible
that will be helpful to you in your design effort. But rather than just seeing this as a data-mining initiative,
think of it as a series of conversations with real people. While demographic information and technical
statistics are vital to planning your site’s development, collecting anecdotes and quotes from actual people
will help to create a more effective persona. Remember that these are ostensibly the individuals that will be
visiting your site, and whose needs your design will need to address. When you think of them as users,
your design suffers; when you think of them as people, your site will be all the more successful.

Once you’ve collected as much data as possible, the analysis begins. By sifting through your notes,
trends should emerge. An overwhelming percentage of your users might use the Macintosh version of
Internet Explorer; a large minority of your users might be color blind, or suffer from poor vision; a high
number might be working mothers, or perhaps teachers looking to acquire professional development
credit. More than likely, your audience will be multifaceted, and could contain any or all of the above.
But no matter the spectrum that your users cover, it’s important to keep these seemingly disparate char-
acteristics in mind as you sit down to write your personas — because just like your “real” users, your
persona may not be able to be easily categorized.

The Planning and Development of Your Site

In fact, the best place to start working on your persona is probably the narrative, or the persona’s biogra-

phy. This is the meat of the persona, and is where the credibility of this virtual user is established. If you

have a gift for embellishment, this isn’t a bad time to flex those creative muscles. While you might want

to communicate your persona’s lack of technical expertise (and, in doing so, remind the developers that

your users aren’t especially Web-savvy), try to think up a few fictional details about his or her life:

Is your persona married?

Does your persona have any children?

What about hobbies? Perhaps your persona is a cigar aficionado, reads avidly, or was president

of his or her high school chess club.

All of these details might seem superfluous when your project deadlines are looming, but this extra level

of creativity can help your persona leap off the page and into the forefront of your mind while you’re

planning your site.

Once you’ve completed the narrative, add the finishing touches that will complete the picture:

Name. A real name, such as Nathan, Molly, Jon, and so on.

Age. The age of your persona.

Work environment. What kind of computer does your persona use in the office? How fast is his

or her connection to the Internet?

Technical frustrations. What does your persona find difficult about working online? What

makes him or her want to close her browser window in sheer frustration?

Photo. A photo.

Ideally, your personas should be around one to two pages long, chock-full of important details about

your users’ needs, as well as those personal details that make the personas come alive. That said, there is

no hard-and-fast rule to determine when you’re finished working on your personas. Most projects will

benefit from a relatively small number of personas; popular opinion ranges anywhere from two to seven

personas. Ultimately, you are the best judge of your project’s specific needs. By better understanding

your audience, you can then begin to assess the second most important part of your site: its content, and

how your users should access it.

Sunday, 12 August 2012

Saturday, 21 July 2012

Thursday, 28 June 2012

Hospitals in Bangladesh

Al-Raji Hospital Ltd.

12, Farmgate Dhaka. Phone:329186, 326033, 8119229

Plot: 81, Block: E, Bashundhara R/A Dhaka. Tel : 880 2 9891661-2 Mobile: 88 01713 046684, 88 01713 046685 Fax : 880 2 9896139

Zia Colloni, Dhaka Cantonment, Dhaka.

Shahbag, Dhaka. PHONE : 88 02 9661051-6, 88 02 8614545-9, 88 02 8612550-4

House # 19/1, Road # 6, Dhanmondi, Dhaka - 1205, Bangladesh. Phone:+880 2 8651950, 8651951, 8651952, 8651953

Bangladesh Institute of Research and Rehabilitation for Diabetes, Endocrine and Metabolic Disorders (BIRDEM)

Shahbag, Dhaka, Bangladesh

Phone: 9661551-60, 8616641

Road No: 14/A, House No: 33&35 Dhanmondi R/A, Dhaka-1209, Bangladesh Tel: 880-2-9118202, 9120792-3, 9124619, 8115843 Fax: 880-2-9125655 E-mail: bmch@bangla.net

Bangladesh Railway Hospital

Phone:502220

Barisal Medical College Hospital

Barisal.

BDR (Bangladesh Rifles) Hospital

Dhaka.

CENTRAL HOSPITAL LTD

House # 2, Road # 5, Green Road, Dhanmondi Dhaka Phone: +880-2-9660015-19, 017523400 Fax: +880-2-8619321 Email: chl@bol-online.com

Center for the rehabilitation of the paralysed(CRF)

Post CRP Chapin, Savar Dhaka Phone: +880-2-7710464-5, 7711766 Fax: +880-2-7110069 Email: crp@bangla.net

China-Bangla (JV) Ltd.

Plot# 1, Road # 7,Sector # 1, Uttara Dhaka Phone: 8913674, 8913606

Chittagong Medical College Hospital

Chittagong, Bangladesh.

Chittagong Metropolitan Hospital (Pvt.) Ltd

948, OR. Nizam Road Chittagong. Phone: 031-651242

Cholera Hospital

Mohakhali, Dhaka Phone:8802600171-8

CMH (Combined Military Hospital)

Dhaka Cantonment

Continental Hospital Ltd.

10, Gulshan Dhaka, Dhaka 1212 Bangladesh

1085 / 1, Malibagh Chowdhury Para Dhaka - 1219 Bangladesh. E-mail :cdcdoza@accesstel.net Phone : 880-2-9341662 - 4 880-2-8313305 Fax :880-2-9338470

Crescent Gastro-liver & General Hospital

22/2, Babar Road (Mirpur Road) Dhaka Phone: 8119775, 9117524

Crescent Hospital & Diagnostic Complex Ltd

22/2, Babar Road (Mirpur Road) Dhaka Phone: 8119775, 9117524

190/1, Baro Moghbazar, Wireless Railgate Dhaka-1217, Bangladesh. Phone : (+880-2) 9351190-1, 8314887 Fax : (+ 880-2) 9338706 E-mail : dch@bangla.net

DHAKA GENERAL HOSPITAL (PVT) LTD.

17,Hatkhola Lane, Swamibagh New Road Dhaka Phone: 235351, 246708 Fax : 880-2-9569455

Phone: 500121-6 505025-29, 502529

100 Ramna, Dhaka 1000

12, Farmgate
Dhaka.
Phone:329186, 326033, 8119229

Plot: 81, Block: E, Bashundhara R/A
Dhaka.
Tel : 880 2 9891661-2
Mobile: 88 01713 046684, 88 01713 046685
Fax : 880 2 9896139

Shahbag, Dhaka.
PHONE : 88 02 9661051-6, 88 02 8614545-9, 88 02 8612550-4

House # 19/1, Road # 6, Dhanmondi, Dhaka - 1205,
Bangladesh.
Phone:+880 2 8651950, 8651951, 8651952, 8651953

Road No: 14/A, House No: 33&35
Dhanmondi R/A, Dhaka-1209, Bangladesh
Tel: 880-2-9118202, 9120792-3, 9124619, 8115843
Fax: 880-2-9125655
E-mail: bmch@bangla.net

House # 2, Road # 5, Green Road, Dhanmondi
Dhaka
Phone: +880-2-9660015-19, 017523400
Fax: +880-2-8619321
Email: chl@bol-online.com

Post CRP Chapin, Savar
Dhaka
Phone: +880-2-7710464-5, 7711766
Fax: +880-2-7110069
Email: crp@bangla.net

Plot# 1, Road # 7,Sector # 1, Uttara
Dhaka
Phone: 8913674, 8913606

948, OR. Nizam Road
Chittagong.
Phone: 031-651242

Mohakhali, Dhaka
Phone:8802600171-8

10, Gulshan
Dhaka, Dhaka 1212
Bangladesh

1085 / 1, Malibagh Chowdhury Para
Dhaka - 1219
Bangladesh.
E-mail :cdcdoza@accesstel.net
Phone : 880-2-9341662 - 4 880-2-8313305
Fax :880-2-9338470

22/2, Babar Road (Mirpur Road)
Dhaka
Phone: 8119775, 9117524

22/2, Babar Road (Mirpur Road)
Dhaka
Phone: 8119775, 9117524

190/1, Baro Moghbazar, Wireless Railgate
Dhaka-1217, Bangladesh.
Phone : (+880-2) 9351190-1, 8314887
Fax : (+ 880-2) 9338706
E-mail : dch@bangla.net

17,Hatkhola Lane, Swamibagh New Road
Dhaka
Phone: 235351, 246708
Fax : 880-2-9569455