|
From: Mike G. <mi...@op...> - 2003-06-25 19:33:42
|
Hello Justin, On Fri, 2003-06-20 at 23:44, > Hello Again! "Software Engineering" set our project group on sail through a > tempest and storm (so to speak). We took our share of batterings, but we`ve > all come out alive. Good to hear! > Mike, Peter, I apologize for the delayed response and status update, but I > want to let you know we`re on track for the project. For the last several > weeks of our course, we took an in depth study of System Analysis. From this > we used many tools (Data Flow Diagrams, Use Cases, Time Sequence Diagrams, > etc) to model the Take Action System, and compiled a 200 page Analysis > document. We have passed the document through the academic department for > technical review (and to meet course requirements); we would like just to > edit it before providing you with a copy (we plan to do that this coming > week). That's quite the analysis document. > Our plan for the summer is to research the environment and languages we will > use to design and code the Take Action System, coupled with changing and > adapting our analysis of the system to meet your requirements. Please note > that our academic guidelines have not changed, and we cannot deliver a > complete system before November 17. However, we look forward to working > with you in analysing and designing the system. You should look at the action components within Back-End's CVS at the moment. The standard classes and action classes have been developed since we last talked and I think you will find them both instramental to you successfully completing your project, but it is critical for us as we've had to develop some of the functionality that we were looking for for cupe.ca There is quite a lot more that can be done though, much of which we have already gone over. Not having code before the 17th isn't a problem at this point. > We have finished the Take Action Analysis Document. It has been converted > into OpenOffice and PDF formats, and placed on Richard`s server (the links > can be found below). The analysis document presents a thorough description > of the Take Action System as we see it, in terms of the data it will handle, > and its behaviour regarding the data. Please take the next four weeks to > read and review it and discuss with us by e-mail where our analysis is wrong > or lacking information. Once we are all in agreement with what the system > will do, we can proceed to designing it. > http://www.nullfusion.com/projects/files/Analysis%20Document%20Final/AnalysisDocumentFinal.pdf > http://www.nullfusion.com/projects/files/Analysis%20Document%20Final/Analysis_document_v1.sxw > (If the login prompt displays, use "projects" as username and "test" as > password). I couldn't download the star office document, but could grab the pdf file. The screen shots are a nice idea.. Could grab some from BE's eAction as well. 1.2.2.4 An invalid action item should take them to the search page or to an eAction home page and display the error there above other content. 1.2.2.5 An invalid email should return them to the form with the other information they had just filled in (but with a note at the top saying that the email address was invalid and that they need to correct it. Actually, all of the error messages and confirmation messages should return values within the template & framework of the action pages. they should never get to a blank page without link or branding information no matter what they type in. Campaigns can get floods of folks participating in them. It's important that signatures aren't lost because 200 folks (just an extreme oddball number) decide to sign up at the same time. It occurs to me that having verified that the email address that is provided upon a new registraiton is a good step. Certainly one worth taking. However, it should be something that could be overridden as I believe that there are occationally problems with this method of email verification. More importantly, one still needs to send an email to personX upon a new registration and get an affirmation that they want to join the Take Action Page. Just because I'm using a valid email doesn't mean it is mine. I didn't see this in the proposal, but it may be there. Do you have the action history page in there? So folks can see how many letters they have sent? Some groups give "points" for sending letters. An admin should be able to choose if they want the users to send any combination of email, fax, pdf, or rtf. With a cc of all info sent to a designated campaign email address. User tracking within Back-End would also be useful. Being able to know where folks were in the site before and after they signed the petition. Also site referral information. Who is sending who to the campaign. This info should be available to the administrators. This might be outside of the scope which we talked about, but Peter's done a great deal of the work that was inside the scope.. I'm also working away on integrating some of the existing petition scripts into Back-end using the new standard base classes. So much of the base functionality is likely already going to be built by the time that you get to doing the coding. The focus is going to have to move to improving the campaign tools (to know who is coming and what they are signing and providing that kind of user/effectiveness analysis).. That and making it easier for the user to participate and be remembered by the system so that they too feel like they are making a difference. A user should be able to ask for a username/password to be resent to them if they loose theirs. Should also have the option of setting a cookie to remember them in the future. Might want to add that testing should be done in the sf.net web space. These are my thoughts on this at the moment. Haven't had much time in the last week to look at this. It's a rather long document. Mike -- Mike Gifford, OpenConcept Consulting Free Software for Social Change -> http://www.openconcept.ca Featured Client: CUPE National -> http://www.cupe.ca Whoever controls the media-the images-controls the culture - A. Ginsberg |