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.