By this time, I was hoping to have had a meeting with Agile Charleston, but their group seems to be pretty inactive on LinkedIn and there is no semblance of a meeting/event schedule. Perhaps I will meet with another group and then talk about that experience, even though I am heavily interested in the Agile Charleston group. So, rather, I will focus mostly on Chapter 8 of Software Development: An Open Source Approach.
This chapter focuses on the development of user interfaces. So I'll start by just following the breakdown that the book does because it is a really good breakdown of what makes a user interface a solid user interface:
Completeness - All the steps of every use case in the design must appear on a page or group of related pages in the user interface, but no more.
Language - The language of the interface must be consistent with the language of the domain and user. All labels and user options that appear on individual pages must be consistent with their counterparts in the design document and the application's domain.
Simplicity- No page should contain too much information or too little. Each page should be pleasant to view, yet its functionality should not be buried by excessive detail or elaborate stylistics.
Navigability - Navigation within a page and among different pages should be simple, explicit, and intuitive.
Feedback and recovery - Each page must provide the user with a clear indication of what has just been done, what can be done next, and how to undo what has just been done.
Data integrity - The types and valid values for individual user data entries must be clearly indicated. The software should validity-check all data at the time of entry and the user should be required to correct errors before the data are kept in the database.
Client-server integrity - The activities of several different users who happen to be using the system at the same time must be kept separate and independent.
Security - An individual user should have access to the system's functionality, but only that functionality for which he/she is authorized.
Documentation - Every page or group of pages in the user interface should be linked to a step-by-step on-line instruction that teaches a user how that page can be used to accomplish a task.
So you may have glanced over this and may just think "well, duh", why wouldn't you do all of that whenever developing an application? No one makes an application and is happy if it has security holes or if it is not easily navigable, etc. But these things are not always easy to do. For example, in my own research we have been slowly locking down the security of our program because we had a few security holes which were problematic and those holes were part of the reason that we had not completely open sourced and released it to the public earlier on.
To make these issues easier to tackle, it is vital to adopt a policy for development. One common policy is to adopt a stringent design pattern and follow it throughout the entirety of the project. Arguably the most common design pattern utilized whenever developing an application is the model-view-controller (or MVC, for short) pattern. An image can be seen below which depicts the basic strategy for implementing MVC (image adapted from Stack Overflow):
So if a user visits your site, all they ever see is the "View". The "View" is just a way to represent all the backend information of an application in an easily-comprehensible manner - an abstraction. The "View" is typically created with some markup language (e.g. HTML) and is typically altered with some scripting language (e.g. Javascript). The creation of the view is crucial because users can easily be turned off of an application if the web frontend seems to be shoddily made - and this goes back to several of the aforementioned points about user interface design. So let's say a user interacts with the view and is expecting some change or update; this change goes to the "Controller", which I will talk about in a bit, and the "Controller" then communicates with the "Model". The "Model" is what contains the state of the application, as well as storing information in databases (hence the "MySQL" image on top of the "Model" in the image. The "Model" does not actually alter the data it contains, though - that is the job of the "Controller". When a user interacts with the application, the controller is able to perform some operation (or operations) based upon the user's input. This can result in changes in the model, as the state of the program may have changed. So the changes that were made in the model can effectively be "read" by the "Controller" and output can be sent to the user's view. But what about the bottom half of that image? First, I'd like to make a mention that that is not always present when talking about MVC schemes. This image is merely an example of MVC applied to a web-based application. That is mostly the handling of HTTP POSTs, requests, responses, etc. It acts somewhat as an adapter so no matter what browser you are using (unless it is some old version of IE, which fails to even do HTML5) to handle posts, requests, etc. If you would like to read more about this, then go here.
I'd like to take some time now to talk about security. A user should never be allowed to access information that is not needed for them specifically. This can be done through using a browser's session variable and cookies as a place of storage - or, the approach I took with my own research, initially, we matched them in a datastore by using their email as a unique identifier. Before, we had created a random, unique session ID, but we were able to work around and not use that. Regardless, though, we were doing all we could to disallow users from entering input into forms that could utilize code injection. We implemented OAuth2 and linked it to Google APIs so we know we have a secure and true Google account, use the email associated with that, and pull down information that we have created in the database, rather than having a user input their email or any kind of malicious code into a form that we then use to grab information from the datastore. Hypothetically, if we allowed users to enter their own email, they could write a SQL injection and destroy our entire database, or maybe retrieve all the information out of it. If they retrieved it all, then that could be bad in case we had sensitive information stored - encrypted or not, that is bad.
So you can easily see why a lot of forethought and a lot of time has to be dedicated to user interface design. You have to design in such a way that everything is easy to understand while also balancing security issues and usability issues. It's a game of tug-of-war that will never stop as you constantly maintain and evolve your application.
Music listened to while blogging: Kendrick Lamar and Tech N9ne
No comments:
Post a Comment