Page History

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.