SRS Services and Programs Directory Team Minutes

From The Communities That Care WIKI

Jump to: navigation, search

May 31st Team Minutes

SRS Services and Programs Directory

Purpose of Meeting:  Fully define the desired functioning of the directory program, and we all agree on the definition.

What are the options – Community Access Network will no longer be functional as of June 30th.   An agreement is in the process of getting approval for ownership or access to the coding.  Since coding is available and has updating possibilities, there is existing money in the Greenbush contract to possibly cover the cost we will move in that direction.  If we cannot use this money, we will need to revisit how to cover the expense or what the next steps will be.  When is it going to be determined whether we can do this?  Peggy has a meeting Monday with Greenbush and LaDonna will be in attendance too to assist.  From that meeting, the cost will be determined and given to Kelly Peak to see if there are funds available.

Outcomes and Outputs Committee met yesterday.  Defined definitions and determined which programs are primary, secondary or tertiary prevention.

Qualities of a Learning Conversation – help ourselves to get into detailed thinking.  This is a process for evoking the collective intelligence in the room.  Qualities:

  • Actively asking for input
  • Ask for feedback
  • Well structured – had a purpose
  • Common goal/purpose- shared
  • Structure the meeting (physical set up that invites participation)
  • Everyone equal
  • Perseverance – have to keep going
  • Agree to disagree
  • Coming with a positive attitude
  • Inviting people with needed knowledge
  • Clear about the purpose vs. limiting the conversation (shared drive to achieve)
  • Ok not to know something, issue of failure not an option which provides group safety
  • Having the right people to make connections
  • Taking risks

Define our wants for the Directory – what it will look like, how it will be used, etc.
Vision this is up and running, what do you see?  Basics/helpful:

  • Clean interface, easy to understand, very usable, stand alone and don’t need a manual to use/understand, simple to use.
  • Usability testing occurs before site goes up
  • Once designed, want it to be stable.  Information refreshed, design stays.
  • Not cluttered/stay focused.
  • Easy to search by John Q Public – plain language/easy to search/check boxes
  • Bare bones basic information i.e. phone #, address
  • Re-directs to emergency numbers/other state services State Agencies Resource Guide
  • Language crossover/plain language – i.e. babysitting = child care
  • ADA compliant – rollovers not considered ADA compliant for this project
  • Follows usability standards/guidelines
  • Effective user helps
  • Need to be printable and exportable to CSV
  • Capability to hyperlink from SRS home page into subsequent pages of directory rather than always to the front page
  • FAQ page – basic information and definitions
  • Be expandable (able to add records) and modifiable (able to add fields)
  • Turnaround time for changes – need to define reasonable
  • Automatic update feature functioning – need to discuss just how this works and how updated info gets into the database
  • Inventory linked to the community resource database screens for easy access
  • Greenbush participate in the messaging process for accurate communication regarding the directory
  • Provide team with prototypes as being developed
  • Site statistics (hits, visits, search passes, browsers, dates and times, measure public vs. staff visits)
  • Simple feedback survey and comment box with email address (what were you looking for that you didn’t find?; was this information helpful?; suggestions?) – where would these emails go and who would respond?  Difference between Webmaster contacts re:  site functioning and messages re:  content of resource directory
  • Search functions along two tracks – 1) services/programs  2) prevention related info
  • Click box search filters pre-defined (mock ups of service search provided)
  • Two buttons on main/home page – services and prevention information
  • One site for all, public or staff – public facing server
  • Prevention search – geographical area (county, region, institution), program, service, target group, SRS Division
  • Make it non-browser dependent/browser neutral
  • Use cascading style sheets for interface design
  • Major links will be on every page; also links page specific – page frame
  • Must be recoverable in event of a disaster or malfunction
  • Able to contain several hundred records
  • Link to SRS Access Points page on SRS public website
  • Directory to include “how to apply” info – including weblinks when appropriate
  • Translated to Spanish – initial launch and as updates occur

 

Phase 2 – how will we use the site information to plan for prevention:

  • Capacity to link to community resources/organizations – needs more definition
  • Key word of key value searches
  • Ability to add success stories by program as they become available – audio, video, text

Thinking like a programmer – if we were the programmer, what questions would we likely ask?  Can we answer the questions?  What do we know or need to know to answer the questions?  How will be know that we have achieved a common understanding and frame of reference with the programmer?

  • How much space do you think it is going to take up? (volumemetrics)  We know we will be adding fields, records
  • Who the targeted audience is?
  • What kind of computers will be used?
  • What does the researcher want/need to know?  (builds a shopping list, know who to contact, 6 prevention principles)
  • Do we need to maintain history? Needs more discussion
  • When do you expect to have it done/timeline?
  • Greenbush estimate mid-June.
  • Links page specific

Review the requirements list in triads – compare list of information from BRD to list from this meeting.  Are there things that appear not to be necessary?  Is there anything unclear?  Questions or concerns regarding the requirements?

  • “Inventory” changed to “directory”
  • Peggy has master list of changes

Identifying benchmarks and desired time frames for the next year - what benchmarks will tell us the project is moving forward appropriately?


June 4 – meet with programmers (Greenbush)
June 18 – estimate from Greenbush
June 25 – response from Kelly Peak on funds availability
July 2 pm – Meet with Greenbush on Requirements Refining Session
August 15 9:30-12:00 – meet with Greenbush on prototypes and agency review (invite Communications Team)
                  12:00-4:00 – team review
October 17 9:30-12:00 – meet with Greenbush Release 1 Version 1
November 1 – Real data given to Greenbush
November 13 pm – meet with Greenbush on pre-beta
December 1-31 – beta testing; ADA/usability; promotional communications
December 31 – Phase 1 live

January 1-June 30, 2008 – Phase II

 

--Libby 09:38, 6 June 2007 (EDT)

Personal tools