Searchable Tickets and more!

So I was thinking today:

We definitely need to be able to search for tickets, but how? Right now with a “filtering” system, that makes it pretty easy to isolate the ticket that you’re looking for. However, what if you don’t remember the specifications of that ticket (i.e., who owns it, when it was modified or created, whether it’s open or closed)? What if you are looking for tickets based on a certain topic? This is where it would be handy to search for tickets based on topic! So there could be some key words. I remember back in CSC207 or CSC209, we did an assignment where we had to pick out the key words to be “topics” of an excerpt of text based on the frequency of words. That same assignment could be applied to this as well. OR we could ask the user to indicate tags for the ticket and so the search can be done by tags. I would prefer the first method mainly because it means the user has less to do, which is more convenient. This is a rough mock-up of what the search bar could look like. The image is a little faint.

Another thing I may or may not have mentioned in prior blogs is the ability to choose how many tickets to display at one time. Some people may want to see all the tickets at one time. We should provide for this. This would be an “option” of the grid box where the user can either input their own value for the number of tickets or use default values such as “all”.
I wanted to integrate the options into some sort of drop down menu, but then that would call for the user to input a value in some sort of pop-up window or something of that kind. Personally, I don’t like pop-up windows. So I used radio buttons to give the user the option to show all the tickets in one page, or select a custom amount. By default it will show 10 with the first option selected.

One thing about the “save” button. We want it to save the settings of the current grid so that when that particular user signs back in, they don’t have to change the settings again. One flaw with this is that the tickets are communal. So, if somebody closes a ticket that somebody else may have been viewing, when that other person goes back to try and find it, it may be hidden by default for being closed. I propose that if there are discrepancies between the previous log in tickets and the current ticket states, some sort of update should appear for the user so that they know, “oh yeah, so-and-so closed this ticket”. These updates could also include new tickets that pertain to the settings of that user. So if I have my grid set so that I only see tickets owned by me that are open and somebody assigns me a new ticket, I will get a notification that I was assigned another ticket. Also if somebody closed a ticket I owned, then I would be notified of that so that I’m not trying to find that ticket and know that it has been closed. This can either be achieved by a pop-up window (although I hate those), or an update box that appears either on top or underneath the grid. I think that on top is better since the user will see it right away.
This is an image of an update alert. I was thinking that the box should be a shade of red, but then realized that it would seem too alarming. Let’s face it, it’s not like the monitor is about to explode. So a light blue would be more calming.

Upon clicking the “more info” link, the window should expand (sliding the ticket grid down) and give a more detailed description of the tickets that were added or removed like so:

This is it for now! Please comment on this post. I will try to have more professionally mock-ups in the future. Perhaps even in PEN. Shocking!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: