Summary of last 3 weeks of designing

Different ways to show the date created:
- A ticket should display the date that it was last modified instead of the date that it was created
- It seems more useful that the ticket’s last modified date and time is more useful to the owner of the ticket and if the ticket was never modified, then the date and time would actually be the date and time it was created. It also allows other users who are tracking that ticket to know when things are being modified to be able to determine if work on the ticket is actually progressing.
- In relation to the date and time, the ticket could also show who last modified the ticket, which may or may not be the original creator or the owner of the ticket.

How to represent age:
- using icons instead of text (Note: this could also work for ticket priority). For time, a symbol like a snail travelling and leaving a trail of goo would be cute, but perhaps too childish. I have pictures drawn in my notebook, that I will post up in a bit. Another issue with icons is it may not be specific enough for users.
- Using the actual date/time stamp. This could also be cryptic to read since this is the format for the events page.
- Using more “natural” English to tell the date and time would be most intuitive to users. Phrases such as “# minutes ago”, “# hours ago”, “yesterday”, and “# days ago” (up to 7) would be fairly intuitive to users. Any older, and the ticket will just show the date. Preferably in “Jan 14, 2009” kind of format instead of numbers.

Priority:
- Depending on how many levels of priority is necessary. I think that 3 levels of priority is sufficient and simple to have them colour coded (red, yellow, green) where red is the highest priority.
- If icons are used, they could be stars and go up to 5.
- I think that colour coded is best because it doesn’t require an extra column in the grid display.

Editing:
- What should be allowed in one edit? If you modify the wiki, does that change the date and time modified in the ticket?
- Using in-line editing is most convenient for users.

Results Thus Far:
- The “save” button at the bottom of the grid should allow users to save their preferences for filtering and column ordering. This should also be the place where all edits are saved. This way all the tickets get edited at the same time, so users can change multiple fields in multiple tickets and it will all count as one change per ticket.
- Grid layout with filtering options in the column headers.
- Wikis are created upon clicking the “more information” button on that ticket. So if you need more information, then you can create it the first time and if you just want to know if there is a wiki, then you should be able to roll over and get a small text bubble to tell you if it exists already or not (like a handy hint small text box attached to the mouse tail. I’m not sure what those are called)

Future Features:
- Drag and Drop columns and adjustable size columns
- Editable number of tickets shown per page
- Wiki ticket title synch
- Have a drop-down menu next to the column headers space to allow users to customize the columns that they want to look at.

This is just a summary and images of my mock-ups will be up soon.