A reshape of the PhoneBook is needed to

• Keep historical records of users - institution changes, period of time when users are active members or not should all be kept.
  Examples include:
  • a student may belong to institution A and later change to institution B: right now we would lose the history of him beloguing to A as the institution relation is a single field part of the user record (design naivete).
  • A user appears in STAR and leave STAR. Years after, he joins again (has happened with Frankfurt). We have no records of that.
  • Past council representative information are lost
  • A reshape would help managing one database while providing self-consistent tools (for example, the talk allocation statstics interface currently relies on N backup copies of  the DB, each backup representing a year as a poor man's job of keeping history)
  • ...
• Ease the management of records by the spokesperson office PhoneBoook record keepr.
  A Web GUI sould be developped to easily manage the records.

Functionalities of this new GUI to be developped for the PhoneBook record keeper should include

• The first page we access (or Front page) should start with general information
  • Mulitple menu item should exists such as
    • Search user or nstitution (fuzzy match)
    • "Add User" "Add Instituion"
    • A "Select Institution" drop down should exist
  • When an institution is selected, a new page appears
    • Institutional information should be showed (general address, Phone, etc ...)
    • A list of council representative (chronologically sorted, current/active one on top) should be showed - current active should be clearly defined and visible
    • A list of users belonguing ot this institution should appear - they should be color coded (similar schem as in the shift signup i.e. authors flagged, experts, etc ...)
    • Each users should be clickable, leading to the user view (below)
    • The council respentative should be easily changed (for example, a box check would appear by the active council rep but someone else could be enabled)
    • Institution name could be changed - for example Indiana University became CEEM - this chnage would be recorded and saved (this would also be displayed as histotical information although I assume those cases are rare - we have a one handful of cases like thse in 15 years of STAR's life)
    • A [Disable] box could appear - this would globally disable the institution (hence all users as it is now). Historical records should be kept for each user as "institution leaving STAR on XXX date" as reason for losing membership at that date.
    • Everytime a major action is made (disabling the institution as a whole, changing the council reprsentative, ...) confirmation should be asked
    • ... (there may be more as we go) ...
  • If a user is selected, the user view is reached and should
    • Display all current user information - a few information should be clear( is he an author? an expert?) and this should be displayed as a color coding consistent accross the insitution list. All field could be edited and modified
    • There should be a way to move/change institution for this user - only known institutions would be allowed. If this is used, the historical records should be updated.
    • The user page should display his historical records as per to which institution he belong and when, when he was an active STAR member and what not

Opene questions

• Should the "Add User" be from the front page or the institution pan?
• How fancy do we want to be on adding a user? For example, do we try to make a fuzzy match and say "record trala below exists, are you sure you wan to add user tralala?" ?

Search capabilities

• Search should have (at least) two levels of searches
  • Cross navigation – we would see a list of users belonging to institution X below the institution history as noted above (author / non-author color coding) … clicking on name would open the user record editor - this is "a" form of search (hidden)
  • Explicit search - we need to be able to search both insitutions and user using fuzzy logic there for sure (doing it during a user add is an icing on the cake). Fuzzy search should search first/last name withour discrimination (in case of name inverssion)
• Search should have convenience features, quick links
  • Give all users who are authors
  • ... shiffters
  • ... non-authors
  • ... experts
• Advanced features may be things such as "list of authors at date XXX"