GR2 Wrapper - Designs

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 (by searching for, say, 'MacGregor faucet' or 'McCormick refrigerator').

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.

Design 1:
Top: The first design was a stretch to an extreme focusing on the illiterate audience. This design was eventually adopted into the third storyboard. The purpose is to eliminate most of the words on the screen. In the left panel, there is a diagram for each floor in a stacked formation that opens up in an accordion fashion. The right panel just shows the particular job with a list of the mechanics whom the house manager can select. Prioritization happens by selecting the drop down in the top left of the pane.

Bottom: After all of the tasks are prioritized, the house manager can see a list of the tasks and the corresponding mechanic for the task. The completed tasks are located at the bottom with check marks next to them.

Design 2:
Top: The second design is focused on dragging and dropping tasks. The existing queue of tasks are located on the left while the right list indicates what are the new tasks. The house manager can then drag and drop the new tasks directly into the existing task list.

Bottom: From there, the mechanic can see an tabulated list of jobs and update the status of each job.

Design 3:
Top: This design is focused on splitting up the tasks into relative prioritization rather than absolute prioritization by flagging the important tasks. The first screen simply has a list of the tasks with a few additional buttons. The House manager can then designate if the task is important, not as important or require additional info (e.g. order more parts).

Bottom: The following screen will showcase the tasks being split into the three lists (important, do later and parts to purchase) so that the mechanic can easily see the three sections and decide what to start with.

Design 4:
The premise of this design is to sketch out something for a small screen such as a mobile device. Behind this model is the thought that the mechanic might not be able to constantly check his/her phone throughout the day and this would help him/her to check the latest requests that need to be fixed. The left image shows all of the tasks that the mechanic might need to see and queue throughout the day. When the mechanic is done with a task, he/she will just need to click on the checkbox on the right. By double clicking on a particular task, there will be a separate card that gives more details and allows the users to enter in additional information that would be useful for fixing the repair.

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.  As a main use of the mobile web app would be to resolve the issue or comment on it, those opetions are easily available.  The user may also want more information in which case they can drill into the job by clicking the side button.  The main view will give a list of items (scrollable) and provide enough basic info to get the job done.

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.  Similarly to the other design, jobs can be drilled into by clicking on them.  The focus here is to allow a user who knows the problems well to just resolve the issues or delete them.

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.

Design 1:
In this design the jobs are organized by their progress toward completion (New Requests, Not Started Jobs, In Progress Jobs, and Completed Jobs). In the New Requests area managers can assign their workers to particular repair jobs by selecting their worker with the drop down list and then clicking the Assign button. Then the job is moved to the Not Started Jobs area. Users can change the order of jobs in the list (i.e., to visually change their priority) by clicking and dragging on the texture on the left of the job. Managers can also add notes for each job by clicking the Notes button. A window will appear with notes previously written and will allow the manager to add new notes. Workers will have a similar interface to the managers’ (except for the ability to assign workers to jobs). Clicking on the Contact Info link at the top brings the user to a new page that lists workers contact information.

Design 2:
This design organizes repair jobs by the repair area (Air Conditioning and Heating, Plumbing, Electrical, Electronic, etc). Also, upon clicking on a job, more details about that job will appear. In the picture below, clicking on the Shower not draining job will expand that job in the Plumbing section, and the user will now be able to modify worker assignments, update the job status, and add notes. The user can access contact information the same way as in design 1.

Design 3:
This design is for a tiny screen interface and potentially a touch screen phone. The design allows the user to view All the jobs or just the Important jobs by clicking on the appropriate tab. At first only basic information about each job is listed (name, location, status), but when the user clicks on a job, it is expanded and the user can add/view notes, mark the job as completed, or mark it as important. Worker assignments are not included on this interface because there is not much room. Perhaps this could be a mobile web version of the application that workers/managers may check occasionally throughout the day, assuming that they already checked the non-mobile version of the website (that has more details) at the beginning of the day or during lunch break. However, the user can view worker contact information by clicking on the Address book area. Worker names will appear with buttons next to them that allow the user to quickly call or email the worker.

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. (This prioritization is key not only for house managers so that they can more easily find important information about repair jobs but also for mechanics so that they know which jobs they should attend to first. The key here is that house manager prioritization affects the prioritization in the mechanics' view.) 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.

The checkboxes in the main panel allow multiple jobs to be selected and be operated on by a common operation (this is the aggregation pattern for increased UI efficiency). The star can be used to indicate high-vs-low priority jobs (i.e., in addition to the order of the jobs, which jobs are in the 'high priority' group vs the 'low priority' group). The exclamation point is highlighted when the application heuristically pre-determines a given repair job to be important (much like how Gmail predicts whether any given email is important).

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.