In the past few lessons, we've talked about how design works as an abstraction, how it is a high-level view of the product, and how it can be changed more easily than after it's been implemented. This is especially true when you're considering the user interface or UI. There's another element to this called the user experience or UX, and we'll talk about that in the next lesson. Of the two, UI and UX, UI is the more technical and objective because it interacts with the user. Security is of prime importance, but there is also the matter of consistency and design. The way the user interface operates should not be radically different from one screen to the next. Granted, screens do different things, but how the controls operate, how the information is displayed should be consistent enough so that if a user becomes accustomed to one screen, that knowledge makes another screen more understandable. In a simple example, buttons which add, delete, and edit information should appear roughly in the same place from screen to screen. The buttons should look alike and they should operate alike. The similarity in form and function can be facilitated by object-oriented programming languages and by design policies. If all grids, for example, derive from the same base class, it's easier to make them all behave the same way. One area is a bit difficult to master sometimes and that's the area of graphics. Your buttons all behave in expected ways, but they contain graphics. There must also be a consistent style among them. Take for example this button. The design has an old-fashioned, woodgrained carving look. Other buttons should have the same graphical style. Even though they might contain other images, an OK button in the same style might be something that has a woodgrained look to it. Clearly, this might seem outside a software engineer's area of responsibility. After all, this is graphics, not code. If you're uncomfortable with this aspect of design, it's time either to break out of your comfort zone or perhaps subcontract the effort. In a project I was in charge of about 20 years ago, the user interface was to be internationalized so that it could appear in six different languages. This also meant people from six different cultures would be viewing the user interface. Colors can mean different things in different cultural contexts. The subtleties were important enough that we hired a graphics design company to make sure that not only were the images consistent in style on the screens, but they would not be misinterpreted in different cultural contexts. In this particular project, we also had to go against the conventional localization design paradigm. At the time, the practice was to produce different dynamic linked libraries, DLLs, one for each intended language. The problem with this was that to change from one language to another, French to Norwegian for example, you had to close the application and restart it. We needed an interface which would change languages without that overhead. The answer was to create a database of terms used on all the screens and have columns and tables for different languages. This design brought about another advantage. Not only were we able to switch languages at the selection of a menu choice, but we were able to add new languages as the need arose. So when it came time to add Finnish to the repertoire of languages, it was only necessary to add a column to a database table and have the existing screen terms translated into that language. In truth, we hadn't accounted for the need to add languages when the screen translation system was designed; it was a happy accident that we could easily add more languages. Screen or UI design is powerful. With a handful of policies and design standards, you can influence how an entire product looks and behaves. But this comes at a price. Whereas some capability can be incrementally designed into the system, such as adding warranty claims to a system that already handles purchase orders, it's often necessary to understand the full range of UI capabilities required by the system at the outset to produce a consistent design. This means that if you need language translation, you need to know that upfront. It's rather difficult to add that in to an existing product. If you need to design your screens so that they can be used in high ambient light or by users with visual handicaps, it's best to know that from the outset. Retrofitting a design to comply with Section 508 of the Rehabilitation Act of 1973 can be costly. There's another aspect of UI design that specifically concerns security, and this has to do with unformatted user endpoint. Accepting random text from the user, such as a login ID or a password or information about a new user when establishing a new account, is a liability. SQL injection attacks are famous for using this method to gain access to a database. Here's the login screen for an application. An unprotected application might encode a SQL statement based on the inputs from select user ID from user where username equals my username and password equals myPA55word. If the user ID and password matched an entry in the user table, the ID would be returned and the user would gain access to the system. However, if the user maliciously entered the following information and the system were not protected against such mischief, the resulting SQL statement would be select user ID from user where username equals myusername and or true. And the rest would evaluate to true because it would be ignored, the -- is a comment. Unchecked free-format user input has been a bad idea for decades. Parsing user IDs and passwords for acceptable format is simple using regular expressions. Looking for clues to SQL injection is also fairly standard. This behavior can be embedded in controls which receive free-form user input so that any time a user is allowed to input free text, it's checked to ensure it doesn't create a liability. Creating design rules that all implementers must use certain screen controls go a long way towards preventing security problems. But there are some subtleties here. In an example several lessons ago, I mentioned drag-and-drop interfaces. These can also result in free-form user input, even if you think that's not the intention. You may allow a user to drag and drop a file, but what's really happening is that information from the clipboard, the name of the file, for example, is being read by the application. A malicious user could put anything there, text that is unusually long, a huge number of files, and so forth. So it does take a bit of insight and experience to identify the possible roots of attack. What we've covered in this lecture are elements of user interface design, the need-to-know, the broad outlines of UI requirements upfront, even for an incrementally developed project. There's the element of consistent appearance, which may need an outside specialist's attention. And of course, there's a matter of consistent behavior of screen forms and functions. Next, we'll turn to the matter of user experience.
