Assignment 4

Interface Architecture Design, by Zach Tomaszewski

for ICS 667, Fall 2002, taught by Dr. Dan Suthers

• Essential Use Cases (Again)
• Interface Contexts
• Comments and Conclusions

Essential Use Cases (Again)

Here are the essential use cases again from Assignment 3:

Interface Contexts

Here are two possible interface contexts to support these uses:

The List Item Input context includes a large input field and a confirm/commit action (button). This supports my first use case: inputting a task There is also a cancel action supported, which takes the user to the List View context.

The List View context shows the tasks in the large Task List container. The action Delete supports my second use case: removing a task. The Add action takes the user to the List Item Input context.

Comments and Conclusions

Once again, actually trying to use some of these techniques, rather than only read about them, helps them sink in. These abstract prototypes/contexts are a nice bridge between the very abstract EUCs and the actual concrete interface.

However, it is certainly true that these abstract interfaces are already being influenced by ideas about the final implementation. They are not truly abstract. For instance, the reason I was motivated to separate the task input into its own context was because I know PalmPilot screens are very small. Inputting would be easier with a big field to work in, especially if I want to accept handwriting directly. Were there room, I would like to make the task list container an input field too, and input new tasks directly into the list.

Another thing is the Add action. Were this only the sheet of paper "implemenation" this design is based on, inputting and adding are one action, indivisible. Yet in a digital world, we need to alert the system that we're done inputing.

Similarily, the Delete abstract component in the List View context implies some button or implementation (though perhaps this is not necessarily the case.) Indeed, I had hoped to support a more direct manipulation of list items: simply crossing them out would remove them. There would be no need to first select them and then hit a delete button. The action would still be supported by this interface, but possibly without an visible button implementation. Yet listing a canonical abstract component in these abstract contexts implies there will be some sort of interface control implemented down the line. However, this may not always be the case. (Ideally, both modes would be supported, for those users who don't yet know that crossing-out is an option.)

Despite trying to design to avoid some of the hassles of using a digital interface, working on the interface prompted me to consider certain digital uses--such as Undo. If this application is modelled on a paper task list, crossing out an item is undoable. Though, depending on how zealous you cross things out, you can usually still read it; in the digital realm, when something is deleted, it usually leaves no trace. Is "undoing" an essential use of all paper lists? It doesn't seem so. Is it at least a use case of all digital lists that should be incorporated into the interface? I'm not really sure.

So clearly these contexts are not abstract. Yet they do help transfer the abstract EUCs into something useful by making sure each aspect of a task is mapped to or supported by the interface in some way.

This task list/scheduler has been fun to play around on, but I'm looking forward to the project!