Difference between revisions of "NewYork2008:PM Principles - Web Site Essentials"
| (9 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
---- | ---- | ||
| − | INITIATE | + | '''INITIATE''' |
| − | QUESTIONS TO ASK/THINGS TO THINK ABOUT | + | '''QUESTIONS TO ASK/THINGS TO THINK ABOUT''' |
*"What is the goal of the site?" | *"What is the goal of the site?" | ||
*"Why do we have a website?" | *"Why do we have a website?" | ||
| Line 27: | Line 27: | ||
*Committees can be a drain on designing a website. | *Committees can be a drain on designing a website. | ||
| − | *Web Plans: We'll commit x | + | *Web Plans: We'll commit x hours of coding. You commit y hours of content creation. We can't proceed until you're done with that. |
Trouble in defining logistics for organizations in the planning phase. | Trouble in defining logistics for organizations in the planning phase. | ||
| Line 41: | Line 41: | ||
| − | PLAN | + | '''PLAN''' |
*Set expectations as clearly as you can for developer roles, clients, deadlines, when expectations aren't meant, what the site will need. It should be on paper. | *Set expectations as clearly as you can for developer roles, clients, deadlines, when expectations aren't meant, what the site will need. It should be on paper. | ||
*The smaller the site and the smaller the budget, the more you need to deliberate in the planning process. | *The smaller the site and the smaller the budget, the more you need to deliberate in the planning process. | ||
| Line 52: | Line 52: | ||
| − | IMPLEMENTATION | + | '''IMPLEMENTATION''' |
| + | |||
You need to be able to visualize and conceptualize the project for your clients? (Specific/vague?) | You need to be able to visualize and conceptualize the project for your clients? (Specific/vague?) | ||
How do you deal with people not realizing what they got into until after the site is done? "How do you say 'holy crap'?" | How do you deal with people not realizing what they got into until after the site is done? "How do you say 'holy crap'?" | ||
How do you test site usability and navigability? | How do you test site usability and navigability? | ||
Limit the amount of reversibility. | Limit the amount of reversibility. | ||
| − | + | *Laura: The Boon of Paper Prototyping | |
Have 20-30 pages. Tests flows. | Have 20-30 pages. Tests flows. | ||
| Line 64: | Line 65: | ||
| − | CLOSE | + | '''CLOSE''' |
| − | Continuation plan | + | |
| + | '''Continuation plan''' | ||
| + | |||
Josh: You don't come to an end of a project with rises and falls of workflows. | Josh: You don't come to an end of a project with rises and falls of workflows. | ||
The Skeletal Site: Immediately posting a site and working on it to the needs of the clients (either as a demo site or as the site).-->That's how Google does their applications. | The Skeletal Site: Immediately posting a site and working on it to the needs of the clients (either as a demo site or as the site).-->That's how Google does their applications. | ||
| Line 75: | Line 78: | ||
| − | TAKE AWAYS | + | '''TAKE-AWAYS''' |
Latest revision as of 23:50, 15 January 2016
BASIC INTERNET PROJECTS
- Introductions
- Colin's Happy Story and the Flow Chart
- "What is a Database-Driven Website?" --> Site able to draw content from different database. Easier to change & update.
INITIATE
QUESTIONS TO ASK/THINGS TO THINK ABOUT
- "What is the goal of the site?"
- "Why do we have a website?"
- "Who is your audience?"
- "Who are the people generating the content?"
- "What are their tech/time capacity?"
- "What are the institutional constraints?"
- "What is the budget range? (short term vs. long term)"
- Colin: "Are you resource constrained or are you able to think of what you want and dig up the resources for them?"
- "There's a minconception that when you deliver your initial website, it's all ready and perfect. It's usually not."
- RFP (Request For Project)
- "What is fixed and/or opened?"
- Committees can be a drain on designing a website.
- Web Plans: We'll commit x hours of coding. You commit y hours of content creation. We can't proceed until you're done with that.
Trouble in defining logistics for organizations in the planning phase.
SHOULD YOU EMPOWER EVERYBODY TO CHANGE THE WEBSITE? Hierarchy in managing website. You need somebody whose job it is to maintain the site. Having a consistent person who deals with look and feel can deal with possibly disastrous consequences?
Josh: Are there certain CMSs that are better suited for the level of control you want over content creation?
PLAN
- Set expectations as clearly as you can for developer roles, clients, deadlines, when expectations aren't meant, what the site will need. It should be on paper.
- The smaller the site and the smaller the budget, the more you need to deliberate in the planning process.
- Problems occur because the people who need it didn't know it and the consultant wasn't responsible.
Sarah: The importance of transparency. Radha's CMS Nightmare
IMPLEMENTATION
You need to be able to visualize and conceptualize the project for your clients? (Specific/vague?) How do you deal with people not realizing what they got into until after the site is done? "How do you say 'holy crap'?" How do you test site usability and navigability? Limit the amount of reversibility.
- Laura: The Boon of Paper Prototyping
Have 20-30 pages. Tests flows.
CLOSE
Continuation plan
Josh: You don't come to an end of a project with rises and falls of workflows. The Skeletal Site: Immediately posting a site and working on it to the needs of the clients (either as a demo site or as the site).-->That's how Google does their applications. How long does it take to code a skeletal site. It totally depends on the content and its availability. Also, what do you do with too much content?
TAKE-AWAYS