Current development - 2005/8/24

Current development priorities are:

• List builder interface


• User management and sessions


• Inline event modification


• Create new event in 3 minutes wizard

List builder interface
Currently only small RSS elements can be directly stored into the database via Enterprise Mgr. Even then, there is a 8000 character limit on the size due to the use of varchar as the list storage type.
So, we need to revamp the list storage mechanism to allow:

• Unlimited list items per list


• List items can be enabled for viewing or hidden


• List items can have dynamic number of elements, though within a list the elements are the same (following a schema). Initially all lists follow the RSS 2.0schema, though the Atom schema might be worth implementing too.

We need an inline UI for creating and modifying a list. That is, if an event is being designed and they add a list field, then they can select a current list or create a new list right there and then. The list does not have to exist beforehand. I hate systems that force you to create the list first before using it.
Future: There should also be a list repository – for viewing and modifying your own set of lists, lists you have access to via the events and groups you are a member of, and other public lists.
User management and sessions
Currently I have a TEST_USER = 1 within the code ( At the top of the page is the “Hi Nic Williams | Settings | Log Out” menu that is taken from the LinkedIn website.

1. Add UI at the top of the page for users to log in, and then after they login show their name etc, using AJAX. The current text can be used for the latter html. Provide a New User link.


2. Connect this to a User database table, and manually add user Nic Williams as user 1. Change the name and test that it is displaying at the top of the page after login.


3. Remove all instances of TEST_USER from the code. Provide session support to pass the logged in UserId, or an AnonUserId if the person is not yet logged in.


4. Add another user to DB manually. Login as one user. Log out and login as the other.


5. Allow new users to register from any page, at any time. Login should happen within the same page they were already viewing, so they do not need to fear losing track of where they were. Also, email validation automatically updates the website (via a callback).


6. Logging in or creating new accounts or logging out all change the level of access a user has to different sections of the site. Upon changing the user access level, the site should automatically update. The client function that changes the access level (LogOut, LogIn, SubmitNewAcct) receives a callback that updates the different panels on the screen.


7. Collect information about new users before they have officially registered and logged in. E.g. email address, location, preferred name, events they are interested in (allowing a guess at their location), groups they are interested in, and allow them to retain this information Amazon.com style once they join.

Inline event modification

• Create a “button” div and css code. It is a slightly orange background with border, that is lighter orange when cursor over it, and very light orange when clicked. The text is in a <span> tag, this it is possible for the css to hide the text and show a background image in the div instead. Implement this in a utility class such that it calls some client JS upon clicking. The button retains its “clicked” colour until the desired functionality is completed. All references to a “button” use this button.


• Place an Edit button on the top right corner of an Event/Object (only show if user is Owner/Manager of object)


• Open a new view of the Object to the left of the Object List.


• The new view should contain Attribute edit controls instead of the Name and Input/View controls that are normally shown. For example:


• Each Attribute name should be in a transparent text box thus allowing it to be modified in place.


• (future) Each Attribute value should allow the user to change the input/value/view combination.


• Attributes can be deleted (except core attributes like Name, Date, Location) via a Delete button


• For non-votable values:


• The value can be changed. (updated as a new DE entry, not an update)


• Can be changed to “votable” via a “Allow vote” button.


• For votable values:


• Can manually close the vote via a “Close vote” button.


• Can cancel the vote via a “Cancel vote” button.


• A “Delete Event” button is added to the Object Edit Header (where the “Edit” button might have been).


• Changes are dynamically shown in the original Object View immediately after they are made by the user. These changes are temporary though, and not committed until the “Accept Changes” button (at the bottom of the Object Edit view) is pressed. The Object Edit view is then closed and the Object View shows the live, committed view of the Object and its attributes.


• The Object Edit view can be closed and changes undone via the “Cancel” button which is next to the “Accept Changes” button.

Q: should the dynamic view of the Object + its attributes show both the Data Entry/Input view of attributes – e.g. a drop down list; AND the attributes’ view states – e.g. an example of a winning vote or 3.5 stars.
Create new event in 3 minutes wizard
Whilst its nice to be able to change an Event, we want users to be able to have a new event up and running within 3 minutes or faster. This will be aided via templates for standard sets of attributes and attribute styles, and a lazy registration of the user.
Like the Inline Event Modification requirement above, whilst creating the event, a dynamic view of the event is available.
User Access to sections (and fields)

• There are 3 states of user site access: Anonymous, Unauthenticated User, and Authenticated User.


• There are 4 basic states of user event access and user group access: Guest, Member, Manager, and Owner.


• There is also a notion of time-based access for an event: Before Event, During Event and After Event. Some attributes may not be accessible nor visible before an event, such as Post-Event Rating nor Attendance attributes.

Every control on the site can be invisible or visible based upon the user site access and user event/group access status.

Users that are not Authenticated Users will be able to use the site happily and easily without requiring them to log in nor authenticate until the absolutely must.