Overview
This document details of a basic user's prefererence in the Scooby 0.2 web application. Basic user interface will entail preference such as user's account information and passwords and timezones. Eventually this will grow into a larger set of preferences which may include changing the skin/color of the web application, working hours, language, holidays, subscriptions including public calendars or publishing the user's calendar, feedback etc.
Background
TBD.
0.2 Release
Goals and Objectives
The primary goal is to have a centralized place to set preferences. This release is not a useable release for users so at this current stage only the basic requirements are needed.
High Level Use Cases
- A user would be able to change thier password every month for security reasons.
- Matthew lives in Houston and travels to San Francisco for a conference. At the conference he may not have his work machine on him and stops off at the computer lab to take a look at Scooby to see which room his lecture is going to be at. His Scooby calendar is set to Central Time, and he would like to switch the events to relate to Pacific Standard Time.
Requirements
Centralized location on the web application (ie. new page/dialogue box) to create edits to account.
User ID and Password: In the form field there needs to be a place where the user can change their user ID and password.
Timezone: In the form field there needs to be a place labeled 'Timezones' and a descriptive text that says something like, 'this is where I am located'. The user can then select from a drop down box or type in the location of where the person is, and the calendar will adjust the timeline according to the timezone. This is currently in a drop down box on the top right corner of the Chandler 0.6 and iCal calendar. The behavior should be similar.
Feedback: A link on the preferences area may be a good place to link feedback.
Assumptions
No assumtions at this time.
UI Details
See sketches and review proposals on the wiki.
Open Issues
Timezones. Review current discussion on the design list.
- We currently have an issue between the sharing layer and the
app
layer. Unless our change commits, it won't get synched. This means, I
could change an event title, my sync would run but the change doesn't
get updated to the server. Basically the changes won't get shared until
you "save" the changes. We somehow need to force the commit, perhaps by
the sharing layer telling the UI to do a commit.
Code Design
[John/Matthew to add info here] This section must be completed by the developer. Schematic of any kind (class hierarchy, object relationship) is welcome.
Use this code style for code example or anything that needs to be typed on a command line.
Special Considerations
QA / Test
API / Developer Platform
Security
Internationalization / Localization
Accessibility
UI must be accessible (Section 508).