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.

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.