all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Orange
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On a GoToMeeting session with Alan. We were working on processes and documentation specs. Most of these ideas come from the sitepoint article we are reading. See element of time # 1226 for more details about the article. - Choose a flexibility level based on the client. Basically, we can go loose or very tight based on the client and the trust levels with the client. - Educate the clients in the process. Accommodate them without compromising the project's success. - As the project progresses, try to read what and how the client is feeling. Are they digging it, hating it, sick of it, frustrated with it? Adjust as needed. - Release multiple iterations of your project. Let people start using it and collect feedback from the usage of the products and features. It is ok if the project is not complete, showing a half done project can really help. Let people see where the project is at. - What if we get the UI (user interface) out there... basically mock-up the data (dummy data). Then get a sign-off from the client on what they are seeing and the overall visual concept. This could be proofs, graphics, plain HTML pages, and other mock-ups. No real code at this stage. Sometimes what is said on paper may not be what is really wanted and/or needed. - Keep and save your emails. This is already a kind of documentation. Here are some suggestions: 1. Write every email as if it might, one day, be read by a judge in a court case. Be careful not to be too informal. 2. Don't keep a super long chain. Think about one topic and/or related topics per email. It is ok to split them up. 3. Use the subject line well. Help you and the client know what is going on based off of the subject line. This helps you find things if you need it. - Sign-offs and versioning - Think about critical milestones along the way. Maybe think about: the original quote, project specs, schedule and work flow, and final acceptance (completion). There may be others. Get sign-offs along the way. This helps you be more confident and the client more happy. - Use sign-offs as somewhat official decisions vs. just talking and making suggestions and/or giving ideas. - Put just one person in change. Groups and committees can be a major pain. Pick someone and give them ownership. Things tend gravitate to the person who shows to be the most promising leader. - Use an agenda and then return and report on meetings and decisions. - Different document types (keep things specific and direct for a purpose): Functional Requirements, Technical Specifications. Allow your clients and other developers to read over these docs and make changes and suggestions. This is still early in the planning phase and will help capture ideas and suggestions before any coding takes place. This process will also help limit the amount of scope creep and on the fly changes that may occur. - Plan things out on paper before ever going to code. Make a plan and think through things... - Think flow, layout, navigation, use cases, scenarios, if/then's, content, and functionality. What about validation, pagination, field length, and other details? What are the cause and effects? Think of the bell curve type model - try to tackle the biggest part as a basic flow and then deal with the other exceptions. At some point, there will be a point of diminishing returns - going beyond this will ware everybody out. - Wireframes, sitemaps, flow charts, etc. We many not want to draw static lines between all pages. Make a wireframe and then setup the relationships on the fly. Use callouts to clarify and define functionality. Wireframes include blocks, specific functionality, lines, placeholders, explanations, instructions, and general flow. Don't worry about the graphics. Keep it simple and unpolished. It is ok to keep it slightly rough. Allow for changes as needed. - Early planning will help with custom verbage and names for pages, permissions, and functionality. - Functional vs. Technical Specifications - Functional = how does it work? Think a general audience. Technical = IT level stuff - how, why, what, when, etc. Think about speeds, sizes, technology, languages, code, databases, protocols, and other techy stuff. This is meant for the IT and programmers as the audience. - Other possible documents (just ideas): contracts, project scope & overview document, project schedule, workflow, roles & responsibilities, phases & milestones, creative & technical briefs. Focus on the major points and get a sign-off on those. Think of hitting a target. These documents won't be needed for smaller projects. Once again, size-up the client and what is needed to protect all parties. Share these documents with the clients. This helps to get good buy-in. - Early naming convention and being consistent will really help. Try to get everyone on the same page with names, pages, features, and flow. - Using Microsoft Word is awesome for building outlines with bullets and numbering. Numbering and bullets can really help with organization and grouping of like topics. Using numbers and sections can also help later on when referring someone else to the documentation. - Word docs can help with table of contents and other formatting options. Once completed, make sure and attach those outside docs to the actual project (in adilas, that is media/content stuff). One downfall is that the Word docs are not searchable from the Adilas quick search. They are a separate doc. - To see more notes, see elements of time # 2521 for the next section on use/test cases, changes orders, etc. |