GR2 Wrapper - Designs

House manager Michael McIntyre logs on to ‘appName’ and sees all of his repair jobs in the center pane of the main dashboard. Michael decides the “broken printer” job should have a higher priority than where it is currently listed (at the end of the ‘New’ section), so he clicks and drags the event to the top of the ‘New’ section using the drag-and-drop affordance at the left of the repair job listing. Next, Michael decides to assign the “broken lightbulbs in the penthouse” job to his mechanic, Jenks. He clicks on the job, which is then highlighted, and more details about the job appear in the right pane of the dashboard.

Michael can use the ‘Assignment’ area at the bottom of the right pane of the dashboard to assign the job to a worker. At first the worker picture is blank, and the drop down list says “Job not assigned”. Michael clicks on the drop down list arrow, sees a list of all his workers, and chooses “Jenks J”. The blank picture is now replaced by a photo of Jenks, and an “Assign” button appears which Michael can push once he is ready to assign the job.

Jenks J. the McCormick Hall mechanic gets to work that morning. He logs on to ‘appName’ and notices on his dashboard (very similar to the house manager’s dashboard) that he has some new repair jobs assigned to him. (In essence, a mechanic’s dashboard focuses on presenting to the mechanic the new, active, and recently completed repair jobs assigned to that particular mechanic as opposed to presenting all repair jobs.) He notes down the jobs assigned to him in a notebook and heads out to complete the jobs. (Note: Same screenshot is used as Michael M.'s dashboard since UIs are very similar.)

Jenks realizes that he needs more light bulbs in order to repair the lights in the McCormick penthouse. Each repair job has an update log that Jenks uses to record a new update; specifically, Jenks uses it to note that the job’s progress is being blocked because he needs more light bulbs. He submits this update by filling in a text description of the update, specifying the type of update via a dropdown menu, and then clicking ‘Add Update’.

When House Manager Michael McIntyre returns from his lunch break, he logs back into ‘appName’ and notices (in the top-left corner of his dashboard) that he’s received a notification. He clicks on the notification alert to bring up a dropdown menu of notification summaries. He sees from these summaries that Jenks needs more light bulbs to proceed with the McCormick penthouse repair job.

So Michael McIntyre uses ‘appname’’s Address Book feature to bring up a searchable, filterable list of contacts and their contact information. He filters through the contacts by clicking the ‘Electrical’ Tab, finds Home Depot’s phone number, and then places a bulk order for light bulbs.
Michael McIntyre then returns to the main dashboard and in the left pane updates the light bulb job to notify Jenks he’s ordered the light bulbs and that Jenks should proceed with the job tomorrow morning.

Michael is able to log into the app and see all of the new and unassigned jobs right away.  They are ordered by time at which they came into the system.  He is able to take basic action on them such as combine duplicates, resolve or close already completed job, and assign them to a particular worker.  In order to combine duplicates, jobs may be dropped into each other or there may be check boxes for group processing.  Not shown in the image, there will be a quick and easy way to close a job which may have already been done by the time the job was seen by Michael.  Finally, jobs can be dragged and placed into a particular worker’s list.  Michael can  also see the jobs assigned to that worker that have not been closed.  

When Jenks, the house mechanic, logs into the app he is able to see the jobs assigned to him.  Instead of being ordered by timestamp, his jobs are ordered by priority which is editable by Michael, the house master.  Jenks can quickly take action by resolving the task.  For many reasons he wishes to see more info on a job.  He can do this by clicking more info.

Note: More need finding will be done to see exactly what jobs will be shown in this view.  It may be the case that the mechanic also has the option to see all incoming jobs, in which case he will also have an overview and be able to “pick up” jobs he’d like to work on.

The view for more information shows all details for a given job.  This includes information such as the reporter, time reported, location, full description, etc.  Additionally, there is a way to comment on the specific tasks.  When Jenks realizes that there are no more light bulbs, he writes a note which automatically notifies anyone following the task (in this case, it would be Jenks and Michael).  

Sketch 1: Home Page
The idea behind the home page is that Michael can easily see all of the problems associated with a particular floor. Michael sees a floor plan on the left that he can easily tab between. The design is almost folder-like so that he can move to see what problems are associated with a particular floor. Each problem will be enumerated depending on the ordering from the right panel. When Michael first logs on, the task lists will arranged based on the time the event was entered. However, he can then rearrange the tasks on the right by dragging them and dropping them in the proper order.

Simple icons are used to represent what object needs to be fixed. There is a drop down menu that the house manager can use to assign the task to. If the job is urgent, he/she can click on the exclamation point icon to signify importance.

Sketch 2: Drop down Menu
Initially, no mechanic will be assigned to a particular job. When Michael decides that Jenks should be in charge of a particular task, he can then find the picture of Jenks and select him.

Sketch 3: Address Book
In the case that Michael needs to contact an outside source, he can easily click on the phone icon (or some other address book-like icon). A list of people who are available will pop up with their name and associated profession (e.g. an electrician will have a light bulb next to his image). Michael can then click on the person and then a phone number will appear for him to call.

Sketch 4: Mechanic’s View
Jenks the Mechanic has a similar view to Michael the House Manager. He sees two panels with both the floor plan and the task list on the right. However, in the task list, he does not need to assign the task to anyone so instead there will be a modified right panel.  There is an additional icon (the hand) that allows Jenks to notify Michael when there is a need to request additional parts or that he, Jenks, needs assistance.

When he is done with a particular task, Jenks can click on the check mark to signify that the job is completed. The task will then be greyed out and diminish in size in order to allow the user to still see the task if desired, but be in an unobstructive manner.

My first stretch design is for ultra-efficiency. To accomplish this, I sketched out a command-based utility, whose GUI is like most shell/bash applications. That is, the application accepts keyboard-typed commands ('jobs' or 'assign 6 jenks') and then outputs simple, ASCII-based feedback (like a table indicating new/active/recently closed repair jobs). Ideally, such an application is ultra-efficient for experienced users. This design may give us insight into creating text-based shortcuts for our application that allows advanced users of our application to work much faster.

The output is relatively uninteresting (either ASCII tables or text as feedback); so, I have only one sketch for this design. However, here's a sample set of input commands for the application (as a regular grammar) (The '$' character preceding a word in the grammar means that the word represents a variable.).

command ::= jobs || mechanics || details || prioritize || assign || update || close || contacts || search || filter
jobs ::= jobs (new || active || closed)
details ::= details ($job_id || $mechanic_id)
prioritize ::= prioritize ($job_id) (high || med || low)
assign ::= assign ($job_id) ($mechanic_id)
update ::= update ($job_id) ($update_type) ($update_text)
close ::= close ($job_id)
contacts ::= contacts
search ::= search (jobs || contacts) (($keyword)*)
filter ::= filter (jobs || contacts) (($keyword)*)

This is the main dashboard of my initial Gmail-esque design. The idea again was to provide comprehensive details about repair jobs via the listings in the middle panel and the focused details on the right panel. However, very much like Gmail, we want these listings to also easily be searchable/filterable so that the comprehensive information can be managed, hence the large search bars/tabs on the left panel which can be used to sift through the data.

At the bottom of the right panel, house managers can assign repair jobs to mechanics (using the dropdown menu and image feedback). Also on the bottom of the right panel will be the update log, since repair jobs often require coordination among mechanics and house managers.

Alternative designs of the update logs in the Gmail-esque design.

Design #1 just displays text (the text of the update and the text of who posted the update).
This is hard to efficiently parse.

Design #2 visualizes the update log to increase comprehension. It is easier to determine who has posted a given update based on the image displayed next to the update's text.

Design #3 visualizes the update log to increase comprehension. But in this instance, instead of displaying the image of the person making the update, you display an icon representing the type of update (is this an update about blocked progress, is this an update about things being good to go?). Design #3 might be preferable to Design #2 given that the type of update may be more important to easily parse than who posted any given update.

Design #1 for the Gmail-esque application's Address Book feature is a skeuomorphic design relying on a physical address book as the metaphor (complete with spiral ring, lined paper background, and having to click the bottom corners of the notebook to "turn the page" and navigate to next/previous contacts). 

The main problem with this design is that it's inefficient. Adding search to the design increases efficiency but breaks the metaphor of using a notebook.

Gmail-esque Address Book Design #2 and #3 are much less tied to the notebook metaphor than Design #1. Both Design #2 and #3 include filters/search bars that allow you to easily sift through contact informations. The only difference is that Design #2 is more visual than Design #3 by also including visuals for each contact entry in the address book. But unlike the user interface for the main dashboard, it is not necessary for the user to see _as many_ address book entries as possible at the same time, so the visual approach (which takes up more space per contact entry) may be preferable.

See above.

My third design is another stretch design: for mobile devices (i.e., small screens). This design is an attempt to port the previous Gmail-esque design to a smaller screen. The goal then is to really nail down what is most important to display to the user (especially the mechanic user class since mobile devices are more useful to mechanics who spend most of their time away from a desk).

So the dashboard presents the most important things to a mechanic: a list of what repair jobs has been assigned to them and their other active jobs.

They can click on a job to get more details about job status/priority as well as to leave updates (the leave update button is large since it will be an often used task and we want to enhance clickability).

When a user has clicked on a job, not all the details will be displayed for the sake of saving space. But a user can click the Details button to get details and then subsequently collapse those details.

See above.

This is the first mobile design.  The focus is to present the user with the information they need and allow them to easily take action.

This was the second mobile design which focuses on efficiency.  Items can be marked and then action can be taken (shown: `mark complete`, but other actions may be available.

This design was focusing on showing the user everything they might need.  This is done in a table format.  The table headers may be used to filter by priority/assignee/etc.  Moreover, filters are available to the user on the site and action items on top.

This was a run at showing jobs in a nicer maner.  Jobs can be filtered then selected, information about the job is shown on the right.  This allows the user to quickly drill into a specific problem they're having and filter out any noise.  The view of the task could include things such as a notes/comment section, activity, etc.

This design is similar to the above design except that it takes on priority sections in the middle panel.  The view also has more focus on "activity" and notes/comments than the previous.  The focus here was layout over specific details.  There may be more actions or details noted on a specific task, but those might have been omitted here.

This was a unique design that listed all the tasks.  The tasks may have some indication of priority when they come in, or may be dragged/dropped into place.  When the manager wants to assign a job to a worker, he may drag/drop it into place.  The focus here is to allow the manager to do what he needs to do and be done with it.  He can view incoming/existing jobs and then view the jobs per worker as well.

This was an alternate for a closeup of an individual task.  Again, the focus is on another design layout opposed to complete functionality.  There may be more to this design such as `location`, `description`, `time`, etc.