How to code ? — 5

Find a way for someone to use your code as soon as possible.

See post-4 for background.

In the last series of posts we examined what we want to do and to some extent how we want to do the bakitup application. One of the important aspects of application design is the user interface. At the end of the day, all the code we write is to enable the customer or user to be able to use the application to satisfy their need.

It so happens that people who code do not appreciate spending time understanding how an application should look in terms of usage for the end users for whom they build the applications. Often this fact is overlooked easily and may result in a very utilitarian application not getting its due recognition.

User interface is not about jazzy looking screens and menus. It is about bringing the exact function of an application in the most direct way for an user eliminating a steep learning curve for him. Imagine if Google search had some menus to navigate before you can type in the search keyword. It would have kept you away. The search bar is the most direct way to trigger a search. This ‘medium’ page I am typing on is the most direct way without any frills I can type something. No menus at the top, not too many options to care about to type a text. Of course, if you build a text editor for a power user, then it has to be like a Microsoft Word. But then a editor on the Web, free of cost, is mainly to write stories and blogs and it has to be simple and to the point.

While it may be good to design a Graphical User Interface (GUI) for bakitup, we need not and should not do it in the first round. The reason is, bakitup is a utility. It is not an application whose functionality is largely in the way it looks. Rather the importance is on what it does, which is, backup and restore. So it would be good to ensure that it delivers its function properly.

However, to allow end users to do a backup and restore, we can probably allow a Command Line Interface (CLI). CLI requires that the user type in a command to run the application. This means a normal user will never use this. It will limit the usage to computer savvy users. However, we will live with this limitation as going into developing a GUI at this point does not make us get closer to our goal of building a backup and restore application. So we will circle back on a GUI at a later point.

Coming back to the CLI for the bakitup application, the question to ask is, what are the Verbs or Actions supported by this application. In this case, backup and restore are the two Actions to be supported. So we will have the following CLI.

> bakitup -b

> bakitup -r

bakitup is the name of the application and the name of the program to run on the Windows command line.

-b is an option to tell that we want to backup the files from the folder where this command is run to an external drive.

-r is an option to tell that we want to restore the files from the external drive to the folder where this command is run.

This sounds pretty simple. However, we need to also specify the external drive. So we will add the drive name as well to the command as follows.

> bakitup -b <drive>:<folder path>

> bakitup -r <drive>:<folder path>

In the above drive denotes the external drive. The folder path denotes the folder in which the files will be backed up or restored from.

If the folder path is not provided, bakitup will create a folder called bakitup under the root folder of the given external drive and copy the files as a default behaviour.

For now we assume that the source folder from which files will be backed up will be the current folder where the command is run. Same thing applies to restore also.

In order to allow the user to run bakitup and assume it will backup files to the external drive which was given before, the user can omit the <drive>:<folder path> in subsequent runs. Internally bakitup will maintain a configuration file to store the settings of the external drive.

Now this means it may also be good to allow the user to specify one or more source folders from which files should be backed up. So that it will free up the user from the need to go to a folder and run the command.

So we will adjust the CLI as

> bakitup -b <source folder 1>,<source folder 2>,… <destination folder>

> bakitup -r <backup folder> <source folder 1>,<source folder 2>,…

The destination folder is the external drive and the path within it.

The source folders are comma separated and denote the folders from where the files will be backed up during backup and copied into during a restore. So we can assume that bakitup will store these settings internally and reuse it whenever the user runs without any source or destination folders in the command line as

> bakitup -b

> bakitup -r

When we run a restore, it would be better if the backed up files are restored onto a folder that is not the same as the ones that got backed up. This is because, the backed up copy could be older and can overwrite the more recent changes that might have happened in the source folders.

On the other hand, the user might want to restore backed up files to the same folder from which the backup was done in situations where he accidentally removed the source folder and just need a replacement from backup. To allow for this, the bakitup should warn the user on a restore that it is restoring to the same folders from which it backed up and allow the user to ‘continue’ or abort and specify a different set of folders to restore to.

The above as you see is a little detail that we missed during the initial requirement analysis phase. It is normal to add or modify our original requirements as we expand on the implementation.

As we uncover the constraints in the implementation, we will end up going back and forth between the requirements, design and implementation.

I will expand a bit more on the command line in post 6.