This is one in a series of articles about Time Tortoise, a Universal Windows Platform app for planning and tracking your work schedule. For more on the development of this app and the ideas behind it, see my Time Tortoise category page.
A Time Tortoise feature consists of a user interface, and one or more components to support that UI. The MVVM pattern provides a way to separate the UI from the supporting components, to help make the code more understandable, and facilitate unit testing.
In my experience, building a feature with a corresponding graphical UI is almost like building two separate features. Creating the model and view model requires writing functions that are called by other functions. Unit testing these components is straightforward, since unit tests are just another kind of function. But building the view (the UI) is different. Although there may be functions in the view layer, the main work is laying out controls in a way that is intuitive for the user. That work requires different skills, and the result is almost impossible to unit test.
This week, I’m exploring a UI paradigm that supplements graphical buttons and lists with a textual approach.
Graphical UI
For some features, the best UI is a graphical one. For Time Tortoise, that applies to all of the features that are currently implemented. For example, clicking on a list item is an intuitive way to select an activity, and a digital clock is a clear way to represent work times.
In general, a graphical UI is preferable when a user selection should lead to an immediate change in the UI. For example, clicking an activity loads a list of time segments, or clicking the Start/Stop button starts or stops the activity timer. Implementing features like this in a GUI makes an app easier to use and more interactive.
For the app developer, the trade-off with GUI implementations is the extra development time required to get the visual elements right. So it’s worth considering how a feature would work using other UI approaches.
Command-Line UI
The most basic non-graphical UI is the command line. Familiar to UNIX aficionados and power users in general, it’s a way to expose features of an application without a lot of UI work. For a sophisticated user, a command-line UI can make it easy to execute common app functions. Rather than clicking around, they can quickly type and run a command. For example, there could be a command like TimeTortoise start <ActivityName> to start timing an activity. These commands can even be automated using scripts.
A well-known disadvantage of the command-line UI is that it requires users to remember command names. A console window also isn’t optimal for presenting interactive or frequently-changing data. In the TimeTortoise start example, it might be useful to start the timer from the command line, but a running timer is better shown in a window, along with the corresponding time segments and their time totals.
Text File UI
Consider a UI that relies on the user typing commands into a text file rather than a command window. This may sound like a strange user interface, but it’s the primary way that programmers interact with a compiler. Compilers have command-line interfaces and often graphical interfaces as well, but their main purpose is to process text files.
If an app is reading user input from a text file, it makes sense to also write output to a text file. This text output is analogous to the output that appears in the console window in the command-line scenario. We could even combine the two, writing to a text file that the user then edits for subsequent reading.
One way to think about the text file UI is as a way to reuse the UI from the user’s favorite text editor. So while the app developer only has to read and write text files, the user can take advantage of copy/paste, find, scroll, auto-reload, and other features of their chosen editor.
Format
For the input text file, it’s important that the file format be easy to read and edit, but also parseable by the app. A format like XML can be parsed using standard tools, but it’s not very friendly for reading and editing. Formats like JSON and YAML have been developed to address the readability issue.
Examples
Here are a few examples of how a text file UI could be useful for Time Tortoise:
Settings
Many apps have a settings section for adjusting how the app works. It tends to have a lot of UI elements, so the developer has to create and arrange those elements in the designer. For an MVVM app, this also means creating a lot of view model properties to move the data around. To simplify the development of a settings feature, the settings could be read from a text file.
Time segments
In a time tracking app, it’s sometimes necessary for the user to manipulate the day’s time segments after they have been recorded. An input text file could facilitate bulk editing: the user could make changes in the text file, and the app could then read the result and update the database. In this scenario, the output text file could contain a comma-separated version of the data for easy copying and pasting into a spreadsheet.
Daily summary
An output text file could be used to summarize the day’s activity, with a list of time segments and time totals. Free-form notes extracted from the input file could allow the user to supplement the data with comments on the day’s work.
(Image credit: Dan Ho)
